Project Exodus

My first major project in Unity. I served as the Lead Programmer and helped coordinate system design and source control as well as assembling builds for play testing.
The main goal for this project was to form a team and develop a full fledged game slice in Unity while simulating the workflow of an established studio.
Milestone delivery dates were instituted to keep the team on track within a 7 month development cycle.

TurnSystem.cs

An example of a typical conversation

I was the main architect of our repo throughout all phases of production. Since this was my first large scale project, I went with Plastic SCM as our version control system since it was already integrated into Unity.
The Art and Animation team had a limited understanding of how to use Unity so I set up branches where they could work in isolation and not disrupt any of the design team’s workflow.

Our GameManager in all its glory

I set up the initial framework for our turn based combat system using a CombatManager singleton to handle overarching logic (i.e. taking damage, awarding XP, selecting targets) .
Unit and Enemy classes interacted via a TurnManager script that sorted and executed their actions. To facilitate this, I set up an abstract Action class that held information related to the target of an action as well as who originated it which allowed me to create inherited classes for various combat abilities (attack, heal, etc.).

Since our game was 2D, I decided to have the entirety of our combat scene live on a Canvas so that scaling and placement would be easier to achieve. Our GameManager singleton held persistent references to actual character stats and this information would be relayed back and forth between their on screen combat widgets.

I started by establishing a singleton framework to handle the core aspects of the game. This included various manager classes that controlled logic related to their respective systems.
Since I knew our game would be narrative focused with the majority of its exposition being conveyed through conversations, I decided early on to implement the Dialogue System plugin by Pixel Crushers. This saved countless hours and, since the package used a visual, node-based design structure, it also allowed for non-programmers to work on conversations as well.

I chose to primarily work with two main scenes, Combat and Travel, so as to simplify the logic and keep the project compartmentalized. In order to avoid issues that would arise from objects being destroyed when scenes changed, the majority of our objects were set up to instantiate at runtime.
Heavy emphasis was put on Scriptable Objects and building around them. In particular, we established an ad hoc event system that incorporated an event listener component on objects and a corresponding Scriptable Object “event” that could be subscribed to by these objects. This allowed us to broadcast event messages to the whole system and have different objects react accordingly (i.e., a conversation ending triggers our EndIntro event which the SceneManager hears and responds by loading the next Scene). The advantage to this pattern was that it allowed for logic to be hooked up in the Inspector tab which meant non-programmers could skip writing code and still have a means of interacting with the game’s systems in a way that made sense.

Plastic SCM

PROJECT EXODUS