I hate my popular game: Star Driller Ultra post-mortem

[Cross-posted from Omiya Games]

In less than a week of submission, my third Ludum Dare entry, Star Driller Ultra has 76 votes. This is easily the most popular entry I’ve put up, compared to the 2 weeks it took for The Sentient Cube to get 100 votes, and the entire 3 weeks to get 60 votes for Laundry Day.  Clearly, a lot of people liked the game, with the comment section on the site being largely positive.  But I have a major confession to make about the game: I hate it.  Here’s the post-mortem to Star Driller Ultra.

What is Star Driller Ultra

Star Driller Ultra is a Star Fox inspired space combat game where you play as a neon-colored drill.  The entire game revolves around defeating enemy ships by drilling into them using limited fuel supplies.

The idea was born from an one-hour long brainstorming session where I written down 61 short game descriptions. The one that caught my interest the most was this one:

There was a video of an obscure Playstation 2 game I had in mind when planning on this game. You would always be moving towards an enemy ship, and the majority of the gameplay revolves around dodging bullet formations. Only when you’re close enough to the enemy would you have the chance to attack, via a drill.

What went right

Early prototype identified several problems

By noon on the second day of development, I had a prototype ready to test the idea.  This prototype only had a cube to represent the player’s ship, and a few static enemy spheres that shoot bullets.  This product helped find some problems I needed to resolve:

Identifying issues this early allowed me to quickly plan on a solution to each of them.

A practical and consistent graphics

One of the first issues I’ve tackled was the player’s ship always obscures the view to the enemy ship.  Ultimately, I had one of the three options to choose from:

Naturally, I chose the wireframe, as it felt like it was something most other games didn’t do.  From there, I’ve experimented with Blender’s Wireframe modifier and put together a very thin ship.

After that, I dropped an unlit color shader on the ship to make sure it was always visible, even if the screen dark.

Once that was done, the rest came pretty easily: the enemies needed to be clearly visible, so I stuck with the earlier wireframe method and simply made the outlines thicker.

While I initially used unlit color shaders on enemies as well, I quickly found out that it made it harder to tell the shape and distance the player was from the enemy.  Instead, I used a toon shader that provided a distinct bright color that, at the same time, made the sillouhette of the enemies clear and easy to distinguish.

Lastly, to put a nice bow to the whole package, I applied a bloom image effect, lots of trailer renderers, and star particles to fill the negative space.  The result was the most easily praised feature of the game: gorgeous graphics.

Lots of enemy types

Star Driller Ultra actually features a lot of different kind of enemies: the Asteroids that replenish health; stationary enemies Turret I, X, V, and M; and moving Chasers I, X, and V.  I’m personally impressed with the amount of enemies I was able to put together, especially the heatseekers and the beam types (V and M respectively), in such a short amount of time.  Granted, I feel like there should have been more enemy types, since bullet formations was supposed to be a major draw in the game, but it still worked out to a cohesive experience.

Maximum juice

Thanks to years of honing this skill, adding juice to the game came very easily for me.  In this simple game’s case, I only needed the following actions to have a form of juice:

This amounted to some simple feedback for each aspect of the game.  For a few examples, flying only needed an obvious animation on the direction the ship was facing, which I later accented with trails on all of its four back corners.  Drilling uses motion blurs which, combined with the ship’s trails, spinning animation, and rainbow-colored nose particles, lead to a really hypnotic graphic.  Destroying an enemy was a bit more involved: jack up the bloom intensity, and pause for a fraction of a second to let the bright lights suck you in.  Lastly, add a lot of big, bright particle effect and a low growling sound to depict explosion.  Knowing about these common juice techniques such as pauses, sound effects, and particles helped me polish the game at a super-rapid pace.

Proper food and sleep

I was able to balance food and sleep pretty well in my schedule. Well, that’s not much

What could have been better

Boring core mechanic

The intended flow for Star Driller Ultra was as follows:

Since working with 3D space in a space shooter is complicated enough as it is, I tried to simplify the idea by having the player always focus on one enemy only while the fight was going on in the surrounding.  This means that I needed to make the locking into the enemy and dodging bullets part as fun as possible, as they take up the majority of the time in the diagram above.

I think I failed on both accounts.

The order that you lock into a desired enemy is, from the player’s perspective, completely arbitrary.  Basically, all I do is aggregate a list of all enemies, then sort them by distance from the player when the scene initially loads.  The list never gets re-sorted in real-time.  This has a few advantages, such as allowing the designer to control which enemy the player will lock into next, but it’s disadvantages are enormous: it makes the player feel less in control.

For dodging bullets, I had a two-fold problem: I struggled to offer tight controls for the player ship without causing it to fly off or dive right into the enemy, and I couldn’t get the enemies to be better at their aim.  Given these two problems, I was forced to take one of two terrible decisions:

I ultimately chose the latter, thinking it was the lesser of the two evil.  Regardless of whether I was right or not, neither would have made the dodging bullets part more engaging as fixing the player controls and having better enemy aims would have.

Disguised as a space combat simulator

So without good lock-on system and a fun dodging mechanic, what is Star Driller Ultra, really?  For a good long while, I was trying my hardest to turn the game into the space combat simulator I initially envisioned.  However, as the deadline loomed, I took the defeat and polished on what I thought the game did succeed on: a resource management game where you need to handle the health and fuel meter.  The health would be limited in number: you can only recover health by destroying asteroids, which needs to be locked on (a cumbersome process) from the first place.  Fuel is necessary to drill, and while it deplete quickly, it also regenerates quickly as well. Additionally, drilling makes your ship invulnerable, negating the need to dodge bullets if you have enough fuel.  For both, I simply put together stages that I thought balanced these aspects well enough.

Ultimately, though, I feel like I robbed the player’s expectation. As much as I tried hard to make Star Driller Ultra into an action-packed space combat simulator, I just couldn’t within the 48-hour time frame.

Poor difficulty curve

With only several hours left to put the game up, I hardly spent any time working on smoothing the game’s difficulty curve. So when it came to stage design, I relied on a simple: introduce something new in each level to keep the player engaged.

Bad idea.

I introduce different enemy types so quickly, players had a hard time catching up to even the most basic tasks, such as controls. I could have been a lot less rushed and spent a bit of time reducing the difficulty of the game.

Prioritizing on content over playability

On the second day, there was a comment from a playtester indicating that the game was hard to navigate, and a radar would have helped. Weighing on whether I should add more enemies or work on the radar system, I ultimately chose to add more enemies and levels. At the time, I thought the radar was going to take too much time to implement. Looking back, I think I greatly over-estimated the effort to add more content, and should have focused on putting together the radar first instead. Generally speaking, I favor usability over content, but this was a bizarre moment where I simply didn’t think a radar would be that high of a priority.

What will I do next

I chalk Star Driller Ultra as a pretty big mistake and a learning experience. While my ability to create juicy and visually attracting games are better than ever, I found this entry to be a bit enlightening in the fact that I still have a long way to go in deciphering what game mechanics leads to which experience. You can’t polish turd, and if the mechanic is broken, so will the rest of the game. I also think I clung to the the space combat simulator idea too much, when I could have abandoned it and made Unconventional Stick Swinging Simulator instead, or something more experimental.

Still, I’m hardly deterred. I’ve had an incredible streak with #OneGameAMonth, with such wonderful games like Suddenly, Thousands and Ichabot Crane. If anything, I think Star Driller Ultra helps me be a little more humble with a realization that I still have a lot to learn. I could use a bit of humility every once in a while.

In any case, I’ll probably continue the experimental route that I’ve worked hard on. I’ll continue to throw spaghetti on the wall, but I have one more data point this time to make the spaghetti more sticky.