VOOGASalad

Games are an increasingly important medium in terms of international use, cultural impact, and profitability. Arguably, gaming has 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? Games contain all of the basic elements taught in computer science and commercial game engines are becoming increasingly complex software systems. The focus of this project is not to build commercial quality 3D games, but you will experience all of the same basic concepts by building basic 2D games.

As games have become more popular and can be played on more diverse platforms, tools have emerged to make it easier for everyone, including non-programmers, to design and build games. The goal for such authoring environments is to create a WYSIWYG (What You See Is What You Get) interface, like that of word processors, but the dynamic nature of games and the number of different things that need to be edited makes this challenging. Some popular 2D game authoring environments include GameMaker (the most established), GameSalad (a new example for mobile games), Clickteam Fusion (very polished example from Adobe), Sploder (with different editors for different genres), or even Scratch (a general visual programming environment). The focus of this project is not to build an innovative new programming environment, but you will need a good design to allow the game's content to be created using visual editors.

Specifications

In teams, write a Java program using JavaFX that provides a game authoring environment allowing game designers, people with no programming skills, to build arcade-style 2D video games of a specific genre, using a variety of visual tools and requiring minimal programming. These games should be saved in a format that allows them the be re-loaded by the program for additional editing or deployed, loaded into a different program to be played by a user. The game player might be located on the same machine as the editor or it might get access to the game files via the web.

Example game genres include:

• Scrolling Platformer (i.e., Super Mario Brothers)
• Real Time Strategy (i.e., Warcraft)
• Tower Defense (i.e., Bloons)
• Turn-Based Strategy (i.e., Civilization)
• Role Playing Game (i.e., Evoland)
• Fighting Game (i.e., Street Fighter)
• Puzzle Game (i.e., Atomix)

No matter what genre you choose, 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 or using multiple controllers); the point values of game objectives (e.g., for tuning the game or to make a bonus level); and basically anything else you can think of that might change.

At a high level, this program can easily be divided into the following four components:

• game authoring environment: program of visual tools for placing, specifying, editing, and combining general game elements together to make a particular game
• game engine: framework of general Java classes to support any kind of game within a specific game genre
• game player: program that loads the game data and uses the game engine to run a particular game
• game data: files, assets, preferences, and code that represent a particular game
  

Graphical Authoring Environment

No modern game hard-codes individual levels into the source code. Instead, the programing team actually codes general game action but the levels and characters are built by game designers that place every obstacle, monster, powerup, etc. To make this possible, designers need an interactive environment that lets them:

• place game elements (i.e., starting positions for a level)
• determine the order of advancement (i.e., what level or stage follows the current one)
• setup graphical elements (i.e., the level background or images used for each of the monsters)
• assign reactions to collisions (i.e., what happens when a monster collides with the player)
• assign reactions to interaction (i.e., what happens when a key is pressed or the mouse is moved)
• set instructions, splash screen, player setup, level bonuses, etc.
• tweak settings (i.e., monster hit-points or projectile speed or animation timing)
• load previously created games to be edited again or nodded

Note, the authoring environment should integrate with the game engine, e.g., if the engine represents game specific kinds of monsters by sub classing, the authoring environment needs to be able to recognize that new subclass and make it available to the game designer but not be completely defined by it.

The environment will likely be complex, with multiple screens for different kinds of data entry and dependencies between that data. The problem of providing a flexible and extensible environment that also makes it easier to define a game than directly editing text data is the key design challenge.

Game Engine

Games have many common characteristics that can be shared in a framework so that creating a new game requires only creating things specific to it. Your engine provides a set of Java classes that handle these common tasks in a general way that is easily tailored to any particular game. Common aspects to consider include:

• setting up, running, and completing levels or stages
• rules, interactions, or events
• goals, both small and large
• progression through the game
• behaviors or animations
• game status information
• game genre specific concepts

Note you do not want your framework to be over specialized — each game genre encompasses a wide variety of games and you want to make sure there are plenty of places where the programmer can plug in custom code to build new kinds of features. The problem of providing significant built-in functionality while still making it flexible enough to support a variety of games is the key design challenge.

Game Player

This separate program will load the data for a particular game and, using your game engine, allow a user to play the loaded game. Additionally, it should allow the user to:

• keep track of games' high scores through successive runs of the program until the user clears it
• display dynamically updated game status information (i.e., heads up display (HUD))
• replay the game repeatedly without quitting
• switch games repeatedly without quitting
• see which games are available, including at least each game's name, image, and description
• save their progress in the game to restart later (perhaps only at specific save points)
• set preferences specific to each game played

Game Data

Since your authoring environment (for building games) and your game player (for running games) are not intended to run at the same time they must be independent enough that they do not rely on each other directly. Thus, they should communicate indirectly through an agreed upon set of data files (formatted data files, Java resource files, and media files).

Game Utilities

All teams should design at least one utility component that can be used outside their specific game genre. For this component, you will need to write more generic code, more documentation, and to communicate with other teams in order to understand their needs for your general component to support. Here are some example general utilities:

• Resource Engine: Develop a framework for keeping track and accessing game configuration files, images, sounds, and any other asset files within game. While this team will not be responsible for the specific format of these files each genre chooses, they should provide common tools for accessing data files. The resource system can be even more efficient by managing all game resources, e.g., cache all images and sounds so they are only stored once.
• Interaction Engine: Develop an interface to allow users to interact with games using different input devices than the keyboard (like a standard game controller, Kinect, Leap Motion, or Wiimote). This system should be dynamic so that it can be changed for each game played or, better yet, while a game is running.
• Heads Up/Stats Display: Develop a framework for displaying information the the user needs to see during a game. This information should be updated automatically, displayed in a variety of formats, and automatically positioned within a HUD that is separate from the game screen.
• Anything else your team(s) come up with together ...

Challenges

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 into the project, sometimes even from the start, not simply be added at the last minute. Some ideas include:

• AI Engine: Allow game designers to easily create smart enemies to oppose the player. Note, depending on the genre, this may be easy or extremely difficult. Also, making agents that appear "smart" but beatable is a challenging problem, so providing ways to debug these agents graphically is desirable.
• Live Game Editing: Allow game designers to interactively build their game while it is running. Note, in this case, you will need to embed your engine within your authoring environment.
• Networked Games: Allow users to find networked games that are starting or start one with specific friends. An update at any one computer should be visible immediately to all connected users. Note, this will require agreeing on a protocol of exactly what information to send over the network to represent what happens in the game.
• Shared Editor: Like Google docs, allow multiple people to edit a game's design together. An update at any one computer should be visible immediately to all connected users. Where appropriate, allow users in the same game to chat directly as well. Note, this will require agreeing on a protocol of exactly what information to send over the network to represent the game's design, but it is not as time critical as a networked game.
• Social Center: Allow users to log in, choose an avatar to be used within the game player, 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. Note, this will require a connection to a central database (or files that simulate a database) to keep track of user information that persists beyond the running of a single program.
• Game Data Producer and Viewer: All current high-profile games keep track of what happens during game play and allow it to be viewed so levels can be improved. Note, this will require creating a way for the game designer to choose what to measure in the game (as well as providing standard measures) and then a way to load and visualize that data in a meaningful way later, including comparing two different runs of the game.
• Dynamic Game Content: With fewer people willing to pay for games without trying them first, it is useful to have a model that allows game content to be "unlocked" or updated after the game has been started. Consider different models, such free versus paid for game content, unlocking levels, power-ups, or tools based on achievement or pay, subscription service to enable serialized delivery of levels to create "infinite" games, etc. Note, this will require designing the content of you game in a more modular way as well as designing a general way to provide access to the content.
• Make a Game out of Making a Game: Like MineCraft, gamify the process of creating the game. Note, this will require design of a different kind to determine what earns "points", what the rewards are, etc. Even better will be if this game runs on your standard game engine!

Deliverables

Roughly each week you will have something due and you will meet with your assigned UTA, in teams or sub-teams, to "demo" your progress.

• Team Choice: form teams and set goals
• Sprint 1: plan project, design initial APIs, agree to standard file formats
• Sprint 2: implement basic functionality
• Mid-Project Demo: implement example game, demo and present design to class
• Sprint 3: implement extended features and utility component
• Final Demo: implement variety of games to show off in final demo
• Sprint 4: reflection on the project

Individual Responsibilities

Individually, you have several responsibilities to the team.

This is a large project, and it requires steady, consistent, work. Only if you put in the time each 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

• Understanding Games
  • The Structure of Games by T. Fullerton from Game Design Workshop
  • I Have No Words and I Must Design by G. Costikyan
  • Comparing Computer and Traditional Games Using Game Design Patterns by S. Loh and S. Soon
• Designing Game Engines
  • The Game Loop from Entropy Interactive
  • JavaFX Game Loop by Steven Van Impe
  • The Magic of Data Driven Design by S. Rabin from Game Programming Gems
  • Teaching Design Patterns Through Computer Game Development by P. Gestwicki and F. Sun
• General Framework Design
  • What is a Framework? by M. Clifton
  • Introducing OO Frameworks by Taligent
  • Framework Design Guidelines by K. Cwalina