top of page
Force of Nature Title Card Large.png

Force of Nature

Created: May 5, 2019

Updated: May 6, 2019

Genre: 3D Horde Survival

Project Type: Team (as part of Doom Shrooms)

Status: Prototype

Force of Nature was the first game development project I worked on as part of a team. The player is the Guardian of The Evergreen, a stretch of wilderness and forest that has, until now, remained relatively untouched. However, a legion of extraterrestrial robots has marked The Evergreen as an invasion point, and your job is to clear them out before they destroy The Evergreen further.

Gameplay is story-centric. The player uses a WASD movement scheme to navigate the map, and mouse clicks to use items and attack with weapons. Items, such as weapons, can be picked up with mouse click or by walking near them. As the player clears The Evergreen of enemies, they will reach the Factory - the robots' base of operations. There, they must survive waves of robots as they seek to disconnect all of the Power Batteries that keep the Factory's Core running. Once all Power Batteries have been disconnected, the Factory will explode...and The Evergreen will have been saved.

My Work and Credits

All code in this game was written by me, except for savepoint code. Dialogue lines were also written by me, and I was also in charge of building the Factory. Art assets used for the Factory were taken from the Unity Asset Store. All other art assets were modeled and animated by Jimmy Liu, our team's artist. Justin Kung, our sound designer and writer, chose the music and sound effect pieces.

Thoughts and Reflections

This project was a far cry from my first foray into C# and Unity; I was not only able to design and create mechanics from scratch, but I was also able to design systems - like the Item system used for the weapons and drops found in the game - and create code that could be understood and easily used by anyone else. Many pieces of code found in this project were adapted from Experimenta, like the detection and wandering code for enemy AI, the Item system, and the first-person controller.

 

Modularity and ease of use were major parts of my design philosophy; I wanted to not only create code that could be easily understood and manipulated, but could also be easily reused with as few changes to code as possible. Enemy AI, for instance, was designed through layers of inherited classes. The AI class includes variables and methods used by all theoretical types of AI: the state of the AI, methods for detecting objects of interest, and so on. This is inherited by the Walker AI class, which includes variables and methods for movement, as well as more advanced decision-making. The final class in this inheritance tree is Enemy Walker AI, which includes combat decision-making.

 

Modularity also meant that certain objects - such as enemies - were created through a series of scripts that take on specific duties, instead of one or two that control everything. Enemies, for instance, use an AI script, a Sound Manager script, an Animation Manager script, a Combat script, and a Stats script. This made it easier to debug code, since I knew exactly where to look without needing specific debug information from the console. It took me roughly a week of many sleepless nights to design and write the code we needed, but it was well worth it.

Videos and Playthroughs
bottom of page