Ask Slashdot: Freedom From DRM, In the Social Gaming Arena? 71
An anonymous reader writes "My wife and just successfully funded the production of our board game on Kickstarter, and are putting the over-funding toward the development of an electronic version of the game. It's a two player game turn-taking game with pawn movement that we envision being played on a social network (Words with Friends-style) and it's important to us that it be DRM-free. Does anyone have any experience or know of issues we should consider in terms of preserving the users' rights, achieving scalability, and gaining exposure through the ability to interoperate with platforms like Facebook, the iTunes store, Android market, and so on?"
Publish the program under a free software license (Score:5, Informative)
The server is the essential part (Score:4, Informative)
Every game in Apple's App Store has DRM, it's part of the system. You can make the source available as well though, so your users have the ability to make modifications to the client or port it to new devices. Put all the intelligence in the server, that way the client is simpler and you don't have to worry about people cheating by modifying the client.
For scalability, since this is based on a board game I would guess the number of players per game session is relatively low, which makes scaling easy: you can start new game sessions on the server with the lowest load. More difficult to scale is the matchmaking, where you do have to deal with the total worldwide number of players. Perhaps you can create a hash of the user ID and use that to determine which server handles authentication and status of users, like buckets in a hash table.
For deployment, I think this is one case where cloud computing is a good match: you can bring up move servers when there are a lot of players and bring them down again when demand is lower. This is especially useful if you get a lot of players when the game is first released or got some media attention but the number doesn't stay high; if you would buy your own servers you would be stuck with a lot of capacity that you don't use anymore. Ideally you'll either have the ability to migrate games between servers or a time limit on game length, so you can force games off a server when you want to shut it down.
Don't spend too much time on designing the perfectly scalable system though: a game with scalability issues is still better than a game that is never released at all. One thing that allows you to correct your mistakes is to make the client and server negotiate a protocol version. This allows later client versions to use a protocol version that is more suitable for scaling. If needed, you could even stop supporting old protocol versions at some point and instruct the user to upgrade the client.