Demonizer has been out for six months. In that time, I have done some private reflection on the project, but kept myself too busy or distracted to talk about it.

As my development brain seems to be on break, I’m laying out some thoughts and memories to learn where I’m strong and weak, and where I succeeded and failed, so I can grow as a developer and plan my next moves. This will focus on the parts of the game that I conceived and made myself.

Background

The main goal of making Demonizer was simple. The idea came to me, mostly from shmups and fantasy stories I enjoyed, and I wanted to play it. There was no serious ambition to change the world (despite the social justice story), or make tons of money, or revolutionize the genre - the resources and experience weren’t there to support anything like that.

I went into Demonizer as strictly a programmer. I had some industry experience on AAA mobile games and was expanding my skill set with engines like Unity and LOVE. But I had no background in visual art or game design. In my youthful optimism, I was hoping to get by on my “gameplay sense” and mostly off-the-shelf assets.

I was always a “jack of all trades, master of none” kind of gamer. I played a lot of shmups, and played shmups a lot, but my actual skill was never more than intermediate level. So I didn’t trust myself to please the hardcore shmup guys, but instead targeted a more general audience of indie retro action gamers.

Design

It was naturally the controls and game feel that most benefited from “gameplay sense”. Although these took a lot of time to get right, as they always do, I found it by far the most enjoyable part of development.

Mechanically, the core actions of the game are surviving, shooting, and item collecting. All of the player abilities are geared to accomplishing one or more of those actions, and I avoided mechanics that encouraged the opposite behavior, except for the rare friendly-fire or unbombable situation to add gameplay variety.

Level design for a new game is hard for a new level designer, because there’s inherently not much “textbook” knowledge available. It depends on your own creativity, the specific game mechanics, the support of the game engine, and your patience to keep trying until something works. Again I fell back on “gameplay sense” along with scenario ideas that might be fun. This mostly worked, but flaws and limitations in the game code (which I’ll get into later) complicated the creation process and may have held the game back from its full potential.

One of the more regrettable additions in retrospect was Demonic difficulty. Late in development I raised the fire rate and bullet speed a little, played it a little, and called it a new difficulty level, because WOOO! Dodging super fast bullets! was good fun and a good laugh for a few minutes. I realized too late this was a disservice to the players most interested in very hard difficulty, who found parts of the mid and late game completely unfair on Demonic.

Code

The code is an odd and clumsy beast.

When I discovered LOVE, I was hooked by its focus on 2D, smaller CPU and memory footprint, and the ease of the Lua language, but I was still undecided on a game. So to facilitate prototyping I put a layer of custom and third-party code on top of LOVE to make a Unity-like engine, following Unity’s model of scenes and game objects and scripts and event callbacks, the most familiar model to me at the time.

I built the first released prototype of Demonizer upon this framework-in-a-framework, and when it tested well enough with people I continued to build on that.

At first, it was a pleasure to write gameplay logic and get levels running in the familiar Unity-esque way. It didn’t make the most simple or efficient code obviously, but I powered through because I was used to large and complex code from my previous job. But the more the code grew, the more its inefficient design dragged on me and the less I wanted to work with it.

This meant that some systems didn’t receive as much thought and iteration as they should have. The AI suffered the most from this. I thought I was so clever having all the characters run the same huge script, so I wouldn’t have to touch it again and could make a new character out of pure data - until I did have to touch the script again, which often caused bugs with existing characters. So enemy movement and attack patterns had to work within a very limited system, and weren’t all as finely tuned as they could be.

Etc.

I tried to be somewhat original with the world-building and the story, but I invested more in the out-of-game presentation than the in-game, saving my development effort for the gameplay and other essentials. I hope we can see more of this world in future, but I will probably continue to favor external media until more development resources are available.

Finally I have to give special mention to my local developer community. I cannot give enough thanks to this diverse mix of students, hobbyists, industry professionals, educators, and entrepreneurs, who effectively doubled as the game’s producers and playtesters. Their advice, feedback, and encouragement carried me through the project more than I ever could have carried myself.

Results

Reviews, sales, and player counts indicate Demonizer is a very solid first effort, but still clearly a first effort. Most players seem to enjoy it for a while but then move on. It’s reminiscent of some early console shmups like Arrow Flash - a fine introduction to the genre that captures the joy of shooting, held back by some rookie rough edges.

Future

A console port has been underway since January. It runs with only a couple of minor issues, but it faces a steep climb to release in a competitive state. The genre has been growing more than expected in the past year with all-new titles like Barrage Fantasia and R-Type Final 2, and more still on the horizon like Mechanical Star Astra and Senjin Aleste.

Based on player feedback, these are the updates I aim to do for the port: online ranking, easy difficulty, more bullet colors, another player character, and revised enemy encounters and attacks. They will of course come to PC as well.

The last one requires new AI code, so it’ll be a stretch. But I’m actually considering a major rewrite of most code to support these and future updates. I already started a new codebase for my latest jam game, which I’m using to remake the Inebriator minigame as a test. The results so far are promising; all of the core systems are a lot easier to work with and understand. They can do everything I need at a tiny fraction of the size of the old code.

Thanks to all players for your support, and double thanks to anyone who reads all this.