Well I figured it was time to finally utilize this section of my site to talk about the stuff I’ve been working on. I think, like many creators, the idea of sharing your projects with the world can be intimidating, but I realized that if I ever plan on actually releasing, I’ll have to rip the bandage off eventually anyway. The problem is that, often when you read anything about an indie game in the works, the developers post pretty screenshots or game play videos (definitely not for advertisement reasons wink wink), but as a solo developer who has spent the last 25 years writing code, my artistic and 3D modeling abilities aren’t exactly praiseworthy.

However, I think there’s a niche for people like me. I’ve often found myself digging through various games to try and find early blockout work, discussions on their process, what challenges they faced and how they resolved them, etc.

What I’ve found is that, the vast majority of studios simply don’t document (or at least share) this sort of early development work online, and so I decided that this is exactly what I’m going to do. My screenshots are not going to be anything to brag about, and you may think I’m winging it at times (because sometimes I really am), but I think there’s something of value I can bring to the world, or at least a few of you indie devs out there. Maybe that’s “I understand your pain” or maybe it’s validation that you’re not failing. Whatever it might be, I welcome you to follow along as I rip out my beard hair in the beautiful, painful world of indie game development.

Just know, I actually do plan on releasing one day, but there are no guarantees in life. I could get sick, I could get burnt out and decide all of the time and effort just isn’t worth it anymore, I may find the expenses once I start reaching out to artists becomes too great, or I may simply get bored and decide it’s time to call it quits. I think it’s important to realize that it’s OK to stop when the joy and love for your project / hobby starts feeling more like a chore.

The “Reaper Project”

I originally began work on this project around 2019. Back then I had very unrealistic goals and expectations. I thought Genshin Impact was the coolest game I had seen in many years because it was an open-world game I actually loved to explore. The anime themed, stylized design was awesome in my opinion. Now, I certainly knew that I could never even scratch the surface of a game that’s made by a studio that had dozens of skilled artists, programmers, and an entire orchestra on standby whenever they needed a new masterpiece of video game music... but I could certainly take inspiration from it.

Fake Progress

What am I even trying to make? I spent months working on code. I purchased several asset packs. I spent weeks modeling terrains and adding mesh assets. It felt like progress. I could see something that was starting to resemble a game. I had enemies that spawned in and attacked the player. I had visual effects on the weapons. I even had a sound track I purchased for the game...but..

I realized that what I actually had was the start of a pretty looking...interactive asset pack, not a game. I didn’t actually have a plan. I had no real direction. I knew about game design docs well before I began working on the project, but I didn’t quite understand what the point of them actually was. I would spend hours writing up the story, locations, etc. but my actual game play descriptions were vague at best.

2020-2021

I scrapped the original project, then the next, then the next after that. It wasn’t all a loss however. Like Edison, I was learning 1000 ways not to build a video game, but I wasn’t actually getting any closer to actually creating one. Having finally realized this, I took the time to properly study game design. I scaled the project scope back to what I thought then was a reasonable scope. I stopped buying asset packs and began using placeholders everywhere.

The thing is, I’m a programmer at heart. I was bored at work writing client middleware, wrapping wrappers around generated protobuf clients... it wasn’t exactly thrilling work and so my game development hobby became more of an exercise in software architecture. Now, I will say that wasn’t the worst thing I did. In fact, I’m still using quite a bit of the code I wrote back then because it was pretty good code. The problem was that I lost focus on what I was actually writing all of that code for.

2022-2024

Still massively bored at work and starting to get burnt out with programming in general, I shifted my focus toward level design. I found myself obsessed with it. A hike in the forest became a research trip. A drive through the city became a study of architecture. I was taking dozens of photos every day of random stuff; moss-covered stairs, old wooden doors, and maybe the most odd, retaining walls. There’s something about the sharp contrast between nature and brick and our constant struggle to control nature that’s fascinating to me.

Yeah, I still had no idea what I was doing. I spent about a year creating and scrapping dozens of blockouts. I kept thinking “ok, I messed up on the last one because I didn’t really have a good layout plan for it”, but that wasn’t quite the issue.

What I eventually learned was that, video game levels are a playground for your game mechanics. Without having a solid plan for your game mechanics, your levels are going to look and feel like a random collection of grid-textured blocks. This is when it started clicking for me what the true purpose of a game design document actually was, and why all of my previous attempts ended in failure.

Then in 2025

After returning from a work related trip from Las Vegas, I was feeling super motivated once again. However, I decided that this time around was going to be different. This time, before I wrote a single line of code or added a single cube to the scene, I would spend the first 2-3 weeks doing nothing but planning what the game was actually going to be.

I drew inspiration from dozens of games, including:

• Death’s Door
• Battle Chasers: Nightwar
• Bastion
• Tunic
• Hob

I had a very specific style in mind. I knew I wanted the overhead “isometric” style camera. For some reason, that style always felt like “a video game” to me. A bit hard to explain, but it did come with a few benefits:

1. Works extremely well with the stylized aesthetic.
2. Doesn’t require super-detailed meshes - geometry can be greatly simplified.
3. Greatly reduced need for LOD assets since simple frustum culling can do a lot of the heavy lifting.
4. And more reasons I’m feeling too lazy to think of currently.

However, this style also comes with a few slight problems, such as the inability to place hero assets that draw the player’s attention, the player can easily get lost unless you have unique areas / assets to act as anchoring points, the camera can clip through tall objects, etc.

Anyway, I’ve gone off on a tangent. The result of the legwork I put in to design the game before getting started working on it, ultimately paid off. While the game design has undergone dozens of iterations, the original concept and mechanics are mostly intact.

Some of the major decisions I made included:

Decide what the core pillars of the game are going to be:

1. Exploration and discovery being the primary design goal.
2. Souls-like combat and save points.
3. Puzzle heavy level design, traps, and environmental hazards.
4. Frequent object interactions.

Determine how combat works: I didn’t want to create a mob fest game where every 3 seconds the player is engaged in yet another encounter. I’ve always found those games to become very monotonous, very quickly. I wanted encounters to feel intentional and dangerous. Games such as Death’s Door, Hob, and Tunic do a great job at pacing encounters instead of just tossing wave after wave at the player, which turns the game play into a blender simulator.

I decided early on that the players weapons they unlock over time will become the key to encounter design, and in fact, enemy design in general; each weapon would specialize in different types of damage. A weapon that specializes in physical damage may barely scratch an ethereal creature, while a weapon that specializes in radiant damage would obliterate corrupted spirits.

What type of puzzles and why do they exist?: I decided the reason why puzzles exist is to keep the player engaged and to give them something to do in between encounters. They would typically act as gates. This could be literally blocking the player from moving forward, or could be optional, maybe unlocking a reward if completed. This simple mental framework could lead to dozens of unique puzzle types, perhaps something like:

1. A torch activates the moment the player walks across a tile.
2. This prevents them from accessing a room which has a lever that’s required to open a gate.
3. The player must find and smash 4 oil tanks that feed the torch.
4. They can then access the room, pull the lever, then move on.

Ask, don’t tell: There’s all sorts of things that happen automatically in many games; you walk up to a door, it opens automatically. You walk onto a lift, it starts moving... I felt like that’s a huge missed opportunity to engage the player to take action. What if a lever is placed 3 meters from a door that has an automatic timer to close after 2 seconds? This would require the player to use their dash ability to make it through the door before it closes.

There’s also a theme in many modern games of hand-holding the player to the point of playing the game for them. While you want to avoid confusing the player and making them sit there thinking “wtf do I do now?”, you also don’t need to have flashing red arrows pointing at everything. This tied in with my exploration and discovery core pillar; give the player a chance to discover how the world around them works.

Fast Forward

It’s now August, 2026. It’s been a rough year. I was laid off back in December and spent the past 8 months applying and interviewing without any luck yet. This made game development feel like a fun, rewarding activity that I felt guilty for spending time on, because it’s not earning me a paycheck. However, I figured that I could spend all of my time creating web apps in order to keep my skills sharp, or I could spend the same time working on something (I think is) considerably more difficult.

I’m still finding a lot of things difficult. At this point, I’ve:

1. Figured out the player progression system.
2. Created a full character attributes system.
3. Created a pretty cool (I think) solution for enemy AI.
4. Enemy spawning and pooling.
5. Game save system.
6. Dialog and interaction system.
7. SO based audio system.
8. Status effects.
9. And tons more.

My biggest breakthrough however happened about a month back. I mentioned earlier that Battle Chasers: Nightwar was one of my inspirations. For a while, my goal was to create levels very similar to those in Hob. The issue was that, level design is a discipline that takes years of effort to master. I’m not a level designer. While I’ve studied it now for years, there’s a difference between theory and real-world experience. Many level design professionals work on small parts of a game for years while learning from the pros before they ever take the lead. I’m not so naive to think that I can somehow brute-force my way into it by sheer will-power.

This meant I needed an approach that works for me, and that’s exactly where Battle Chasers became my north star. I had played around with the idea of “diorama based levels” for a while at this point, but it never quite clicked that “diorama” didn’t have to mean “a 10x10ft room” before. I had spent days on end playing the game, watching game play videos on youtube, digging through every last screenshot I could find on the game’s development, etc.

I think it clicked after seeing this video where the developers were talking about how it came to be and what made them go in the visual direction they did. Now the difference between my design and theirs is that, in Battle Chasers, you move from area to area via the 2D over-world map. Where I deviate is that, in the reaper project, the game world is one continuous, sprawling series of “rooms”.

I prototyped the basic system for this within a few hours. What I came up with was:

1. Each level is entirely contained with a Unity Scene.
2. Each room is nested within a “room_x” game object hierarchy.
3. Each room then has 1 or more “room connectors”.
4. As the player moves through the connector “gates”, they’re teleported to the next room while the previous room is deactivated and cleaned up.

What This Gives

Programming for me is a fun activity. I could spend the rest of my life experimenting with architectures and growing my skills. This often has led me to procrastination from “the hard stuff” - in particular, level design. What I kept finding was the “blank canvas” problem. I tried many ways to find constraints, but I had kept trying to use Hob as a reference for my level design.

When I switched to the idea that each level could be a series of rooms, I suddenly had the exact constraints I desperately had been searching for:

1. Each room is self-contained, but connected to one or more rooms.
2. Each room could be as small as a 5x5 square with a “shrine” at the center, or large enough to comfortably fit a puzzle along with a few enemies.
3. Each room would generally have one point of interest or game mechanic, but not strictly limited.
4. Each level would have 12-15 rooms, many of which looped back to previous rooms.
5. If I felt the level was too small at the end, I could easily add additional rooms.
6. Rooms would provide a simple way to organize “game beats”: encounter -> puzzle -> rest -> story -> hazard -> encounter... but wouldn’t necessarily need to be linear. The player could choose to go through any unlocked gate they wanted to.
7. Puzzles could span multiple rooms. For example, a locked area that requires a lever to be pulled 4 rooms away - however, this must be at least hinted to the player, possibly through a voice over “Hrm, this area seems to be locked. I’ll have to find the mechanism to open it”.
8. Natural boss “rooms”; the player enters the room, but it’s a one-way door and the only way out is to defeat the boss which activates the gateway to the next area.
9. Level to level blending: As the player begins to reach the end of one level, more and more assets from the next level begin to appear, creating a smooth visual transition and selling the idea that they’re exploring a single, continuous world.
10. Hubs and Dungeons: Each level will have at least 1 major hub area. Hubs will typically be several times larger than the typical room, and will feature doors / gates to several “dungeons”. Dungeons can be as small as 2 rooms or multiple rooms, but they’ll each exit back to the hub.
11. Hidden rooms: Players get rewarded for exploration. Perhaps they push a bookshelf out of the way which reveals a door to a secret room where they’re given some reward.
12. Level loop-backs: This is my favorite idea. Level 1 could have a blocked off section that requires a specific type of damage to break through and access. The room it connects to has higher level enemies than what’s normally found in level 1. However, they can only access this room once they’ve acquired the appropriate type of weapon which may be found in level 4 with a gate nearby connecting back to level 1.

With all of that said, I would say the primary thing this design gives me is the ability to think in much smaller steps than what I was facing when trying to design a Hob-like level and feeling overwhelmed the entire time. Here’s a small portion of a room in a recent blockout:

Wrapping Up

Well this post became 10x larger than I was originally planning. The rest of the posts I’ll add to this project will be far more scoped. I plan on talking about this in further detail such as how the player progression and attributes system works, my level design workflow, more early development screenshots, etc.

If any of this resonates with you, hit me up on Discord @ xealgo.

I’m also looking for people who’d like to contribute to the project. If you have Unity / C# skills, 2D/3D art or animation skills, level design, sound/vfx skills, etc. please reach out if you’re interested!