CS354R - Final Game Project

Project Description

Now that you've completed the "required" game platform and proof of concept game in the first 3 projects, you are now free to leverage what you've done in a game of your own choosing. You may reform teams, work with your current team, or work alone (the scope of your final game should reflect the size of this team). Your team will then propose a final game project to work on for the remainder of the semester.

There are not particular constraints on what type of game it can be, but it must have at least one of the "core technology" requirements discussed below. Also we encourage you to pick something that builds on what you've done to allow you to finish something substantial, but that is not strictly required. Starting from scratch, as you no doubt have learned, is an expensive process, and one that is unlikely to lead to an interesting finished product in the time you have. Any game you build should demonstrate the full range of capabilities of the platform you have developed, as well as one major additional capability of your choosing (see below).

Getting Started

Be careful not to get too ambitious! You should have a feel for what is reasonable scope, but there's still a danger of biting off too much. Make sure your proposal has a fail-safe capability built in. That is, make sure there is a base game that isn't risky to implement, and augment from there, so you'll be sure to have something working. It is much, much more important to have a simpler game finished than a too ambitious game that doesn't work.

Since we are allowing reorganization of teams, we hope members of each team will share a common vision for their game. You should take some time to discuss this early on to ensure everyone is working toward the same final product. Also teams will need to work with me during the first week of the project period to ensure we agree on team members, size, and scope.

Requirements

Your game should incorporate one or more significant extensions to the capabilities you have already completed. At least one of these extensions should be a "core technology" listed below, which should be heavily featured in your game:

Procedural Generation: Include at least one form of procedural generation in your game. This can be related to terrain generation, map/dungeon generation, or texture generation. Your procedural generation must be traversable if it is constructing terrain, and you will probably want to support AI traversal as well.

Advanced AI: Include advanced AI features such as a more robust and extensive Behavioral Tree, Fuzzy Logic, a Rules System, or A* Navigation/Flocking Behavior. You will need to have multiple agents to demonstrate the flexibility and adaptability of your AI system.

Advanced Networking: Include advanced networking features such as grid or aura-based replication, cheat-detection checks on incoming packets, or a matchmaking system. This project does not necessarily need to be robust to packet loss and intermittent network connectivity, as we will be testing on the lab machines, but this would be another feature.

Advanced Graphics or Simulation: Include advanced graphics or simulation features, such as billboarding/LOD effects, physically-based particle systems, shader techniques, or homemade physics systems/renderer. If you do make your own physics engine, I would recommend getting something working in 2D before considering tackling 3D as 3D has a lot more complexity.

Tools Pipeline: Create tools for building out in-game systems. These tools should have some form of GUI editor for designers or artists (e.g. a node-based interface for building a questline, or a specialized level editor for a hexogonal-based game). You may also need to include parsers or simple scripts for stream-lining this process, but you will be demoing both your game and the tool for the final presentation.
Advanced Software Systems: Include complex software systems that are integrated into the game play, such as a tech-tree/skill-tree system for RTS/RPG, a branching narrative and dialogue system, or a combo system in a fighting game. This system should be robust and flexible, and you will likely want to include at least some tools to simplify the content pipeline int your system.

As part of your writeup, highlight what you consider to be your significant extensions to current capabilities and the core technology you are focusing on.

Try to make sure that this one is a true game -- it should be playable and winnable without being excessively difficult due to crude gameplay elements or excessively easy due to poor design. As with previous projects, this requirement is intended to ensure you spend at least some of your time thinking about gameplay and implementing and tuning it rather than devoting all of your efforts to making a bag of special effects that is in no interesting sense a "game." As before, it does not mean that we'll be grading you on the quality of your game design beyond these basic requirements.

Technical Document

Documentation: You will turn in a document with the following information:
- Overall design of your game. What core technology are you implementing? How does this core technology relate to your game play? What other systems will you need to implement to support this? What game engine will you be working in?
- Software architecture and plan. How will you implement this core technology and supporting systems? What is already built out? What needs to be built out? Include detailed information about the expected systems and how they will interact. UML diagrams are encouraged to make the underlying code structures clear.
- Division of labor. In terms of the delivered capabilities, who is responsible for which parts of the code, and what is your plan for meeting up? My experience is that teams who meet up and code together on a regular basis create a more cohesive, functional project than teams where everyone works autonomously and tries to come together at the end. Keep this in mind during your planning stage.

Alpha

Project Demo: Each team must turn in a demonstration (i.e. video) of technology and basic mechanics. This should show that you have at least classes created/partially implemented for any core technology needed to make it functional, and have placeholders for any unfinished features. You should also include a report detailing what you have built, which teammates have contributed to which components, if your time is on schedule, and if not, what the setbacks are and how you intend to proceed to overcome them.

Final Submission

Completed Project: At the end of the project, you'll have links to a working game, along with a final report, README, and, separately, evaluations of each team member. In addition, for this final project, you will need to make a 30-60 second long video trailer to show off your game and illustrate how it is played. You may use any tools you like to help in the production of this video.

Only one teammate needs to turn in the assignment by submitting a link to your repository on GitLab. Make sure your final submission is on a branch called codefreeze.

Grading

As with the other assignments, your primary grading criterion is to turn in a working game on time. As you progress in the project, you may need to scale up or down your original plans. Prepare a strategy for that in your proposal, as we've previously recommended. And remember that a good game is always better than a technology demo, so if you have to sacrifice some glitz for playability, do it.

Last modified: 11/08/21 by Sarah Abraham theshark@cs.utexas.edu

Final Game Project