Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Why do so many GREAT RPG's worsen in late game?

Monocause

Arcane
Joined
Aug 15, 2008
Messages
3,656
development progresses in a linear fashion in most cases
this isn't true tho
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)
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).

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:

MF

The Boar Studio
Patron
Developer
Joined
Dec 8, 2002
Messages
906
Location
Amsterdam
I'm not sure what my takeway from this is yet. Probably that about 10 hours is fine for this particular game. Also that for the long endings, the game outstays its welcome for the majority of players. If I had to guess I'd say most RPGs are simply too long for their own good. Some people enjoy that. Most don't.

I got some of the game's endings but never got to the long time limit related endings, because I had completed pretty much all the side content long before that limit would run out. So there was pretty much nothing to do for me for several in-game days other than wait, which isn't terribly exciting.

I think the problem with the long endings in Titan Outpost is that there isn't enough side content to make waiting for it fun.
You're right. A lot of content leads to some kind of ending so none of it is being treated as side content with which to fill the gap. Moving the timeline forward a year and adding the expansion content improved some of that, but it didn't move the needle much in terms of how many players reach those endings. Definitely a lesson in pacing there.

Someone mentioned Underrail as a counter example earlier in the thread. I sort of agree and disagree at the same time. I think that's a great showcase of how difficult an endgame can be to get right. The Deep Caverns completely change the pace and atmosphere of that game, which is a neat way to wrap it up, but it's also a bit of a slog with respawning enemies and moon logic. I did an Underrail run twice when it was released and once again when Expedition came out. I quit at the Deep Caverns that third time. It's not like it falls apart. It's clearly just different and a lot of effort was put into it. I liked how it suddenly becomes a horror survival game that wears the player down the first time around, but it's not as replayable as the rest of Underrail.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom