Games Industry perspective: Usually getting things done is more important. Code gets rewritten many times and features change very fast, so not much use or time to try to come up with a solution that lasts that long. Also, once a game is out a lot of the code is thrown away. Engine code usually more durable and stable but also pushed to get it out of the door as fast as possible.
back
1 comments
> Also, once a game is out
Curious, what kind of games you work on that still "get out"? I used to work on mobile, now switched to Steam "indie", and in both cases the public release is only the beginning of ongoing tweaking and support.
You're right, my work has been mostly standard (old-school?) AAA games but lately with games being developed more as a service things have changed. Nonetheless, what I meant was there's is a lot of ad-hoc code, specially in gameplay, that only really fits that particular game, so its life is fairly limited. In my experience, that code tends to just get the work done, which is good in my opinion.
> In my experience, that code tends to just get the work done, which is good in my opinion.
Not if you have to support it and build on top of the features implemented with such an ad-hoc approach.
Not the OP or in the games industry, but when Blizzard rereleased StarCraft 1, they made it a point to reproduce all the known "bugs" of the original. By this time, those are treated as part of the game.
I've heard this is true of other games as well: Street fighter (cancels I believe?) and smash (Wave dashing). Sequels reproduced bugs from earlier versions as they came to be seen as features of the gameplay.