Devcathlon: Mockup 2.0 badges and levels

Introduction Ongoing development of Devcathlon, we started mockup 2.0 which includes the addition of badges, levels, and more events. The mockup6(old) group includes John Ancheta, Phillip Lau, and myself, at the 11th hour John came up with the neat idea of incorporating Devcathlon with the Hackystat Project Browser. Mockup 2.0 John's idea was to build Devcathlon into the Hackystat ProjectBrowser adding on the Game Master page, badges, and levels page. My Game Master page is an ongoing design which handles some of the scoring in Devcathlon. The game master should be able to promote or demote a developer's level and award badges outside of the automated scoring system. The goal is to be able click on a level or badge, along with choosing a player's name and the developer will have a new level or badge appear on their profile. With mockup 1.0 the Game Master was more of a system administrator adding projects and teams to Devcathlon. It was decided, because Devcathlon is tightly bound to Hackystat player registration was not necessary. To participate in Devcathlon a developer must be register with Hackystat. Sorry to those who wanted to enjoy the excitement of playing Devcathlon. Events Thinking up a new event is difficult and requires heavy thought it is not a simple as it sounds. I thought it important to keep track of the ratio of development time and the number of commits. For every hour of development time there must be at least one commit to the repository. If a developer does not make an upload after coding for a hour they lose so many points and the point loss will be incremental as programming time increases. During a development an issue could pop up that requires the learning of a new language or technology. A player could earn points, a level bump, or badge for successfully implementing something new into the system. As students we hope the development of a system like Devcathlon will assist us in getting employed. I know of at least two local employers who are aware of the content in Professor Johnson's ICS 413/414 Software Engineering classes. Big bonus points for the team that gets noticed by the folks in the professional computing community. Checkout the Events page for more information. Badges and Levels Philip is handling the badge and level design. A player will earn a badge after scoring so many points. You can see the detail of the badge system by clicking on the images on the right. For the level hierarchy Phillip chose a military theme. A level will be awarded to a player after earning so many badges. For instance after earning 10 badges a player will earn the rank of PFC. Team Scores Because of Devcathlon is still in mockup stage there are no builds to break or no worries over coverage at this point. The SVN sensor is not set up for mockup 2.0 so none of the commits are tracked. Team mockup6 had 3 team meetings, made commits, and spent time developing the mock pages. The point system is not set yet but I would say mockup6 has over 80 points. The chart above represents the total amount time spent developing mockup6 on Eclipse from January 27 to February 3 which was a total of 5 hours spent writing html script. What the chart does not show is the time spent meeting and mulling over badges, levels, and events. Phillip and John probably used other tools that are not tracked by Hackystat to develop their pages. In order to score John's and Phillip's development they need to self report the time spent coding or designing. All of the Hackystat sensors are not in place so not all of the data is being collected for scoring. Conclusion Mockup 2.0 is moving the team towards doing some heavy duty coding. Devcathlon is starting to take shape, I am excited to get started and get this project working.

Devcathlon: mockups

Introduction The Software Engineering II class is in the initial phase of developing Devcathlon. The class has broken into groups and creating mockups for the game's interface. Currently the user interface is written using html as the game will be tracked via the internet. Events As the team went through the mockup we needed to assess where each step applied to an Event. Some of the events that stood out.

• Commit Early
• Commit Often
• Don't wait till the last minute
• Collective Ownership
• Pair Programming
• Team Meeting

The team did not start working on the mockup until Friday afternoon so we did not have an early commit. We did pair programming and was able to get a decent amount work done, which would have scored us a fair amount points. However, because we did not get an early start we lost 2o points. Point Assessment At this point it is difficult to know if the mockup1 team won on points. I do know team mockup3 score 10 extra points because of their early start on the design. However, looking at the commit log I did not see a lot of activity until Sunday night. So I think all three teams should have a deduction of points for waiting till the last minute. Issues Some of the issues I encountered during the coding process.

• Keeping track of development time while not connected to the web.
• Keeping developers honest with pair programming and development time.
• How to handle administration, how much control to give the Game Master.

The issues will be ongoing and probably will require tweaking when the game is in play. To handle pair programming both developers must independently verify the session by choosing their names from a drop down list and either choose date from a menu or input the date into a form. Dealing with a lone developer who was without a web connection is a little tricky but is something that can earn points. The Game Master must be able to add or deduct points at his or discretion. That way any coding without a web connection can still earn points as long as the administrator verifies the code. Conclusion I wish we had more time for the mockup design there were some issues that required some thought and discussion which led to a late start on the coding. I hope the team can pull this project off because it seems interesting and deserves to reach its potential.

Introduction to Game Design

Introduction For the ICS 414 Spring 2009 development team, we have been given the task of developing a game. The game is called Devcathlon, which turns the programming process into a game of sorts where programmers score points for good deeds. But the major point of Devcathlon is to use gaming concepts to foster better development practices. The Devcathlon The purpose of the Devcathlon is to turn software development into a score-based game. Points are awarded to developers and their respective teams when they perform a positive event on a given project. Likewise, points are taken away should a developer cause a problem with the build i.e., break the build. There are various events that fall into the field of play here is a sampling of the events that will earn or lose points in Devcathlon, here is the full list.

• Commits to the system are done often.
• Verify the build locally before commiting.
• Work as group, do pair programming whenever possible.

An excellent example of turning the programming process into a game was done by this development team who awarded fake money to the proper execution of tasks making a commit without build failure. At the completion of the project, using the fake money developers could bid on mp3 players, trips to vegas, dvds, etc. For senior management the end result was clean builds, a cohesive unit of programmers, and a decent product. Game Design Game development is about as complex as any business system development as there many issues to tackle. Before the team can begin coding there are numerous details that must be considered.

• What kind of game is going to be played?
• What does the field of play look like?
• Who are the participants?
• What are the objectives?
• How complicated should the game be?
• What are the rewards?
• How does a player score points?
• What happens to the loser?

The team must understand the games rules and objectives so they can write the proper code. As the team transitions to the coding phase several key points must always be questioned.

• Is this game entertaining?
• Is the game challenging the player?
• Is the game overly complex?

There are probably more elements of the design that must questioned but the above are the things that stand out in my opinion. http://gamasutra.com/features/20000707a/huntsman_01.htm This site is geared towards video game design however, I thought it posed important issues when considering the front end of Devcathlon. Such as how difficult is the game? Will the participant be able to the understand the overall concept out of the box? Obviously, Devcathlon will require some explanation before the developers can start playing. http://www.sloperama.com/advice/lesson13.htm Another video game design site that talks about laying the foundation for the game. Devcathlon needs to start somewhere and the team cannot start coding without some kind of direction. A decent game has a plot and/or objective. In order for Devcathlon to be interesting for its participants the development team should brainstorm to come up with a list of ideas. Also, checkout the flow diagram and thought it would be handy for when it comes time for development. http://ravendsg.com/video-games/game-design-theory-video-games-development-2/breaking-down-a-game-interaction/Ray/2008/06/19/#more-62 This site points out what is needed for Devcathlon to be playable. In order to understand what the game is about and how it should be played the player needs a certain amount of information. Without the necessary info how will the participant know the rules game or how to score points? A good game must be interactive, the player should have a certain amount of control during play. Devcathlon is not a video game where the player gets to shoot bad guys. But the developer's actions through the coding process will be their interactivity. For Devcathlon to be satisfying for its participants it needs to have some sort of feedback system i.e., a way to earn some kind of reward. http://www.vancouver.wsu.edu/fac/peabody/game-book/Coverpage.html The site is primer for game design which will come in handy when laying the foundation for Devcathlon. http://www.randomterrain.com/game-design-gameplay.html Keep the game fun and simple! The point of playing a game is to have fun. A person is going to lose interest if a game is not fun or overly complex. In my estimation Devcathlon is way to make application development lively and interesting. So there should be some kind of mechanism that makes Devcathlon exciting for the developer. What that exciting piece is, has not come up yet, the team still needs to brainstorm. Devcathlon does not need to be a convoluted system where players need to have a wacky button combination to score points. The overall design should be simple yet challenging enough for everyone involved. Open Issues Pair Programming To verify that more than one person participated in a programming session all members have to verify in order to get their points. Two or more developers would not cheat right? Rewards There has to be more to Devcathlon than just the high score and bragging rights. Perhaps a tiered extra credit system? Fun factor One of the more troublesome aspects, from my perspective, of Devcathlon is the fun factor. I guess once we start developing the fun part will be clearer. Conclusion I am not sure whats in store for the team. It will be interesting to see what we come up with and I am hoping we can develop something that will be fun for everyone.