VOOGA

As a class, break into teams, and create a software system designed to ease the creation, development, deployment, and playing of arcade-style 2D video games, often called casual games. Examples you can draw from include portals like Shockwave, Orisinal, or the 2D games at Xbox Live; "app" sites like iTunes, Valve, or GameMaker; social sites like Facebook, Reddit, or the61.

Sub-projects software system will include:

• General Projects: allow users (i.e., people with no programming skills) to play, discuss, and rate available games (like portals such as)
  • Arcade: 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, 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 for by name, category, or other attribute. The user's history of game playing should be saved so it can be revisited and others should be able to view what's being played right now or played the most. Note, this class will be the main class for the program and thus will need an API to allow them to add their views to the program.
  • Lobby: allow players to log in and create an online identity by choosing an avatar to be used within the arcade (or even individual games). They should be able to 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). An administrator should be able to manage the user list as well, including support for resetting passwords or blocking users. Note, users may be needed by other projects to store useful data about their specific activity and thus will need an API to allow them to add their data to the user.
  • Wall: allow players to enjoy the social aspects of being online by allowing players to rate, recommend, tag, 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. Note, some of this functionality may be needed by other projects to allow their component to be part of the social context of the community and thus will need an API to allow them to add it.
  • Store: allow players to buy new games to add to their personal library and authors to add games that can be bought. 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. Note, other projects may want to charge for their services and thus will need an API to allow them to be part of how a user is charged.
  • Ads: allow ads, images by default, to be displayed on the site on a rotating basis or when some aspect of the interface changes. Ads should be able to be submitted to the project and updated based on a variety of options, including ads that are featured for some reason, or related to what the user is looking at, or timed for a specific event. Additionally, ads may themselves be animations or games that can be played. Note, ads may be included in other projects to be automatically added to the queue when loaded or removed and thus will need an API to allow others to build their own ads.
  • Security: allow users with different kinds of needs to use the site, such as those who just want to play, those who want to develop or sell new games, those who administer the community. Each of these users may have different access to tools or page content. There may also be different ways in which users can change their status, through experience using the tools or by the recommendation of another user, or by the main administrator. Note, other projects may need to defines its own users or privilege and thus will need an API to allow them to create a new kind of user.
• Game Related Projects: allow game designers (i.e., people with minimal programming skills) to mod, deploy, and advertise new video games (like "app" sites such as
  • Level Editor: designing levels for a game is difficult for many reasons: the shear number of objects to create and the difficulty of testing the level's play-ability are chief among them. But these problems are compounded if the game designer must hand-edit a text file to specify appearance of all the level's objects. Build an application that allows game designers to load, save, and edit the appearance of game levels graphically. Your GUI should show conform to standard visual design principles of modern applications (e.g., File, Edit, and Help menus as well as context specific toolbars and preference dialogs).
  • Mod Environment: game companies encourage this practice because different versions of a game add extra play value and interest for purchasing the original 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). Extend it further by allowing users to change variables of game play or even add new rules or behaviors to 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.
    • Examples: Warlords, Battletris, Pongbat, Scorched Earth, Slime games
  • Competition Framework: allow users to submit and run code that drives a game character in a competitive environment.
    • Examples: Robocode, Greenfoot

Note, many of the named games have videos of people playing them on YouTube.

Resources

• What is Software Design? by J. Reeves
• Introducing OO Frameworks by Taligent
• Chapter 2 from Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
• More coming soon ...

Deliverables

• Thursday, December 2, Design Plan is due
  • describe your team's vision for the project (cite specific applications as sources for your project)
    • project's purpose, think of this as the advertising on the box in which your software will be shipped
    • project's functionality, specifically what is of "core" importance and what extensions your team is most interested in implementing
    • project's graphical user interface, including drawn "screen shots" of how you plan to lay out your interface and how you plan to connect the interface to the model
  • describe your team's design plan for the project (cite specific design patterns the will enable your project's flexibility goals)
    • the primary interfaces/classes that will support your design's architecture
    • the API you will create to interface with other projects needs
    • detailed descriptions of how your program will handle three use cases of your choice --- it should be clear from this description which objects are responsible for completing each part of the task
  • describe your team's plans for completing the project
    • each team member's primary and secondary responsibility on the project
    • goals for what will be completed for the first draft, second draft, and final version of the project
    • a justified estimate of how long each part of the project will take to complete
      
• Monday, December 6, first draft of the project's implementation is due for an in class demo
• Thursday, December 9, final design document describing this project is due
• Thursday, December 16, final draft of the project's implementation is due by 2pm, the course Final Exam period
• Saturday, December 18, individual project analysis (one submission per person)