'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
Platform:
Genre:
Engine & Tools:
Development Time:
Team Composition:
PC
First Person, Tower Defense
Unity, Perforce
7 weeks (2021 Q1)
3 designers and 4 artists
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.
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:
Each system was built to balance, counter, or complement the functionality of the other two systems.
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!
* Bonus: They are the cutest bots ever...!
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.
The tower defence was built on that each tower would have a specific counter-function against enemies if used correctly.
The enemy were these three archetypical classes - each complete with their own behaviours and stats.
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).
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.
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.
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.
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.
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.
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:
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.
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.
I made two categories of tools - Narrative Tools & Level 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.
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.
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:
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.
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.
