OOGASalad

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, shared, oogasalad_teamNN repository hosted in the course's Gitlab group.

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

• doc folder: all design documentation and any supporting images
• src/main/java folder: all project code
• src/main/resources folder: any images or program resource files
• src/test/java folder: all JUnit test code and test specific configuration files
• src/test/resources folder: any test specific configuration files
• data folder: all example game configuration files
• top-level (no separate folder): project README, and otherwise no other files created by you

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

Deliverables

Each week you will have something due:

• Plan: plan project, design APIs, agree to standard file formats
• Sprint 1: implement the most basic version of the APIs, focusing on a simple, testable, core
• Sprint 2: implement the team's planned first priority features
• Sprint 3: implement the team's planned second priority features
• Complete: implement the team's complete functionality
• Demo: create additional example data files and record a demo of the games chosen to show off your design's flexibility

And at the end of each Sprint:

• your team will demo their incremental progress to the class
• individually you will reflect on your progress and teamwork

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

• demo the final version
• present your design
• review your progress on as a team

Specification

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:

• Basic games: these games are each relatively easy to implement, so these options would focus on many different game variations within the genre
  • Card games (e.g., Poker, Solitaire, Uno, etc.)
  • Video games (e.g., Centipong, Tetris, Tower Defense, etc.)
  • Grid-based games (e.g., Bejeweled, Candy Crush, etc.)
  • Block pushing puzzle games (e.g., Atomix, Sokoban, Rush Hour, etc.)
    
  • Physics-based games (e.g., Pinball, N-Jump, etc.)
  • Scrolling Platformer games (e.g., Super Mario Brothers, Doodle Jump, etc.)
  • Strategy games (e.g., Checkers, Connect4, Othello, etc.)
  • Google Map games (e.g., seven examples, ten more examples, Worldle, etc.)
• Complex games: these games are each relatively complex to implement, so these options would focus on the many variations possible within a single game
  • Card games (e.g., Trick-based, Fluxx, Slay the Spire, etc.)
  • Video games (e.g., Pac-Man, Street Fighter, Plague Inc, etc.)
  • Grid-based games (e.g., ChuChu Rocket, SpaceChem with suggestions and tournaments, etc.)
  • Physics-based games (e.g., Pool, Angry Birds, etc.)
  • Scrolling Platformer games (e.g., Zelda, Evoland, Warcraft, Civilization, etc.)
  • Strategy games (e.g., Chess (shotgun, human, and AI suggested variations), Settlers of Catan, etc.)
  • Coding-oriented games (e.g., Baba is You, Duskers, Bot Arena, etc.)
  • Mashup games (e.g., Habro's Game Mashups, Breakout Fantasy Mashup, etc.)

Authoring Environment

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

• choose and place game elements (i.e., what things will be in the game, their starting positions and values, etc)
• setup graphical elements (i.e., background, images/colors/shapes used for game elements or board spaces, etc)
• change settings (i.e., point values, game timing, projectile/obstacle/objects speed or number, etc)
• set game rules (i.e., what actions are allowed, what happens when two objects intersect, etc)
• set interaction types and reactions (i.e., what happens when a key is pressed or the mouse is moved, without hardcoding specific keys, and what object is controlled)
• set goals for the game (i.e., how to advance within the game, how to win or lose the game, etc)
• determine the order of advancement (i.e., what level or stage follows the current one)
• set instructions, splash screen, player setup, level bonuses, etc
• save preferences that persist between program runs (such as theme, language, last game edited, starting component configurations, etc.)

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:

• show any number of available games automatically (i.e., adding a new game to play cannot require changing any Java code)
• see information about each game, including its name, author, description, and image/icon
• select any game to play repeatedly without quitting
• play multiple, possibly different games at once
• pause a game during play (note, depending on the game or its goals, you may want to blank the screen when paused to prevent "cheating")
• see dynamically updated game status information (i.e., heads up display (HUD))
• keep track of each game's high scores through successive runs of the program
• save their progress in the game to restart later (perhaps only at specific save points)
• save preferences that persist between program runs (such as theme, language, player token, starting game configuration, keyboard keys for game actions, etc.)

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:

• Properties File, a list of key/value pairs, specific to Java, but easy to parse and use
• Comma-separated Values, CSV, like those used to represent spread sheets, that can be parsed using a third party library (available via Maven)
• eXtensible Markup Language, XML, an open, industry standard, flexible format, that can be parsed directly within Java but, to help serialize objects, we recommend a third party library (available via Maven)
• JavaScript Object Notation, JSON, an open, industry standard, flexible format, that can be generated and parsed using a third party library (available via Maven)

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:

• 1 test game that shows most of the project's features and is very easy to play
• 2 complete games with clear variations in rules, goals, and interactions determined completely by different data files
• 1 game MOD(ification) with a clear visual and thematic appearance determined completely by different data values rather than the functionality
• 7 interesting games, one by each team member that help demonstrate your project's design flexibility

Extensions

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:

• Basic (2 expected)
  • Dynamic Game Rules. Allow users to change the rules of the game during the game, perhaps after voting or otherwise confirming that everyone playing understand the rule change.
  • Player Profiles. 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, language, age (if parental controls are implemented), and favorite variants, tokens, colors, etc). Player information should be saved between runs of the program.
  • Easy MOD Editing. Allow users to easily change many related data values at once (e.g., graphical icons, text, goals to turn a SciFi game into a political statement or a violent game into a peaceful one).
  • Save Game Data in the Web. Allow users to save and load game data using an online database or web server with REST API.
    Note, these use the JSON data format so you likely would also.
  • Help System. Create a substantial help or tutorial system, perhaps providing templates or wizard dialogs to guide a designer through creating a game.
  • Artificial Players. 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.
  • Incorporate AI APIs. Allow users access to popular AI tools to develop elements of their game like ChatGPT, DALL-E, DeepComposer, or Murf by integrating their APIs into your Authoring Environment. For inspiration, check out the Material Generator tool (beta) for Roblox.
  • Live Game Editing. Allow game designers to interactively build their game while it is running.
    Note, in this case, you will likely need to embed all or part of your authoring environment within your player.
• Challenging (1 expected)
• User Permissions. Offer different user roles that provide different access to program functionality (e.g., guest access to a few games, game author access to see usage stats about their game(s), admin access to see data about the users playing the games, add/remove users or games, etc.).
  Note, this will require a connection to an online database (or files that simulate a database) to keep track of user information that persists beyond the running of a single program.
• Social Center. Provide social aspects to the Player app such as allowing users to rate, comment, chat, or generally collaborate while playing games.
  Note, this will require a connection to an online database (or files that simulate a database) to keep track of user information that persists beyond the running of a single program. Real-time collaboration will also require some very basic networked connections (if you are not using a real-time database).
• Networked Players. Allow users to join games over the network or start one and wait for others to join. Updates on any one computer should be made visible 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 so that an update at any one computer should be visible immediately to all connected users (perhaps even allowing designers to chat or comment 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.
• Play Modes. Allow users to play a challenge mode, through any number of randomly selected levels or games, generated from those that have been created, or a tournament mode, against other players competitively by displaying others' current or recent scores.
• 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 add-on packs 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.
• Game Data 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, including comparing two different runs of the game.
• 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!

APIs

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:

• Frontend
  • Authoring Environment: program of visual tools for placing, specifying, editing, and combining general game elements together to make a particular game
    Key design challenges are providing a flexible and extensible GUI that makes it easier to define a game visually than directly editing text data
  • Player: program that loads the game data and uses the game engine to run a particular game
    Key design challenges are 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?)
    
• Backend
  • Engine: framework of general Java classes to support any kind of game within a specific game genre
    Key design challenges are providing significant built-in functionality while still making it flexible enough to support a variety of games by ensuring plenty of places to plug in custom code
  • Data: files, assets, preferences, and code that represent a particular game
    Key design challenges are providing standards for what data needs to be represented in files, loading the data for a particular game and assembling concrete classes, handling any errors in the data that might occur, and insulating the rest of the program from your format choices

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/API_CHANGES.md, that is updated each Sprint.

Example

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

• setup of the board and players starting funds
• interactions within the game
• how players win
• how players lose

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:

• Monopoly Jr.: a smaller board with simplified rules
• Monopoly Here and Now: collect all passports
• U-Build Monopoly: domino-like board with hexagonal spaces
• Make you own rules

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

• Dice: type of dice (2 6-sided dice, N-sided dice, even the Speed Die); extra turn after rolling doubles; go to jail after too many doubles in a row
• Funds: money bills; electronic money; starting amount per player; income-tax rate
• Properties: order on board; which property group, including utilities/railroads; cost; house/hotel prices; rents; mortgaging/un-mortgaging
• Property interactions: buying; auctioning; trading; paying rent based on mortgage, monopoly, house, or hotel status
• Chance/Community Chest: different actions on cards; keeping cards (e.g., get out of jail)
• Houses/hotels: cost; buying; building shortages
• Board: arrangement; number of locations; moving between locations; actions when landing on specific locations
• Go: collecting $200 or other amount; landing directly on it; when passing enables player to collect money
• Jail: various ways to get into and out of jail; various options for money paid to get out of jail; whether or not player can do business while in jail
• Turn-based action: roll and move; moving again based on game actions; other results of move; any player can manage property
• Joining a game: choose token; choose first to go; choose starting position; choose number of tokens per player; choose "local" variation separate from game rules

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:

• actively participating in all team meetings
• regularly contributing clean code to the shared repository in reasonably sized chunks
• solving and coding at least one "interesting" design problem
• helping a teammate at least once by going above and beyond

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.

Resources

• General Framework Design
  • What is a Framework? by M. Clifton
  • Introducing OO Frameworks by Taligent
  • Framework Design Guidelines by K. Cwalina
• 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
• 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
• Example 2D Game Authoring Environments
  • GameSalad and as a video
  • Super Mario Maker and as a video
  • Sploder and as a video
• WeMod: Personalize your Gaming Experience