'Oddy's Escape' is a First Person, Tower Defense, Strategy game. As the sentient AI, Odysseus, you are to fight M.O.T.H.E.R's evil AI forces in a brave attempt to escape a hollowed out world in search for freedom.

Project Details



Engine & Tools:

Development Time:

Team Composition:


First Person, Tower Defense

Unity, Perforce

7 weeks (2021 Q1)

3 designers and 4 artists

Oddy's Escape

My Responsibilities

Core Design

Design Pillars

These 3 pillars guided the decisions and pivoting of the project - both early and late development.

Thanks to the thorough setup of the core pillars, we were able to refine the core concept into these two paradigms:

Improve your strategies... Or redo them, without previous flaws.

Systems Design

As I am a gameplay & systems designer, my personal goal was to make multiple engaging and interacting systems. I ended up making these three main systems:

  • The Minion System.
  • The Enemy System.
  • The Tower System.

Each system was built to balance, counter, or complement the functionality of the other two systems.

Minions System

I made both the enemy and friendly AI use the same code base. Their perception, logic, and action patterns were the same, but they chose to do their actions on different gameobjects.

Why even have Minions?

This problem become more important over time. If the player can already fight, build towers, and gather resources - why even have the minions? We wanted the minions be important to the player. That is why the minions can do everything the player can do, but better!

Attack Enemy

Build Structures

Pursue Target

Gather Resources

Why everyone needs Minions!

The solution was simple - make them invaluable!

  • Minions* are needed to build structures.
  • Minions are better at gathering resources, with a larger yield over time.
  • Minions can reach places the player can't reach.
  • Minions are cheap labour, and good at defending the base in a pinch.

* Bonus: They are the cutest bots ever...!

Minions vs. Enemies

The main difference between friendly and enemy AI is their chosen targets, especially due to the unique enemy classes.

With the base patterns, it was a lot of fun designing the tower defense system, and then further redesigning the enemy system to make them iteratively counter each other.

Tower Defense System

The tower defence was built on that each tower would have a specific counter-function against enemies if used correctly.

Enemy System

The enemy were these three archetypical classes - each complete with their own behaviours and stats.

Player Strategies

Since we were making a soft-strategy game, I wanted players to instinctively understand the functionalities of  towers and their enemy-counters. I always considered player strategies when I balanced all the properties (damage, brain speed, movement speed & health).

Adding Enemy Evolutions!

Eventually, I realised the enemies lacked diversity. Because of this, I introduced 3 evolved enemy classes. These new classes look different, are stronger, with new properties and behaviours.

Scrappers → Assassins

  - Only hunts Minions

  - Larger scan, finds targets easily

Swarmers → Hunters

  - Only hunts the player

  - Faster than before

Brute → Annihilator

  - Only hunts the ship

  - Ignores everything else

Thanks to these added enemy evolutions, the attacking forces felt much more diverse and changed player strategies, which solved the problem of the lacking variation in enemies.

New problem – Still not enough variation

Even with the additional enemies, there was not enough gameplay variation. Testers would use the strong tower, and build many of those. Even with buffs & nerfs, strategies did not change.

Solution – Shields & a new Tower!

Putting protective shields on the enemies, and adding the new "Energy Tower" counter, gave rise to new variations. The energy tower does double shield damage, where other towers do half. Using a mix of towers became a much more prominent player strategy.

Technical Design

Since I was responsible for the scripting, I began to do rapid prototyping of the systems and prefabs we needed. The bulk of my coding went to the AI Code, the Building System, and the Game Mode. I also made narrative and level design tools for my fellow designers.

Rapid Iterative Prototyping

The benefit of prototyping was answering certain unknowns. An example is how I handled switching between Weapons and Tower Modes (I ended up making a hybrid Input + UI system!).

Another early prototype were the two player weapons - the Hammer and the Rifle. This helped us tweak certain values with the enemy designs, like making one enemy far faster than the player.

AI Code

To keep the structure uniform and easily tweaked, I made all AI use the same code for movement, logic, scanning and interaction. What set them apart was their different priority targets. All logic went as follows:

Problem – AI Navigation

When iterating on the level design, we noticed that enemies would not make complex navigational decisions.

This resulted in them literally hugging the walls, grinding their movement to a complete halt.

Solution – Waypoint System!

I had avoided a waypoint system to keep enemies dynamic, but it was needed at this point. It also gave the level designer freedom to experiment with pathways.

I still wanted dynamic pathfinding, and so I added value variations to the classes, which simulated that.

Project Tools & Prefabs

I made two categories of tools - Narrative Tools & Level Tools.

Narrative Tools

Since the narrative was to be told in-game without the use of cutscenes, two tools were made to make that happen. These tools were also made to be as non-intrusive as possible.

A dialogue system utilizing prompts, which allowed for non-intrusive conversations.

An intermission prompt, to be used for conveying info not related to conversations.

Level Design Tools

As I and the level designer worked back-to-back, we had an ongoing conversation related to the needs of the game, as well as the tools needed for the levels to work with my systems. The tools are the following:

Nav Mesh Links for AI, which enable AI's to navigate complex terrain typology.

Tutorial System, which easily introduces the player in tandem with the dialogue system.

The Enemy Spawners, for placement of the waves' origins, and fine-tuning enemy numbers.

Level Hazard, that immersively block off certain areas.


Even though I was the sole scripter of the game, I always felt that the team had my back, and did their part gallantly. Such team-work really gave space for a strong team spirit and consistent project cadence. It made my job as product owner much more stimulating.

Product Owner


In this final school project, I wanted to focus more of my efforts on becoming a better project manager, using the experiences from previous projects. These were my primary functions:

  • Vision: Assisting the team in deciding on what to add or cut in reference to the game direction.
  • Communications: Conducting presentations, pitches, retrospectives and sprint planning.
  • Solutions: Acted as a mediator in events of conflict or misunderstandings.


The best example for this is when we needed to downscope. Where we could simply cut pieces of the game, I saw it as a challenge to weave in overscoped pieces to more manageble features.

Originally, we wanted multiple levels with unique game modes. The minions were almost scrapped in the downscope, but I saw it was an opportunity to instead make that feature more central by integrating it in to the core gameplay.


I managed the schedules, presentations, pitches, retrospectives and sprint plannings. This meant keeping things short and on point, while not sacrificing the content or information.

One thing that was immensly important to the team was making sure that the every voice had space to be heard. Meaning keeping track of who had the word, who was next, as well as keeping discussions on topic.

Since communications were done through Discord or Teams, this came with its own challenges. As people are accustomed to seeing whomever we're speaking to, I kept my webcam on at all times in case it would help.


While there were no major confrontations, there were two situations of disagreements and misunderstandings. In these situations, as things could get heated, I though it best to be a mediator, and make sure that the people involved were heard.

I did this by ensuring that all information, feelings and fears, were honest and verbalised - preventing further misunderstandings.

This allowed both parties to have an insight to the other party's perspective. Where needed, I also communicated on how we as a team could address the issues at hand, to ensure they would not be repeated.

What I am proud of

First, the great collaboration between the team divisions. We were always ready to help, and be of assistance to each other.

Second, the intense coding I got to do. I was thrilled to be at the very heart of our game, making it exactly as it had been envisioned.

Third, the streamlined organization and project management. I took every bit of experience from previous projects, and improved on that for this project.