CompSci 308
Spring 2021		 Advanced Software Design and Implementation

OOGA (Object-Oriented Game Architecture)

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 games, but you will experience all of the same basic concepts by building these games.

Today many popular games have an amazing number of variations in an effort to "localize" or tie in to other popular products. Beyond that, many games provide prequels or sequels or people simply make up their own rules to supplement the official ones. For really popular games attempts are made to re-energize it by creating variations that can modernize, shorten, or encourage cooperation --- they are even creating mashups of different games!

Deliverables

Each week you will have something due:

With each deliverable:

Specification

In teams, write a Java program, using OpenJFX, that allows users to play a variety of games within a similar genre. Differences between games must be determined solely by game specific configuration data files (these files can facilitate the use reflection to specify game specific Java code to run during the game, but there cannot be separate setup Java code for individual games). Indeed, one of the primary goals of this project is to identify common characteristics shared by the games within your chosen genre and to design a single framework (i.e., coordinated general classes designed to be extended or to delegate to abstractions that do the actual work) capable of supporting as wide a variety of specific games as possible.

You can choose from the following games or genres:

Your task is to create a design that can accommodate many variations in the behavior (as well as the details) of individual games, while using the basic play expectations within your game or genre to structure your work so the code does not have to be completely abstract. To verify the generality of your framework, you will need to demonstrate games that differ in as many ways as you can think of. If you are not certain about the abstractions at the start, think as concretely as possible about how to implement two different games, paying special attention to the code that they would have in common and the code that would differ. Then figure out a way to design something that captures that difference as an abstraction that can be used by the common parts so that, by the end of the project, any differences can be configured from a data file.

An Example

Consider the (un)popular game Monopoly and its official rules (which most people have likely never actually read) that determine:

Within the goals of these rules, there are tremendous variation that can completely change the game play as seen in variations like these:

These games (and many other Monopoly variants) share common traits, but allow for different behavior within them, such as:

By now, it should be clear that your design must be fairly general so that it will be possible to support any of these varieties without changing any of your code. If you were just building a program to implement a basic Monopoly game, you might have classes called "Utility", "Dice", or "Chance". Instead, your framework should use more general terms to indicate more possibilities, like "CombinableProperty", "Randomizer", and "Action", and allow them to be instantiated with options or subclassed to make a specific kind of game. This is especially important when designing the protocols for how parts of the game interact.

Games that have a similar look and feel, but differ only in storyline are easy to implement. For example, Dukeopoly is a variation that can be implemented simply by changing the text and images used in the basic game. A great many different games have successfully been made in this way (localizing Monopoly's properties has been popular since the game was first invented), but they are exactly the same game. You should support MODs simply by not hardcoding your values, but do not limit your design to support only MOD-style extensions.

APIs

The many variations within your game or genre typically differ in certain ways that you can exploit to create APIs that allow specific features to be "plugged into" your general frameworks, thus providing for the extensibility to support as many different variations as you can. Put another way, the core should be a platform that exposes APIs for extending a game in different ways so that concrete pieces can be created and combined to make a specific playable game.

At a high level, this program can easily be divided into at least the following APIs:

Engine

Games have many common characteristics that can be shared in a framework so that creating a new game requires only choosing the things specific to it. The engine provides a set of classes that handle these common tasks in a general way that can be 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 to 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.

Data

No modern game hard-codes its data in source code, so the configuration of any game variation should be represented using data files. In addition to the obvious simple data variations (like strings or images displayed, point or item values, or size or shape of the game play area), think about how to represent and substitute game rules, interactions, or goals. No matter what genre you choose, basic characteristics of the look and feel of the game should be able to be easily changed:

The exact format and content of these configuration file(s) is to be determined by you, but you must use a standard file type and parser (rather than developing your own) such as:

You will need to determine what data needs to be represented in these files, to load all the data for a particular game and assemble concrete classes, to handle any errors in the data that might occur, and to read and generate them algorithmically. Defining the standards for these files and insulating the rest of the program from your format choices are key design challenges.

Player

Users need a GUI to select a game from the possible options, to coordinate the game play, to display game stats, and to let players know when they lose or win the game. Specifically, it should allow the user to:

This player can be as simple or complex as you are 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 possibly generalizing beyond games completely (e.g., what is the difference between a game and a book when you are rating it?) are key design challenges.

Expectations

Your overall grade will be based on the program's design, the functionality of your games, and the overall complexity of the genre and features you choose to implement (i.e., Checkers or Monopoly are more complex games than Black Jack or Breakout). So everyone should be able to create a complete, well designed, program by picking a less complex game genre if necessary.

To review, the basic specifications are to create:

Additionally, your team must do something "easy", "mild", and "challenging" 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:

Basic
Mild
Challenging

Design Goals

Thinking deliberately about each class' public methods as an Application Programming Interface, or API, for others on your team can really improve how you approach the task of programming and design. One way to view an API is as a contract to provide a service and, once such a contract is in place, developers are enticed to use the API because they know they can rely on its stability. The design of the APIs is arguably the most critical part of designing a program, because it affects the design of other components dependent on them. So focus on organizing your program as a collection of interconnected services that work together.

This assignment provides a context to begin thinking about larger scale design issues:

  1. Develop Programmer's Interface. Change your focus from simply writing code that works to writing APIs, code that serves other parts of the program (other team members) and allows those parts freedom to implement without regard to the internal workings of your code.
  2. Design Patterns. Find the right design to help you solve specific problems and adapt it to your specific situation taking into account its trade-offs.
  3. Data Driven Design. Use data files to drive the flexibility of as much of your code as possible rather than hard-coding it.

Resources

Copyright 2021 Last modified 04 May 2021 Feedback?