Hacker News Reader

Comment by glacials | Hacker News Reader

These are pretty common terms in a speedrunning context and I do not believe they were meant by the author to be emotionally charged. Because speedruns often take advantage of game-breaking glitches, the extent to which the game has been literally broken is usually described with destructive terms like these. Smashing records, destroying games, obliterating levels, etc.

It makes a bit more sense if you imagine the developer's intended way to play the game being a glass bridge across a chasm, and speedrunners literally shatter the bridge and glue the pieces into a ramp that they jump a dirtbike off.

Source: I've been speedrunning for 7 years and my full-time job is in the speedrunning community

View on HN

This is one of the worst parts of the speedrunning community, imo. The constant, "This team can't program" or "bad devs" or "LOL their QA department was asleep" commentary undermines what's potentially a very awesome relationship runners could have with devs.

I've never understood this need to take pot shots at the devs while running, but it happens all the time during events like GDQ. Even when the developers are on the line chatting while the game is being played (which just seems straight up rude.) It also ignores all the complexity involved in making and shipping a game, which is definitely non-trivial.

I think the community would be more positive if the same issues did not always crop up.

Several early 3D games increased player moment speed when holding strafe and forward at the same time. (Doom, EQ, etc.) That’s just incompetence and really should be described as such.

Now some games may have intentionally copied common bugs for style reasons etc, but more often titles are just rushed out with many known bugs and or vastly insufficient QA.

Yes, that's a common issue (though typically you had to push against a wall), and it's an issue that still occurs in games today.

It's also one that doesn't impact core gameplay for most people. Heck, a lot of players will feel quite clever for discovering and using abilities like that in a game.

Fixing bugs like that require not fixing other bugs. They may have been aware of the issue and chose to fix other, more pressing bugs first. I'd strongly hesitate before labeling someone incompetent because their linear algebra didn't quite do vector math correctly in every case.

I'm also surprised to hear you describe the devs of Doom as 'incompetent', given their widespread praise in the engineering community, specifically for their code.

> Now some games may have intentionally copied common bugs for style reasons etc, but more often titles are just rushed out with many known bugs and or vastly insufficient QA.

So in some ways, those bugs become a part of the culture. That's an interesting avenue to explore, but it's an aside from my point that insulting the devs (who probably aren't the ones making decisions about QA or release schedules) undermines a relationship speedrunners could have with the developer community.

Unfortunately, QA costs money. Developers cost lots of money. Finding, root causing, and fixing bugs therefore costs lots and lots of money. You cannot just fix bugs forever, at some point you need to evaluate the current amount of money you've spent making the game and compare that to what you think you'll be able to make back on it. Does fixing that bug end up costing you more than you'll make back? Who knows, but it's a very real, complex prioritization problem that I don't think you are giving enough value or depth.

Doom was a rather groundbreaking game so it’s often given a pass for many issues. However, a famous failure like the tacoma narrows bridge collapse is less likely to be repeated in other fields. The 20th game with the same failure really is best described as incompetence. Especially if it will often be discovered within 10 seconds of playing the game and it’s not a complex fix.

> However, a famous failure like the tacoma narrows bridge collapse is less likely to be repeated in other fields.

But, if we're comparing failure modes, can you at least agree that there's a pretty significant difference between:

* The tacoma narrows bridge, where there entire bridge was totally destroyed narrowly avoiding loss of life, AND * A bug in a video game that impacts the movement speed in a not-negative way for 90% of the players?

Like, if the strafe-bug was destroy millions of dollars in infrastructure and killing people I'd be on your side. But who cares if the 20th game has the same bug that doesn't affect most players in any way?

I agree it'd be better if games had no bugs, but if I had to choose between a game being 1% more fun, or a game not-having the strafe-bug I take the game that's 1% more fun every-time.

There's a nearly infinite set of tasks that sit in front of game-devs. The first thing you learn is that everything is an opportunity cost.

Sure structure collapse is a vastly larger downside, but also vastly harder to detect and fix.

Nobody’s life is at stake in these games, but the gaming industry is both gigantic and competitive. So, a hypothetical 1% difference is enjoyment really can translate into 10’s of millions of dollars. Now, I don’t think this specific bug means a 1% drop, but it also does not take significant resources to fix.

Also, it’s not just about immersion this has real impact on game balance. Can players run away from enemy X often makes a huge difference in terms of fun. Balance assuming people are running sideways and people get stuck playing that way, balance assuming normal running and tension feels fake because they can easily escape.

Collectively obvious game bugs have killed off several game companies and represent billions in lost sales. As an industry that’s clearly extremely important even if we are just talking about entertainment.

> it also does not take significant resources to fix

This is where you are wrong. Even small fixes can destabilize builds. Every change needs code review, testing, a build, release (and possibly release notes). You need to schedule time to work on it, which means prioritization meetings and advocating why this bug should be fixed and not the other large pile of bugs.

Maybe you need to update some unit tests or automated feature tests. Maybe stop by the level designer's desk to make sure there weren't any baked in assumptions about player movement and space. Probably a good idea to chat with a gameplay designer as well to make sure it wasn't intentional (and also to validate that the fix doesn't actually make the game less fun.)

Wouldn't hurt to go to a playtest and mention that it's been changed, see if anyone on the team notices.

Actually, come to think of it, maybe you could put your fix behind a console command! Then you could quickly flip back and forth and see what you like better. But that also means adding a little more code and probably a little more documentation.

Sure, on the face of it you've just changed one arithmetic function. But there is a ton of hidden work and complexity that surrounds that.

As someone who made games for a living, there's a huge amount of unseen work that goes into even small changes. Players consistently underestimate the complexity of even minor fixes.

This this is not some obscure off by one error. You see it in basic game building tutorials. Hell, I will admit to making this mistake on an early game, but only once.

Not making the mistake in the first place should generally prevent the issue even if it was never fixed in any game ever. I am calling it incompetence specifically because it’s the kind of mistake you make when you don’t know what you’re doing.

PS: If detecting and fixing an issue like this is a significant issue for your team, that’s a much larger issue you need to deal with.

Even if that were true, fixing the kind of irrelevant bugs you describe would do far more damage to the games industry due to the cost of development (and I’m being generous here because I don’t even believe your claim that running sideways against a wall has ever caused a game studio to go bust let alone cost billions in lost sales).

You seem to believe this notion that it is possible to write bug free code. Which suggests to me you’ve never written anything serious because you’re comments are textbook examples of the Dunning-Kruger effect.

I am describing buggy games as costing billions, rather than suggesting this is the only bug that ever occurred. There are many expensive examples where excessive bugs tanked sales.

The kind of bugs that hamper game sales aren’t the kind of bugs that speed runners exploit - which is what you were originally arguing about.

Sure, some games are released buggy. But even there, blaming the developers just demonstrates how little you experience you actually have with professional software development. You think developers are really that stupid that they don’t know when their own games suck? Usually bad games get released because of financial and/or time restrictions rather than a lack of pride from developers. And often bugs will just be placed on a snag list and prioritised in order of estimated time to fix vs the severity of the bug. Which means many of the bugs you described would just never be financially beneficial to patch.

You keep talking about the monetary impact of bugs while ignoring the fact that software development is a business and thus saving will always be cut where needed. Having your development time prolonged by 12 months to fix bugs most people won’t even see is perhaps the single most expensive and unnecessary way to drive your development.

Frankly I’m astonished anyone would believe development happens the way you idealise, let alone dare to call other engineers incompetent for not writing perfect software.

It’s not a net savings if it’s costing vastly more money in sales. The tradeoff is not always obvious, and some bugs are beloved by fans, but my point is bugs have real costs. Further, excessive bugs always tank sales.

Errors with collision detection are one of the most common speed running exploits and in excess can make games unplayable. Broken quest chains are similarly exploitable, but in excess result in an unplayable mess.

Anyway, cost is really not the driver for most of these issues it’s poorly scoping what can actually be finished in a given time and budget. I have no idea what your background is in game dev, but it sounds like you don’t understand the overall development process.

> It’s not a net savings if it’s costing vastly more money in sales

I’d already addressed that when I said the kind of bugs you’re complaining about wouldn’t have an effect on sales.

> Anyway, cost is really not the driver for most of these issues it’s poorly scoping what can actually be finished in a given time and budget

That is exactly what I’d just said except you’ve overlooked that development time is still an expense.

> I have no idea what your background is in game dev, but it sounds like you don’t understand the overall development process.

Not my current role but my previous job was a lead developer. So I was not only hands on but I also had to manage workflows and budgets. Basically all the stuff you’ve just claimed I don’t understand ;)

I imagine the reason you keep getting asked about the impact of a given bug is because fixing bugs is always (and should always be, given limited time) a value proposition where the time spent fixing has to be weighed against the improvement for the average player.

This is ridiculous for so many reasons.

Comparing a minor bug with player speed calculations in an edge case scenario with the total collapse of a bridge. They are on totally different scales. One cost lives. The other is a minor inconvenience at worst. When bugs are found you triage them, and if the expected cost to fix is greater than the expected benefit gained, you don't fix it. The benefit gained from fixing an edge case movement bug like this is minimal, so it will often be left unfixed. This isn't incompetence, it's just prioritisation.

What you describe is a natural consequence of adding the side-to-side velocity to the forward-and-back velocity. It is simple to implement, fast to run, and would be completely correct with something like a spaceship, where velocity components would naturally sum up like that.

  velocity.x = (RIGHTKEY-LEFTKEY)*speed;
  velocity.y = (BACKKEY-FORWARDKEY)*speed;

The constraint it doesn't capture is that humans usually run about the same speed in any direction. To capture that constraint, you either normalize the xz components and multiply by speed or do some extra logic when perpendicular directions are input. Either way, it's slower, more complicated, and harder to get right. If it doesn't break the game, why bother?

How fast players can move is one of the core aspects of game design. So, it does break gameplay balance.

Compared to building even a 2d side scroller let alone 3D worlds it’s not meaningfully more complex or slower.

PS: For a spaceship to move like that it would need equally huge engines on all sides. A design like the space shuttle with big engines on one sides and little ones for rotation seems much more logical outside of possibility low speed zero g docking.

Quite correction

For a spaceship to accelerate like that...

> So, it does break gameplay balance

No, it alters gameplay balance, but it doesn’t break it any more than shooting your film at 24 FPS breaks the cinematic experience. At this point, it has such a storied history in video games that “fixing” the problem may make the game less fun to many people, despite being more accurate.

> So, it does break gameplay balance.

That is one way to see it, another is to add extra depth to gameplay by introducing secret areas only accessible through gaps that you can only cross if you move diagonally.

Designers often acknowledged these bugs, especially in older games. The classic Tomb Raider games, for example, has several secrets only accessible through outright breaking the engine. One very obvious example is in TR1 a health pickup is only accessible if you keep jumping upwards at a corner of a pillar which causes Lara to move forward a single unit and eventually, due to some collision bug, she teleports at the top of the pillar which is otherwise inaccessible... and the only reason you could know about this health pickup is because due to the painter's algorithm used to draw the level, sometimes under some angles the pickup is drawn in front of the pillar even though it should be invisible.

Also strafe-jumping has been a common tactic in FPS games (especially multiplayer games) to the point where games reimplement it in engines that otherwise work 'properly'.

Is it really incompetence if a tricky to pull of bug that doesn’t affect gameplay unless you specifically and deliberately use it to affect game play exists unpatched?

It’s like blaming knife manufacturers that they’re incompetent because you accidentally slice your finger while cutting vegetables. Except the kind of gameplay bugs you’re describing aren’t security vulnerabilities and can’t be used to cheat in multiplayer games (outside of speed running where these kinds of cheats are often allowed). At some point you have to accept responsibility for your own actions; you guys are deliberately trying to break games to get faster speeds so it’s hardly a surprise that you’ll find ways to break games.

It really has nothing to do with this. If the quotes you mentioned are real then I'm ashamed members of the community would speak like that towards developers. But the terminology of "destroying" a game has nothing to do with badtalking developers. This is purely about understanding a game so well that you can undermine it. See also: "tearing up the dance floor".

They're two different things; you're absolutely right that "destroyed" in this context is not meant as a slight, but your parent is also right that there is a nasty tendency in the speedrunning community to actively suggest that game developers are bad at making games.

This is not the speedrunner community, this is everybody.

Whenever this gets under my skin, I simply remember the classic: "I could place chunks of fat in a bathtub and call it art!" "Maybe, but you did not, Beuys did."

Haters gonna hate, it just shows their ignorance.

> my full-time job is in the speedrunning community Could you elaborate? This whole world is new to me.

There are a number of websites where speedrunners gather, share resources and tips, and validate their runs. (There's significant prestige in being the world record holder for a game/category.)

Additionally, there are constant charity events that are moving millions of dollars annually. For example, a week long event just closed that raised 3 million US dollars for Doctors Without Borders. Those events need staff full time to support their mission, plan for future events, etc.

I build and run Splits.io, a self-analytics tool for speedrunners. They upload basically log streams and I tell them where they can get better.

> usually described with destructive terms like these

Perhaps a way to inject some visceral excitement into an eSport. Also makes it feel like more of an accomplishment.

Reply on news.ycombinator.com