top of page

Enemy System

For A Twin-stick shooter prototype

Overview

Curse of Brie is a prototype twin-stick shooter game.
For this project, I was tasked with creating a polished gameplay prototype that contained a variety of different enemies, within a rapid-prototype environment. I designed the games systems and enemies, scripted player combat and enemy AI, and created all art assets (with the exclusion of the player character sprites and weapon sprites).

Goals For The System

When I think of enemy variety, I think about differences in their behavior and appearance. So I wanted my design to mechanically mirror these ideals. So to achieve this within a 7 week deadline while also maintaining polish, I structured my design off of these goals:
 

  • Use inheritance when writing scripts.

  • Design enemies from common industry archetypes.

  • Present players with unique challenges to overcome and adapt to.

  • Keep the project scale small and focus on polish.

Design Process: Inheritance

I used inheritance in my scripts by creating a parent "Enemy" script. Other more specified enemy scripts inherited universal functions and variables from that main "Enemy" script. This was instrumental towards helping me meet deadlines, because it allowed for me to keep my code easily manageable, clean, reusable, and organized.


Examples of some of these universal functions and variables include:

  • Max Hit Points.

  • Movement speed.

  • Damage dealt to the player

  • Tracking the player's position.

  • Chasing or fleeing from the player.

  • Calculating the distance from the player.

  • Spawning into the scene.

  • Updating a "Game Manager" Script.

  • And more.

Enemy_ParentScript_Variables.png
Enemy_ParentScript_Functions.png

Design Process: Architypes

I absolutely love the use of archetypes in design. I believe that finding common trends within the industry and using them to play off of the players expectations is one of the best ways to subconsciously give the player a sense of both familiarity and gratification.

It makes them feel familiar because it's something that they have seen before and are used to. It also makes them feel intelligent because they developed an expectation, and saw that it came true (as an added note: intentionally inverting archetypes is also a tool that can be used to great effect in games, as it can provide something unexpected for players and keep them on their toes). Architypes can also be used to help establish a firm sense of character through cohesive behavior and design.

I wanted to capture as much of these philosophies as I possible within my design, so I began with brainstorming enemy types.

CurseOfBrie_Gif03.gif
CurseOfBrie_Gif04.gif
StateMachine_Enemy_Slimuxulious.png

The first enemy that I designed was one I called "Slimuxulous", a toxic snail-like creature. I wanted this enemy to embody the tank of the game, with a slight additional twist. To fit this architype, they are slow and have a larger max Hit Point pool than all other basic enemies. They always take the shortest path towards the player, and when they are near they unleash a deadly close range attack. This attack takes a couple of seconds to charge, but once it's released, a pool of toxic slime quickly spreads across the floor. These pools damage the player if they are ever standing atop of them. The Slimuxulous also leaves a smaller trail of slime wherever they travel, providing an ongoing hazard that players must avoid.

I knew that I also wanted to create a swarm/horde type of threat. Something capable of challenging
 players with their numbers, while also being extremely vulnerable. After playing around with their design, I thought that it would be fun to make them clumsy as well. So I made them attack by leaping at the player. If they miss, they crash to the floor and require a couple seconds to recover. This incentivizes players to try to dodge them more effectively, as a well timed dodge will provide the perfect chance to counter attack.

While designing these (and all other enemies in the game), State Machines were an immensely helpful tool in structuring my code. They kept everything organized and helped to present a clear mental map of how behavior functioned in code. This is also where my earlier work with inheritance was extra valuable, as most of the functions included in these States was taken directly from the parent "Enemy" script.

StateMachine_Enemy_WizLiz.png

Design Process: Animation

I love learning information about all aspects of game design, but one particular artform that really captures my interest is animation. Its quintessential role in game development fascinates me, and one of my favorite resources for insight into this field is the YouTube channel "New Frame Plus".

There may be no element of game design where animation if more critical than in combat design. Animations provide critical information about the behavior of their enemies. They also provide players will "tells", animations that offer an opening for players to take advantage of.

For this project I was most interested in utilizing the animation principles of Anticipation and Timing.

I did so by creating animations that play as enemies begin to unleash their attack. The Slimuxulous for example, will always bend backwards and open its mouth for the entire duration that it is channeling an attack. This informs players of when they are in danger and need to either back away, or deal with Slimuxulous fast!

My ranged threat architype, an enemy I called the "WizLiz" (short for Wizard Lizard) follows a very similar trend. Their attack involves summoning a series of fireball projectiles that surround their body, before being sent towards the player. This attack has a much further range, acts as a shield against the player's projectiles, and "homes-in" on the players location. Because this attack is so threatening, the "WizLiz" has a very generous build-up animation prior to this attack. This gives quick players ample time to take them out before their projectiles even spawn.

CurseOfBrie_Gif02.gif
CurseOfBrie_Gif01.gif

Design Process: Avoiding Instantiation

FireballAttack_Enemy_WizLiz.png
SlimeManagement_Enemy_Slimuxulious.png

Throughout my experience designing mechanics and systems, I have learned about how important it is to avoid instantiating and destroying objects wherever possible. These actions can take up a lot of memory and effect the performance of a project, especially on a large AAA scale. I strive to exercise this knowledge, even on smaller-scale games like this.

To do so, I created a system where all projectiles that are "spawned" by the player or enemies are instantiated once, and never again. This occurs upon the games start-up, when all projectiles are also set to be deactivated. Afterwards, these projectiles are kept in a rotating list or "pool". Whenever one of them is called, the first within the list is activated. Then, once that active projectile would normally be destroyed, it is instead deactivated, returned to it's parent game object, and added back into the list or "pool" that it started in.

Experience

Curse of Brie was a very engaging and challenging project to work on. It represents a lot of exciting new discoveries and developments for me as a designer, but it also reminds me of a number of peaks and valleys that I faced in development.

There are elements of this games design that I regret in hindsight. Visually, I really like the orthographic perspective that the game is presented in. Though this unique camera angle presented a number of challenges with creating tight and effective player aiming. This was an issue that I did not expect, and it's reiteration persisted throughout the entire duration of the project.

Also, this was my first experience working with any kind of Navmesh system. Going through the typical "growing pain" snags of learning something new created some complications in development as well. One bug that occurs on occasion happens when the player collides with enemies, which may result in that enemy being flung across the scene. This is a bug that I failed to solve prior to the final deadline. Still, Navmesh systems are an extremely powerful tool, and they're one that I am looking forward to experimenting with more in my future!

Not all of Curse of Brie went along perfectly, but hey, that's basically game design in a nutshell! In the end I gained a lot from this project and feel very proud of the result.

CurseOfBrie_Gif05.gif
CurseOfBrie_Gif06.gif

Software Used

UnityLogo.png

Unity

Game Engine

PerforceLogo.png

Perforce

Version Control

PhotoshopLogo.png

Photoshop

Assets & Visual Design

CurseOfBrie_Screenshot01.png
bottom of page