Monocause
Arcane
- Joined
- Aug 15, 2008
- Messages
- 3,656
This is true in most cases where you have a proper pipeline setup and work in a non-agile environment (and last I checked agile was really not working out for game development and in cases of most RPGs I played it would be definitely a straight up foolish choice to go agile).this isn't true thodevelopment progresses in a linear fashion in most cases
you don't need to do A finished to do B because you already (mostly, except for content altered during the implementation) know what A will contain
and as you get more modern with bigger teams, the team making B often knows nearly nothing at all about A. Which is why so many modern games feel completely disjointed with content that seems to not acknowledge each other at all.
e.g., I just playtested a game about a week ago that had the mid-game mostly finished, but the beginning/end unfinished(afaict)
A situation where you skip A to develop first B and then go back to A doesn't make sense for a lot of reasons and is clearly suboptimal. You're basically setting yourself up for situations where fe first you develop B, then you develop A, then over the course of A's development you realise the implementation of B needs more work/doesn't make sense/needs to be rethought. So you then risk having to devote extra resources to B which you technically have already finished.
If you have a linear story/linear progression, it also makes the quality processes much much better if testing proceeds along the natural curve (assuming core systems are already in place). There may be specific titles and situations where non-linear development might be a sounder choice, but more often than not it's a decision made because you're forced to make it. For example, you wanted to develop A first but the engineers still haven't delivered the special engine feature that is required to make A work at all - in PM terms, there's a dependency blocking you. So you go ahead and do B hoping they'll deliver by the time you're done with it. But in an ideal world you'd be working on A. Sometimes you also start working on A but development reveals that you need an extra piece before A to make it work, so during development you have to quickly design piece "pre-A" from scratch.
Imagine it as creating puzzle pieces, where you start off with creating a 2nd puzzle piece. Then you go ahead and create the first one and all of a sudden it's revealed that the two pieces don't fit. Piece #1 is the core building block so more often than not you have to adjust #2 to make it fit. The extra time spent on adjusting #2 is not spent on building #3 which gets increasingly delayed, and so on, and so forth.
Team size overhead you're mentioning isn't related to being modern really, it's just the team size and project scope, and most game studios don't have issues you're talking about. The silos phenomenon shouldn't hit you until you reach a few dozen people working on the game - unless the whole thing is grossly mismanaged and/or spiced up with cost-saving pitfalls like liberal use of outsourcing.
Either way, the endgame for RPGs really lends itself well to being developed at the end of the project's timeline. On paper, because in reality this usually means that there simply isn't time enough to do it right so it gets brutally cut and rushed.
Also imagine this. Your RPG according to the script and the plan should mean that by 75% of the game you defeat a dragon, and the game's ending revolves around the fact that you defeated the dragon. Then around the 50% mark the engineers come over after a month of delays and say "uh, hey guys. Can't be done. We can't make the engine support a big creature like this. It looks rubbish. Performance is garbage. Physics are going crazy. Refactoring the engine would take a couple months minimum." - so then there's a scramble to figure out how to salvage the script and the guys figure out that okay - we'll show the dragon's full form in cutscenes but when you actually fight it it's gonna be in its human form. Then you quickly rewrite and redesign a lot based on that decision. The quality loss is there, but it's manageable.
Now imagine the ending got developed first and you've got tons of material and VA talking about how you defeated the huge angry red lizard, or worse yet some special abilities that were supposed to let you transform into a dragon and all that was needed was that thing the engineers were working on, and you balanced the whole experience around the player having access to that. Not a good place to be in. This is a very simplified and kinda stupid example but I think it showcases why linear is the most common choice there.
tl;dr - the problem with your statement is that you say that you KNOW what A will contain, while up until A is developed and finish, you only have assumptions on what it will contain. And assumptions are uniquely dangerous in software development :D
Last edited: