Digital Rights Management (DRM) is not a new concept, and it is not exclusive to games, but DRM in games does exist in various ways. HowStuffWorks has an informative article on the history of DRM and various techniques it employs (http://computer.howstuffworks.com/drm.htm). Put simply, DRM is any method employed by an artist or publisher of digital content (music, movies, games, etc.) to eliminate or at least decrease the pirating of said digital content. Some examples, not restricted to games, would be a publisher controlling the amount of times digital content could be copied, the amount of separate computers that could access the content, or writing code onto a CD that deliberately confuses copying/ripping software. In games, DRM is handled inside the software. Some part of the game enforces the protections the designers have placed to handle piracy. Games may need a unique code before playing that is only available on the CD, for instance.
However, until now, DRM has not been utilized through the game controller. The practical side of this makes sense—some games can be played with either a joystick or keyboard for instance, and controller-side DRM would mean making two protections for only one game. But blow that away for a minute and consider this: how could a controller-side DRM scheme be feasible? One way is with old-style arcade game setups, where the game was housed in a large cabinet/desk type contraption. Think video game arcades. Those would have been difficult to steal (can’t exactly stuff one in your pocket), and even if that copy of the game itself was stolen, it would be designed to run on anything except the large arcade machine. So, design a game to work with one specific controller, and make that controller impractical to steal. This is how I’m looking at DRM for this project.
My project will take the form of an arcade game housed in its own housing. The main DRM aspect will be handled with two turn key controls (turn a key to activate a sensor) set on opposite sides of the housing. Why two keys and why on opposite sides? That leads into the second design aspect, that this arcade game and housing will be built to make it unfeasible for one person to play the game alone. Thus, this will be a cooperative arcade game. But where most cooperative games feature separate characters to control, this will feature only one. Two players will therefore need to communicate quickly to control a single character through the maze/arena filled with hostile objects to eventually defeat the final boss character (huge amounts of health and attack power—standard boss character concept). More on this two person setup later. Through this communication and camaraderie, the players will hopefully be less tempted to pirate the game, just in case the controller setup is not deterrent enough.
According to the article linked earlier, a successful DRM scheme aims for three things: establishing copyright, managing distribution, and controlling what a consumer can do with that content. This game controller establishes my ownership of the game through its presence and, well, control over the game. Because this game will be set inside the code to only recognize this controller, the housing controls distribution. And finally, the players can only do what the controller will allow, and the key turns bring this point home. The controller controls not only the game, but access to the game. The idea is that the arduino program that sends the sensor input into the game for actions like moving, shooting, equipping items, etc. (as seen in the class demo) also keeps track of the time between key turns. Both players turning their respective keys together (keyword—both) resets the timer (an LED bar on the housing can visually inform the players of the time remaining). When the timer is reset, it starts counting down again. If the players do not successfully reset the timer before it runs out (say, if they are too engrossed in the game to remember), then the controller will stop sending signals to the game until the timer is reset. Are the players fighting a group of enemies at the moment? Well, they get to scramble to reset the timer by simultaneous key turns while they watch their character getting pummeled onscreen. The game waits for nothing in that respect. With the non-pausing in these moments, the near simultaneous key turns required by both players, and the LED bar showing the timer’s progress, this project will hit the players in the face with the fact that DRM is put in place to crack down on unauthorized use, whatever the developer says that entails.
While some might comment that this system bears a resemblance to the old style arcade machines requiring pay to play upon starting a new game or to continue a game upon death (put in a quarter to begin or resurrect yourself), this is different in one key way. The game has no idea if the keys are being turned, and does not care, hence the non-pausing nature. To be clear, the controller (arduino) handles that aspect, both in timing between key turns and whether or not to send input signals from the players into the game. The game chugs along regardless.
Here, you can’t circumvent it; it’s physically built into the project, more specifically the controller for the game. Just to keep the players on their toes, if they successfully reset the timer without letting it run out several times in a row, the timer could become random. The DRM measures here, with the timed and cooperative aspect, thus become a sort of game on their own, albeit a much simpler and slightly annoying game—winning that game means you get to play the. And it is supposed to be slightly annoying, to keep it in the players mind. Forgetting about the key turns could lead to potentially disastrous results for the players, so how will they deal with this obstacle? Will one player try to play the game and turn both keys on his/her own? This will be impossible because of the key placement on both sides, but the controller or the game can’t physically stop them from trying. Will two players quickly turn the keys before the time runs out? Will those two players enlist two other friends to turn the keys for them? Either way, the keys must be turned.
Which brings up the difficulty built into this controller’s/housing’s design. Why key turns? Sparkfun.com does have a turn key sensor available, but they also have different types of buttons. Wouldn’t slapping a button be easier to operate then the action of putting an attached key into the slot and turning it? Yes, it would. Which is exactly why I’m using the key turns. Key turns can be done quickly without memorizing a code or something complicated, but they force the player to perform an action different from what’s in the game. The controller sensors and switches whose inputs are sent into the game are similar to regular controllers’ inputs: buttons, knobs, and joysticks are all available through Sparkfun and can be hooked up to the arduino, and these are more familiar to those who have played arcade games. Key turns are not, key turns require different movements the shifting a joystick or punching a button. Key turns force the player to confront the DRM system set up for this game, pull them away from the game for just an instant, and remind them “big brother controller” is monitoring their playtime. The article linked earlier mentions that a good DRM scheme is transparent, that doesn’t shove its existence in the consumer’s face. Operate in the background as much as possible, the article says. Well, this is one area of DRM that I’m purposefully ignoring, and even going towards the extreme in the opposite direction. The player will know, and if they realize this and still keep playing because the game grabs them, then this project will have succeeded.
*mention actual artistic details, large components fit in with slight annoyance/unusability while still remaining entertaining and eye grabbing
*pertinent links to sparkfun.com components mentioned would be helpful
*what has been done already and what still remains
Arcade game and housing (my project will look different, but is based on this build concept). Two players side by side, one controls the direction of movement and firing the selected weapon. The other controls the player orientation (which the movement direction is relative to) and selection of current weapon or item.
base inspiration (not the game, but the physical build)
Physical Computing, Round 2 