INTRODUCTION
This article details an arduous effort of implementing a raid mechanic from the popular first-person shooter Destiny 2, particularly, the first boss encounter of the raid, the Vault of Glass. We will start talking about the basics first and then dive into some challenges, some victories, some not-so victories and then wrap it up by talking about the future.
THE PLAN
Tooling and Specifications
Below are some specifications I finally landed on after deciding the scope and the level I wanted this project to be on to be achievable.
Genre: FPS - I decided on an FPS since up until then I had built a few first-person controllers but had yet to build one and put in a fully realized project.
Engine: Unity - It was the engine I was most familiar with
Game Scenes/ State - There would be only one state/ level, which is described in detail below
Models Required: Guns, Boss, Enemies, Objectives.
The basic Idea
Why make a recreation rather than make something unique? This game was a challenge to me since I hadn't used my broken-up skills of movement, or shooting wholly. Also, I think the raid encounters in Destiny are one of the best in the game.
If you want to know the inspiration behind this project, click here. Otherwise, I will explain a barebones function of what this game does.
There is a boss (the big bad) that you have to defeat to win the game. But if you notice, shooting him does nothing. Looking around, you'll see 3 blocks floating up in the air that will grow red in a certain order. Shooting them in that order will allow you to damage the boss. The boss's health is pretty hefty so you have to keep an eye out for when the blocks glow again to make sure you can tell what the pattern is the second and the third time! Repeat this until the boss's HP is 0 and you have yourself a win.
Enemy spawns and will keep pooling around you, so you have to make sure to manage that by dashing around and using your bombs.
The following sections will dive deeper into some of the code and the problems faced during the implementation.
THE GOOD
This section highlights some of the surprising discoveries and some success story points from the project.
The player needs to move?!
In unity, the engine of choice: There are two ways of making your player move around. There is a physics-based movement on rigid bodies and then there is a translation-based movement based on transforms. Both have their strength and weaknesses. As a stubborn programmer insistent on tight-controlled, yet momentum-based movement, I decided to go with a rigidbody movement system.
This surprised me later down the line as when I decided to add a dash feature to make moving around more exciting, all I needed to do was to add an impulse to the player's rigidbody and the physics system handled the rest.
Wait, the player shoots too?
With another stroke of my almost scary gift of prophecy, when making a weapon, I decided to set up a scriptable object, so I could generalize weapons. Even though I did not plan on creating more than one weapon in the final demo, I thought I'd be better off generalizing the system since it's good practice to write extendable objects. The scriptable Object, very aptly named "Gun" had stats like its index, name, fire rate, Damage and even a unique 3D model and a shooting sound.
This planning ahead also happened to come in clutch soon when eventually I decided to give the player an ultimate (or super). Instead of having to code in another weapon I simply created a new gun with 1 bullet and massive damage.
THE BAD (not really, but the title was fun)
This section highlights the challenges faced during development.
Wait, this is what a memory leak is?
I wanted the enemies to keep spawning so there is constant pressure on the player to move around. Otherwise one would just stand still underneath the blocks and then just shoot the correct order. A bit too easy, and I wouldn't get to show off my movement system. However, spawning enemies with GameObject.Instantiate every second might not be the best thing to do if you want your game to not cause a stack overflow.
This I learned by researching that could be fixed with a concept called object pooling. According to Unity: Object Pooling is a creational design pattern that pre-instantiates all the objects you’ll need at any specific moment before gameplay. It allows me to not overload my CPU just because I want sheer amounts of enemies.
What is a "state"?
For the boss mechanic, I figured that I would require a state machine. Since technically the boss was in 2 different states (un-damageable and damage-able) a state machine would surely be the way to go. As I went on to implement the state machine I realized that this was needlessly adding scope creep to the problem. Since the boss's behavior doesn't usually change and it's the enemies that pose a threat, I just created a simple masking rigidbody and a bool to hide it when the conditions were met. 3 functions to switch between if the boss is damageable or not. Occam's razor or something
(image courtsey of google images, tv-tropes)
And just like that, the game was ready. Well, after like 2 more weeks of bug fixes.
TO BE CONTINUED...?
Conclusion
Tackling a gameplay slice rather than just concept mechanics and small tidbits taught me a lot. Having to learn how to think like a programmer, and then deal with scope creep and fixing bugs as they happen.
As I move on to my next project as a game developer, I will look back at this project and remember what it taught me. I will keep popular design patterns and pre-existent solutions in my planning phase so I don't have to compromise dev time and tech debt to things that should've never gone wrong.
What's next?
Next, I am working on a street fighter, Tekken, Guilty Gear style fighting game.
(but we shall talk about input buffers in the next article)
It will challenge my skills with input mapping and buffered actions. Which should be fun to work on, and I'm looking forward to writing another "tech" blog with silly titles soon.
Until then, stay well-fed friends
Starman