The design process of WoAH

WoAH is a procedural content generation project built in Unity aimed at creating a Hivemind resource allocator that adapts according to the player's actions to ensure that their ship is running at its maximum capacity.

Role in WoAH: Programmer / Designer

Engine: Unity2D

Team size: 2

Language: C#

Main contributions to WoAH: Hivemind AI

Gameplay demo of WoAH

Origins

WoAH first came about from the idea of wanting two adaptive AIs that try to counter each other's strategies depending on the player's input. One being the Companion AI helping the player and the other being an enemy Hivemind AI. Both AI will duke it out as the Companion AI continuously feeds the player information to defeat the Hivemind while the Hivemind AI tries to adapt to the Companion AI's strategies, creating a to and fro battle.

However, upon receiving feedback and some minor testing, we realized that in a chaotic bullet hell situation, the player's focus is mainly on surviving and taking on the enemies that are in front of them. The player will not have enough attention to listen to the battle strategies fed to them through the Companion AI, in which they might even find it annoying if both the player and the Companion AI have conflicting strategies and gameplay styles. This resulted in the possibility of players not listening to the Companion AI. We decided to scrap this due to possibility of wasted work in the short time constraint that we have.

Thus, the Companion AI was cut and more focus was put into the Hivemind AI.

This portfolio will cover my contributions and its process in this project.

Hivemind Utility AI

Room Evaluator

Each room in the spaceship is evaluated by the hivemind to determine the requirements of each room.

Utility AI

A scoring system was added to the factors that determined the requirements of a room.
- Scores were added to factors depending on the urgency of the required resources
  - e.g. If a room is under attack, additional score is added to the soldiers required as they are needed to defend the room.
  - e.g. If a room has extremely low health left, additional score is added to the workers required based on how many workers are already in that room repairing.
This resulted in a more diverse gameplay as the types of units sent are different depending on what the player is doing in the room.
- e.g. If the player is only attacking the units in the room, more soldiers are likely to be sent by the Resource Allocator as the room's total health is not touched, reducing the worker's score.
This was implemented to resolve the previous issue of a linear evaluation. (Find out more in the technical document below!)

Resource Allocator

After evaluation of each room, the rooms are put into a resource allocator to be sent resources. It makes use of the data gathered from each room using the room evaluator before deciding on which resources to send to which room.

Prediction AI

The formula has now been upgraded by a prediction system.
- The system calculates the time taken for the player to potentially destroy either the room or all the occupants in the room.
  - The Resource Allocator will use the shorter time taken to destroy either the room or all the occupants in the room.
- The Resource Allocator then accounts for the time taken for their resources to arrive at its destination.
- The time taken for resources to arrive is then added to the shorter time to calculate the required soldiers to take down the player by the time they arrive at their destination.
This change was made for the resource allocator to send the correct amount of soldiers to deal with the player, preventing the never ending loop of lack of firepower by the time resources arrive.
This also helped in controlling the pace of the game as resources are created from fixed positions and are usually deep inside enemy territory. Therefore, reinforcements will take a longer time to arrive depending on how far the player has progressed.

For a more indepth look at the algorithms used and the changelogs, take a look at this technical document!

Technical Document

Post Mortem

Project takeaways

Pointers I learnt from this project which I will take note of in future projects.

Less is more

Clarity is always important in games, players have to be able to understand what is going on at all times.

We struggled very hard trying to make things clear to the player as the gameplay was extremely chaotic at times.
We tried adding additional indicators as to what is happening such as the activity feed and the status icons of the enemies.
- This resulted in too many elements in the screen screaming for attention, contributing to the chaos in the screen.
One take away from this is that adding more does not result in better results.

Experience

Dynamic experience is more important than a perfect AI

The Hivemind AI initially executed in perfect order according to a series of maximum efficiency rules.
- The Hivemind AI was suppose to try its best to take down the player.
- However, this resulted in a very robotic and predictable manner, which did not achieve the intended dynamic gameplay for the player.
  - Our solution only semi solved this as even though the Hivemind is generating dynamic content, the experience was still roughly the same.
Some take away from this is that
- Its okay for the AI to make mistakes, players capitalizing on the AI's mistake makes them feel smart.
- The possibility for AIs to make mistakes opens up possibilities of dynamic content depending on the timing of the mistake.

Experimentation

If given extra time and resources, I'd like to experiment with the Hivemind AI more.

Due to Procedural Content Generation being new to me, I took longer than I expected to get the Utility AI running.
- I did not think about combining a few utility AI together to increase the possibility space of content.
- This resulted in the lack of time to try different approaches to PCG.
Now that I have roughly gotten the hang of generating PCG, I am more confident in trying out new things for PCG.