Phil Peron Flash Platform Developer and Game Development Hobbyist

CARRDS for Game Protection

The latest IDGA quarterly features an article authored by Steven B. Davis, CEO of SecurePlay and provides an overview of the CARRDS framework. This framework is meant to alleviate much of the problems inherent in any multi-user system but specifically, multi-player games.

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.