Productive gaming: what if your boss wanted you to play games at work?

If you asked high school and college computer science students what they want to do, I'd wager that a great number, probably a lot more than the industry can support, have at one time or another said, "I want to make video games." Of those, many don't know just what is involved, and very few will go into that multi-billion dollar industry and get that chance. I certainly wouldn't say no to the right opportunity to join in. When I started at my currently place of employment as a student programmer, I had to learn an "ancient" language I'd never heard of before: M or MUMPS. After some light reading, the first thing I started work on to get comfortable with the language was to create a text- and keyboard-based version of "minesweeper" using M. Random mine placement, recursive safe-spot clearing, boundry limits, and all that good stuff. Though I never got it to what I would brand as "production ready," I learned a lot and my co-workers were impressed. To me, engineering is often about solving puzzles, and solving puzzles to create a puzzle game fit me well.

Devcathlon

Now I'm getting another chance to create a game system, but on a larger and more serious scale. As part of the second semester in my software engineering course at UH Manoa my professor, Dr. Philip Johnson, has proposed the creation of a produtivity game called Devcathlon, inspired by the developement game and a Hudson continuous integration plugin. The idea is to link the Devcathlon a game system into the Hackystat monitoring system and award (or take away) individual and team points based on good (and bad) software development practices such as creating unit testing, committing verified code, doing code reviews, and other principles. The goal is to create a game system that is motivation, fun, and productive. It would have foster both competition and collaboration, be fair, be challenging and rewarding, and be fun without being distracting. To achieve these goals requires knowledge of just what aspects of games can be used to create such an environment. Games draw from many different areas to create an enjoyable experience, and people will vary wildly over what whether a game is or isn't fun, as will their reasons. Some of the most widely known games are the most simple: go, chess, etc. No storyline or character developement is necessary. The areas of gameplay are simple grid layouts. They are international, unhindered by borders, linguistics, expensive materials, physical limitations, and copyrights. Go and chess have no element of luck beyond perhaps deciding who goes first. As mentioned in this article, they are fun because of the challenge, experience, and satisfaction gained from playing with a closely matched opponent. Each move opens up thousands (millions? trillions?) of others. Other wildly popular games with relatively simple rules and materials yet a vast possibility of moves, such as poker in America and else where, incorporate the possibility of more opponents, an element of luck and pyscological warfare, as well as real risks and rewards. However for other people, and especially with modern games, it takes a much more complex game system to hold their attention. Some of these elements are mentioned in this article. These games often have storylines, expansive visual and audio effects, complex character development, goal and reward driven design, and anywhere from zero to extensive interaction with others. These are generally geared toward entertainment, and occasionally learning, while games geared toward real world productivity are a bit more rare. Some of the best known such games would be categorized as "icebreakers" and "team-building exercises." The main challenge is usually not the stated game goals, but rather to break people out of their normal routine and spend time (aka money) now to create a better work environment for the future. Productivity games are about the people and product, not the game. "These games don't need winners as much as they need players," says Ross Smith. He also mentions score boards a number of times. The score board becomes the avatars of the players, marking their location on the path toward the goal.

Issues

To develop the Devcathlon system presents a number of technical, balancing, and even ethical challenges. While I'll gloss over the technical issues for now, I definitely want to address the other two at this time.

Balancing in games goes on in many different ways in an effort to keep the rules fair to players without being boring. In roleplaying games, stats are balanced so that a certain player does not have a constant advantage over other players. It generally a question of what one activity or ability is worth in comparison to another. Is breaking the build worse than submitting code with no unit testing? If it is worse, by how much? Depends on the nature of the break? I find this balancing issue interesting because I did a similar algorithm for work. In order to identify a person using their name, gender, date of birth, address, and phone number (about as many data points as tracked by Hackystat) I helped develop and test a weighted point based system. The weights weren't simply that a name was more points than gender since it's far more specific. There were many different conditions that would change other points. For example, if comparing two people shows they have the same address, the first name of the people becomes more important than the last name. How many-points-more-important took a lot of testing. While this kind of medical record algorithm is definitely more important to get right than the Devcathlon system, it shows how complex the systems can get to achieve the right result.

An issue that also jumped out to me was more along ethical lines. To be successful, a group using Devcathlon has to make all of their team a part of the reporting. Some people will be more reluctant. Some will be more distracted or nervous that their performance is being tracked in an additional way. Then there is the possibility of cheating, boosting, questional negotions ("Hey, Good Friend Joe, since you don't care much, can you break your team's build, my team's trying to get ahead") and so on. There is also the issue of instant notifications and reporting. I think this has to be controlled from two ends. Administrators of a particular game can control how often notifications are sent out, but players should also be able to only get notifications as often as they want, and of the type they want. Checking your score 20 times a day could be distracting. The system should update constantly, but have customizable updates to the display ranging from real-time to semi-hourly to end of day/week/project. The truely public boards also have to be scrutinized since development projects can differ widely. For example a hall of fame scoreboard could have categories such as team size(eg 5, 20, 100 people), lines of code (eg 10000, 50000, etc), development time frame (2 weeks, 2 years), and so on so that comparisons can be made appropriately. Addressing and testing such issues allow the game to be more widely used and enjoyed.