I just read CG Online's review of X-COM Enforcer, and had to sigh and shake my head at another game that didn't allow in-level saves of any kind. That got me to wondering, and I'll pose the question here: has anyone heard *any* justification from developers for doing this? Second question: has anyone heard any *credible* justification?

The only justification I've ever heard given (and this in a surprisingly few cases--mostly I've never seen it addressed) is that in-mission saves make the game too easy (a justificaton I find pretty weak). More often the "answer" is just silence from developers, which makes me wonder if they're just hiding the real reason (which my unkind side says is something like "we're using the lack of a save to mask a lack of gameplay").

No, not at all. Nothing could be further from the truth.

If a game is not specifically architected from the beginning to have in-game save, it can rarely EVER have it. And, more importantly, architecting a system that handles it can add months to development time, particularly testing.

Why?

Imagine a mission-based 3D world like Enforcer, or, say, Rainbow 6/Rogue Spear. To do an in-mission, anytime, game save, literally thousands of variables have to be frozen and put in a usable format. The exact position, animation sequence, AI state(s), knowledge state, ammo count, wound level, etc., of every enemy on the map plus every friendly on the map is just the beginning. Then take into account environmental options, and every other change that could possibly have happened to the game world in that time.

OK, that's doable, even if it would take 20 seconds and a 50 MB save file every time. But realize that that all has to be tested very, very thoroughly: saves when all sorts of things are going on, in every conceivable combination. Hard drive reads and dumps are very susceptible to system error as well, not to mention the RAM swapping and subsequent chugging. All kinds of things go funky when Save/Load is broken, and it usually is. S/L is usually one of the last features to be built and last features to be debugged.

Disclaimer: I am not an engineer. But I do argue with them a lot.

There ARE design justifications for limiting saves in some circumstances, but very few games even approach these justifications. In most cases, it falls under 'just too damn hard'.

I spent a little time explaining this at E3 to Bruce Geryk and Gordon Berg, IIRC. Both were as surprised as you.

Trust me-- if you want credible justification, I can get an actual engineer to write one up. Might actually make a nice article for one of you print types.

"The exact position, animation sequence, AI
state(s), knowledge state, ammo count, wound level, etc., of every enemy on the map plus every friendly on the map is just the beginning."

That's very interesting. I had always thought Bioware's/Black Isle's Infinity engine games didn't allow saving during combat as as a design decision. But from what your saying, it sounds like it was at least partially an engineering decision, drastically reducing the number of variables that have to be accounted for.

Why is "save-anywhere" a necessity for first-person shooters, but not for mission-based space sims or racing games? For instance, the levels in freespace 2 aren't much shorter than the levels in Aliens vs. Predator (and, in fact, they include a lot of scripted sequences that can become pretty tedious after one viewing). Yet, after a quick search of deja news and various reviews, I can't find a single complaint about the lack of an in-mission save in freespace 2.

>Yet, after a quick search of deja news and various reviews, I can't find a single complaint about
the lack of an in-mission save in freespace 2.

There were some complaints, as there are whenever a space sim comes out -- because there has never been a space sim that allowed you to save whenever you wanted during a mission (the Independence War expansion pack had automatic save points within missions).

It's for technical reasons, not design reasons, that there aren't saves in space sims. But the reason there's so few complaints is because there aren't competing products that overcome those technical issues, unlike in first-person shooters.

X-COM Enforcer's more like a videogame in its approach. The levels are pretty short and the challenge really only comes from having to replay them if you don't succeed.

Ken Levine and I talked about in-mission saves in my latest GameSpin column, which is blurbed on the front page. Basically, it's what Kevin said.

Shooter players demand saves because most shooter missions are designed around the save/restore cycle. You walk into a room. You die. You restore, and remember not to get shot this time. No one designs shooters where a good player could reasonably expect to go through the game without ever dying--just like their on-screen avatar supposedly would try to do "in real life."

If you had a shooter where you had the situational awareness and control ability to actually do real-world damage limitation and avoidance--i.e., if you could see and avoid deadly situations in the game as well as you can in real life--you could perhaps get away with a full save anytime/load anytime system in a shooter (but you'd have to allow folks to exit anytime and reload there, anyhow, or face the wrath of people with lives everywhere).

Of course, most shooters depend on fast and furious action of some sort for their kicks, and that sort of gameplay doesn't lend itself to my approach, I guess. I think a game like Deus Ex or Thief could work that way though, if done right.

Still, I love being able to quicksave and move on, knowing that if I screw up I won't have to play the whole level over again. I have a very low frustration tolerance sometimes.

SWAT 3 doesn't have mid-mission saves, but it is MISSION- as opposed to LEVEL-based, which means it's playable in small 15-minute or so chunks.

I guess I was thinking more of types of games where save is a pretty standard feature (particularly FPS and RTS games). It seems that many of the games in these genres that don't allow saves have other weaknesses (not always; I've heard that Alien vs. Predator was generally a good game). I especially wonder about this when a follow-on to a game much maligned for lack of in-mission saves ends up including this feature, although Kevin's statement about the extra development time--even assuming in-mission save is planned for (and why wouldn't it be for some of these games)--makes sense. I guess I'm just reacting to the developer silence on this. Rarely have I heard developers give technical difficulties as a factor -- they either don't say anything at all or mumble a lot.

And the points about genres that don't generally have saves are good ones too. It's interesting that sims basically don't allow saves. Some flight sims used to allow recordings of the flight (and I believe some of those even let you restart the game from any point in the recording), but that was when things were a lot less complex (I can imagine the difficulty of saving Falcon 4.0's dynamic campaign world). Interestingly, Microsoft Train Simulator provides a save function. Sure, it's not got as many objects as most combat sims, but I'd almost be willing to wager that it has more objects than most civilian flight sims (especially when you're up high in said sims).

Stating "save games are hard" is a really stupid excuse for why you don't have them in your game - if the gameplay demands it, it should be done.

As someone who writes code for a living, if you can't figure out a way to economically serialize the state of your application, there's something seriously wrong with either a) the design or b) your design team.

It's not like they're writing the launch routines for the space shuttle - games consist of objects. Write out object states. Wash, rinse, repeat.

Furthermore, if save/load is "one of the last things that get written".....there's something seriously wrong with your development process. How hard is it to write finite state machines?

That's not quite what he said.

The ability to arbitrarily save game state at any point is expensive to develop.

Let's go down the reasons why:

1) Every object needs a serialize/deserialize routine. In and of itself, this isn't that hard, but given the number of pointer references floating around a game engine, you lose the quick and easy "oh, just dump every object" and start getting into issues of organizing the serialization and handling the pointer references. But yes, this is inherently a solved problem.

2) It's remarkably fragile. Minor errors made by programmers will cause all sorts of oddball and difficult to track problems. Use of code checking tools can help, but it's still prone to human error during development.

3) It costs an enormous amount of QA time. Checking for errors (and finding them), and validating the save/load suites are expensive and require a full regression check every time pretty much anything else is changed.

So, can save/load be done for any PC game? Sure.

What are you willing to give up to get it? Like everything else, features have to be compared against each other in terms of cost and value.

What compromises might give a good result with less costs (i.e. checkpoint saves, saving after the planning stage, etc)?

--Dave

Dave: Ok, arbitrary point saves aren't absolutely necessary, and they can be expensive to develop, so there's a cost/benefit tradeoff in gameplay there, where checkpoints and the like are a good idea.

However, I wrote that post in shock after reading this: "All kinds of things go funky when Save/Load is broken, and it usually is. S/L is usually one of the last features to be built and last features to be debugged."

I simply can't believe this silliness is the actual state of game design. I'd also say if debugging serialization is that difficult, whatever design methodology you're using has some problems.

What next? Making the game fun as the last part of the development cycle?

Debugging serialization is tricky because the problem scales badly with game complexity, and because human error often manifests in very different locations of the code than the ones which were broken.

And funny you should mention the last...

One of the strong risks of game design is that a lot of the development ends up being done on the evil right hand side of the "design change" asymptotic curve they list in all the Software Engineering texts to scare impressionable young minds.

You can't determine, for example, that the AI isn't capable of coping with the game design until you... well... have an AI and have a game engine it can play in. You can mitigate this risk with experienced developers or with products which are within problem areas you as a team or company have worked in before, but it's still a very real risk.

One of the most serious fears in game development is that you'll make exactly what you set out to make, and discover that it may be what you wanted, but it isn't fun. And the reasons aren't necessarily obvious except in hindsight.

Now, there are ways to get around this problem. One of them is the much maligned, "we'll make a game exactly like that game over there, but we'll change the graphics and add more special effects". This is why sequels are safer.

Another way is to do early playable prototyping of games. This involves trading upfront costs ("we'll spend this many developers for this long to make something we'd have to scrap anyway even if we go ahead and make this game") against the risk of making late design changes.

Sounds good? Let's factor in a few things. One, this is expensive. Two, how much time are you spending? Too little, and you can't test any new or innovative features. Too much, and you are making a game twice to sell it once. Three, how close a match is your prototype to the actual gameplay. Even if you only test the things you think are risky, you still run the risk that the combination of features you were confident in ends up giving you an unplayable combination.

Even if you do all your work, and carefully get to a playable version of the production game as soon as you can, there is still the nagging fear that you may end up with either repetitive gameplay ("how long is it fun" is another matter completely) or that the parts of the game yet to be fully fleshed out or filled in will reveal serious flaws that need to be fixed.

Making the game fun is something that happens throughout game development. But it is towards the end of development that you find out whether or not you succeeded, and if you didn't, it gets very expensive, very fast.

--Dave

Dave - hey, I didn't say it was easy. ;0

So you're saying it all seems boils down to getting the design right the first time?

"Some flight sims used to allow recordings of the flight (and I believe some of those even let you restart the game from any point in the recording), but that was when things were a lot less complex"

Falcon 4 has an ACMI feature.

The only remotely credible excuse I've been given for lack of save-anywhere in a PC game is "it's to create tension."

Which makes some sense, I suppose. If you have no fear of your character dying or whatever becuase you hit the quicksave key every 30 seconds, it's hard to make the player fear anything.

Or at least, that seems to be the logic. I personally think it's bullshit. The player should fear for his CHARACTER or in-game persona or whatever. They're substituting "fear for the guy I control in the game" for "fear of me having to replay 20 minutes of this things three times."

I also have this theory about games having to be challenging to be fun, which goes like this:

They don't.

My favorite games of all time weren't very hard at all. They were actally pretty easy (but not so incredibly easy as to be outright boring). The fun comes from your moment-to-moment actions, figuring out puzzles, planning successful strategies, etc. Not from the satisfaction of knowing you got past this artificial construct where the variable of "10" kept getting you killed while a variable of "12" would have allowed you to: make that long jump, kill that tough bad guy, survive that viscious onslaught, blah blah blah.

Speaking of boneheaded--Diakanta's Save Crystals. They had all the code necessary to save the game anywhere, becuase you could, but you could only save a limited NUMBER of times, and you FOUND the objects that let you do so! It's not like you knew you only had 5 saves per level, because you may or may not find a save crystal. Dumb, dumb, dumb.

I liked Soldier of Fortune's solution. Give the user unlimited saves on easier levels, limited saves on harder ones, and even then let them turn it back to unlimited saves.

So you're saying it all seems boils down to getting the design right the first time?

--------------------------------------------------------------------------------

In the same way that success at the stock market boils down to buying low and selling high.

It's true, it's just not easy.

And you can have successful titles that didn't get it right first. They just get more expensive to develop. Given that even well designed, well developed, really good games can and do flop in the marketplace, more expensive is bad.

Incidentally, that is the final justification for arbitrary save/load implementation on PC titles. In many genres, the marketplace requires it, and not including it can guarantee that all people know about the game is that "you couldn't save".

--Dave

Dave,

Thanks for the cogent explanations of some of the technical issues here. You've hit the nail on the head with the marketplace bit, though--in genres where save anytime/anywhere schemes are de rigeur, leaving this feature out can be the kiss of, if not death, then at least serious illness.

Which should tell developers that this is an area that needs to be addressed early in the design process, precisely because it's so difficult to handle. The other alternative is to develop games that don't need such save systems--mission based games for example, with built-in save points perhaps. It all depends on the game. Deus Ex without quicksaves would have been too damn frustrating. Ditto System Shock 2 or most shooters. But MechWarrior 4 worked without in-mission saves, as do most flight sims.

Ultimately frustration is bad. There have been games designed--many but not all for consoles--where causing frustration seemed to be the main design goal, under the illusion that frustratingly hard = fun. Saves mitigate frustration, ergo, they're a "good thing," independent of the effort needed to make them happen. In a zero-sum game, they're usually one of the things that has to be taken as a default. Yes, you will lose "something" else by including them, but if you know from the start that that's the case, at least you can plan for it.

On another note, the problem with people designing the game they intended only to have it suck, that's something I've seen too. The original Dungeon Keeper, for instance. The Bullfrog folks told me they had it designed just the way the had spec'ed it, and it wasn't fun, so they redid the entire thing. Same with Jagged Alliance 2's planned real-time mode. Game design seems to be one of those fields where the only way to see if your idea is good is to make the product, by which point it's often too late to go back...which might explain a lot of mediocre games out there.

---

Quote:

Ditto System Shock 2 or most shooters

---

True enough, and a great idea. They still left in creep and save, though, as an option. Interesting.

I've talked to Rob Fermier a bunch about Shock 2, even played it with him online in co-op (it was his first time with multiplayer Shock 2 also :). There's a ton of really cool things in that game which they don't seem to get enough credit for. Every design decision was weighed heavily.

For example, the cameras can be shot lowering Shodan's effectiveness at finding you. That's kind of silly when you consider that shooting a camera would probably have the opposite effect and set off an alarm. But it improves gameplay, so they do it that way. The logic of it really never sinks in and I never even considered that while playing.

The training mode as part of Cyberspace is also a work of genius. A great nod to fans and a perfect way to acclimate you to the game. Some people don't like the breaking guns, but they also balance the gameplay extremely well. Not only that, but you can just avoid guns altogether as a PSI. Did you know that your eyes are in your chest? Play co-op and you'll see a strange perspective which bears out all the comments from Ken Levine on how they really didn't want to do multiplayer.

But to address your point, Bob, they know their games and knew they had to have save anywhere even with the regeneration possibility. Developers can't do much better than to use the Shock games for their inspiration when making a first person game.

--Dave

"There ARE design justifications for limiting saves in some circumstances, but very few games even approach these justifications. In most cases, it falls under 'just too damn hard'."

I dunno. I just find that a little hard to swallow. As an example, I'm currently playing Arcanum. That sheer amount of game state information that this game has to write out every time you save must be absolutely immense. The game is incredibly non-linear and features hundreds of objects and inventory items. It has a contiguous world that (as far as I can tell) is as large or larger than the land masses in many online RPGs. It remembers where every fallen foe lies in every dungeons and city that you've ever visited. It remembers every conversation option (and there are a LOT) you've ever chosen and your current relationship with every NPC in the game (and again, there are a lot). It remembers the inventory of every NPC and shopkeeper in the land (if I sell something to a shop, leave town, and come back later, often the items that I sold the shop are still there). No offense, but the amount of data that goes into an Arcanum save must make the amount of data needed for a Rogue Spear save look almost inconsequential in comparison.

And yet the game lets you save whenever you want, and the save files average about 1.3 MB (although they are getting slightly larger as time goes by, obviously). So obviously something doesn't jive here.

Yeah, that's kind of what I thought, too. RPGs -- which almost always allow you to save at almost any time -- surely have more variables than games that were being discussed here. Baldur's Gate II has many of the same issues you brought up, yet you can fit a saved game -- or two -- on a floppy disk.

Well, yes. You can save anywhere in most games. It just has to be architected from the ground up, or you're in a world of hurt.

--Warning: Going Well Beyond My Actual Technical Knowledge--

It seems to me that much of the problem is how much of the world is in flux at any given moment. With Arcanum, it's not much. Overall, though, the amount of info gets staggering.

Compare that to an action game where everything is in flux at once.

As Jason Levine pointed out, you're not allowed to save during combat in Baldur's Gate. That might be due to the higher level of variables in flux, or it might have been a deliberate design decision.

--Back on Firm Ground--

Let me edit my earlier comments for clarity. What I meant was that there surely are design reasons for limited saves, but many production teams don't even get far enough to evaluate them, because they decide early on that in-mission save is just too darn hard.

So yes, saving anywhere can be done, in much the same way that stable multiplayer can be done. Not all games have either. Both are hard to do if you don't know what you're doing and don't build the system right from the ground up. And people have different expectations of both in different genres.

Most of the PC games I can think of that skipped in-game saves claimed that in-game saves ruined the suspense or simply made it too easy (neither of which I agreed with). Some prime examples were Dark Forces (suddenly in Jedi Knight it was in there), Aliens Vs. Predator (sans the later patch), Hitman (scared me off), Giants: Citizens Kabuto.

I prefer the methods some other developers took of either asking you at installation whether you wanted to be able to save during games or not and then you have to stick with your choice unless you want to reinstall; limiting the # of saves or giving you only one quicksave slot, which limits the save'n'creep method; or eliminating saving on the hardest skill level.

Some of my favorite games were ones where you'd get so caught up in what you were doing you'd forgot that you COULD save anytime anywhere. Half -Life and System Shock 2 both did that to me, and sometimes had me howling in amusing despair, but I mean that as a compliment. :)

>Baldur's Gate II has many of the
same issues you brought up, yet you can fit a saved game -- or two -- on a floppy disk.

That's deceptive, however, because you can't save any of the Baldur's Gate engine games in the midst of combat, which is when those games have the same issues as sims and action-oriented games.

"Well, yes. You can save anywhere in most games. It just has to be architected from the ground up, or you're in a world of hurt."

*That* I can understand. Adding such a feature after the fact has got to be pretty difficult.

"It seems to me that much of the problem is how much of the world is in flux at any given moment. With Arcanum, it's not much. Overall, though, the amount of info gets staggering."

I think the key is weeding out all the game state data that doesn't really need to be saved. Is it really necessary to remember where every character is in their animation sequence, for instance, or would it be enough to simply start them all in one default state?

[disclaimer: I honestly don't know the answer to that, but it seems that there must be game state information that is not particularly vital to save]

"And people have different expectations of both in different genres."

This is certainly true. The sim example is the best one--few flight or space sims feature in-mission saves, but you rarely hear anyone complaining about it. Release a shooter with no in-missions saves and you're likely to get raked across the coals, however.

Does that really make much sense? No, not really.

"Most of the PC games I can think of that skipped in-game saves claimed that in-game saves ruined the suspense or simply made it too easy (neither of which I agreed with)."

This is the excuse that I find the most annoying, because it is demonstrably untrue. Aliens vs. Predator is the best example--some of the levels in that game truly were suspenseful... the first few times you played them. Getting stuck and having to replay parts of each level ten or fifteen times does a really admirable job wringing all the suspense out of the game, though. Eventually all you feel is frustration, and that's not nearly as much fun.

I agree, Ben. It should make precious little different which animation state any of the off-screen NPCs are in, and, with many off-screen NPCs, it wouldn't even matter exactly what spot they're on. If they have a default start location, and they're off-screen, seems to me that they could just start at the default spot.

And, yes, there's NOTHING more annoying than having to do the same freakin' thing over and over again due to the lack of the save feature. I just refuse. I won't play a game that requires me to do that.

As far as the technical requirements for saving the game in a FPS, let's go over what things in the game actually change.

Ammo count, health, armor, fatigue, and various other "status" information per character. Pretty simple here; maybe some timers listing how long until you can use first aid again or the like. Not that big of a deal, though, as this stuff is obviously part of the object state. At least, logically it should be.

Simple, non-animated objects in the game world, such as guns and ammunition lying around. Just keep track of the location, and any status info for the object.

Animated things, such as players, whatever. I don't know anything about saving specific animation sequence, but it can't be that hard. The UT engine does it, right? ;0

Destructable or changable objects that aren't "actors", such as destructable walls, bullet marks, and burned areas of floor. This is the most difficult one, and I think that's the reason we're just now starting to see movement in this direction. Doing the FPS equivalent of Syndicate Wars, where everything in the game universe could be blown up to the point where there's nothing but grass and pavement left, is pretty difficult from a rendering engine/game engine intersection standpoint.

Unless I'm missing something, none of it sounds really hard, except for persistent world destruction, which no one really does anyway.

I think it all goes back to what KP pointed out -- it's not that hard to do, as long as you plan for it from the beginning. (Personally, I don't understand why anyone would NOT plan for it from the beginning, because I think, just about no matter what kind of game I was making, I'd want to have a save feature, but that's just me.)

I'd be really interested in hearing from someone who IS on the programming side of things, to get their take on it. (Kevin, I actually would be interested in reading something by one of your engineers on this, if one of them has time to put a little something together...) Everyone around here seems to agree, it doesn't sound that hard. But none of us has actually done it before. (Not excluding myself -- I agree, it SOUNDS easy.)

(sound of buck passing to Dave Weinstein, an actual RSE engineer)

I've gone into most of the details already.

Without going into too much detail (which I did in the first three attempts to write this particular post), the problem is finding an existing and stable game state to save.

In a turn based game, which is the easiest example, at the end of every turn, there is a single game state, with nothing which affects the game state actually in motion.

In games which support multiple execution modes (for example, planning to action in Rainbow Six or Rogue Spear), saving at the bridge between modes may be ideal, since data has to be packaged up to be transfered anyway.

If the game is real time, but everything is running below the surface in synchronized microturns, the microturn is the obvious place to save. This isn't necessarily easy (for all the reasons listed up topic), but it's easier than our worst case, because everything all ends (or at least takes steps) in lockstep.

Our worst case is a real time game, with actions proceeding without a synchronized microturn. Obviously, each frame is a "turn" of sort, but actions don't line up with each other, they are allowed to start, operate, and stop, independent of any master synchronization. This is extremely tricky to do save/load for (even if it is implemented from Day 0), but it can have real benefits elsewhere. The amount of data that has to be saved for an absolute object image is quite high, and complexly interelated. And if you choose to elide data, you run the risk of restoring invalid or indeterminate game states, which will cause QA hell, may cause your QA lead to kill you, and is incredibly high risk as far as bugs go.

--Dave

So there's actually real time games out there that don't have any sort of master "clock" other than individual frames? *Boggle*.

"The amount of data that has to be saved for an absolute object image is quite high, and complexly interelated."

That probably explains why save games tend to be so large for shooters, particularly the more complex ones (Deus Ex, et al). Still, given the choice between being able to save anywhere and not, I'd rather be able to save anywhere. As Kevin pointed out, some games without that feature bother me a lot less than others, though. I guess it depends on difficulty and distance between save points (i.e. how likely is it that I'll end up replaying one section over and over and over and over...).

A lot of it's the length and difficulty of the missions. X-COM Enforcer doesn't allow in-mission saves, but the missions are short and relatively easy. It would be nice to have some kind of checkpoint save in that game, but the mission design doesn't make for obvious checkpoints.

"So there's actually real time games out there that don't have any sort of master "clock" other than individual frames? *Boggle*."

-=-

The master "clock" is the real world elapsed time. Frames are just the smallest quantum of that time the game has to work with.

--Dave

Thanks for filling us in on all that, Dave. We sure appreciate you letting us know.