Protecting Games is broken into four primary sections with piracy and cheating having the most obvious relevance. The latter two sections address social attacks from griefing to gold farming and finally a “Real World” section that seems to act as a catch-all covering relationships with third parties, real money transactions and even a brief chapter on terrorism.

The sections on piracy and cheating seem to make up the core of the book and carry with it interesting tips, anecdotes and in some cases psuedo-code that help illustrate a solution to the problem at hand. I actually walked away from these chapters feeling a bit depressed in regard to how monumental these security challenges are. It’s not that you’re left empty handed or unwarned. It’s just that you start to feel like you’re being attacked from all sides and quite frankly, you probably are. By this point in the book you’re ready for a change of pace and chapter 18 (which concludes the section on cheating) comes at the perfect time. Ironically for me, I was hoping for something different than the high score cheat case study which plagues many online Flash games and are of special interest to me. It’s only after devouring the chapter on network attacks that made me want to see more in that category.

What was most surprising was how game design can adversely affect security. By tweaking design documents early in the process there are some issues that can simply be mitigated instead of turning into real dollar problems that affect the integrity of the game and potentially turn away paying customers. Perhaps the author would consider changing the subtitle to “A Security Handbook for Game Developers, Designers and Publishers”. That being said, I should also mention that although the book is targeted toward those in the industry there’s incredibly useful information in this book for gamers and parents as well.

Protecting Games is an excellent security handbook albeit a slightly overwhelming one that deserves a place on the bookshelf of anyone involved in the process of creating games. It arms us with the knowledge we need to make the right choices while navigating through the process of not only an building an entertaining game but a secure one as well.

As a footnote, I was pleased to discover that Mr. Davis did not turn Protecting Games into a 398 page brochure for his SecurePlay products but kept a reasonably neutral perspective toward the topics covered.

Congrats, Steven! Can’t wait to read it.

This is particularly interesting to me as I’ve started development of my own framework for multi-player games.

CARRDS (Control, Action, Rules, Random, Display, State) encapsulates a fundamental issue in developing multi-player games: never trust the client. As developers, we need to assume that any data arriving from the game client is corrupt.

Davis offer a few different implementation designs but to me, only one stands out as being the most solid approach. That approach entails sending client controls or actions down the wire to a server. The server then acts as an interface to the rules and is also tasked with storing game state. In this way, the aforementioned corrupt client data can be thoroughly sanitized before it impacts the state and that state is sent back up to the client.

The alternative to this (and the one that Davis seems to lean toward) is a model where the client hosts the entire engine and it is the actions that are exchanged between each instance. Now you kick all those CPU cycles back to the client and save some bandwidth as well. As he mentions in the article, “Game actions are inherently bandwidth efficient.” I agree. It just doesn’t feel right to leave all that juicy game logic on the client.

I may be naive, but having the rules and state stored remotely makes me feel all warm and fuzzy. I like the idea of having “dumb” game clients that provide two things: A control interface and a display. That all being said, scalability now becomes an issue. What happens when you go from a 100 client load average to 100000 overnight? For the independent game developer, forking out big dollars for more servers may not be an option.

So, what to do?

All in all, there are definitely wrong ways to handle game security but I think the two methods mentioned above aren’t in that category. They both work for the most part and both have their pluses and minuses. This is just one of those issues that seems to become more complex the further you dig into them. I guess that’s why a company like SecurePlay is so relevant in today’s game market.

I’ll most definitely be coming face to face with this issue before too long and it will be interesting to move from theory to implementation.