Apologies for the delay, my instance is having problems with communities so i can’t reply with that account.
To answer the question, not anymore.
The crunch culture was a big part of me leaving.
Honestly it’s not that different in type from non-game dev houses, the difference is in the magnitude.
I understand why these things happen, the reasons just aren’t good enough for me.
Poor planning compounds with ridiculous timeframes to create an almost immutable deadline to deliver unrealistic goals.
The problem is, they’ll jump right back in to the next project and make exactly the same mistakes. At what point does it stop being mistakes and starts being “just how things are done”.
One of the main reasons this works at all is that they take young idealistic programmers who want to work in their dream industry and throw them into a cult of crunch where everyone is doing it so it must be ok or this is the price of having my dream job.
it’s certainly not all studios and it seems to have gotten marginally better at the indie to small-medium houses but it’s prevalent enough that it’s still being talked about.
When you worked in games, how did your team deal with the unplanned scenarios where a feature, or even the core game, wasn’t fun and you needed to go back to the drawing board?
On paper what you’re “supposed” to do is iterate through gameplay mechanisms and scenarios by building up the bare minimum needed to get a feel for it, then once you have something viable you proceed further along the development process.
In reality it really depends heavily on context, sometimes you find a particular scenario works fine standalone but not as a part of the whole, or some needed balancing change elsewhere breaks the fun of something established, late additions can also cause this.
but again that depends heavily on the type of game, rpg’s are more sensitive to balancing changes than racing sims for example.
Specifically we’d usually evaluate the tradeoff between how much it doesn’t work and how much work it is to “fix” it, sometimes it’d get cut completely, sometimes it’d get scaled back, sometimes we’d re-evaluate the feature/scenario for viability and make a decision after that re-evaluation and sometimes we’d just bite the bullet and work through it.
Over time you get a bit more cautious about committing to things without thinking through the potential consequences, but sometimes it just isn’t possible to see the future.
I understand the realities of managing a project like that, at the same time these kinds of things are known upfront to a degree and yet people always seem surprised that the cone of uncertainty on a project like that is huge.
As i said, i have no problem with re-use, i have a problem with saying re-use is “essential” to stopping crunch, like the management of a project like that isn’t the core of the problem.
Do you think you end up with a more realistic development timeline by remaking things you’ve already made? Your comment can end up downvoted for calling one of the most common industry practices, for very practical reasons, “cutting corners”.
Because while it’s a tool in one’s tool belt to work smarter, it is obviously not the start and end of where crunch comes from. Nor is it cutting corners.
Utter bullshit, you stop crunch with realistic timeframes and competent planning/project management.
Asset reuse could be part of that sure, but making out like it’s essential is a geometric fractal of red flags holding other, smaller, red flags.
Genuine curiosity: are you a professional game developer?
Apologies for the delay, my instance is having problems with communities so i can’t reply with that account.
To answer the question, not anymore.
The crunch culture was a big part of me leaving.
Honestly it’s not that different in type from non-game dev houses, the difference is in the magnitude.
I understand why these things happen, the reasons just aren’t good enough for me.
Poor planning compounds with ridiculous timeframes to create an almost immutable deadline to deliver unrealistic goals.
The problem is, they’ll jump right back in to the next project and make exactly the same mistakes. At what point does it stop being mistakes and starts being “just how things are done”.
One of the main reasons this works at all is that they take young idealistic programmers who want to work in their dream industry and throw them into a cult of crunch where everyone is doing it so it must be ok or this is the price of having my dream job.
it’s certainly not all studios and it seems to have gotten marginally better at the indie to small-medium houses but it’s prevalent enough that it’s still being talked about.
When you worked in games, how did your team deal with the unplanned scenarios where a feature, or even the core game, wasn’t fun and you needed to go back to the drawing board?
Depends on the team.
On paper what you’re “supposed” to do is iterate through gameplay mechanisms and scenarios by building up the bare minimum needed to get a feel for it, then once you have something viable you proceed further along the development process.
In reality it really depends heavily on context, sometimes you find a particular scenario works fine standalone but not as a part of the whole, or some needed balancing change elsewhere breaks the fun of something established, late additions can also cause this.
but again that depends heavily on the type of game, rpg’s are more sensitive to balancing changes than racing sims for example.
Specifically we’d usually evaluate the tradeoff between how much it doesn’t work and how much work it is to “fix” it, sometimes it’d get cut completely, sometimes it’d get scaled back, sometimes we’d re-evaluate the feature/scenario for viability and make a decision after that re-evaluation and sometimes we’d just bite the bullet and work through it.
Over time you get a bit more cautious about committing to things without thinking through the potential consequences, but sometimes it just isn’t possible to see the future.
I understand the realities of managing a project like that, at the same time these kinds of things are known upfront to a degree and yet people always seem surprised that the cone of uncertainty on a project like that is huge.
As i said, i have no problem with re-use, i have a problem with saying re-use is “essential” to stopping crunch, like the management of a project like that isn’t the core of the problem.
Careful, I made the exact same comment and you’ll find it downvoted to the bottom there.
Do you think you end up with a more realistic development timeline by remaking things you’ve already made? Your comment can end up downvoted for calling one of the most common industry practices, for very practical reasons, “cutting corners”.
If it’s an integral and common industry practice, how has the industry not entirely eliminated crunch already?
Because while it’s a tool in one’s tool belt to work smarter, it is obviously not the start and end of where crunch comes from. Nor is it cutting corners.
Ah so we are picking and choosing whose statements we take as absolutes then.
Because it’s fucking inane. Yes, it’s only one part of the problem - nothing was ever stated otherwise, he’s simply speaking on the topic at hand.
Do you also say “no, ALL lives matter?”
“Essential” implies more than just a small part, but if you want to claim otherwise you are free to do so.
Because project management is comparable to civil rights? That’s some weak sauce whattaboutism.
I think we might be talking to a project manager.
Downvotes with no actual reasoning behind them?
I am shocked, shocked i tell you.