Monday, January 26, 2009

Devcathlon site mockup

Overview:
This past week my group and I were tasked with mocking up the general features of our game, called Devcathlon. To learn more about Devcathlon, please read the blog post prior to this one or head on over to http://code.google.com/p/hackystat-ui-devcathlon/.

Planning:
Generally, I approached the mock up of Devcathlon like any other website. The parts that go into a website are apparent and can be easily modeled by notable ones like Google, Blogger, or Facebook. It seems to be a must, in today's standards of Web 2.0 to have Ajax functionality and dynamic webpage access and retrieval. Unfortunately, our mockup didn't express those characteristics physically, but the idea is still quite enforced. I thought of the application as more of a social website. So the basis of this application is very much that, it had to be socially adept and capable of growing. Users should be able to communicate with others in a personal or public matter depending on what the situation calls for. Designing the structure of the site wasn't very specific, but it had to be standardized. We simply broke the site into two parts, the public and private domains. The public section of our site is a simple "tour" for any outside user who is willing or just curious to explore our site without a direct account. Of course, for any alien who comes near our site, we restrict them access to certain elements or retract any links that only should be seen by registered users.

Site work flow:

* Public user enters site's home page. He or she is prompted for a login/password.
* User enters a valid login/password, then gets redirected to his or her's profile page.
* The logged in user is able to edit their profile as they please, add/remove/update teams and matches.
* Registered user could also search and associate with existing teams or matches.
* Every user is provided a personal and public profile.
* When a match is declared then it is marked as a user event and should message the user under their recent activities.
* When a user gets prompted by an administrator, then that information is displayed under notifications.

Besides dealing with site administrative tasks, such as creating a user account and modifying profile settings, we also focused on important questions dealing with how the game should work. One idea that I posed (as mentioned in my previous entry) is to possess every user/player the ability to create stories/tasks for themselves as the project/game progresses to a goal/objective. Creating these special “stories” is another way of saying a developer creates an issue on an issue tracking system (Google Project Hosting). Upon generating these stories, other players can either interact or discuss (Google’s issue discussion groups) about a particular subject and trade off ideas through post entries. This way players will interact with other players and thus resolve some obtainable “mini” goals. Mini goals can also be known as a milestones or phases in a project development (stages or levels in games) that give players awarded advances and points for their achievement. All of these aspects are simply ideas, but we have yet to encounter the facts of reality in creating such a world for them to exist in. Hopefully in our next increment of this project, we will dive into those concerns in more detail.

Conclusion:

Mocking an entire website from scratch is particularly difficult since website designers need to anticipate every move. Every form built was either doodled out or envisioned multiple times before getting it right. Most likely changes will be made after the mock up, so I wouldn’t be surprise that we would keep or discard certain elements from the current design. Unfortunately, the only regret I had during this process of mocking was the lack of “mock tools.” I wish we had more open source mock-supported development tools for web development. Maybe they won’t reach the same standards such as high competing tools from Adobe’s Creative Suite, but we need to start somewhere to ease the process.

Saturday, January 17, 2009

What's in a game?

Overview:
In this brief blog entry, I'll explain the concepts of game designing and utilize these tactics to enable a better understanding of my new venture into a project called Devcathlon.

About Devcathlon
Devcathlon is a computer game designed to help improve software development and developers while rating the health of their project. The players include the developers, tech managers, etc, game pieces include the code, quality assurance (QA) tools, etc. Continuous integration is a software engineering practice to help teams speed up their implementation and expected delivery date by providing automation of redundant tasks (such as building code, QA builds, maintaining a code repository, etc.). The concept of the game is derived from a collection of continuous integration practices that should be second nature to most software engineers/developers. The goal of this game is to provide an educational way of keeping a developer on task with such practices. Once the developer sees that the game is not just a way of racking up points and envelop in certain bragging rights, but it also fuels the notion that you are really just competing with yourselves. The self-improvement of an individual will contribute to the overall success and health of a project.

So far, we understand the motivation of the game we are trying to create, but we have yet to capture the attention of what a game really is and how to go about from creating a successful one.

Designing a game

What's in a game? What is the effective game design? The methodology behind the creation of a game is undoubtedly its high standards in the designing process. Let's first define the meaning of a game and the essence of a computer game. A game is basically a contest of rules designed to have multiple players making strategic decisions to achieve a specific outcome (winning). In computer games, the definition is not all that different, it is a software program in which one or more players make decisions through the control of game objects and resources, in pursuit of a goal. The make-ups of a game is fairly simple, yet the complexities lie in the makings of the game. Every computer game consists of players that interact with or against each other to obtain or reach an objective/goal. The players provide a variety in a game. Each player has a personality and it shows as they make decisions in the game. Another resource that's prevalent in this game is the game objects. Game objects or resources are the tools that equip a player in the game. These objects are either given or obtained as the process of the game continues. Every game needs an obtainable goal and objectives leading up the climatic conclusion of a game. The interesting part about the goal of our project is that it is fairly non-aesthetic, very virtual, because it is meant to educate a developer and his team. That is the higher logic of our goal, yet it sets apart from the "mini" goals needed to achieve a higher standing in the game. In a competitive thinking process, you are trying to out think your opponents, and gain an edge in winning the game. In our situation, getting an edge is a matter of how motivated you are to keep up with tasks relating to your development environment. Some questions would be: Is the user doing daily builds like he should?, or Did he make his 1 of three commits for the week?, etc. Is it possible to have a competitive edge in our game without tiring the player? Can we relieve a team by rewarding them for good behavior? In every good game, there is a matter of aptitude decision making on the part of the player. They make decisions to either square against a demon from hell or choose to run away and find shelter to level up. These questions are posed to the player and in relation to the outcome of the game. How will decision making be incorporated with our game? What will we need to give developers a crux in the game where they would have to choose routes? Another matter is the dealing of balance in a game. For example as players play the game, they are ranked on the games scoring report, and from that we rank #1 as the winner of the game. But in our situation ranks are not set, in that I mean there will be times when other development teams who play Devcathlon will have a succeeding or lost for one day. So to say that balance is in the game, then we have achieve at least that much in the process of effective game designing. The other hot topic goal of gaming is the feeling that the player feels mentally "immersed" in the game. Every successful game gives us that feeling of importance for a character and its relation to its environment. As players become more involved to the grounds of what they are trying to achieve, then the soul purpose of the game becomes more apparent.

Conclusion:
When it comes to creating a game then every detailed manner has to be addressed clearly and reasonably. The design process is a key aspect in developing a coherent game. The pieces and the overall concept or objective is primary to when drawing an audience of players. Once a developer has a product concept in mind, the next part is to involve drilling into the details of each subset piece of the game, then analyzing how each piece will integrate with each other as a whole.

Open issues and ideas for Devcathlon
One of my main concerns is regarding the blind processing of pair programming. How will this issue be dealt with? We can probably create options for pair programming and delegate points depending on the difficulty of tasks (changes via code base) and number of participating members. Another interesting topic not mentioned heavily above is the concept of artificial intelligence. Possibly in a more stylized situation will we need such a component where the computer itself will challenge our players rather than just having our players go against themselves. However, one situation would be to supply a "tutorial" of Devcathlon to simulate a good, bad, and okay development project environment given a default sample program event. The process will detail the scoring and correct moves to be successful in the scoring high in the game. Player interaction with other players are somewhat limited to the design of Devcathlon. Possibly communication is dealt with elsewhere from the system, but there is no good way of knowing that. One way to solve this is to have conversational story boards, where each developer is required to write a "story" before hand, to describe his/her intention in a very technical manner (using bullets etc.). Each story will be in conjunction of a task (provided by issue tracking). For every story there is a twist, given exceptions where the story teller doesn't know the ending. So another team member jumps into provide a more complete "ending" to the story. These interactions will be mapped out via issues and marked as "dependent on" another issue number. We can score a project on their effectiveness of communicating with each other and issue management! Of course, this is only a very rough draft of what's to come. Hopefully when our development team gets into the nuts and bolts of this project, only then will we know exactly what is effective or not.


Resources:
http://code.google.com/p/hackystat-ui-devcathlon/wiki/References

Other resources:
The Art of Computer Game Design by: Chris Crawford
http://tinyurl.com/dmug

This online book explains the artistry of creating a game. Although the time period of which this book was written seems old, I have to still consider this a good starting point for any game developer or gamer to grasp. The thing that drew my attention the most was that it provided history about the evolution of gaming and the growth of the gaming industry and users. He starts out giving a good two chapters worth of information about what a game really is and different gaming genres. The author also speaks about the future of gaming and its implications on our world's society. He also addresses many predictions that are very true in our community today. The book also describes the game design sequence which lays out a general sense of what computer game developers can do. The author merely presents his generalizations and habits as suggestions rather than a strict set of processes which readers will find very coping.

A Primer for the Design Process, Part 1
http://gamasutra.com/features/20000630/huntsman_01.htm

This interesting, yet incomplete article dives into the concerns of gaming and the market as to inter-relating things. It follows a more business approach for real world game developers, and makes you pose questions prior to implementing your game. The article serves as a simple planner for effective game designing in the pre-production stages.

Gamasutra
http://gamasutra.com/

Good place to learn and contribute the gaming community.

Java Game Development
http://www.gamedev.net/reference/programming/features/javagame1/

Describes the technical details of creating a full-fledged game using Java as the platform for development.

GameDev.net
http://www.gamedev.net

Is yet another great place to attribute the philosophy of game designing and further education of games.