Progress

This is a small status update on the various things I want to write about.

Firstly, there's the concurrent savegame system pattern.

That's currently on hold; it's an interesting subject, and I want to dive into it further, but for the moment I'm not well-versed enough in concurrency that I want to model it. I want to eventually utilize a concurrency modelling language to implement a real world model of it - I want to use either coloured petri nets or spin:

http://en.wikipedia.org/wiki/SPIN_model_checker

I've drawn up a preliminary diagram, but I need to work in the rigerous models in order to fully understand the problem and how to best tackle it.

Secondly, there's the non-linear story development tool. I'm inclined to call it Texton. I've been discussing with my good friend Aksel whether I should implement it in C# - Which I've never used before - or if I should implement it in Java. C# seems far more suited to the kind of enterprise level software it's turning into - and it comes with windows presentation foundation and if I do program it in that, I'll actually have C# experience.

Java, on the other hand, would mean I would have to use java swing for the interface, which is a lot less delicious than windows presentation foundation. It would be multi-platform, but that's not really a concern at this point. The biggest problem with not using java is, probably, that java is home to staggering amounts of open source software and frameworks.

Either way, that is a bit of a concern.

Thirdly, I've yet to device an appropriate storage model scheme for the tool. I'm inclined to use xml-based object serialization through an SQL database for all storage, since it effectively decouples all storage and concurrency concerns, and allows for remote sync of data. The problem is, I have to write an SQL database adapter at some point. On the plus side, I can start out simply relying on local xml object serialization.

On the other hand, I've been very enticed by the prospect of using a remote object-data-base, since it allows for transparent development and very clean code.
Problem is, such a database utilizes a model-view-controller system of it's own, where the view into it is often locked to a specific language very tightly; a java object db communicates through a java interface in the client application, for example, so you'd have to find some sort of interoperable object db in order to not get your data locked into a specific piece of software; but an interoperable DB, unless it's interoperable because there's a host of different client frameworks in different languages, would lose the elegance.

In the end, I think I'll go with a highly modular approach, where data can be saved and stored through the utility of the adapter pattern. That is, I write my own client in either C# or Java that relies on an adapter interface for loading and unloading data. How that adapter handles data persistence will then be variable, but the main application can effectively treat the adapter as the model it's working on.

If necessary, an adapter should be able to easily be fitted to a remote object data base for live sync, and one can be written for both sql databases and xml serialization. Given the modular approach, two adapters can also be chained up and translate between two different formats relatively easily. Finally, adapters can be written that are able to translate serialized or sql'ed objects into new ones with appended fields and properties, allowing for patching the data-structure without corrupting the data. Hopefully.

Fourth project is my computer game theory course exam. I need to work on it relatively vigorously, so I'll have to put the other projects on hold for now. Hopefully, the next time I post on that, it'll be concerned more or less directly with this exam.

Blog consistency

I sometimes feel the need to argue why I'm doing things a certain way. Honestly, it's not for posterity, or to make anything clear to anybody else; it's mainly for me.

When I write things down, the syntax and semantics of what I write help me express something I feel. On occassion, those feelings are misguided. That's a pretty way of saying that I'm sometimes wrong, in spite of presenting a thorough argument.

I know this, because it's happened in the past, and I'm not going about things terribly different these days, so it'll happen again.

I'm not always going to go back and say what part of an argument was right or wrong; in the end, I write this for myself, and if I feel making a wrong argument ended up making me smarter, and expressing how that happened doesn't appeal to me, chance is I won't do it.

Sometimes, that will mean my blog becomes inconsistent between blog entries, and on occassion, even within individual entries. This is a choice. I'd rather make entries distanced by clean breaks, even if that means the entries don't fit together, if that in turn means the entries themselves grow to be of better consistency internally. And I'd rather spend my time writing about new ideas I think might be right, than old ideas of my own I think might be wrong.

But, _for_ posterity, I will be making sure that the results I derive will be easy to seek out, handle, and utilize. So the good stuff, I will be certain to reexamine later. The blog is a part of the process towards arriving at those things, so those are what matter.

With that in mind, I hope to soon make a blog entry tying together the game concurrency pattern and the save game pattern.

Designing savegame systems

Since we've previously established that the design of the save game system impacts gameplay, even if it requirres specific behaviours by the player to do so, I think it's in order to discuss different behaviors in relation to different save game systems. Before we get that far though, we need to establish just how difficult the subject is to work with, how it can possibly fit within my pattern model, and generally how we should procede from there.

I hope to narrow the subject towards a somewhat monolithic conclusion, but I fear it will be far more divergent than any of the other patterns I've discussed. I don't think it'll turn into a nice uniform set of rules, but rather several sets of conditional rules, that can be followed depending upon what exactly you're trying to achieve. The key to the difficulty, in my view, is the heterogeniety of the player behaviour. Perhaps I should embark on explaining why exactly save game systems are different from other gameplay mechanics, and perhaps more importantly, on how this difference is reflected in the way players tend to percieve save game systems.

Save game systems are technically different from everything else because they can be invoked at any one time during the game, and because they completely change the state of the game. None of the other metafeatures have this effect. Changing your options and configurations do not, as a general rule, effect the play experience; but there are a few exceptions to this rule, if for example you play a timed game against a chess computer you can underclock the cpu that's driving it to make the experience easier. Or, if you get a faster mouse and monitor for an FPS game, or a game with quick time events, it should improve your reaction time by as much as a 10th of a second. And of course any difficulty settings.
And then, there's the save/load feature, the focus of this blog, which alters the games state completely, at any time. Unless there isn't one, in which it simply impacts the players life, if he needs to leave the game, instead. Either way, once invoked, either by shutting the game down because there isn't one, or by saving it because there is, once the player returns, the game will be altered. Either because it allows the player to start from that point regardless of what happens over and over, or because it forces him to start from the beginning again.

Obiously, it's very difficult to anticipate the invocation of the feature, since it's invocation may not relate directly to anything that is within the game as a product. In fact, it's very normal not to respond to the invocation at all, for that very reason, nomatter where or how it occours.
This relies on a, by now completely ingrained, very specific suspension of disbelief amongst players.
Anecdotally, when disguised as anything but a save-game system, this feature would be looked upon as being completely different; a common system could be percieved as an undo-button which you can press if you anticipated that you might need to press it ahead of time. Omnipressence of this feature, this ever-pressent choice, within the game is at the heart of why it is very difficult to work with. But the bulk of the trouble in dealing with it in any innovative way is the vague notion that the feature is to be treated as special and somehow "outside" the game, which has by now festered and taken root in the public consciousness amongst players, even though it can clearly alter the experience very considerably.

Choosing wether or not to cooperate with the notion is not a difficult choice to make on the surface, as the advantages are many and ample. Many players will appreciate incorporating a traditional save game feature because it makes matching their lives with their gaming. This will largely be casual gamers, and if anybody uses it to improve their abilities within the game, it doesn't really relate to them because those who have the largest benefit from a save-at-any-time system are likely so casual that they wouldn't bother. The most hardcore gamers, of course, will likely choose to limit themselves from abusing the system because they want to play the way it was meant to be played, and somehow they feel that not using the save-game system to their advantage is more "real".

But the downside is that, somewhere in between, there will be a demographic that will likely use it to alter their game state in various ways, and it's incorporation will alter their play experience significantly. For this reason, what to do is not obvious, and because the demographic is difficult to pinpoint with any accuracy, it's difficult to say wether or not it is safe to ignore it. If it composes 75% of players, their reasoning behind using the feature to min-max their chance of doing well should be of no concern. They're your target audience, and you should try to maximize the fun they have; that's why they pay you. Not to fuel your artistic expression, but because they want to have fun. Unless you want to deny them that, you must try to cater to them.

But then...is it really worth maximizing their fun by doing something that will probably also inconvinience 30% of your players greatly? The choice is bipolar. But to me, the conclusion of this discussion is clear: If you want to design good, solid games, you'll put care into make the right decision about what save game system you choose for your game, and you'll take both the fun of your audience, the current perception of the save game feature, and the non-linearity of your game into account.

Now that I feel I've argued how to best approach the problem, I want to go over some different save game systems; I'll probably only blog about one today.

The first system is the no-save.

This is often used with arcade shmup games; it's impossible to save the state of the game, often because games in arcades are simple, easy to play, and revolve around learning level patterns in order to optimize and anticipate events that always occour in the same manner. Also, player death is directly what earns the arcades money, so if the player could skip over difficult sections after completing them once, it would be a less efficient manner of getting the players cash.
Another advantage is that playing the same levels over and over again is how you get good at many shmup games - there is no arbitrary skillset, only how good you are at the specific levels. This no-save system, then, lines up perfectly with what the game is trying to do - make the player feel as if he's constantly improving, getting better. But it comes with many drawbacks too, one of them being that when not alligning

It seems that games with more than 20 hours worth of playtime would be impossible to complete for any single player, as that appears to be the point where most get sick without rest. There have been reports of heart attack and similar ails setting in after 36-50 hours of playtime, for instance.

So there is a theoretical limit to the no-save system, as well as a, presumably, much lower practical limit. An estimate for the practical limit could be as low as perhaps 2-3 hours.

This is where the players behavior comes into play however. Some players will only be able to accept a sessionlength of 10 minutes or less for a no-save system game, whereas some players will be willing to accept much longer sessions without the ability to save their games.

This is perhaps one of the largest problems I've encountered so far in my work on game design patterns. Which demographic groups are able to accept which playsession lengths, and which invonviniences? And if so, does a particular type of content, which attracts a particular demographic group, need to be paired up with a particular kind of save game system in order to optimize the design? And how exactly should your demographic distribution be before you should cater to the convinience of one part, or the fun of another?

Naturally, my greatest interest is within one particular type of game - those with adaptive narratives and non-linear storylines. Sadly, those do not even fall within any one of the commonly accepted genres - and they make up only a small minority of those genres they do fall within. So there's no real chance of finding empirical evidence one way or another.

Instead, I have to approach the problem using only anecdotal evidence collected from various demographic groups. And in order to really capture the possibilities, I'll of course have to go in depth with examples from different genres and what kind of concequences game systems can have.

Oy vey. This pattern will take a while.

The "save" pattern

Many games implement some manner of saving and loading progress and game state. I've been thinking over, for a while, just how these various features affect the game play experience.

Some examples of the pattern are in order:

- A friend of mine played max payne with me many years ago. In my games, max, the titular character, was often limping around on low health, dodging bullets and dodging death with them. In my friends game, he was always stacked with 5 bottles, the maximum number, of painkillers, the games healthpack, and he was always at full health.

The difference was, he always loaded if he got hurt and he had the clear sense that he'd be able to do better. He would replay some encounters 3-4 times on occasion, till he got it "right". I only ever loaded if I died.

The game had an adaptive AI - it would leave a lot of painkillers around for the player if he was hurt, leave few if he had a good stash and he was healthy.

It should be painfully obvious that our different utility of the save game system made for different gameplay. I was consistently running the risk of bumping into an encounter that was too difficult for my hit point level, forcing me to reload over and over at the same place 10 or 20 times. He was constantly reloading nomatter what, but rarely many times at the same place; it would be wrong to say that he wasn't challenged, because clearly, it was more difficult to do every situation perfect rather than only those where max was low on health. But he always knew he had leeway, if it came down to it, whereas I always knew I didn't. Quite possibly, I might even have had easier encounters, and I deffinately had more healthpacks to pick up, than he had, so in some manners I was challenged less.

The point is not that there is a wrong and a right way to play a game. The point is that if you give a utility, such as saving games and reloading games on demand at any time, to the player, you may greatly impact his play experience by doing so. Certainly, you could argue that the how responsibly the player uses it is his choosing, not yours; but if you know that whatever you choose to make for a save game system will effect 99% of the players playing your game, and that 30% of those people will use the save game system to play the game in a min-maxing fashion, your choice concerning the system could make a difference between the game being called good or bad by many players, so responsibility doesn't even come into it.

The save game system is therefore part of the game as a product. So, the application of the save pattern, then, is concerned with a very product-oriented manner of percieving the game. It relies far more on outside context than many other patterns I have described thus far.

As such, boiling it down to rules will take a lot of work, and will likely relate a lot more to the consumer-producer analysis of the game as a product, and the context the consumer provides, rather than the contextual constructs which we, as game developers, provide within the internals of the game.

I'll be fun to write more about this in the future =]