Postmortem: Dipso Facto

I just released a rogue-lite bullet heaven prototype I’d been working on for the last six months called Dipso Facto and decided not to continue developing the game for a full release. Here are my thoughts.

Motivation

Aside from learning about game development, I made this game in an attempt to subvert the recent bullet heaven craze ignited by Vampire Survivors. My goal was to at once both capitalize financially on this trend and provide a critique or counterpoint to the genre.

Influences

Making this game, I thought it would help to play all of the decent VS-inspired games that had been released to see how things were done.

20 Minutes Till Dawn differentiated itself with a unique, pseudo-monochrome aesthetic, female protagonists, and aimable gun weapons. The total amount of content in the game is small but it was novel enough to make a lot of money.

Halls of Torment is perhaps the most polished and attracts players with a Diablo aesthetic, aimable weapons, and interesting monster behaviors.

Bio-Prototype was the most creative VS derivative I saw. The aesthetic was a bit muddled but the core innovation was that you could combine organs in a graph to produce new abilities. Unfortunately, I think having to solve a graph puzzle in between rounds turned a lot of players off as this one didn’t do as well. Note that the sales were sub-par relative to VS clones. By indie game standards, this game was a success with 2k+ reviews on Steam.

Death Must Die is more recent, combining a Hades aesthetic with Diablo-style gear-management. The game was been quite successful and is in early access.

Brotato is probably the most financially successful. It combines an early 2000s flash or Binding of Isaac aesthetic with a tight and simple arena-fighting, wave-based core loop. That this game found such outsized success is a bit disappointing given the creativity and innovation of its competitors. The advantage and attraction of Brotato is how simple, cute, and addictive it is.

Design

I saw from the release of Pizza Tower that the 90s cartoon pixel art style was growing in popularity. I decided to combine the Pizza Tower aesthetic with VS gameplay and differentiate by including an emphasis on story through quests, dialogue, and ambient storytelling.

The story concept centered around explorations of addiction, with video game addiction at the center. The title of the game reflected this. The title Dipso Facto is a play on the Latin phrase ipso facto which means “by the very fact of”, that a result naturally follows from available facts. Dipso is a Greek prefix meaning thirst (as in Dipsomania). I intended this phrase to mean “the consequences of addiction”.

There would be five levels: Arcade, Casino, Retirement Home, Mansion, and The Internet. Arcade and Casino are video game and gambling addiction respectively. The Retirement Home deals with alcoholism and more generally regret for wasted time. The Mansion level focuses on the relationship between a game designer and the addictive and potentially harmful games they make. The final level, The Internet, was to explore the end result of behaviorally manipulative products, their effect on society, and where the responsibility lay.

The core loop is the same as all the others in the genre: defeat enemies, acquire experience, choose upgrades to become more powerful, defeat more enemies.

I wanted to spice things up a bit by adding a collect-a-thon element and flavor text dialogue. How many items you collect dictates how many stars you get at the end of the level.

Beating the boss allows you to advance to the next level. For the boss fight, I chose to disable all weapons and turn the bullet heaven into a bullet hell survival mode.

To keep things simple, I decided to have the experience points double as currency for upgrades. The upgrade screen is essentially the same as Vampire Survivors with simple stat buffs.

The Good

This was my first time using the Godot engine and I found it very easy to develop with. The core ideas of Godot: Scene Tree, Scenes, Nodes, and calling down and signaling up were very natural and led to an orderly codebase.

I used a single main node to contain the game scenes and swap them out when transitioning between the Main Menu and the in-game scene.

I made pretty liberal use of global Autoload “manager” nodes to handle things that would need to be accessed regularly by many different nodes.

I was able to keep my code loosely coupled such that things would run easily independently of each other. I kept the inheritance hierarchy pretty shallow and tended to use composition where it made sense. For example, all attack abilities were nodes added to the player or enemies.

The Bad

I chose to have the levels only consist of interiors. This meant lots of collidable walls. This caused two problems: enemies getting stuck, and low performance due to physics latency.

I chose to spawn enemies by randomly picking points on the edge of the screen going a bit further and then checking if that point was in the “spawn layer” (orange above) and then spawning the enemy if so. This would spawn enemies just off-screen but still in the map.

As enemies are programmed to simply walk towards the player this often led to them getting stuck against walls off-screen. To keep node counts down, I eliminated enemies who had been off-screen too long. So, if the player stood in certain positions, they would never see any enemies.

At first, I tried to fix this with pathfinding but that was much too slow. I ultimately decided to design the levels around this problem so there were fewer places this might happen.

The other concern was that I would see the FPS drop once the screen was covered in enemies. This meant that I couldn’t have the truly absurd on-screen action of Vampire Survivors or 20 Minutes Till Dawn. This wasn’t an issue as the focus on story and exploration led to a more toned-down, relaxed environment.

I worked very quickly on this project and so couldn’t keep my code quite as clean as I’d have liked. Early code I wrote didn’t conform to the GDScript style guide.

Another concern was that I tended to preload all the assets I need when the game starts. This led to somewhat high RAM usage (~230 MiB). For most computers, this had no side effects but I recognized this wasn’t ideal and in the future would like to load and free resources as needed.

Conclusions

After developing the initial prototype I ultimately decided not to continue. I felt that the game still had a long way to go before reaching a state I considered acceptable to release. That additional work would mostly be producing assets in the pipeline I’d already established so there wouldn’t be as much opportunity for learning and I didn’t see the game being financially successful. Therefore, I’d reached a point of diminishing returns and decided to pull out.

Further, I felt guilty for making a game with financial motivations in a genre that I have personal reservations about. Bullet heavens, idlers, incremental games, and so on have become increasingly popular in the last decade and their vacuousness is concerning. I’d hoped to subvert the genre and so designed my story and concept around that but couldn’t execute on this idea.

I felt I had to choose between making a subversive game that I believed in or making a game people would actually play. I didn’t see a clear way of reconciling the two on a reasonable timeline.

My biggest mistake was an all too common one for new developers: taking on such a big first project. The game had a grandiose concept and required hundreds of unique art assets. In the end, I lacked the artistic skill, and design maturity to pull this off in a satisfactory way.

This was a great learning experience. It really helped develop my self-motivation and ability to break a daunting project down into managable tasks and press forward. I also got much better at coming up with solutions on my own instead of relying on tutorials or Stack Exchange.

Moving forward, I plan to use what I’ve learned to develop smaller games and projects and build from there.