There's an article over on gamrFeed, in which the writer assesses a set of games and tries to determine whether the sequels were better than the originals. And in the end, he comes up with six simple rules:
- Don't spend too much time on development.
- Change your engine every so often, and if you can, use one that you've developed yourself.
- Try to keep the team the same, especially if the original was good.
- Don't get rid of the parts of the original that people loved.
- Don't try to evolve too much and forget what made the original great.
- Improve everything, because one bad aspect can bring the whole game crashing down.
Personally, I'm not too convinced by all of these rules (for reasons which I'll rant on further below). Instead, I'd propose a simpler, more abstract set of conditions for making a good sequel:
- Make sure you've identified what made the original popular, and make sure you retain as much as possible.
- For every new gameplay element you add, make sure that you remove one of the old gameplay elements (or at least abstract it away, by combining it with other elements and/or making it context-sensitive).
The reason for this is simple: if you remove what made the original popular, you're gambling that players will like the new features. Similarly, if the player is faced with too many elements and features, they're liable to get confused and overwhelmed.
So... before I settle down to enjoy the sound of my own typing, what do other people think is needed to make a good sequel?
*pause for comments*
And now, onto the ranting...
1) Aside from the fact that "too long" is a very loose definition: spending too little time in development is just as bad as spending too long: what you release is likely to be unbalanced and/or buggy. There's also plenty of examples where companies have held onto a game until it's right: justabout everything from Blizzard, Half Life 2, Bioshock 2, God of War 3, Mass Effect 2...
As ever, it's up to the developer to balance the cost of continued development/polish against the risk of building up unmeetable expectations (or losing player interest altogether). But that's definitely an art, not a science.
2) Duke Nukem Forever. Need we say more? Also, I'm not sure why changing your game engine for a sequel is viewed as beneficial: it can severely impact your ability to retain the qualities of the original game. For instance, the original PC AvP (Rebellion, 1999, in-house engine) featured a clever dynamic-lighting system: you could shoot out virtually every single light you saw, and throw flares to light up the area. Conversely, the sequel (Monolith, 2001, Lithtech) did not feature destructible lights and the light from your torch was treated as a physical entity: if the circle of light even clipped a wall edge, the beam would be stopped dead. Essentially, Monolith were forced to shoehorn in features onto their engine which it was never designed for; the results were unimpressive.
(Equally; an in-house engine offers more flexibility, but is liable to increase development time)
3) True to a degree, but it's also imperative to make sure the development team doesn't suffer from tunnel vision or is overly influenced by a small (but generally very vocal) hardcore fanbase.
4) and 5) are essentially the same, and are pretty much common sense: if you change the sequel too much, you risk losing the factors which made the original popular. Conversely though, if you don't make any changes, there's a risk that your game will be labelled as an expansion pack or dismissed as a lazy cash-in. Sadly, it's not possible to quantify what a good level of change is; as a general rule of thumb, I'd suggest trying to retain 65-90% of the original game's mechanisms (though you then get into a discussion of what consitutes a "mechanism"...).
6) is effectively a contradiction of 4 and 5: the only way you can improve something is to change it. And the more you change, the greater the risk that the end result will be too different to the original - it may well be better in every way, but if it's not what the fans want, that isn't really of any benefit!