CompSci 308
Spring 2024
Advanced Software Design and Implementation


What if the behavior of your system was largely controlled by the configuration of its plugins? What power would that give you? — Robert C Martin

Submitting Your Work

Use GIT to push your team's implementation to the main branch of the provided, sharedoogasalad_teamNN repository hosted in the course's Gitlab group.

As your submission for this project, use GIT to add, commit, and push the following:

This project is a culmination of your learning this semester and should follow all the design specifications you have practiced in previous projects.


Each week you will have something due:

And at the end of each Sprint:

During the class's Exam Period meeting, your entire team will:


In teams, write two Java programs from scratch using straight OpenJFX that load common data files: one for game designers to build 2D games (Authoring Environment), and one for users to play those games (Game Player).

To simplify your task, restrict the games that can be constructed to a specific genre:

Authoring Environment

Provide a No-Code authoring environment for game designers using interactive, visual tools that require minimal programming, such as:

Note, this program's visible components and their layout should also be easily configurable, determined by data files rather than hardcoded and saved as part of the user's preferences.

Game Player

Provide a game player program that minimally allows users to:

Note, this program can be as simple or complex as your team wants, depending on whether you want to add embellishments beyond simply playing games (like accounts, ratings, comments, etc.).

Common Data Files

No modern game hardcodes individual level data into its source code, likewise your game variations should be determined solely by configuration data files that also activate general game features (i.e., these files should facilitate the use of reflection by general Java code to specify small, game specific code to run). Games should be saved in a format that allows them the be loaded for additional editing or played by a user (perhaps using a separate program that could be run on a different machine where it gets access to game files via the web). The exact format and content of configuration file(s) will be determined by your team, but it must be a standard file type with a parser (rather than developing your own) such as:

Example Games

Create a variety of games (as a team and individually) that differ primarily in their behavior to demonstrate the flexibility of your project's design, minimally:


Additionally, your team must include features from each category below to stretch your design further and to differentiate your project from others. These extensions must further the good design of your program by being integrated into the project through abstractions, not simply added at the last minute as classes or methods that require changing existing APIs or code that should be closed.

Some ideas include:


The many variations typically differ in ways determined by your game or genre that you can exploit to create APIs to allow behavior to be "plugged into" general framework(s). In other words, the core should be a platform that exposes APIs for extending a general game in different ways with concrete pieces, created and combined to make a specific playable game.

At a high level, these programs are multiple views of the backend and can be divided into at least the following APIs:

Ideally, an API should not be changed after it is defined because that affects other's code. If, during the course of the project, an API must be changed, the change and its reasons must be clearly described in a separate file, doc/, that is updated each Sprint.


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

Game MODs have a similar look and feel, but differ only in storyline, and are easy to implement simply by not hardcoding values within your code. For example, Duke-opoly is a variation that can be implemented simply by changing the text and images used in the basic game. A great many Monopoly variations 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 be able to support these simple MODs, and also go well beyond these kinds of variations!

But Monopoly has an amazing number of behavioral variations, that completely change the game play in an effort to tie it into popular trends and products, modernize it, shorten it, or even encourage cooperation. For example:

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

It should be clear from this brief description that a design must be fairly general in order to support any of these varieties without changing any code, by just selecting different subclasses. If you were just building a program to implement a basic Monopoly game, you might have classes called "Utility", "Dice", or "Chance". Instead, your design 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 protocols for how parts of the game interact.

Your task is to create a design that can accommodate many variations in the behavior 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 your design's generality, 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 variations, paying special attention to what they have in common and how they differ. Then figure out a way to design something that captures those differences as abstractions to be used by the common parts such that, by the end of the project, any differences can be configured from a data file rather than special case code with hardcoded values.

Individual Responsibilities when Working as a Team

This project requires steady, consistent, work — only by putting in consistent time each week will you see measurable progress and not have to pull "heroic" all-nighters.

Although this is a team project, everyone has individual responsibilities to the team that can be summed up as follows:

Unfortunately conflicts are likely to occur, so please let the Teaching Team 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 disaster at the end when little can be done to get back on track.