CompSci 308
Fall 2014		 Software Design and Implementation

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 editted makes that extremely challenging. Some popular game authoring environments include GameMaker (the most established), GameSalad (a new example for mobile games), MultiMedia 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, using JavaFX, design a game authoring environment that allows game designers, people with no programming skills, to build arcade-style 2D video games, often called casual games, using a variety of visual tools, rather than programming directly, in a specific genre. 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:

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); and the point values of game objectives (e.g., for tuning the game or to make a bonus level).

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

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:

Note, the authoring environment should integrate with the game engine, e.g., if the engine represents game specific kinds of monsters by subclassing, the authoring environment needs to be able to recognize that new sublcass and make it available to the game designer.

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:

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 that there is plenty of places where the programmer can plug 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.

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. Specifically, it should allow the user to:

Game Data

Since your authoring environment (for building games) and your game player (for running games) and are not intended to run at the same time they should 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 (a combination of JSON, Java resource files, and media files).

Gson is an open source Java library that can be used to convert Java Objects into their JSON representation and to convert a JSON string back to an equivalent Java object. Gson works with arbitrary Java objects including pre-existing objects for which you do not have source-code.

Game Utilities

All teams should design at least one utility component that can be used outside their specific game genres. 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:

Extra Credit

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:

  1. 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.
  2. 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.
  3. Make a Game out of Making a Game: like minecraft
  4. Dynamic Game Content: free versus paid games, subscription service to enable more levels, etc.
  5. Level Validation:
  6. Shared Editor:
  7. Game Statistics Producer and Viewer
  8. more coming soon ...

Stages

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.

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 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