4 ms·

Ex-Game dev here: shipped many titles on console (AAA and some zzz titles). When comes time to shipping a game, the crunches, pressure and overall stress is th

Ex-Game dev here: shipped many titles on console (AAA and some zzz titles). When comes time to shipping a game, the crunches, pressure and overall stress is through the roof. Most everything goes at that point: duct tape, hot glue, bobby pins and toad spit. And if you disagree with management over these 'not so best practices' (in order to ship faster...) they will find someone to do it and you could be out of a job. That being said I would not trade my time in that industry for anything else. It's basically the BUDs of programming (of course I'm biased) Good times!

tartoran 7y ago
What does BUDs stand for?
- kelvin0 7y ago
  https://en.wikipedia.org/wiki/United_States_Navy_SEAL_selection_and_training https://en.wikipedia.org/wiki/United_States_Navy_SEAL_select... Basic Underwater Demolition/SEAL (BUD/S) Training
alxmdev 7y ago
If anyone wants a taste of what it's like to start with a clean code base that sharply turns spaghetti when the deadline gets close, give Ludum Dare a try sometime! By the end of the 48h you're forced to choose between growing the project sustainably vs. implementing as many core features as you can before the clock runs out. Write-only programming!
avgDev 7y ago
What do you do now? I like clean code, but also understand the need of producing results. I get pleasure from creating clean, readable, commented and maintainable code. However, I understand my boss mostly doesn't care, he just wants a working product that can improve the efficiency of our business. Example: Product which ran part of our business for the last 15 years, is the worst code I have seen in my entire life. I have seen better code written in a state university. However, it did its job and generated a lot of money in the process. I think delivering glued/hacked code happens in many places.
- Bartweiss 7y ago
  My favorite insight on clean code is that the metaphor of "technical debt" is incredibly deep. It's not just "we skipped X hours of cleanup" - you can meaningfully discuss the purpose and size of the loan, interest rate, payment plan, and more. From that viewpoint, there are basically three happy cases for paying tech debt. You can treat it like a paid-off credit card, releasing code today and then paying off the principal tomorrow before you incur any interest. You can use it like a home loan, accepting that you can afford long-term interest more easily than committing all the time upfront. Or you can use it almost literally as a business loan, releasing something ugly which makes the money you'll need for services/salaries/etc to pay off the debt. In practice, most companies accrue tech debt like credit card debt or back taxes. Either they pay a fortune in interest (i.e. maintenance, dev ramp-up time, and slowed development) so they can't afford to work down the principal, or they ignore the entire problem until it grows way more expensive. The upside is that there's not much longterm cost to declare tech bankruptcy. If something can limp along until it's replaced, all the work you've been putting off can be skipped completely. Hence the godawful state of videogame code: people aren't necessarily worse about hacking things together, but they're usually coding with a clear ship date in mind, so they don't worry so much about feature requests, training new devs, or anything else long-term. (Sometimes this blows up, like when a studio wants to make a sequel to a hit game and discovers everything they've built is unusable. And post-release patching has raised the lifespan of game code a lot from the days when you pressed a master CD and walked away. But all of that is speculative: if you don't ship, or don't sell well, the code is dead anyway.)
soup10 7y ago
it usually makes sense to start hacking and slashing towards shipping anyway since 95% games have a shelf life and aren't maintained and extended much beyond the original release. By the time the next game starts production there's probably major engine and platform upgrades to contend with and a different non-overlapping set of features to support so why bother with excessively clean well architected code that won't be re-used. (Of course this is somewhat of a self-fulfilling prophecy the state of the code-base influences business decisions with regards to what will be re-used and what the next game will be)
markandrewj 7y ago
I enjoy playing games, but have long felt conflicted because of the studio practices so many AAA shops have (i.e. long hours and lack of job security). I have quite a bit of respect for studios like Klie (https://www.polygon.com/features/2013/5/29/4362838/the-birth-and-re-birth-of-klei https://www.polygon.com/features/2013/5/29/4362838/the-birth...) because of this. I wish more studios would spearhead cultural change like this, instead of waiting until they are forced by employees.
godot 7y ago
I used to work in a large FB/Mobile game studio (one of the largest) and was on a team that launched a certain FB flash-based game. It was a project that was on "crunch" from beginning to launch (about 6-9 months). Literally 3 days before launch we found a severe flaw in our client-server communication layer that didn't do what we needed (this was almost a decade ago, I no longer remember what exactly the issue was). I spent an entire day heads down rewriting the whole client-server communication architecture that day. I've been in non-game, software dev jobs after that company, and can't imagine something like this happening in any other company/industry, even in aggressive scrappy startups. Duct tape and hot glue are pretty much the norms in game industry. Like you said, I also wouldn't trade that experience for anything else, but I am also never going to get back to it.

tartoran 7y ago

What does BUDs stand for?

kelvin0 7y ago
https://en.wikipedia.org/wiki/United_States_Navy_SEAL_selection_and_training https://en.wikipedia.org/wiki/United_States_Navy_SEAL_select... Basic Underwater Demolition/SEAL (BUD/S) Training

alxmdev 7y ago

If anyone wants a taste of what it's like to start with a clean code base that sharply turns spaghetti when the deadline gets close, give Ludum Dare a try sometime! By the end of the 48h you're forced to choose between growing the project sustainably vs. implementing as many core features as you can before the clock runs out. Write-only programming!

avgDev 7y ago

What do you do now? I like clean code, but also understand the need of producing results. I get pleasure from creating clean, readable, commented and maintainable code. However, I understand my boss mostly doesn't care, he just wants a working product that can improve the efficiency of our business. Example: Product which ran part of our business for the last 15 years, is the worst code I have seen in my entire life. I have seen better code written in a state university. However, it did its job and generated a lot of money in the process. I think delivering glued/hacked code happens in many places.

Bartweiss 7y ago
My favorite insight on clean code is that the metaphor of "technical debt" is incredibly deep. It's not just "we skipped X hours of cleanup" - you can meaningfully discuss the purpose and size of the loan, interest rate, payment plan, and more. From that viewpoint, there are basically three happy cases for paying tech debt. You can treat it like a paid-off credit card, releasing code today and then paying off the principal tomorrow before you incur any interest. You can use it like a home loan, accepting that you can afford long-term interest more easily than committing all the time upfront. Or you can use it almost literally as a business loan, releasing something ugly which makes the money you'll need for services/salaries/etc to pay off the debt. In practice, most companies accrue tech debt like credit card debt or back taxes. Either they pay a fortune in interest (i.e. maintenance, dev ramp-up time, and slowed development) so they can't afford to work down the principal, or they ignore the entire problem until it grows way more expensive. The upside is that there's not much longterm cost to declare tech bankruptcy. If something can limp along until it's replaced, all the work you've been putting off can be skipped completely. Hence the godawful state of videogame code: people aren't necessarily worse about hacking things together, but they're usually coding with a clear ship date in mind, so they don't worry so much about feature requests, training new devs, or anything else long-term. (Sometimes this blows up, like when a studio wants to make a sequel to a hit game and discovers everything they've built is unusable. And post-release patching has raised the lifespan of game code a lot from the days when you pressed a master CD and walked away. But all of that is speculative: if you don't ship, or don't sell well, the code is dead anyway.)

soup10 7y ago

it usually makes sense to start hacking and slashing towards shipping anyway since 95% games have a shelf life and aren't maintained and extended much beyond the original release. By the time the next game starts production there's probably major engine and platform upgrades to contend with and a different non-overlapping set of features to support so why bother with excessively clean well architected code that won't be re-used. (Of course this is somewhat of a self-fulfilling prophecy the state of the code-base influences business decisions with regards to what will be re-used and what the next game will be)

markandrewj 7y ago

I enjoy playing games, but have long felt conflicted because of the studio practices so many AAA shops have (i.e. long hours and lack of job security). I have quite a bit of respect for studios like Klie (https://www.polygon.com/features/2013/5/29/4362838/the-birth-and-re-birth-of-klei https://www.polygon.com/features/2013/5/29/4362838/the-birth...) because of this. I wish more studios would spearhead cultural change like this, instead of waiting until they are forced by employees.

godot 7y ago

I used to work in a large FB/Mobile game studio (one of the largest) and was on a team that launched a certain FB flash-based game. It was a project that was on "crunch" from beginning to launch (about 6-9 months). Literally 3 days before launch we found a severe flaw in our client-server communication layer that didn't do what we needed (this was almost a decade ago, I no longer remember what exactly the issue was). I spent an entire day heads down rewriting the whole client-server communication architecture that day. I've been in non-game, software dev jobs after that company, and can't imagine something like this happening in any other company/industry, even in aggressive scrappy startups. Duct tape and hot glue are pretty much the norms in game industry. Like you said, I also wouldn't trade that experience for anything else, but I am also never going to get back to it.