Scene: a project meeting of Hypothetical Games, a mid-sized developer working on a prestige product for the upper market - something equivalent to God of War or Resident Evil 4. Present are the game's Producer (who is in charge of the schedule and, by extention, the budget), the Game Designer (who is the advocate for the games' audience and co-ordinator of the game design), the Lead Programmer (in charge of the programming team), the Lead Artist (in charge of the graphics and animation teams), the Lead Level Designer (level design team leader), and the QA Lead (in charge of testing and quality assurance, and an adjunct to the game designer).
The meeting is nearly over.
Producer: Any other business?
Game Designer: Just one thing. The save games. I feel I need to point out that if we can't save everywhere without restriction, it will upset some of the Hardcore players.
Producer: How many players are we talking about?
Game Designer: 5-10% of the total audience. But these are Hardcore players - there will be a crossover with magazine reviewers, so it could cost us on our review scores. And the people affected feel very strongly about this issue - it could hurt us.
Producer: You said before that a lot of Hardcore players benefit from being a little frustrated - it enhances the emotional payoff of 'fiero'. Is that right? The feeling of triumph over adversity?
Game Designer: Well, it's true that a lot of Hardcore players have fiero as a key payoff. But you don't need to be frustrated to get fiero. It's beating the challenge which gives the fiero - frustration is just a common accompanyment to fiero.
Lead Programmer: I'm not keen on trying to support a save anywhere system for this game. We've got a lot of unique subsystems - it's not just a single gameplay model throughout. We'd need to implement a seperate save mechanism for each subsystem. Some of our foes are as complicated as a typical boss in terms of the programming - we'd need to develop a system for saving all their states in all instances.
Producer: How long would it take to implement?
Lead Programmer: It'll add maybe 10 to 20 percent to the time to implement each subsystem.
QA Lead: And it'll add at least the same to the QA time... we'll have to test each one seperately. It's a lot more work to test a save system that can be used anywhere than a save system that only needs to be tested for each checkpoint. This is a big world we're talking about, and we have to check the save works in every situation! Personally, I liked the plan we already had with the hermetic save system...
Game Designer: It's certainly the simplest and easiest option to implement, but as I say, we could be alienating some players in a very influential audience cluster. If we don't get Hardcore support, we'll never reach a large enough Casual audience to make back our development costs.
Lead Artist: What about the Casual players? How does this affect them?
Game Designer: Well actually, that's the other problem. We're expecting to reach quite a few players with mid to low game literacy. The save anywhere system could be a problem - it will be possible for players to accidentally save in a situation from which they would be trapped. But given we have a check point system, they can always go back to an earlier checkpoint.
QA Lead: I have to say, I don't relish the thought of running the useability studies if we have a save anywhere system. We never do an adequate job of teaching inexperienced players how to use a save system.
Lead Programmer: There are people who don't know how to save?
Lead Artist: I have to say, there are times I don't know what I should do when I'm saving. I'd prefer not to be faced with any decisions when I'm saving; I just want to play the game! If I have to manage my own saves, I usually just keep one, so if that save leaves me trapped - I'm screwed.
Game Designer: If that happens, you'll still restart at the nearest checkpoint though.
Lead Artist: Still, I don't like it when the game makes me feel stupid.
Game Designer: We could add a save game tutorial...
Lead Artist: Which would make me feel even more stupid!
Producer: Not to mention adding to our costs. You're already saying this is going to add at least 10% to the programming and QA budget, let alone the cost of a tutorial to teach Casual players how to use the extra save system.
Game Designer: Well we can hide the 'save anywhere' system in the options, where it has to be manually enabled. Hardcore players always find things in the options, whereas Casual players almost never look at them.
Lead Artist: Does that mean we need multiple versions of the in game menus? That will take a little extra time, but I'm okay with it if the programming team don't mind.
Lead Programmer: Well we can do it, if its definitely worthwhile. It all takes time to implement, though. I'm more concerned about saving the state of the rooms in all cases - it gets quite complicated when there's a lot going on. We have to save positions, animation frames, AI data, particle system states...
Game Designer: I suppose we don't have to save everything perfectly. As long as the player starts in roughly the same place - it should be okay.
Producer: This is a prestige product. Either we save perfectly, or not at all. We need the publisher to back the game with substantial marketing spend and if it looks like we're not doing everything with the highest possible production values, that won't happen.
Lead Level Designer: We could extend the checkpoint system to specify more places to restart, and just use those as the restore points when the player uses the anwhere save.
Producer: Will that add to your workload significantly?
QA Lead: It will add to mine if you want us to test them all.
Game Designer: We can just restore the player to the start of each room.
Producer: Will that satisfy the needs of the Hardcore player who wants to save anywhere?
Game Designer: I don't know. It's hard to predict this sort of thing.
Lead Level Designer: We have some pretty big rooms. I think starting at the beginning of each room is going to be basically the same as our current checkpoint save system.
Producer: Okay, let me just get this straight. You want to use maybe 5 to 10 percent of the development budget - say, half a million dollars - for a save system that only benefits a minority of our audience, and that may give problems for a large part of our audience. I don't get it. God of War and Resident Evil 4 pull in 94 and 96 scores on Metacritic without this sort of save system, so it doesn't seem like we need it. Even GTA: San Andreas doesn't have it. Why do you think this is so important?
Game Designer: Every game is different. If our game needs the capacity to save anywhere, we need to plan for it now.
Lead Programmer: It's true - once we've built all these subsystems, it will be much harder to add save mechanics to them all. It would help to know what we're doing before we implement the key systems.
Lead Artist: It seems to me that for the kind of game we're making, impressive graphics and sound are more important than little details like a save system. Wouldn't we be better off putting the money into that?
Game Designer: We're already spending millions on the game; I'm just suggesting we use a small amount of the budget to meet the needs of an influential part of our audience.
Producer: This isn't a democracy, but I'd like to know what you all think. Let's put it to a vote.
They vote, and a decision is made. The question is, what decision does the producer make?
Disclaimer: the voices in this discussion represent viewpoints I have heard expressed in game development during my years working in the industry. None of the voices represent my own viewpoint, which can be found in an earlier post entitled 'To Save or Not to Save'. The purpose of this post is to demonstrate some of the factors that contribute to 'save anywhere' not being a standard feature in games.