Slashdot Mirror
Ask Slashdot: Freedom From DRM, In the Social Gaming Arena?
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?"
XML. You need lots of XML. No such thing as too much XML.
Make sure that your electronic versions can all play together, so that people don't need the same version of the device to play against their friends.
It may seem like a dumb request, but most Windows, OS X, Xbox360, PS3 and Wii games don't seem to understand this simple concept. Maybe it's companies who want to keep their users inside their own walls, I don't know.
If it's successful, zynga will clone it, and dump money into it until your version is forgotten. If you're not successful, you're not successful. Either way, you lose your investment in the electronic version.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I recommend the AGPL version 3 or later; this license will preserve the user's software freedom and keep users on a level playing field with you. I also recommend enforcing your license. The Software Freedom Conservancy can help you enforcing your license with the assistance of experienced GPL enforcers. As you probably already know, if the program is proprietary nobody will be able to determine if the program is DRM-free or not. If any distributor discriminates against free software, you can choose not to do business with them.
Digital Citizen
Keep user information at a minimum inside your game. If you are not going to handle payments directly you only need an alias (username, not the real name), a password and maybe an e-mail. At the database don`t use default ports and restrict database users to access the database only through the IPs your servers are into, you should avoid using the domain names at the database configuration if you use static IPs.
Scalability can be tricky. I never faced this problem directly but I`m aware that AWS is a good choice most of the time. For now I use vps.net for hosting of small servers. Worst case you will have to make a server front-end to manage incoming connections and redirect them to a lightly loaded "shard", so you can keep everything simple for the user at the end.
To get exposure you have to actively ask people to participate into the evaluation process. Ask for likes and shares on Facebook and ask for a 5 star classification at the IStore. If people like your game they will comply. Just don`t get overboard with the number of requests (one every 3 matches should be good but is a wild guess depending on how log each match is) and keep it simple (direct links to the evaluation page).
This combination doesn`t exist: ETIs that know about humanity and want to see us dead. Otherwise we wouldn't exist.
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.