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 OpenJFX 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)
• Physics Oriented (i.e., Pool, Pinball, N Game)
• Turn-Based Strategy (i.e., Civilization)
• Role Playing Game (i.e., Evoland)
• Fighting Game (i.e., Street Fighter)
• Coding Games (i.e., Top Coding Games, Corewar, Bot Arena, Osmo Coding)

No matter what genre you choose, basic characteristics of the look and feel of the game should be able to be easily changed:

• graphical icons used in game (e.g., to turn a SciFi game into a political statement)
• keys used for interaction (e.g., to accommodate multiple players on the same keyboard or using multiple controllers)
• point values of game objectives (e.g., for tuning the game or to make a bonus level)
• number of levels, their starting configurations, and the order in which they are played
• 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:

• Frontend Views
  • game authoring environment: program of visual tools for placing, specifying, editing, and combining general game elements together to make a particular game
  • game player: program that loads the game data and uses the game engine to run a particular game
• Backend Views
  • game engine: framework of general Java classes to support any kind of game within a specific game genre
  • 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 modded

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

This player can be as simple or complex as your team is interested in making it, depending on whether or not you want to add embellishments beyond simply playing games (like accounts, ratings, comments, etc.). The problem of providing a player that fits all possible games (e.g., high score can mean the highest or lowest value depending on the game's goals) and generalizing beyond games completely if you add embellishments (e.g., what is the difference between a game and a book when you are rating it?) are key design challenges.

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 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). Defining the standards for these files and insulating the rest of the program from your format choices are key design challenges.

Challenges

Your team must 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.
• 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.
• 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.
• 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 when Working as a 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.

Although this is a team project, everyone has the following individual responsibilities to the team:

• participating in all team meetings
• contributing clean code to the main repository regularly in reasonably sized chunks
• solving at least one "interesting" design problem
• going above and beyond to help another team mate at least once during the project

Unfortunately, conflicts are likely to occur so please let the course staff know as soon as possible — even if it has happened just once or twice since it is better to deal with the situation early rather than having a big disaster at the end when little can be done to get back on track.

Resources

• General Framework Design
  • What is a Framework? by M. Clifton
  • Introducing OO Frameworks by Taligent
  • Framework Design Guidelines by K. Cwalina
• Designing Game Engines
  • Game Loop as a Programming Pattern by R. Nystrom from Game Programming Patterns
  • 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
• Understanding Games
  • What is a Game? by W. Kramer
  • The Structure of Games by T. Fullerton from Game Design Workshop
  • Comparing Computer and Traditional Games Using Game Design Patterns by S. Loh and S. Soo