It's Not Fun to Mock Someone

In my previous post, I mentioned that we were going to be working on a game called Devcathlon, based on Hackystat sensor data. Well this past week, I got first taste of what the game is like.

Our task was to create a mockup of the site and walk through the typical activity a user would experience if the game were to be played today. I tried to apply my background in games to Devcathlon. I play fantasy basketball and I thought it would be clever to model it after it. It made sense since fantasy basketball (or any sport) basically compares statistics just like Devcathlon would. What came out of that was:

• A week-by-week scoreboard -- Shows who was in the lead, who has made progress, who has fallen, etc.
• Breakdown of events -- Who contributed to what categories.
• Community Approval of Self-Reported Events -- Let the participants as a whole approve/deny self-reports. Minimum of half of the remaining participants must approve.

Other noteworthy things that came out of our mockup included a drop down type menu bar (that Phillip found) and a developer's card with achievement or badges if you will. The achievements server as a marker for individual excellence. It's fun to collect and used as bragging rights.

As a participant in the game, I think we violated a lot of the events. I didn't start or commit early. DEDUCT POINTS. It felt like we waited towards the last minute. DEDUCT POINTS. The only real positive I felt was commiting often... but only within the last 72 hours. It's hard to apply events such as "Build OK" since we only worked on HTML pages. But overall, I felt we didn't deserve any score higher than a 50, which hopefully isn't high enough to win any match.

Unfortunately, all of us did not know the proper way to set up the project on Hackystat since this is unusual with no Hudson and actual build files to configure the sensors with. So I can't provide a valid screenshot of our projects health. But judging from the log messages, the bulk of our commits were on the weekend. DevTime seems to be the only working sensor and that mostly took place during the weekend too. DevTime could be misleading though since Phillip and myself used Dreamweaver a lot to help create the pages with tables, outside the reaches of Hackystat.


So how did we score? Again I would say 0-50. It could have been in the hundreds had we spaced things out properly. Would we have won that event? Score-wise, no.... I sure hope not. But did our pages turn out alright? I would say so. I know this may contradict the encouragement of good practices. But if the final product is somehow better regardless of method/practices, I think that should be a bonus. Afterall, we don't want to encourage crappy programs either.

Games.... not all fun and games?

When I first heard that our project, Devcathlon, this semester for Software Engineering was going to be a game, I was extremely excited. This is the reason I first went into ICS. I didn't anticipate any jaw-dropping graphics or excellent music to be involved. But I've played games lacking one or even both, and still be fun and enjoyable. Can Devcathlon succeed as one of those as well? Hopefully.

What is Devcathlon?

Thankfully not a marathon or decathlon, because Wii Fit classified myself as "overweight" so I don't think I would have the endurance to participate. But Devcathlon is a game whose goals are to promote good software development practices. Software developers face off individually/collaboratively and attempt to accumulate the most points for a set period. Players are awarded points for positive practices, and lose points for poor practices. A scoreboard will be available to see where each player/team stands.

Events have already been determined and the rationale is based on the rules we try to follow in our Software Engineering course. Examples are commiting early and maintaining high test coverage. A more complete list can be found in the Events Wiki of the project.

Qualities of a Good Game

After looking over the weekly readings provided by Professor Johnson, it seems opinions vary. But there are certain traits that are commonly mentioned. Challenges/Goals, Rewards, and Story/Character Development are some that I recall.

Challenges/Goals

Games that are too easy tend to be short or cannot hold someone's interest for an extensive period. Games that are too difficult can frustrate a player and also lose the player's interest. So a balance of the two is needed. There also has to be an objective for the game to end. If the goal doesn't seem worth it, people may not play the game.

Rewards

A game can be very boring or difficult if the story progressed and no apparent growth or upgrade occurs. Tasks will get harder and your character remains the same. That seems dull. Rewards in the form of powerups, weapons, or new techniques can help reduce the feel of repetition and same-ness.

My Personal Findings

Googling "What Makes a Good Game?" leads to a bunch of hits. Besides the ones already mentioned, most articles refer to graphics, gameplay, and sound. Lot of these seem hard to incorporate at the same level as those at the commercial level.

Replay Value

In an article titled "What Makes a Good Video Game?", replay value was mentioned also mentioned. I think this is debatable depending on the game. Some games with rich storylines don't have replay value but are still considered a good game. I think since our game Devcathlon lacks a strong (or any) storyline, we definitely should try to strive for good replay value.

Other articles with similar ideas discussed:
The Other Eighty Percent: What makes a video game good?

Open Issues (edited 1/19)

Initially I thought it would be cool to somehow incorporate the points toward a more interactive game. But after reading feedback in Professor Johnson's email, it seems to be a whole different thing and direction we want to go in. So here are some thoughts building on what Professor Johnson mentioned in his email...

• Developer's Card
• Building on someone's idea of "bragging rights", it would be cool if we implemented something similar to the Xbox Gamer Card concept. (see below for example)
  
• Determine a list of achievements that a good software developer would accomplish. When a user accomplishes a task, it will appear on a card for individual bragging rights.
• Generate HTML code so you can show off the card on any web site.
  
• Examples: "Committed 25 times without breaking the build.", "Coverage has reached a 100% (minimum 1000 lines) ."
  

• Incorporate Story/Character Development (edit)
  
• At some point, it would be cool to see this "game" be more than just points and texts.
• I originally had an idea of a boxing game and using team stats toward the boxer attributes.