Revenge of the Firstborn is an upcoming party-based CRPG that leans heavily into classic design philosophies, drawing from the depth and complexity of tabletop systems while embracing modern development workflows. Built around the D&D 3.5 SRD ruleset and developed primarily as a solo effort, the project blends tactical combat, modular system design, and a carefully scoped production pipeline supported by contractors and available third-party tools for support.

In our interview, developer Rob Koska of Sawtooth Games shared how Revenge of the Firstborn builds on inspirations like Temple of Elemental Evil and Baldur’s Gate while tackling the realities of building a system-heavy RPG with a small team.

From Unity-based architecture and prefab-driven workflows to performance optimizations and custom editor tooling, the project offers a detailed look at how classic CRPG design can be adapted for modern development constraints.

There's also a demo out now!

Revenge of the Firstborn is built around the classic 3.5 SRD ruleset. What motivated the decision to base your systems on that foundation, and how did you adapt it for a modern game experience? Why not 5E itself or something similar?

Rob Koska, Solo Developer from Sawtooth Games: I chose the 3.5 SRD due to the fact that it is a much “crunchier” ruleset than 5E. It allows a lot more options for character building (especially since the Feats in 5E are not included in the SRD) and the combat has more depth to it than 5E, in my opinion.

A related question I get asked from time to time is why choose a tabletop ruleset at all? Well, given the scope of what a full-fledged RPG entails, I have my hands full enough implementing something I don’t have to design (and game balance!) from the ground up.

Which games (both new and old) do you mostly draw on for inspiration?

Rob Koska: The most direct inspiration for Revenge of the Firstborn is Temple of Elemental Evil. In its fully patched form, ToEE is a masterful implementation of the tactical combat that is possible with the 3.5 rules. My goal has been to match the combat capabilities of the engine created for that game while hopefully adding a little more narrative spice to what was, essentially, a massive dungeon crawl without a lot of story to it.

I’m a huge fan of all three Baldur’s Gate games, which means that it almost has to have some subconscious influence on my work, but I decided to go the route of having the player create the entire party and occasionally be joined by NPCs rather than creating a single protagonist who recruits his party during the course of the game.

How big is the team, what's everyone's past experience like, and how long has the game been in development?

Rob Koska: There is a total of four people who have worked on the game in some capacity. I have been very lucky in who I’ve been able to find to contract work with, especially given that I have no contacts in the industry. The work breaks down like this:

There's a 3D modeler named Kirill Buzmakov. I have had to be pretty selective in the 3D work I’ve commissioned because, for me, it is very expensive. I was lucky enough to come across Kirill’s work on an RPG forum where he was looking for freelance work, and he has created a handful of monsters to help fill out that classic D&D bestiary, as well as creating a custom model for the main NPC of the game.

I’ve hired a pair of awesome 2D artists named Heitor Queiroz and Lucas Oliveira, who are creating all of the character portraits for the 125+ monsters in the game and the numerous NPCs, along with a variety of UI elements. This has been the single biggest investment in the game, and I feel it has paid off in giving it a polished, unique look

The rest is me. I’m fortunate enough to have a background in software engineering and in team management, both skills I’ve used to help bring Revenge of the Firstborn to life. 

The demo highlights a mix of open exploration and dungeon crawling. How did you approach designing these two very different gameplay spaces from both a systems and level design perspective?

Rob Koska: They’re not as different as you might think, at least in my mind. I try to have a bit of environmental storytelling in each of them. Especially in an outdoor area, you want to reward the player for exploring every nook of the area they’re in with something to find.

Indoor and outdoor areas do differ a lot in what I focus on technically. In the outdoor areas, I’ve had to learn about GPU instancing in order to make all of the grass and trees that can be on screen at once, not bog the player’s computer down. In indoor scenes, the big technical challenge is lighting. In a fantasy RPG, torches are the name of the game, of course. You have to pay close attention to how close you’re putting each light to another light, especially since, in my case, each of the six party members may be carrying their own light source as well.

Party-based RPGs can become extremely complex under the hood. How are you structuring your systems for character builds, abilities, and progression to keep them both flexible and maintainable?

Rob Koska: It’s critical to follow good object-oriented coding principles. Favoring composition so that everything is modular—attributes are their own class, effects are their own class. Attributes contain effects, characters contain attributes, and so on.

It’s also important to understand how best to pass messages between objects and trigger events. If you have a lot of objects in each scene doing things every tick, even if it’s not much individually, it’s going to add up quickly. It’s important to have as many scripts as possible doing absolutely nothing until one of the scripts that is doing things every tick/frame triggers an event that needs to be responded to. This is good code architecture, and it helps to keep things loosely coupled.

Making good use of prefabs and nested prefabs (or their equivalent in Unreal Engine) is also very helpful in order to keep things organized and maintainable. A good example from Revenge of the Firstborn is the boxes that show inventory items in the UI. They’re used in the character inventory view (obviously) but are also shown when looting containers. Creating a prefab for the inventory UI and a prefab for the looting UI with nested prefabs for the actual icons and their logic means that if I have to change something, I can change it in one place and it’s changed everywhere it’s used.

From a technical standpoint, what engine are you using, and what were the key reasons behind that choice for this project?

Rob Koska: I’m using Unity. The choice boils down almost entirely to the fact that it’s C# under the hood, and I already had nearly a decade of experience in a professional capacity with the language. Now, a decade on from that choice, I will probably continue with Unity due to the fact that it fits the sweet spot of engine capabilities and complexity.  

Can you walk us through your typical workflow for building a scene, from early blockout through to final lighting and gameplay implementation?

Rob Koska: For a typical dungeon scene, I actually start out in Excel, believe it or not, as shown above. I modify the column width so that the width is the same as the height of a row. This gives me a virtual “grid paper” I can map out my dungeon on. I start out by blocking out where I want the major rooms to appear and where I want stairs to add vertical variety to the dungeon.

After that, I look for good places to place a trap or two and plan out where I want the encounters to happen. Every room is labeled with a number and a legend stating what happens in that room.

Once I’ve visualized the complete dungeon in that manner, it’s time to start placing walls and floors in Unity. I’ve set up all my prefabs so that, when placed on whole-number vector3 positions, they match up correctly. That way, I can quickly snap floors and walls into place and not have gaps or overlaps with z-fighting.

All of my walls have utility scripts on them that I can use to spawn and place columns, torches, and any other commonly used objects. This allows me to place whatever I want with a single click and know that they will be consistently placed.

Once the environment is in place, it’s just a matter of placing traps, monsters, and loot in the places that I pre-planned using my Excel layout.  

What tools and software are central to your pipeline for environment art, characters, and assets (e.g., modeling, texturing, animation, etc.)?

Rob Koska: Given that I’m not a 3D or 2D artist, my workflow there is very limited. I depend on the artists I’ve hired for that. However, I do use GIMP to change colors on things a lot. I also use a tool from the Unity asset store called Umotion to author some very basic animations right in the Unity editor. Revenge of the Firstborn has some unique status effects, such as sleeping and grappling, which are not part of the typical animation set for assets on any asset store (which I’ve had to rely on heavily for budgetary reasons), so I use Umotion to modify existing animations so that an Idle animation looks like the creature is stunned instead, for example.

Are there any custom tools, scripting systems, or internal workflows your team developed to support the complexity of the RPG systems?

Rob Koska: Yes, and this is where AI really shines for me. I’ve had ChatGPT and/or Claude generate any number of custom inspectors and custom editor windows for me. I don’t quite trust AI to generate code for game systems just yet, beyond some boilerplate code for moving UI elements or searching for navmesh hits.

However, organizing the display and update of properties to show me everything I want to see in one view? Yes, please. For example, doors in my game have a script for managing whether it’s locked or not, whether it’s trapped or not, and whether it can be destroyed or not, and how. I had AI write me a custom inspector that displays all of that data in a nice, tabbed format right in the inspector. I still couldn’t write a custom inspector to save my life; I’m too busy writing gameplay code.

Performance and scalability can be challenging in system-heavy RPGs. What were some of the biggest technical challenges you encountered, and how did you address them?

Rob Koska: The biggest thing you have to watch out for in any game with a lot going on is the things that happen every frame. One example is my perception system. It’s a fairly heavy bit of work for each creature in the game, and having it run every frame was causing issues. So, I changed it so that every monster registers with a manager object, and that manager does a round robin so that each creature does a perception check every x tenths of a second. The bonus is that I can tune my perception system in one place now if it seems like it’s not responsive enough. Bonus points for making it a serialized field in the inspector so it doesn’t even require a code change.

The other big challenge for me has been lighting. With dungeons full of torches and characters that can carry torches, I’ve had to go through my project with a fine-toothed comb, finding objects that can be set to not cast shadows, for instance. Tweaking shadow distance and shadow quality via configurable game settings is also critical to making the game run on as many systems as possible.

Other scalability challenges have been just configuring the massive number of monsters and items in the game. This is a place where AI can shine. Having it write custom inspectors for these objects so it’s organized and presented well has been a great boon.

What specifically is your primary process as a mostly solo dev? Are you doing everything literally on your own, or do you utilize any outside help via AI, contractors, asset marketplaces, etc.

Rob Koska: I like [AI] for boilerplate code that I could write myself, but it can do it more quickly. Things like searching for valid positions on a navmesh or moving and blinking UI elements. It’s also been a great help with custom inspectors and editor windows, like I mentioned before.

I have been doing all of the coding and writing myself, but have hired out as much art as I can afford. I have neither the talent nor time to do art for the game. I’ve also made judicious use of the Unity asset store. When you’re doing a project that is of such a huge scope by yourself, it’s critical that you not reinvent the wheel. Inventory, fog of war, and dialog systems, for example, are major components that were all purchased from the asset store and integrated into the game.

It’s critical to have that “build versus buy” conversation with yourself. Sometimes it’s worth it to write something from scratch so you have complete control, other times it just makes sense to plug in an asset.

Looking ahead, how do you see your pipeline evolving as you continue development toward the full release?

Rob Koska: I want to get more automation into my process as much as possible. My build process is not as efficient as it needs to be. I want to get to a point of “click button, get build,” and I’m not there yet.

I want to create more scene validators that run whenever the scene is saved. I’d also like to create a few more validators that run before the build itself is run. Things that ensure you haven’t copied and pasted a guid that needs to be unique, that sort of thing. I have some of these, but having a broader set would help prevent things that are perceived as bugs from getting into releases.

I’d also like to plug AI into my code review process. Obviously, as a solo dev, I have no one to give my code a second look, so having AI plug into the merge process could be a nice way to have something say, “Hey, are you sure this is how this should be?”

Finally, are there any additional behind-the-scenes materials, such as WIP environments, node graphs, or in-engine breakdowns, that you can share to help developers better understand how Revenge of the Firstborn was built? 

Rob Koska: All of my vendor data is stored in a scriptable object. The scriptable object itself is a visual nightmare, pictured above.

I had ChatGPT create a custom editor for it and was thrilled with how well it did. I didn’t actually code any of this window myself. It’s maybe not the prettiest, but as a non-player facing thing, it doesn’t need to be.

Rob Koska: And here’s a custom inspector for one of my NPCs. This inspector searches through the child objects for all appropriate scripts and displays all serialized properties for them in a tabbed manner. This saves me so much time clicking through the hierarchy and scrolling through the inspector. This was also entirely coded by ChatGPT.

ChatGPT was even smart enough to use the Odin Inspector serializer where appropriate once I told the AI I had it installed.

Rob Koska: I’m cautiously optimistic about AI use in coding. The danger for all of us is blindly trusting and using what it creates, but treating it like a junior dev who needs guidance and careful review of their work has great potential. While I totally understand the backlash against AI art, I think AI coding is different.

There is so much documentation and open-source code on the internet that it can be trained on that I don’t think it comes with the same copyright ethical issues that AI art does, to say nothing of the missing human element that people decry when it comes to AI art. 

Rob Koska, Game Developer at Sawtooth Games on Revenge of the Firstborn

Interview conducted by David Jagneaux

Also, make sure to subscribe to our Newsletter, join our 80 Level Talent platform and our new Discord server, follow us on Instagram, Twitter, LinkedIn, Telegram, TikTok, and Threads, where we share breakdowns, the latest news, awesome artworks, and more.

And, if you're a fan of what we do here at 80 Level? Then make sure to set us as a Preferred Source on Google to see more of our content in your feed.