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.
While I'm not 100% sure what you mean... web based is probably the best way to go. I actually work on a facebook game, and the client is flash based while the server is in php. There is no drm at all (unless you count flash), however it obviously requires an internet connection and needs to connect to our servers. You can of course do the client completely in html/javascript and communicate with your servers via ajax or sockets to get just as good a client. In fact my boss basically did this with his previous facebook based game and it was quite successful.
If you were able to fund it completely then I guess you could make it open-source.
Can you elaborate what you really mean by that? for instance on the iTunes store (iOS) you can't distribute on the official store without Apple's DRM, but it's essentially non-intrusive. If you're not opposed to using Facebook APIs, they may be your best bet for providing matching, leaderboards, and etc. in a way that's easily accessible from the web, ios, android, and the desktop. Apple has an API that makes turn-based multiplayer and matching very easy, but you won't be able to use that on other platforms, so sounds like you'd be rolling your own.
You will want to explicitly state a license for the users to be allowed to share the product, but not sell it. Also you want to watch your distributors, they will assume that you do not want it to be shared and send out bots to track down "pirates." Alex Jones, of Info wars, has experienced such a problem where authorized content has been taken down under the accusation of piracy.
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.
http://jammerup.com/
Of course, your board game will be DRM free. After all, games that are inherently multiplayer over the network don't need DRM anyway if you're the one who controls the server.
Copyright the game content, Patent the game play, give up now. Make your money with the first couple of months because that's about all the lead time you have. There are lots of people who think that ALL software should be free, and they have no conscience when it comes to pirating software.
There was an unknown error in the submission.
I don't understand the question. YOU are going to be the developer, and YOU are going to be the publisher. Who is going to force you to put DRM into the code? If you want it to be DRM free then write it without DRM. Simple
As you probably already know, if the program is proprietary nobody will be able to determine if the program is DRM-free or not.
I have to agree with the co-poster: this is laughable.
You could technically have some DRM-laden software that stops working for free in 2013 but you have no reason to cater to paranoid players about that. I am sure someone will have fun decompiling your program to check for that, source or no source.
Now, if there is any randomness or hidden information and you haven't protected it against cheating, you (and your non-cheating players) may prefer there are no hacked version flying around. But it doesn't look like it's an issue in your case.
ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
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.
If you don't want DRM, don't use it. (As if DRM has much relevance to board games.)
First you should determine what kind of application you're making. Is it a native application on iOS & android? Or is it a web front end? How deeply do you want to integrate Facebook, twitter, google+, etc?
All the different platforms (hardware and software) have different licensing issues that need to be figured out. It may be that what you'd like to do isn't allowed by one platform or a combination of them. DRM is only a factor on the open platforms (PC & android). For iOS & game consoles DRM is a requirement of the platform license.
As far as users' rights goes, it shouldn't be a factor. Your servers should only keep the bare minimum of information (probably what matches the user is currently playing and the current state of that match). The analytics should be properly anonymized (huge legal quagmire if you don't do it right) and probably best done with a 3rd party analytics system.
From the sounds of it, you're just starting out. Good luck, it's a challenge but it can be rewarding. Get in touch with people that do this professionally, start reading the game design blogs, and depending upon where you live there could even be community meetings. Take a look at existing engines (unity3d being one of my favorites) and see if any are a good fit for prototyping or production. List out all your needs/goals and start making concrete plans for how to obtain them (persistent server side storage, user name & password handling, high scores, etc).