Project GC mission architecture

Project GC is a Godot game project being worked on by a team of fellow DigiPen graduates from the same year as me. We have slowly been working on it since graduation in 2024.

As the producer, I haven't had too much time to code, but for the little I have I'd like to show off some of it.

If you would like to follow along, code samples can be found here.

In the game we have a mission based structure of activities that you can perform. You can only have one mission active at a time, and the progress and completion of any mission might change the state of the game. Because the missions will mainly be implemented by designers and they can vary is objective, the data structure for the missions need to be generic enough to full designer creativity.

Missions are defined entirely as Resources, which means designers can create, duplicate, and tweak missions directly in the Godot editor without touching code. This also keeps iteration fast, since changes are automatically reflected anywhere the Resource is referenced.

Here the mission structure is laid out like so:

• SaveManager: Loads and stores all the save data in memory. Stores a list of all the missions using MissionList.

• MissionList: Contains a list of all the missions that exist in the game. Tracks which mission is currently active.

• Mission: Represents a single mission with multiple goals.

• MissionGoal: Individual objectives within a mission.

Sample mission created in the inspector

The general layout of the mission components are quite simple. A Mission is only responsible for managing state and progression, where the actual win conditions are delegated to individual MissionGoal resources. This separation allows missions to be composed out of reusable goal types, rather than hard-coding logic per mission. Adding a new objective generally means implementing a new goal type, not rewriting the mission system itself.

Mission activation and goal state is handled centrally through MissionList ensuring that only one mission can be active at a time. When updating a goals status it checks the goals state and notifies any subscribers of goal completion or completion of all goals, thus the mission completion.

MissionGoals are the meat and potatoes as they contain the goals name and description as well as its completion. The text data will be used in the UI to remind the players what their current objective is, and the completion to see how much more they need to do.

Goals could have been implemented as simple one-off objectives that complete and immediately advance to the next goal. Instead, I added a configurable MaxCompletion value to allow goals to represent longer-running progress. This makes it possible for a single goal to track incremental advancement rather than only a binary complete/incomplete state. This is especially useful for cases such as collectibles. The number of collectables could be set as the MaxCompletion so each collected item would progress the goal until it reached the max. This simplifies the complexity of certain objectives instead of needing to create a new goal for each collectable, or creating a custom script to track the number collected.

Because everything derives from Resource, saving and loading missions becomes mostly trivial. On a new save, mission data is discovered automatically by using a depth first search recursive function scanning the missions directory. This avoids hard-coding mission references or maintaining manual registries. On load, the system simply restores the serialized Resources, allowing mission progress to resume exactly where it left off.

Overall, the system prioritizes extensibility and modularity to allow for quick and easy use with any designed mission. As the project is still in its infancy and the mission data hasn't had much use, the structure and code will probability evolve as the game does, and when that does happen I'll make another post to keep you all updated! Thanks for reading this mini blog, I hope you got something out of it!