Journals are your Friend

Stolen Ideas

I like computing. I've been drawn to it since I first got my hands on the TRS-80 Color Computer 2 my dad brought home one day. Over the years I've learned a lot of computing history, and one common theme that I see over and over again is how we borrow concepts left and right from other disciplines. Granted we don't do it so much anymore because computing has matured, but 50 years ago everyone who was working in computing was trained in something else. Something as simple as Cut and Paste is terminology that comes from editing paper documents by literally cutting them with scissors and pasting the text onto a new piece of paper. File system directories are often called folders and in many GUI operating systems they are depicted as manila folders. Which contain files that are in turn depicted as paper. There are plenty of examples of this sort of thing where concepts and terminology are borrowed, but these happen to be two of the most obvious and familiar ones.

The concept I want to steal is the Accounting Journal. There is no way I can claim to be the first to do this since there are loads of games out there that make use of journal data. Any time you see a graph of some values over time, you are looking at data pulled from a journal. It might not be called a journal in the game, but the data certainly is. If you've not studied an accounting course, I'm going to put in a few words on behalf of a teacher of mine, Dr. Scalzo. "You should study accounting so that you will know when you are getting ripped off." By applying accounting techniques to the game it is possible to identify when a rip off (cheat) is occurring.

Cheat and Bug Detection

In single player games this sort of thing isn't so important. If a player cheats in single player they are only affecting their own game play experience, but in multiplayer cheats and exploits can destroy a game. I don't expect anyone to argue cheats and exploit should go unchecked in multiplayer games.

In a perfect world we would all write perfect code for perfectly designed game play. This never happens. Sometimes its a bug that allows the player to repeatedly sell an object that they don't own. Sometimes its an unexpected interaction in the game design that allows for limitless wealth. (In The Sims 2 Open for Business you could get a wholesale discount that allowed you to set the prices on things in your store so low that another Sim could buy them, take them home and sell for a profit.) The point is we need to recognize that these things happen and we should take steps to identify, avoid and rectify the problem. A robust journal system in your game can provide the data needed to identify problems, and depending on how it is implemented, it could even contribute to avoiding them (but that is a topic for another day.)

What is a Journal?

The most basic description of a journal is that its a historical record of values of interest. Many multiplayer games have some sort of in game currency that players use to buy and sell in game items from each other. So a simple journal might track every time a players currency changes. For currency journals I like to track when it happened, how much the value changed, the value after the change and a description of why it changed. These make pretty simple database tables. Now this sounds like a log, but there is a difference. Log files often contain lots of different kinds of messages and a meant for humans to read through. A journal concerns itself with only one kind of event. A currency journal would only track when currency values change. It doesn't track logins for example. The other point is that a journal is data that is in first normal form which makes it ideal for storing in a database and querying it for later analysis. Once a table is designed, all that is needed is to start inserting into it, and you are off and running with collecting journal data.

Data Management

One concern is that if your game inserts frequently to this table you are going to end up with a lot of data. As long as you make a habit of using all numeric data in the journal and avoid using text, the database files shouldn't get too big. Since the data is effectively read only, this shouldn't be much of a speed problem since all you ever do is add to the end of the table. Also you probably don't need to query from the game itself. Most queries on this data would be done by support tools. You might use some lookup tables to convert numeric fields into human friendly text, but lookup tables like that aren't usually part of the core game. If you really wanted to for performance reasons, you could put all your journal tables on a separate database server from the core game data. If disk space becomes a worry, you could also run some simple queries to delete journal entries older than a certain age since each entry should have a timestamp.

What’s this data good for?

What can you do with this data? Its primary use is to detect misbehavior by players. You could query the journal and get all the values for a given player and export that data into something like Excel, Google Docs or Some other program with charting tools. When looking at a suspect players data, a huge spike in their money is a good sign something is wrong, and you know exactly when it happened. Once you know when something happened, you can dig deeper to see if other players are involved or what the player was doing at the time. Without this data, many abuses would be much harder to prove. 

Another possibility is say a users account is compromised and a player contacts your support staff to claim that there account was hacked and a bazillion credits were removed from their account. With a journal in place you can verify the players claim and repair the damage, but you can also see where the money went and start tracking down what other users were involved in the heist. Again without the journal this sort of investigation is nearly impossible.

A third use is data-driven development. Frequently developers here on Gamasutra talk about data driven development. You hear phrases like 'Design on what your players are doing, not what they are asking for.' Having journal data like this is key for analyzing player behavior. It is basically a record of what they are doing. If you don't have the record you can't analyze it.

Other things to Journal

Journals aren't limited to in game currency. You can use them to track just about anything. If you are making a role playing game, you can easily track experience points in a journal. A journal can also track multiple values simultaneously, for example a game that has some kind of resource trading system can track how many of each resource a player has in a single journal entry. Basically any value that changes and that you want to track can be.

Journals can be used in Turn-Based and Turn-less games. Depending on the nature of the data being tracked you can add entries at the end of each turn or whenever the value changes. A RTS game where values change frequently it might be acceptable to simply snap-shot the values at regular intervals.

Do it from the start

I strongly urge considering what data you want to journal and what you can live without during the design phase. If the decision to journal is done early enough you can write your code such that a tracked value can't be changed without being recorded in the journal. It’s much easier to add this support in up front than to add it later. (I know. I've done it both ways.)

I've written (and re-written) my code so that currency values can't be changed without calling the code that writes to the journal. In Object Oriented Programming Terms, the currency is a read only property. A method that records the change is called to change the value. A property setter does not work because a setter only has one parameter, where the journaling code requires multiple values to describe the change. With good object design you can avoid accidentally forgetting to write to the journal when the value changes.

If you are pressed for time, you don't need to create tools to analyze the data from the start. Just start capturing the data. You can always create analysis tools when the need for them arises. But if you wait to capture the data after you need it, you won't have the data.

Conclusion

Given how little work it can take to add journaling to a game, and the benefits it can create, I don't see a reason not to do it.