CS378 - Final Game Project

Project Description

For the final assignment, you are free to leverage whatever you've done in previous assignments (or something entirely different) to create a game of your own choosing. You may reform teams, work with your current team, or work in pairs (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 please build it in Unreal as it's what we've primarily worked with during the semester. You will also need to have at least one "advanced" feature where you explore one or more of the UE4 subsystems in greater detail (for example, looking into shaders or particle systems, or creating more extensive network functionality or AI). You can also think about building plugins if you are interested in making tools for the editor or packages to use in games. Regardless of what you create, aim to have a "full" game done by the end of the semester: win/lose conditions, basic menu functionality, a clear game loop, etc.

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 can be in any genre you choose, but it must have all the features in place that constitute a "full" game. That includes:

A Game World: There must be some representation of the game world that the player can interact with and see the actors and NPCs in the world space. This world can be 2D or 3D. Truly almost anything goes. Maybe avoid making an Ascii-based rogue-like, but I can be convinced if you give me a compelling reason why you're using UE4 to build something like that, though.

A Gameplay Loop: There must be a coherent gameplay loop and all requisite states to make that gameplay loop work. For example, in a turn-based game, you need both the player and enemy phases, where players can only provide input during their turn. This can be as complex or simple as fits your game genre, but please make sure it is of appropriate scope given your team size. So, for example, I'll discourage any clicker games, because those don't have a lot of substance or interesting technical problems.

Multiple States: You need multiple states within your gameplay loop to make it interesting. It shouldn't be hard to create at least two states (alive versus dead state, player turn vs enemy turn, pause versus play, in-menu vs in-game, etc), but you can certainly include more as necessary.

Player Interactions: The player should interact with the game world in some way. This way of interacting needs to be visible to the player. For example, if you have a player character, include some basic animations. If you have a board game, make sure the active actor is highlighted in some way.

GUIs: Have at least two forms of GUIs in your game. One of these should be a starting screen that allows a player to start the game, read the credits, etc. The other can be a GUI of your choosing: inventory, stat systems, a pause menu, an in-game HUD etc.

Sound: Include at least two forms of sound: background music of some kind, and sound effects based on either the environment or player actions. Please also include the ability to mute these sounds. Full controls of sound would be nice but is not required.

Win/Lose Conditions: The player should be able to "win" or "lose" your game. We will treat these terms very generally. For example, if you make a walking sim, there's technically no losing condition, but in that context think of losing as giving up -- nothing explicitly happens in the game, but players can return to the main screen from the pause menu.

The final feature your game must include is an "advanced" feature. This just builds on top of everything you've already learned, or allows you to explore sub-systems we haven't had time to look into during the class. Some examples of things to potentially create as advanced features are:

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.

Advanced AI: Include advanced AI features such as a more robust and extensive Behavioral Tree and additional types of AI agents and interactions. You will need to have multiple agents of each type 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.

Advanced Graphics or Simulation: Look into some of the additional UE4 features, such as particle systems, shaders/material creation, or more in-depth looks into the physics.

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. If you make something nice, you are more than welcome to put it on the Unreal Asset Store as a plugin.
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 game genre are you implementing? How does the advanced feature you're looking into relate to your gameplay? What other systems will you need to implement to support this?
- Software architecture and plan. How will you implement the game and its supporting systems? What sorts of classes will you build on? UML diagrams will work well here if you care to make them.
- 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 short video demonstrating the current state of the game. This should show that you have at least classes created/partially implemented for any core features 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 compontents, 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 turn in a working game submitted via GitLab in the branch codefreeze 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.

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/15/20 by Sarah Abraham theshark@cs.utexas.edu

Final Game Project