tANTrum is a VR game centred around tower-defence like gameplay where you’re a ghost that must protect your best friend (a living picnic basket called Basko) from being eaten alive from hungry ants. You defend Basko by placing down towers but also get involved in the action through continual maintenance of towers when they break down and a personal weapon to help the defence. This game was developed in Unity and deployed on the headset alone so that there was no requirement for cables.

This project was part of the IGB388: Immersive Environments subject at QUT where we were tasked with creating an engaging VR game with an interactable NPC. For the first part of development each of our team members had to make a prototype of a VR game that can be completed by the end of the semester. I of originally designed the concept for tANTrum.

When developing our ideas we were instructed to create a design document and ensure that our idea made use of VR affordances and do research of existing VRs to get an idea of whats possible and ensure that the idea separates itself from what other competitors are doing.

After completion of the design document, the next step was creating a prototype of our idea with the goal of implementing its core loop. There were 4 core components that are needed for prototype being, enemy pathing & tower placement generation, Player shrinking and possessing towers, enemy waves, and NPC. Because I’m not an artist, all the art was sourced from an AI 3D asset generation site to meet the needs of the theme but is all temporary until our artist came on to make the assets

For the first component of enemy pathing and tower placement, I opted for Unity’s Spline package due to being able to replicate a similar experience to Bloons Tower Defence where the enemies follow a spline path around the map. The issue now was to how to change the pathing to the player’s need, which after some thought I designed a system where the player had to place pegs down into the ground and once happy the player would confirm, and a spline would generate based on the placement of those points. The tower placement was a little trickier as it involved some math when calculating the offset point based off the spline location but was eventually solved using cross product. For the sake of prototype, the enemy pathing was hard laid out with the expectation the implementation of the player being able to make it will come in the later development stage.

For the enemy waves, I setup a system for the enemy that would connect to the spline on spawn and apply a translation calculation on every update tick to move them across the spline. For spawning I used an asynchronous method where once spawned an enemy it would await x number of seconds before spawning another until the pool of enemies had been exhausted.

Next the player shrinking and possessing a tower. This was an interesting case being that the player needs to able to shrink down and still be able to interact with the world around them. After some research I found that shrinking the player was the best approach in regards for simplicity and efficiency, but after implementing it I came across a bug where the controllers wouldn’t show when shrunk and upon further investigation found that shrinking the player past 0.005 makes the controllers not visible and fixed it by adjusting the scale value to its limit being 0.005.

Lastly, the NPC, originally the idea was that it would be a human manning the stall to sell you items, however, because the end goal I wanted if this game got selected was for it to run standalone on the headset, I feared that a human character model would be to expensive considering the role it played in the game was not so focal. So, after some thought I decided to change the NPC to a living picnic basket which fixes both problems simultaneously where the poly count would be significantly less and it played a more focal role in the game being the objective to protect allowing a lot more interaction options between the player and it.

Because this was a prototype, it was allowed to have multiple UI boards placed around the scene to instruct the player what to do which was easy sure but because for this game there needed some explanation the scene would be very polluted with UI boards. The solution was that I opted to create a tutorial where the player would feed Basko a food item and he would explain how the game worked.

After submitting the prototype, we worked in groups to develop one of the VR experiences generated by each team member. This was even a hard choice for the teaching team as they gave us two options, one being mine and the other Sebastion’s to which meant we needed to deliberate. The team discussed and concluded that while tANTrum was ambitious with the workload to bring it to a polished state, the project would align better with a showcase experience.

Over the course of the second half the semester, my team polished and added content to better serve the game. One of the big changes that occurred was that the player would not possess the towers to take control of them but rather maintain and fix them when they break down and provide the player with their own personal weapon that can be used in “god mode” and when shrunk down onto the tower. This was to simplify the development process as well as solved a design problem giving more purpose to why the player would shrink and unshrink from each tower and not just stay shrunk.

With these changes established, I worked on the strawberry catapult which incorporated a state machine for being dormant, active and broken as well as lifetime until it broke making the player shrink down to fix it.

Here is a video showcasing the result of the tANTrum. Overall, this project was the most fun I’ve ever had and felt it challenged my skillset of the SOLID principles and use of the publish-listen pattern in the code architecture.