- #BIG FAT AWESOME HOUSE PARTY GAME REWRITTEN UPDATE#
- #BIG FAT AWESOME HOUSE PARTY GAME REWRITTEN SOFTWARE#
- #BIG FAT AWESOME HOUSE PARTY GAME REWRITTEN CODE#
Which means many of the bugs you described would just never be financially beneficial to patch. 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. 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.
#BIG FAT AWESOME HOUSE PARTY GAME REWRITTEN SOFTWARE#
But even there, blaming the developers just demonstrates how little you experience you actually have with professional software development. 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. Players consistently underestimate the complexity of even minor fixes. But there is a ton of hidden work and complexity that surrounds that.Īs someone who made games for a living, there's a huge amount of unseen work that goes into even small changes. Sure, on the face of it you've just changed one arithmetic function.
#BIG FAT AWESOME HOUSE PARTY GAME REWRITTEN CODE#
But that also means adding a little more code and probably a little more documentation. Wouldn't hurt to go to a playtest and mention that it's been changed, see if anyone on the team notices.Īctually, 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. 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.) Maybe stop by the level designer's desk to make sure there weren't any baked in assumptions about player movement and space.
#BIG FAT AWESOME HOUSE PARTY GAME REWRITTEN UPDATE#
Maybe you need to update some unit tests or automated feature tests. 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. Every change needs code review, testing, a build, release (and possibly release notes). > it also does not take significant resources to fix 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. 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. Finding, root causing, and fixing bugs therefore costs lots and lots of money.
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. So in some ways, those bugs become a part of the culture. > 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. 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. I'd strongly hesitate before labeling someone incompetent because their linear algebra didn't quite do vector math correctly in every case. They may have been aware of the issue and chose to fix other, more pressing bugs first. Heck, a lot of players will feel quite clever for discovering and using abilities like that in a game.įixing bugs like that require not fixing other bugs. It's also one that doesn't impact core gameplay for most people.
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.
0 kommentar(er)
