Kill The Beast

Summary

Kill the Beast is a shoot-em-up developed in Unity in 4 weeks half-time.

It was created as a way for me to learn more about 3D animation, Unity scripting and how to build a state driven boss in Unity.

To save time I based the game design on a student project I helped create together with Team Three Shots.

Specifications

  • Genre: Shoot ‘Em Up
  • Developed using C# for Unity
  • Created at The Game Assembly
  • Development time: 4 weeks half-time

Tools

  • Unity
  • Photoshop


Code Stucture and Hierarchy

Before I started coding I outlined the relationship between managers and certain vital actors. Previous experience with Unity has taught me that this interaction easily gets confusing, so it was handy to have something to refer to while working.

My aim was to work as component-based as possible, which I stuck to most of the time. In some instances, such as the boss behavior, I found that having many components was more trouble than it’s worth, leading me to code all its behavior in a single script.

Hierarchy reference


 

Inexplicably exploding spiders


 
Angry Golem

Designing the Boss

The design process of creating the “Golem” boss started by first outlining what player skills I wanted the boss to test and creating attacks based on these criterias:

  • The players ability to dash across lava pits and through projectiles
  • The players ability to switch weapons to suit the situation
  • The players ability to multi-task – keeping track of environment and enemies

Not planning the boss properly was the biggest mistake I made during the project. It ended up costing me almost a week, since I coded a bunch of behaviors that didn’t work together and gave no clear segmentation between phases.

To remedy this, I narrowed down the number of attacks to the essentials, thinking of ways of combining them instead. This was to give the player a chance to learn its behavioral pattern while still making each phase feel distinct.

The boss arena underwent pretty much the same process, starting out complex and getting increasingly more simple after each playtest. (I’m sure there’s a lesson here somewhere) The final layout retained the idea I had throughout – to force the player to dash across lava pits – while still giving the player enough space to move around.

Reworked boss flowchart
Different arena ideas.
Final boss layout, with a single lava canal.

 


Playtesting and Iteration

Since the game was based and balanced similarily to an already completed game, the level design didn’t undergo any major revisions due to playtests, for the most part it was about tweaking values and moving around pickups.

From a game design standpoint there were complaints about the readability of pickups; that it was unclear what they actually did. So instead of the funky non-descript models I had used previously, I found models more traditionally associated with health and timed powerups. I also changed the color of the players hp bar from blue to red.

Attack Speed Powerup before and after
Health Pickup before and after

The boss underwent the most iterations, since it was initially too difficult. Aside from revamping its attack pattern, I got the feedback that there was no comeback mechanic if the player had taken a lot of damage early in the fight. My solution to this was to spawn a health pickup between each phase, which helped balance the difficulty as well as reward the player.


Conclusion and What I’ve Learned

The biggest lesson I’d take away from this project is to not skip out on the planning phase. It’s tempting to just get to work when the deadline is so tight, but in the end it ended up costing me a lot more time than it saved.

As a side effect of bad performance I learned a lot about Unity optimizations and good coding practices. This is also the first time I’ve employed post-processing effects and shaders which is something I’m looking forward to learning more about.


Screenshots