3.1 Zhi
Team size: 9 (3 Programmers, 3 Artists, and 3 Designers)
Duration: 18 days (4 weeks)
Zhi is a wholesome couch co-op game where you aim to uncover a mystery within a confined space by solving puzzles together in an asymmetric adventure.
3.2 Goals
As both the lead programmer and product owner, my overarching goal was to streamline both programmers' and designers' efforts. To ensure this our first pillar was scalability, ensuring the system could adapt effortlessly to evolving requirements.
​
Modularity was our way of keeping things simple. Breaking down complex systems into modular components to make the development cycle smoother, allowing for easy iteration. Modularity became the second pillar to unlocking diverse interactions for our escape room-inspired game.
3.3 The Plan
The foremost goal was to build an infrastructure capable of seamlessly adapting to a broad spectrum of game mechanics. Inspired by escape rooms' narrative and interactive elements, our game needed both track progression to allow for hints and seamless integration with the interaction system. Therefore, we opted for composition over inheritance, as shown by the Gustav Composition Graph (see UML), to allow for the modularity the game demanded. A pivotal objective was to establish a robust data structure for quests, designed to be self-managing once set up by our designers.
Gustav Composition Graph
To allow our designers to hone in on the creative aspects of the game, we opted for ScriptableObject as a base class that could easily be modified. In theory, our architecture would allow for quickly building new features and designing new objectives without the need for a programmer to help. Moreover, it would be easily extended wherever needed.
3.4 Execution
I leveraged Linq and modern C# conventions to condense code for better on-screen visibility while acknowledging that excessive syntactic sugar can compromise readability. Throughout code cleanup, I remain committed to maintaining coding conventions for consistency, which I believe increases readability for non-programmers since so many English words are incorporated.
​
Throughout the project, I focused on creating small, scalable systems that could easily be extended by other programmers and used by designers. I also anticipated spending significant time assisting others and engaging in pair programming.
3.4.1 Door
The door inherits from the InteractableObject base class, providing interaction functionality and serving as an ideal showcase of the game's architecture (see UML). Given the game's emphasis on locks, puzzle-solving, and accessing areas through codes or keys, my goal was to create a user-friendly system easily configurable by designers through the inspector, requiring only a brief introduction as by the Handover Graph. The locks for the door are set up through the inspector by adding elements to the list of locks; the lock is then defined as either opened through quest completion or by an item held by the player.
Handover Graph
Once the door is interacted with, InteractAction is called, which attempts to unlock the door.
Door Mechanic
3.4.2 Interactable
InteractableObject is the base class for everything interactable within the game. We serialized fields for user-friendly setup and customization to define interaction permissions and whether they were involved in any quest. The goal was to create a class that respected the Liskov Substitution Principle where the functionality is defined through polymorphism by overriding the InteractAction method.
Interactable
3.4.3 Quest System
The Quest system is a data structure managed by the Quest Manager. The system is built with quests as scriptable objects so designers can easily define them.
​
Quests have connections to their pre-requisites and possible linked quests. Once all prerequisite quests are completed, the quest will become active. This way, it becomes self-managing, we easily prevent this from running in the update method by calling UpdateQuests once a quest is complete.
Quest System
3.5 Post Mortem
The project as a whole was a success; we had to scale it down a bit during production to fit our milestones. But aside from that, we had a dedicated team, talented artists, and driven programmers. That, in combination with a cohesive vision, helped a lot during production.
​
Like most projects with such tight milestones, corners had to be cut; in hindsight, I believe that more abstraction and encapsulation would have saved us time in the end; this was a conscious decision due to team experience.
​
In the end, we still had to go back to refactor small stuff during the project, which was not ideal.