Demon Lord Reincarnation Postmortem

This is a continuation of my previous post and covers the development of Demon Lord Reincarnation in detail. The development was quite hectic, and there's a lot of ground to cover, but I hope this post will be interesting to you.

How it Started

As I posted previously, the development of the commercial version started shortly after the jam ended. After sifting through player feedback, I decided to focus on three design pillars:

• Dungeon Exploration: the player creates a map while playing as heroes, then uses it to escape the dungeon while playing as the Demon Lord.
• SaGa-style Combat: characters learn new skills in the heat of the battle, which expands the player’s options.
• Knee-Deep in the Rot: characters live fast and die young, and a wide selection of classes allows the player to try new party lineups and tactics.

It was very unusual for the DRPG genre, as developers tend to stick to “safer” bets by following one of the three design schools (Wizardry, Dungeon Master, or Might & Magic), and making and marketing games that land outside of them is very tricky.

It was a risky bet, but a compelling one. Because of this and budget limitations I decided to set a very tight schedule during the initial planning phase and reduced the scope to the barest minimum — this way we could stay afloat if the project failed.

Since the project has already managed to attract attention on social media, it was a perfect opportunity to create a novel experience, even if it would lead to worse sales and mixed reception.

Development Overview

The development lasted around three months. The main reason behind this speed came from a library I’ve been writing in my spare time for potential DRPG projects, which included a few simple modules, such as the database, audio/visual managers, and a simple tool to read data imported from Grid Cartographer and construct maps using a set of prefabs.

A lot of inspiration was drawn from four games/series:

• SaGa series
• Wizardry IV
• Megami Tensei series
• Dinosaur

Compared to my prior experience with the Der Geist series, where each map could take up to a week to design, implement, and script, the new workflow allowed me to design a map in Grid Cartographer, import it, bake the lighting, and start playing it, which in some cases could take less than a day. The data-driven approach also helped, as new monsters and skills were easy to implement and adjust along the way.

The goal of the project was to challenge the established DRPG conventions and try new ideas in the genre.

Greedwalker chimed in with suggestions on how to make the experience more balanced without major changes or dumbing things down. For example, he suggested carrying over progression between parties during the early planning phase to make sure players don’t lose progress even if they suffer a full party wipe.

Gameplay

The basic game loop was carried over from the jam version: assemble a party, grow stronger on your way to the final boss, defeat the Demon Lord (or die trying), and then escape the dungeon while playing as the Demon Lord.

One of the earliest decisions was to get rid of the Charisma stat, which reduced the probability of being targeted in the jam version and split the Agility stat into Dexterity (hit chance and slight contribution to damage) and Mobility (action speed and evasion chance).

In hindsight, I should’ve left a way for the player to affect the probability of monsters targeting a specific character or at least have a system that could be used to communicate this. This is adjusted in Gaiden, where certain skills can be used to goad enemies into attacking a specific character or hide from attacks to keep a character safe.

The decision to provide a manual with the game came from my dislike of long in-game tutorials or other interruptions — since the game was fairly simple, it was decided to let the player read the manual to enjoy a complete experience and avoid distracting them during the game itself.

Battle System

The battle system came together rather quickly since it was similar to the jam version, but with the change towards manual control, it started simple but unlocked new tactical opportunities along the way.

One of the first changes was the change to the way targeting worked — instead of attacking the last monster in the group, characters would target a random monster, thus creating a tense situation at first, but then causing the feeling of relief, as damage that exceeded the dying monster’s HP would carry over to another monster within the group, thus sometimes causing multiple monsters to die.

Skill level progression came into the picture later in development — it was designed to compensate for the lack of equipment and provide the player with another way to grow their characters and get more out of their favorite skills. That said, the number of skills ballooned, which made them hard to balance, and certain skills ended up feeling more useful than others.

As for the equipment itself, it was considered but was scrapped during the planning stage. The main reason behind this decision came from the concern that it would increase the amount of micromanagement — since the player was a constant risk of losing a character or suffering a party wipe, it became clear that it would hurt the intended flow. In hindsight, I think that outfitting the party with fixed equipment that could be upgraded would probably be a nice compromise and provide the player with additional options.

Since this project is experimental by nature, and one of my goals was to ensure the player never feels safe, I decided to toy around with encounter scaling. One of the possible approaches was to expand the range of monsters available, similar to how Ringlorn Saga and the jam version handled it, but it never felt quite right.

Eventually, I settled on a system that analyzed the player’s party and adjusted the encounters based on 4 difficulty levels (Easy, Normal, Hard, Brutal). The system would assign use a certain percentage of the party’s strength as a reference and adjust the number of monsters accordingly.

To spice things up, I decided to let monsters learn new skills if the player characters are much stronger than individual monsters. I wanted the player to feel like monsters are learning from their fallen comrades and coming up with new ways to counter the player’s progress. Enemy waves were also added once the party strength passed a certain threshold to keep the player on edge and challenge his resource management.

Sadly, the system ended up feeling too rigid at times, and with player progression being semi-randomized and dependent on skills, it sometimes created a feeling that monsters themselves were scaling and sometimes prolonged battles that were supposed to be fast. In hindsight, I think that the system should’ve decided the maximum *possible* number of monsters, and waves should’ve been introduced much later, once the player was far stronger and could hack & slash his way through multiple waves quickly.

Initially, the damage formulas were taken straight from the jam version, but eventually, it led to the game falling apart towards the end. There were multiple changes to the formula midway through the development, and the final formula ended up being flawed. While the high damage spread was intentional to make sure the player is always on edge, it had a negative effect too — it was hard to tell if stat and skill gains were doing anything. I think it could’ve been solved by reducing the stat cap, making individual stat gains stronger, and reducing the damage spread, but by the time these changes were made, the project started running behind schedule, and I decided to adjust the final system instead of taking additional sharp turns.

Since the campaign ballooned compared to the original jam version, I understood that running back and forth between the camp and the destination wasn’t an option. That’s why the rest system was implemented, using Dinosaur as a reference. This way the player could find a dead end to regain his HP/SP and gave the game freedom to throw everything at him during the encounters. That said, this had a negative effect too, as there was no long-term resource management outside of keeping the party alive during encounters.

The ability to run away from battles at any moment was handled in a similar way to the jam version to allow the player to stay in control and take a step back if they screwed up. The only exception to this rule is when the party leader is unable to act, creating rare but precious moments of tension where the player has to fight with everything they’ve got.

For the same reason, the ambushes and surprises give a speed bonus instead of a free turn — in a game like this, getting wiped out by an unexpected Brutal encounter would ruin the day.

Exploration

Exploration was improved compared to the jam version, which had nothing going on in the dungeon apart from a few pits, pentagrams, fixed encounters, and a single teleporter trap.

To add additional variety and challenge, I added fake walls and communicated this with a sound effect whenever the player was standing close to them. One-way doors were added later, but this led to a funny exploit — running away from a battle after entering a one-way door would return you to the original position. I thought about fixing this but decided to keep it to let expert players weasel their way through the game if they decide to do so.

Treasure chests were added as a way to boost the party’s stats as an alternative to new equipment. Coming up with trap types was fun, but quite a few players got intimidated by them.

Random events were implemented to add additional variety and make sure that each player experiences their version of the campaign. Encountering dead party members led to quite a few surprises, and an optional superboss caused quite a few deaths. Unfortunately, the number of random events was very limited due to time constraints — anything that would take too long to implement was put aside.

Unfortunately, this led to the lack of additional events in the dark side of the campaign. There were ideas about facing the previous generations of heroes on the way to the surface, but they didn’t quite fit the schedule. As a replacement, discarded characters are used during random events, adding a personal element to battles.

Map Design

If you’re familiar with my work or have known me for a long time, you probably know how I despise automaps and the fact that DRPGs are expected to feature them. A large number of classics relied on toying with the player’s perception of 3D space and one of my favorite moments is getting lost on the third floor in Wizardry 1, when I was stuck wandering through identical-looking rooms, trying to find my way back. If it had an automap, that friction and fear would be gone, and that moment would never be burned into my memory.

Since I didn’t want to feature an automap in any capacity, I noticed that few modern PC crawlers could work as a “gateway drug” — high-profile dungeon crawlers featured an automap, while games without it like Jettatura had rather devious map designs, which could be too much for those who want to start.

I decided to double down on this, but add a helper feature to make the process easier, mainly the ability to check your facing direction and coordinates, akin to the DUMAPIC spell from Wizardry — you were still expected to draw a map, but at least you had some guidance. The decision to block this feature on the final floor drew some criticism, but judging from the feedback, most players enjoyed the intimate experience of making a map and taking notes.

This was the main reason why the campaign doesn’t feature teleporters or spinners — while they could’ve spiced things up, I decided to keep it simple and add these challenges in a potential sequel.

Maps were designed in Grid Cartographer and imported into the game. I decided to keep the map size limited to 20x20 to make it easier for Wizardry veterans to familiarize themselves with the game and let the newcomers have an easier time mapping the dungeons.

While the maps themselves were pretty enjoyable to design and play, I think that the challenge to keep the party alive could get a bit troublesome by the end of the game, and adding a few shortcuts to the camp could’ve made the process easier. At the same time, this friction created a unique experience.

Sight & Sound

The 3D visuals were inspired by Hamlet, an old PC-98 game, and my desire to experiment with graphics that would imitate pixel art in some capacity. The internal resolution was increased from 320x180 to 640x360 for the commercial version to render more detailed images and approximate the feeling of playing a cursed early 3D game on the PC-98.

The lines were initially rendered using the same method I used since Der Geisterturm, but it became obvious that the game needed thicker lines, so I switched to Vectrosity since I didn’t have much time to design and code a new solution from the ground up. Atmospheric lighting was used to add additional variety to the environment and boost the atmosphere.

2D visuals were handled similarly to the jam version — I rendered Torio’s art using the 1-bit palette, then adjusted the resolution. This allowed me to place two enemy parties on the screen and have nice, large sprites. There were thoughts about allowing more enemy parties on screen, but it didn’t look nice, so this idea was scrapped.

Music was created using Korg M1. Reincarnation uses updated tracks from the jam version, as well as new tracks. Due to time constraints, I decided to rework two of my older tracks — Confusion was based on a track from Phantom 3D, while Cycle of Pain was based on a scrapped concept track composed for Call of Saregnar, back before Tony Manfredonia came on board, whose music is a much better fit for the project. Fortunately, Damjan Mozetic had no objection, which saved me a few precious days of work during the late stages of development.

I aimed for the synth metal style for the combat music, while exploration and event tracks were composed in the dungeon synth style.

Most of the sound effects were reused from Ringlorn Saga, and new sound effects were created along the way in a similar fashion, but the number of effects was limited due to time constraints.

Cut Content

There are a lot of things that never made it past the planning stage due to time constraints.

One of the ideas was to include a “betrayal” system, which would sometimes lead to situations where a party member would turn out to be the Demon Lord’s servant and attack you with a small group of thugs. You would find a semi-identical replacement after the battle and continue your journey, but your trust in your party would be sabotaged. This system seemed interesting, but it was obvious that it would only work once, so it was scrapped.

Another system was inspired by my experience of playing Lunatic Dawn: Passage of the Book. Certain character classes could have a certain “destiny” assigned to them, which would work as a sidequest and add additional reasons to explore the dungeon thoroughly. As an example, a Thief in your party could trigger an event where his former friends from the Thieves’ Guild are hunting him down, and you could stop this by finding and defeating their leader.

This system was interesting and would add additional meat to the game, but it quickly became obvious that there wasn’t enough time to make it shine.

Release

Demon Lord Reincarnation came out on July 19, 2023. The game received coverage from the gaming media, which made it easier for me to market the game and get more players on board.

I think marketing and communication should’ve been handled much better, as a large number of players expected the game to be a Wizardry-style game, which it wasn’t, which caused some confusion and disappointment.

The game currently has “Mostly Positive” reviews on Steam with a 71% rating and 80 reviews. This is our most successful game and another positive lies in the fact that most negative reviews provided a lot of great feedback and gave a lot of food for thought for future installments.

Internally, sales expectations were low — DRPGs are a niche genre, and this game was a “niche within a niche” case, which limited expected sales by quite a bit. I wanted to sell 3,000 copies in a year, but experience dictated that I should expect to sell 1,000 copies at best.

However, the game was an unexpected hit and surpassed my expectations by selling over 3,000 copies in two weeks, and over 9,000 total across all platforms by late January 2024.

The PlayStation version was released in December 2023. It launched with a few critical issues that were fixed shortly after release.

Localization

The game had no plans or support for localization due to low expectations, but coverage from Game*Spark, high interest from Japanese players, and good experience with the Japanese localization of Ringlorn Saga changed these plans, which resulted in a quick addition of localization support and search for a translator around the release date.

The Japanese localization was handled by Izumi Thorn, who worked on titles like Yakuza Kiwami 2, Persona 5 Royal, and Shin Megami Tensei V. We instantly hit it off, and I had a great experience working with him.

The process was handled similarly to Ringlorn Saga: I created a build that allowed overriding the in-game text, which allowed the translator to tackle the project as they saw fit. The translation lasted for about a month and a half.

The Japanese localization was a commercial success, and localization costs were recouped before the localization even came out, as Japanese players bought the game while expecting the release, and I’m forever grateful for that.

Ukrainian localization was considered, but plans were put on hold due to the low popularity of DRPGs in the region. However, a volunteer translator offered to translate the game and is currently working on it.

Conclusion

Demon Lord Reincarnation is our most successful game, and its sales ensured that we will survive and continue making games for the time being. That said, it also taught me a lot of hard lessons about project scoping, game design, and scheduling.

On one hand, I’m happy with the project’s success and I know that it provides a unique experience, even if it’s not for everyone. On the other hand, players and I can see its faults and quite a few of them could’ve been prevented with smarter planning.

Hindsight is 20/20, but in my opinion, this project would’ve benefitted by slicing the volume in half and doubling the mechanical complexity, and spending more time on core game mechanics would’ve resulted in a more enjoyable experience.

Since the campaign had two sides with quite a few differences between them, the game felt like designing two similar games at once, and due to the size of the dungeon and simple game mechanics, it was spread pretty thin.

That said, despite the screw-ups, it ended up offering something new to the table, and I hope to develop these ideas and continue experimenting in my future work, but in order to do that, I'll have to adjust my processes to avoid rigidness that hampered this game and my prior work.

That’s why both the sequel and the spin-off are going to take their sweet time in the oven. As much as I’d like to ride on the sudden success of the original game, I want to make sure that new games don’t repeat the same mistakes.

At this point, I can promise that Gaiden is going to be a more in-depth game compared to the original, and I allocated additional time to the project to ensure that when it’s out, I’ll have no regrets about it.

As for the sequel, it went in its own direction and became a 2D Ultima-style game. Initially, I wanted to keep it first-person, but it became clear that quite a few ideas wouldn’t work well in a first-person game.

Thank you for your support and interest in our games. Because of the unexpected success of DLR we are enjoying stability for the foreseeable future and no longer have to run towards the release date before we run out of funds, a problem that was detrimental to our prior work.

And this is what all indie devs hope for, but rarely reach.