Kaio Meris

Zero Strain Development

 Zero Strain was not my first game.

In addition to many game jam games and smaller projects, I had a previous game on Steam. This game was Hangeki :


A lot of Zero Strain was taking what I learned from making that game and applying it. That's not to say Hangeki is bad, far from it. Hangeki still plays well to this day, but it forces players to play a very specific way, and heavily punishes players for trying to play in any other way. If you play Hangeki the "Hangeki" way, it's an experience I don't think is replicated in any other game. But if you play Hangeki any other way, the game is incredibly punishing and frustrating.

Zero Strain exists because I didn't feel like Hangeki encapsulated everything I wanted in a shoot em up. Tweaking Hangeki was out of the question. I love Hangeki for all its harsh edges, and changing its highly polarizing gameplay would ruin the uniqueness of it.

Screenshot 2014-06-30 13.39.35.png

So what were the core ideas behind Zero Strain?

1) Resource Management

Hangeki had a lot of resources to juggle during combat. For example, weapon charge and weapon cooldown. I really liked how the game rewarded awareness and second-to-second planning rather than just reaction time.

I wanted Zero Strain to have more meters and options for the player, but at the same time, needed to keep those meters and options intuitive so the game didn't feel too complex.

2) Less Punishing

Hangeki punished players a lot. Didn't keep your combo? Now you can't use your weapons. Get hit? No more weapons for you. Dodge too wide? There go your weapons. Using weapons in Hangeki felt great because they were constantly at risk of being taken away.

Zero Strain was meant to be much more forgiving. Rather than punishments, I focused on incentives.

3) No Cooldowns

I think cooldowns are used way too often in games. It's one of those mechanics that solve the common problem of players spamming stuff too often, but if you think about it, cooldowns are really boring for the player. They literally prevent the player from doing something for an arbitrary amount of time decided by the game developer. No interactivity, no choices, no skill. Yes, I do realize knowing when to use cooldown abilities is part of the skill, but once that cooldown starts, there is usually nothing interesting going on.

Hangeki had lots of cooldowns, and I didn't want any in Zero Strain. I could have done what some other games do by adding reset mechanics to the cooldowns to make them more interesting, but really, rather than prevent spamming, I wanted to provide players with the choice to do so, but at the cost of something else. This decision eventually turned into Zero Strain's weapon charge and energy system.

That’s all the core ideas, now to get into development. Just to be perfectly clear, I didn't really have a strong idea of how this game would play other than "blow stuff up." I went with the "just start working on it" approach.

Looking back....I would not do things that way again, but hey, it sorta worked out anyway.



January 2016

Screenshot 2016-02-14 08.36.19.png

The first thing I did was make a ship that could move and shoot. Using one of Unreal Engine's starter templates, I put something together in a few weeks. 

The result felt pretty good! The ship could turn left, turn right, thrust, shoot, boost left, and boost right. There was even an energy and health system, all represented by an in-game overlay of colored meters below the player ship. The overlays were pretty awkward to read, but they looked pretty at the time :)

My original idea was to have all the HUD for the game appear in the game world, so no 2D elements. This idea would be scrapped later as things progressed, however, due to readability issues.


Something to Shoot

March 2016

Every shooter game needs enemies, and here they are.

There are two other notable things in this version of the game: movement and story.

The movement of the ship at this point was the most complex it would be for the entire development process. Rather than just floating in space, I envisioned a ship that would hover above the ground and cruise up slopes. You can see some of that in the video clip, the ship rides up a slope then flies off the side of it. I imagined using this for escape sequences, and elaborate maneuvering. 

All of this movement would be cut as time went on, though. The reliance on terrain meant collision needed to be preciser than I could make it, and I really wanted to make a game about blowing stuff up, not running around.

The second thing that started taking shape at this point was the story. I should really put story in quotes though, because the story never really materialized into anything important. I had this idea that the enemies were the lingering negative emotions of people who died and the Cavern of Origins was the entrance to this game's version of the afterlife. Sound contrived? I think so too. But at the time it was cool! :)


Dungeons and Danger

March 2016

Screenshot 2016-03-12 18.31.41 - Copy.png

Gameplay time.

I wanted a game that was like...Dark Souls with spaceships. Players would pilot a ship through rooms of enemies and dangers. Clear rooms of enemies to move on and find collectibles to get stronger.

The controls of the game really started to be a problem at this stage. Turning your ship with "turn left" and "turn right" inputs became really hard since the ship changes orientation constantly. So if the ship is facing down, "turn left" actually points your ship to the right. This was a big problem and turned every combat encounter into a slow trudge where half the battle was keeping the angle of your ship in mind.

Hitting things was also hard, sometimes you want to turn quickly to whip the ship around, and other times you want turn slowly to line up a perfect shot. I thought I had a clever solution: If you turn while holding the thrust button, your ship turns faster. The idea being there was "moving mode" and "aiming mode" (the ship cross hairs moved to reflect these two modes). This kinda worked, but still had the orientation issue where left can mean right.


New Ship

March 2016

New ship.

I added the ship that would become the Crystal Viper in the final version of the game. It did not have its iconic Triple Seeker weapon yet, but the 3D model would stay the same for the rest of development.

Small thing to note here. I tried to fix the aiming problem with a lock on system. The ship automatically locked onto targets (as indicated by a glow). Didn't notice the glow? Me neither. This lock on system would be refined to become a core part of the game, however, and solve the aiming problem unexpectedly.


Levels, Weapons, Control

March 2016

Here I added a weapon system, as well as changed up the level design a bit.

Now ships had a blue ammo count above the energy meter. Players could press a button to fire a special weapon. 

I got the big explosions I wanted, but the ammo system made players not want to use them! "What if I don't have ammo when I need it," was the common thought.

Side note, the big explosion super weapon shown here would become the Crystal Viper's level 3 weapon in the final version of the game.

The other huge change were the controls. Instead of "turn left", "turn right", "thrust," the controls were simplified to "push the analog stick in the direction you want to go." This MASSIVELY benefited the game's feel, since the player no longer had to mentally remap left and right before every turn.


A Place to Call Home

May 2016

Screenshot 2016-05-07 18.42.56.png

Here comes the station! (and the super cool launch sequence).

The first iteration of the station made its appearance here. While the general geometry stayed mostly the same, the color scheme and lighting  would go through many iterations.

Another small-but-huge thing in this build was handling loading. That loading screen that appears after the ship flies out of the station was not fake, the game really loaded and unloaded levels. That sounds simple, but it had a bunch of details like remembering what ship and level the player chose in the menu and loading only that ship and level. 

Oh, and I tweaked the level design, but none of these levels would appear in the final game...so....:)


Dive Dive Dive

July 2016

I made a big call here. No more dungeon crawling.

A space ship dungeon crawler sounded cool in the beginning, but it was really slow and clunky. With time I could have improved the chunkiness, but the slow gameplay was the opposite of what I really wanted.

The feedback I got from meetups echoed what I was thinking as well: everything felt really slow.

So here I made the decision to cut the whole "flying around a dungeon" thing and move to wave-based combat. This was received very positively since it made the game much more focused on the ship and blowing stuff up, which were two things the previous dungeon crawler design interfered with.

I also changed the weapon system. Destroying enemies would charge a meter, and pressing a button would fire a special weapon, using up all the weapon meter in the process. The weapon used depended on how much meter the player had at the time.

This weapon system was incredibly awkward because the player could not use a less powerful weapon when at high weapon charge. It was an all or nothing sort of thing. If you could use your level 2 (green) weapon, you had to.  I would go on to completely rewrite this system in the future, but that wouldn't happen for a while.


Let it Glow

August 2016

Mostly visual changes.

I decided to add glows to more things. The gameplay visuals were an improvement, the station though...I thought it looked good for some reason...

...it doesn't.


Yay Meters

September 2016

Two things: Environments and UI.

Environments. I added props and stuff.

UI. Check out those meters. Making the UI in 2D rather than in-game greatly increased readability. I was very much inspired by Overwatch here with how the bars "chip" away as they go down.


How to Play

October 2016

So you know how I said I scrapped dungeon crawling...lol jk.

It's back!

I still wanted to tell my story about the afterlife, so I made an entire tutorial sequence in a  magic cavern. It was pretty cool, and the sound and visuals were not bad.

This is also where I started thinking about the boost and why the player needed to use it. 

As a little background, Zero Strain makes use of an energy system (the yellow bar in the video). The player uses energy to shoot and boost. Shooting deals damage while the boost avoids enemy attacks. Both use the same resource, so the player must balance offence and defense.

Back to the boost.

 I ended up creating an enemy with the sole duty of forcing the player to boost to dodge its attack. This "charger" enemy had a shield in front of it, so players had to use the boost to swing around and hit the vulnerable backside. The enemy worked great! Players immediately understood what the boost was about, and why it was useful. 

I also moved the energy meter off the ship and onto the main HUD. I found having the energy meter move around with the ship made it hard to track. Energy changes often, so having to constantly find the meter on your ship was pretty hard in the heat of combat.

Unfortunately, this entire cave tutorial sequence would be cut later in favor of a more straightforward version in the station.


Lining Up for the Future

January 2017

Polish across the board.

Title screen, menus, better lighting, better HUD, more explosions, smoother lock on system.

There were too many improvements to list them all out, but the end effect was the game mechanics seemed ready to go, and all that was left was to make more content and just iterate.

I was wrong, there was still one huge elephant in the room...

The weapon system.

I originally wanted players to decide between using one big weapon, or multiple smaller weapons. This sounded ok on paper, but the way I had been implementing it really started to bring down the game as the other systems in the game were refined.

Allow me to explain.

There is a bar at the bottom of the screen with weapon icons on it. You blow up enemies to fill the meter. When the meter passes a weapon's icon, that means the weapon is ready to use (the bar also changes color). You can then press one of three buttons to use one of the three weapons that are ready. After using a weapon, the weapon bar is reduced by that weapon's specific cost.

So if your bar is full, you can use your first weapon three times or your last weapon once.

See the problem yet?

In order to make the most powerful weapon on the far right usable, it can't be too expensive, otherwise the player will never get enough charge. But since the bar to charge the most powerful weapons is the same bar used to charge the weaker weapons, the player can spam the weaker weapons since they charge so quickly.

Destroying enemies charges weapons. So what ended up happening was players would spam weak weapons to destroy a bunch of enemies, generate more weapon charge, then spam more weak weapons.

You could literally blaze though levels mashing a weapon button.

To prevent this, I added a weapon durability system. If you used a weapon too quickly, it "broke" and became unusable for a period of time. 

This was a terrible mechanic, and I came to hate it immensely. I was punishing players for using weapons. Every weapon use was stressful. "Is this weapon gonna break when I use it next?" was the thought every time players wanted to press the weapon button.

In a game about blowing stuff up, I seemed to discourage blowing stuff up.

This weapon break mechanic also violated my own rule of "no cooldowns" since the time for a broken weapon to repair itself was essentially a cooldown.

I would fight against this weapon system for a long time, trying to save it with small tweaks. But really what I needed was a complete rework. And that rework would come much later in the form of the weapon system that appears in the final game. 

The new weapon system was much better, but work to overhaul and rebalance the entire weapon system was tough. Quite a bit of code needed to be refactored, and numbers like enemy health all needed to be adjusted since the new weapon system completely changed the pace of the game. It was all worth it, though.


Adding Character

October 2017

Check out that time skip!

So development was cruising along, but I wanted to make the game less abstract. I wanted a face for the game.

I watch a lot of anime, so I easily came up with many anime-esque stories for my game, but the limiting factor was always the art. My illustration skills are lacking, and hiring people is expensive, but I still wanted a character.

So I had a simple idea, what if I just had one character, and just executed that single character really well. Sounds easy right? Well...try telling a story with one character, you have to get pretty creative, and in the end, I didn't want innovative storytelling to be a core part of the game. I just wanted some personality to make game information like tips and tutorials less video gamey.

So what did I do?

I cut the story.

Or rather, I cut the story down the bare minimum. "Go blow up the thing," was basically all that remained. So now I just needed a character. Enter a concept artist I met at a convention several years ago.

There was a LOT more stuff related to the character design, probably more than was necessary, but the above images should give you an idea of the process.

Character design is hard.

But after the final concepts, I still needed to turn them into game-ready assets. 

Enter another artist who took care of the final illustration.

2 (1).png

That last step from flat color to shaded blows my mind every time.


Iteration and Polish

March 2018

The game really started to come together.

I added the Synchro Burst mechanic to give players a way to regenerate health, refined the visuals, and did a whole bunch of other things to make everything feel better.

From here it was really just polish and iteration since the core mechanics were all there and working.

I say that, but that final polish and iteration is the hardest part since there are no longer any big "wow that's so much better" moments. It's just a bunch of "hmmm, ok I think that's better."

The final game wouldn't be ready for a long long while even though it looked "finished" to most people I showed it to.



Developing Zero Strain has been quite the experience. Highs, lows, and everything in between. The game won't sell well, it's too niche for that, but looking back I think I already got what I wanted out of the project: I got to take something crude and ugly, and turn it into something at least one person can enjoy and see beauty in.

I think the station is the most obvious example, but there are countless others in the game.


I guess I just love details and seeing how they add up.

Thank you so much for reading through this, I hope you got something out of it. If you're making a game, please share your process! It's cool to see how random prototypes can turn into amazing experiences. 

I'll see you in the next game!