Browsed by
Tag: gamedev

Designing enemies on a budget

Designing enemies on a budget

I posted a small video of an enemy from Rick Henderson on Twitter yesterday and it gained a lot of traction so i think it would be interesting to post some stuff on enemy design and how i do it.

Ready, aim, fire! Boshin dropping its load

When i started making Rick Henderson i wanted it to be something unique with easily recognizable enemies defined by their faction, design and modes of attack. With something so ambitious as a one man project that works on more than 50 different enemies, making each ship original can be strained in both design and financial aspects of game development.

Boshin was originally designed as an abomination of multiple Paragon Cult faction enemies, easily identified by their purple color and glowing orbs. I wanted some more ships for that faction and funds for pixel artist were already spent so i had to think of a way to utilize what i already had since my artistry level is quite low. I was lucky to work with an artist who knew what he was doing, had a concise palette and distinct shapes for each faction. So i made a pixel art collage that was made out of other ships’ parts in a way that makes it recognizable yet different from other ships. 

1 + 2 + 3 + 4 = Boshin!

Harder part was designing the pattern of attack for it. I try to avoid the usual move from right to left while firing pattern, and if i really have to use it i try to be creative with it. This was the case with Boshin. 

One of the most important aspects of enemy design in shoot ’em up games is “telegraphing”. It is a concept of showing the player that the enemy is about to fire bullets at him. Though not really important for so called “popcorn” enemies (easily destroyable, firing slow bullets rarely) it is a must for enemies like Boshin that fire five fast bullets in a burst. You need time to react, otherwise it wouldn’t be fair and you would feel frustrated by getting hit.

So, what could i do with limited time and no further financial resources? 

Cute guy, but what will he do?

Here is the image of the ship when it comes into screen, with the lower portion of wings with guns drawn into hull. We see it for the first time and we still don’t know what will it do. Upon entering the screen, after a random time in a defined range, the ship plays its opening animation. Best i could manage without artist was to simply obscure the lower portion (wing with gun and an engine) and animate it as going out of the ship. Now that we see the gun, we have a clear idea that it will shoot from it. By adding a bright red light we rise the tension by letting the player know that something is definitely going to happen. It goes out of the gun, widens, and the gun is fired with bullets coming out spreading no further then the red light angle implied. To keep things interesting, i put a new bullet type for Boshin and made the bullets rotate and move at random speeds.

Opening animation is another example of keeping it cheap while trying to look good. It’s not so big, only 22 frames that were just a few layers of parts moving pixel by pixel. Animation of the red “laser targeting device” is made out of two animations since it’s quite large and can’t fit in one texture (maximum is 8192×8192). I wanted to keep authentic pixel art feeling so i did it manually, it consists out of 93(!) 128×64 frames, which gives us a sprite sheet that is 11904×5952 pixels in size, hence the reason for cutting it into two parts. 


After finishing the basic visuals and a small problem with the sprite sheet size, there were some more technical challenges that needed to be taken care of.

It is not yet implemented for Boshin, but most of the ships have some kind of blinking lights on them. To have animated blinking light and the attack mode activation animation like Boshin playing at the same time, you require animation layers and a bit of tinkering with that too. 

Blink, bling

Also, you probably don’t notice stuff like this, but in the video, lower engine does not have engine jet animation playing. I might be a bit of a perfectionist, but i like things nice and tidy. I can either put a new animation, for example a thruster activating then going into regular loop (which requires yet another animation layer), or put an already looping thruster animation as a child prefab and animating its position to follow the animation, with setting the sorting layer to be behind the ship.

The final issue is the collider. As the ship changes its form, it needs to be able to detect hits on the new, extended part too. That can be either done by the most gruesome way known to man, by editing it in the animation window itself, frame by frame, or by using great free asset from the Unity Asset Store called Advanced Polygon Collider, a tool that automatically fits your polygon collider to sprite based on alpha tolerance and scale. It also does a great job in optimizing the collider by reducing vertices, so you don’t have to worry about the performance, at least on desktops.

So there you have it, from a visual idea, to implementation and overcoming slight technical difficulties, a fun and engaging new enemy ship is born.

Spawning System Overhaul and overcoming the obstacle of enemy pattern making

Spawning System Overhaul and overcoming the obstacle of enemy pattern making

The Grid

Wow, it’s been a while, but things are moving forward slowly but surely!

I’ve been busy with lots of coding and programming enemies and i encountered some difficulties in proper positioning. On the image below you can find how the spawn points looked (5 spheres on each side) and how they look now (the red X signs)

Spawning Grid
Obviously, 12 times more spawning points offer much more flexibility

Obviously, it offers much more in terms of positioning. More than a year ago, when i first started working on a spawn system i wasn’t apt enough to make it the way i wanted to (grid system) so i had to be satisfied with only a few spawn points and additional repositioning upon instantiating. Needless to say, it adds much more work to simple spawning and positioning of those enemies.

By using this handy tool from the asset store (!/content/20502) i created a grid made out of objects completely automatic. A fine tool indeed. After that, i simply added those to the hash table and now i can simply reference the object whose position i want the enemy to use as spawn point and voila. Besides using it to spawn enemies already in a pattern, i can use them to actually create random patterns on runtime by referencing a different object from the hash table upon predefined parameters to avoid completely random clutter. Not only that, a finer grid enables me to avoid spawning the enemies too close to each other or overlap. Since i’m using Core Game Kit for spawning, i’m waiting for the developers to implement the feature based on sphere raycasting, i.e. if there’s an object of certain tag or layer (enemy) in a defined range, the system won’t spawn any more to avoid the overlapping. It will work great with the system i made and described few devlogs earlies which is based on enemy pool values and enemy quantities.

Also, Easy Save 3 Beta will soon get a full release (i hope VERY SOON) which will enable IMPORTING variables from a .csv file. It will be of an immense help for tweaking the gameplay.

Enemy Pattern Making (Squadrons)

I must admit, though i am passionate about making a game, some things are quite tedious. I’m having problems with making enemy squadrons, and the way i make them is so boring and uninspiring it really halts my progress.

Before i was well into Unity engine limitations on nested prefabs (only one child per object, i.e. child cannot have it’s own child as a prefab, only when instantiated on runtime due to way serialization works) i thought it was going to be a breeze, i just drag and drop enemies in a formation, put them under a parent prefab and voila! Except it doesn’t work like that. All of my enemy prefabs typically have two children, Gunpoint and Thruster. Gunpoint hold the shooting logic and muzzle flash animation, while Thruster has the, well, thruster animation. It is on a separate object to avoid being colored with the rest of the enemy ship when it changes color on hit by a player weapon.

So i guess i’ll keep my work and make an empty squadron prefab which will spawn and then spawn the enemies in a desired pattern coded into it. That’s all nice and dandy until you actually start working that way. No more cosy drag and drop, just selecting what to spawn, input coordinates and hit play too see what you’ve done. If something’s not positioned correctly (it usually isn’t), reposition the enemy, copy the coordinates, stop, and paste them. Repeat 10 times for 10 enemy objects in a squadron, and i should have hundreds of them! Horrible!

Prefab and Runtime comparison
Prefab with multiple children with position setting on runtime

So i decided to change my ways. I need to make a reverse approach. Instead of creating an enemy prefab with all the children attached, i’ll attach the Gunpoint and Thruster on instantiation, which is only a two step process compared to setting the position of multiple enemies inside the squadron. This way, i have a clean enemy prefabs without children which i can joyfully drag and drop into positions i want and simply save them under a prefab which will be used for spawning.

Prefab and Runtime Setting 2
Prefab with multiple children instantiating on runtime

Though it is a bit more work initially, it provides an immense saving of time later and makes it more visual, fun and intuitive to work with.