Terminal Operations

Summary

Terminal Operations was a game made over 2 days during the Town One 2024 game jam in November 2024.

In Terminal Operations you control a robot who is trying to stop their ship from falling apart while blasting through space. Your ships various systems will break down, based on slightly randomized timers, and require the player to complete mini-games to repair them before a timer runs out - fail 3 times and your ship explodes!

I took the role of Lead Designer and programmer for the team, with my primary responsibilities being owning the overall vision for the game and resolving any questions or conflicts that may arise due to the design decisions I made.

The design goal was high-intensity, low-downtime gameplay, inspired by games like Among Us and Overcooked, while remaining accessible and easy to understand. It was important that the game have a short play duration due to the high intensity, otherwise players would get burned out or frustrated mid-game.

Awards

Won Best Game Pitch (Bard Award)

Key Takeaways

What Worked

• Clear core loop defined early
• Strong alignment across the team
• Fast iteration through exposed systems
• Maintaining clear vision guidelines to keep decisions on track

What Didn’t

• Lack of early system interaction planning led to refactoring
• Limited engine familiarity reduced cross-discipline contribution

Design Lessons

• Start with moment-to-moment gameplay, not feature scope
• Build systems for iteration and tuning early
• Architect systems with the game in mind

This project reinforced my focus on tight gameplay loops, rapid iteration, and system clarity - especially under strict time constraints.

Design Approach

Strong Core Loop First

Given time constraints, I decided that having a core loop we could mock up and play quickly would be best - theres nothing worse than thinking you have an amazing idea only to realize it’s just not fun once you start playing. Knowing the core loop also helps us understand requirements, we could mock up a “screen shot” to understand the sort of art assets we would need, and ensured we had a simple flow chart we could refer to when we needed to understand what stage of the game a design choice would impact.

The core loop we settled in on was:

See damaged system(s) -> Choose which to repair -> Trigger mini-game -> Complete task -> Repeat

Since all the systems being damaged was on a timer, you could hear other systems breaking while you were repairing the current one, which we felt added tension to the game and fed into the high-intensity feel of the game.

Scoping

I made sure we reduced scope early to ensure a complete experience, especially given the tight timeline of just 2 days:

• Single-player only
• ~2 minute sessions
• Minimum 3 distinct mini-games

I broke down the requirements down into a few key metrics:

• Duration: how long a player had to complete the mini-game before failure.
• Frequency: the minimum amount of time a mini-game would not reappear between completions.
• Complexity: did the game require lots of specific inputs? Was it highly skill-based?

This helped me break down our possible types of games we could have, and gave me a rough starting point for ideation.

Some examples of how this worked would be:

• Short + common + simple = press a button every 10 seconds
• Long + rare + complex = complete a 5x5 jigsaw puzzle every 30 seconds
• Short + rare + complex = flappy-birds style “dodge the asteroids”

and the list goes on. This allowed me to make a grid on a whiteboard and start getting ideas from the team, slotting them into their respective row before finally deciding which mini-games were feasible to make and fun to play.

Accessibility by Design

Accessibility was considered from the start:

• Avoid reliance on color alone (colorblind-friendly)
• Use clear icons and visual indicators
• Ensure readability during fast gameplay

System Architecture Fixes

Late in development we started to have build stability issues, so I refactored the core system interactions.

First, I enforced a separation of responsibilities:

• All mini-games contained the logic they needed to run
• Any external values or references should be inserted via dependency injection.
• The stations you launched the games from handled scoring, mini-game initialization, and success/failure states.

This enabled me to standardize the start up/tear down logic, ensuring the player was controlling the correct avatar and system logic could keep running while the mini-game was active.

This improved the stability massively and allowed us to tune the game with much more ease than we had before. It also allowed for us to generate new games, if we had the time, since there was a common pattern all games needed to match to be valid for our system.