CompSci 308
Fall 2015
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 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, using JavaFX, design a game authoring environment that allows 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:

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:

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

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:

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:

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:

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