Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Too often game developers miss the opportunity to do statistics on save games. I will go through how this should behave to the player, and then the implementation for the developer, and point out the benefits for the publisher, and how cheap it is to add.
Too often game developers miss the opportunity to do statistics on save games, so here is my advise to them/you (And I hope the players out there ask the developers to read this article over as well, as this will improve your future games!).
Roger Hågensen considers himself an Absurdist and a Mentat, hence believing in Absurdism and Logic. Has done volunteer support in Anarchy Online for Funcom. Been a Internet Radio DJ with GridStream. Currently works as a Freelancer, Windows applications programmer, web site development, making music, writing, and just about anything computer related really. Runs the website EmSai where he writes a Journal and publishes his music, ideas, concepts, source code and various other projects.
Let us first go through how this should look to the player.
The player reaches the end of the game
A final save is made by the game (aka game completion save)
The player is asked "Do you wish to submit your save game statistics so the developer can improve future development?" or similar to that.
If the player choose yes the save game is submitted, if not then well nothing special happens.
Roll credits as usual.
Alternatively prompt the player after the credits (hopefully the credits can be skipped).
For the developer it's similar but slightly different.
Before (or after) the credits prompt the player if they'd like to submit the save game to you.
If the player agreed then convert the savegame to xml, compress it using zlib (deflate), and send it to the server.
If the server gets a save game from a non-authenticated (i.e. non-legit) game owner then discard the savegame (or store it in a separate database).
If the server gets a save game from a legit owner then decompress it and add the new save game from the xml.
The submitted save game will be stored under a player ID, this ID should be non-identifiable except being able to tie the save games as belonging to the same player.
The save game entry in the database might also store geographic info, and potentially age.
To preserve privacy of the player the max details that should be stored is the savegame (items, choices made, playtime, deaths, retries, etc.), geolocation, age, male/female, and if the savegame belongs to the same player as these other savegames. Things like name, address, email, player account, forum account, birthdate, social site account, etc. should never be stored.
What can a developer use this data for?
Regardless of the game (it could be huge games like Mass Effect or Dragon Age, or tiny ones that are over in less than an hour) the answer is simple, improve the game (patches, DLCs, expansions), or improve the sequel upon the previous game, or improve future/other games, and at the very least it will allow the developer to improve in general.
MMO games do this constantly as the "savegame" is stored in their database directly, I doubt there is a single MMO out there that does not do statistics on the player's characters to help decide on future direction of content, items, quests, or other games they are planning/working on.
But for single player games this is very rare. I believe Valve was one of the first to do this on a large scale, and they tracked a whole lot more than the savegame (including people not completing the game) which might be overkill, they also ran surveys in addition.
BioWare also tracked the savegame (at the very least), in the Mass Effect franchise. I'm not sure exactly what they tracked otherwise though.
A game like Mass Effect 2 supported carrying over a save game, thus the playing of Mass Effect 2 would change dramatically, and the same is true for Mass Effect 3, choices you did in the previous game will affect whether a character is or is not alive in the next sequel. This is great for games like Mass Effect etc. However not all games are sequels and if they are then the story of the sequel may not allow that kind of flexibility.
But allowing players to submit the save game at the end would allow the developer to take this into account for their sequels even if they do not let the player import the save from a previous game.
For example if 90% chose to save the princess then the sequel could assume that the princess is alive based on the save game statistics. It would give the writer something to work on, something that the players would most likely agree on (as that was their choice).
Likewise if a game had a good and evil path and that players for some reason hardly ever took the evil choice at a certain point. In this case as a developer you could do a quick Q&A on the community site/forums and ask players why this is... Maybe a bug prevented them from doing so, or that it was too obscure, or that it felt silly to do so, or out of character.
Or maybe your game is mostly about a good hero, but the developers did add the chance to be evil at times, but with a ending that is basically a good guy ending. But if they had save game statistics they might see that around half the players (or possibly more) enjoyed taking the evil paths or choices, so maybe lacking a evil triumph ending might have hurt the endgame reward for the player.
Studying (i.e. statistics) of the contents of the player inventory might also be revealing.
If only 0.01% of players used certain items, then maybe not including them in the sequel or other games will save the artists some development time.
It's also possible that items that was just thrown in there during spare time turned out to be popular by over 75% of players.
Or that every single sword was used equally frequent, possibly suggesting that artists designing swords normally may not be worth it, and that making a procedurally generating sword routine would open up for an endless amount of sword choices (Fable III seems to be doing this).
So what can you do with all those statistics you can get from this? (for you bullet point folks out there)
Make sure that DLCs fill in or strengthen weak areas or amplify popular ones.
Helps you avoid potential mistakes in an expansion that you would otherwise have made by just making assumptions on what players did.
Helps guide you in where the story of a sequel should go, if the players hated a NPC maybe having that NPC gone from the sequel or letting them kill that NPC would make the sequel even better. Or maybe even make the NPC the antagonist.
Helps you drop items from a sequel or future non-related games that players hardly ever used. Or help you spot items that surprisingly enough "everybody" seemed to use.
Fine tune skills and attributes, if almost nobody took the lockpicking skill but instead choose to blast down doors then the next game with a similar style might just drop the lockpick skill, either that or design the game more towards using that skill (It's a game designer choice after all).
More benefits are spread throughout this article, and I'm sure there are a whole bunch of other benefits I missed. But the message is...It helps you make better games!
You may wonder if doing this will complicate development of a game. And I say that "No it will not!".
Most games currently track enough things in the save game to allow a player to quit the game and start it again, and upon loading the save game the game's state is restored to almost exactly what it was before the player quit. All items, location, choices, quests completed, dialog choices, skills, etc. They are all tracked.
So converting a endgame save to XML isn't that much extra work. Why XML you may ask? Well, because a future patch, DLC, expansion, may change the binary savegame format, it is assumed that if the game can load the savegame then it can convert it to XML. During conversion you can toss away/selectively grab stats you need. A binary may also have dead space in it that you do not want.
An XML is structural text, so it can easily be converted and imported into any database out there for statistical analysis. XML should also compress quite well using zlib (deflate) or similar for quick uploading. Also since most games tend to change the savegame binary format from game to game, the XML intermediary format makes the import/database backend more robust so that only minor changes are needed to do statistics for each game's savegame database. Or even cross-referenced statistics from multiple games.
Valve and BioWare already do this to varying extents. But I think everyone should do this. Even if you do not plan to make a sequel it may still help you when making your next game, even if the next game is in a completely different genre. Small developers may prefer discussion forums, and that might work well, but many players do not feel like posting about evry little detail. And the larger the game, the more people that play it, the more likely it is that they do not wish to speak their mind on the forums (being lazy is also a factor, I'm in that category myself), and many people do not wish to be bothered with surveys which take some time.
But clicking a "Yes Please!" or "No Thanks!" button at the end of the game is something that only takes a second.
And many times this will let the developers know more about how you liked or did not like the games specific elements, than we would ever write in a forum post.
So now I'm expecting to start seeing a feedback box at the end of future games, asking:
"Would you like to anonymously submit your savegame to the developer to help them improve future updates/content and other games?" "No Thanks!" "Yes Please!"
(C) Roger Hågensen, 26th August 2010. http://www.EmSai.net/
(This article is a Gamasutra exclusive for now, but might appear on EmSai in the future.)
EDIT: Nick Breslin wrote a nice follow up article where he gives some nice ideas on statistics during initial development and during play otherwise as well. Thanks Nick.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
