VOOGA

Video games are an increasingly important medium in terms of international use, cultural impact, and profitability. Arguably, video games have also driven many recent advances in computer hardware and are finally gaining acceptance within the academic community as an area worthy of study. And why not? Video games contain all of the basic elements taught in computer science and commercial game engines are becoming increasingly complex software systems. While the focus of this project is not to build commercial quality 3D video games, you will build 2D video games that represent all of the same basic concepts.

As a class, create a software system designed to ease the creation, development, deployment, and playing of arcade-style 2D video games, often called casual games. Video games have many common characteristics that can be shared as a common design framework so that creating a new game requires only creating things specific to it. Common aspects, e.g., models, scoreboards, timers, splash screens, levels, rules, interactions, etc., should be factored out into a reusable game engine that generally supports different game genres, some goals that allow the player to advance through a series of levels, and a separate goal which causes the game to end.

At a high level, this software system should

• allow game designers (i.e., people with minimal programming skills) to create, deploy, and advertise new video games
  From this perspective, it is much like online "app" sites like iTunes, Valve, GameMaker, or even Scratch
• allow users (i.e., people with no programming skills) to play, discuss, rate, and mod available games
  From this perspective, it is much like online game portals like Shockwave.com, Orisinal, or the 2D games at Xbox Live or GameCenter

Sub-Projects

While the class as a whole will be working together, smaller teams will focus on building specific sub-projects that need to work together for the project to succeed. As a class of developers, you will need to rely heavily on each other's documentation in order to figure out how to use other team's projects that you may need to rely on.

Game Genres

Design an object-oriented framework for building video games in a specific game genre. Games should fit into the overall design structure so they can be shared within the arcade but, beyond that, each game genre team can design the internal framework however they see fit.

Each team must complete the following parts:

1. Powerful Flexible Game Genre-Specific Java Framework
   Even with modern high-level programming tools, there is a lot of tedious work to build a game. Provide a set of Java classes that handle these tedious tasks and let the developer get a working game quickly and easily. But you also do not want your framework to be overspecialized --- each game genre encompasses a vast variety of games, and you want to make sure that there's plenty of places where the programmer can add in custom code to build new kinds of features. The problem of providing a lot of built-in functionality while still making it flexible enough to support a variety of games is the key design challenge in a framework like this.
   
2. Level Editor
   No modern game hard-codes individual levels into the source code. Instead, the programing team actually codes the game but the levels are built by game designers that place every obstacle, monster, powerup, etc. To make this possible, the programmers build a tool called the level editor which is an interactive GUI app that lets the designs drag and drop the various chunks of the game, tweak settings like monster hit-points, and setup graphical elements like the level background that the images used for each of the monsters.
   Your game framework should be well integrated with the level editor. You should be able to design a level in the level editor, save it, then go an play the level in your game. Basic characteristics of the look and feel of the game should be able to be easily changed: the graphical icons used in game (e.g., to turn a SciFi game into a political statement); the keys used for interaction (e.g., to accommodate multiple players on the same keyboard); and the point values of game objectives (e.g., to make a bonus level). The level editor should integrate well with custom game-specific code - if you intended to let (say) the game programmer make new kinds of monsters by subclassing a Monster superclass, there needs to be a way for to place that new kind of monster in the level editor.
3. Something Extra
   Do something to stretch your design further and to differentiate your project from others. These extensions must further the good design of your program by being planned from into the project, sometimes even from the start, not simply be added at the last minute. Some ideas include:
   • Physics Engine: Allow game designers to easily use standard physical reactions or define their own style of physics for a game.
   • Networking Engine: Allow users to sit at different computers and connect to a common game session. An update at any one computer should be visible immediately to all connected users.
   • Interaction Engine: Allow users to interact with games using different techniques than the keyboard (or standard game controller), like the Kinect or Wiimote.
   • Mod Environment: This extension to the Level Editor allows users to create different versions of a game amd make them available within the arcade. It gives greater flexibility by allowing users to change variables of game play or even add new rules or behaviors to a game.

Game Arcade

Design an interface users will interact with directly, requiring Swing components for interaction and networking with a central site to achieve persistent, global storage so the entire class can share the same data. The arcade allows users to play all available games and keeps track of their stats in comparison to other users.

This team must complete the following parts:

1. Game Center
   Allow players to pick a game to play and play it repeatedly without quitting and restarting the program. Each game should display its own splash screen, instructions, rating, genre, any setup options it might need, and keep track of a high-score list through successive runs of the program until the player manually clears it. Games can be searched, tagged, or view what's being played right now.
2. Social Center
   Allow users to log in, choose an avatar to be used within the arcade (or even individual games), view personal high scores, and save their preferences (e.g., name, password, image, age (if parental controls are implemented), and favorite games, players, colors, etc). Offer social aspects by allowing players to rate, recommend, chat, or generally collaborate while playing games. Additionally, keep track of social aspects of game playing, such as most popular, recent, and highly reviewed games played.
3. Something Extra
   Do something to stretch your design further and to differentiate your project from others. These extensions must further the good design of your program by being planned from into the project, sometimes even from the start, not simply be added at the last minute. Some ideas include:
   • Administration Interface: Allow users with different roles to have different interfaces. For example, an administrator should be able to manage the user list, including support for resetting passwords or blocking users; game designers should be able to view their games on the site, access the Level Editor to add new levels, or change other data about their game.
   • Networked Game Interface: Allow users to find networked games that are starting or start one with specific friends. Where appropriate, allow users in the same game to chat directly as well.
   • Game Store: allow players to buy games to add to their personal library and authors to add games that can be bought and, also, allow ads to be displayed on the site on a rotating basis or when some aspect of the interface changes. Games prices might be free, a one-time charge, charged based on time played, or via a subscription service; additionally, games may allow for a demo mode that can be upgraded when payment is made.
   • Social Networking Interface: Allow users to connect to actual social networking services like Facebook and Twitter.

Schedule

 

• Part 1: form teams for sub-projects
• Part 2: design initial framework API, agree to class-wide game standards
• Part 3: implement core API
• Part 4: revise framework API based on feedback from initial implementation
• Part 5: improve core API and implement secondary features
• Part 6: implement demo games and interactions
• Part 7: reflection and wrap-up

Individual Responsibilities

Individually, you have several responsibiilities to the team.

This is a large project, and it requires steady, consistent, work. Only if you put in the time week to week will you see measurable progress and not have to pull "heroic" all-nighters near the end. TA meetings each week are designed to help you take responsibility for consistent contributions to the project.

Inevitably, conflicts occur. If there is some one on your team who is not getting their work done or not attending meetings, please let the course staff know as quickly as possible. Even if it has happened just once or twice, it is better to deal with the situation early rather than having a big disaster at the end.

Resources

• The Game Loop by Koen Witters
• Teaching Design Patterns Through Computer Game Development by P. Gestwicki and F. Sun
• Introducing OO Frameworks by Taligent
• Chapter 2 from Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
• Framework Design Guidelines by Krzysztof Cwalina