# Cinco de Mayo Update + Some Discussion About Scope Creep

Happy Cinco de Mayo everyone! This is one of my favorite times of the year because it's a great excuse to eat Tex-Mex food and my family can't say no because it also happens to be my birthday. Win / Win! 

## Fun Stuff To Add

It's funny how that can lead you into some serious temptation though. Yesterday (May the Fourth Be With You btw) I had the "brilliant" idea to add some Cinco de Mayo themed items to Delvers Inc. The thought being, hey let's add some tacos, some enchiladas, maybe a margarita, that sort of thing to the game as a fun little side item. Adding items and giving them effects is pretty easy now, I would just need some icon art which I probably had in one of the many collections I draw from.
<img src="/images/Doner.png" alt="Taco" width="150" style={{ display: 'inline-block', marginRight: '10px' }} />
<img src="/images/GlassOfJuice.png" alt="Margarita" width="150" style={{ display: 'inline-block' }} />

This morning I started to really think about it and plan out what needed to happen. For a start...what effects would they supply? After all, just having some food items that don't do anything would be kinda pointless. It didn't take long to hit on taco = +1 heal, enchilada = +2 heal, and margarita = +1 attack but also -1 defense. So that wasn't too bad but...it felt kinda silly to put them in chest drops. I would need to sell them somewhere. Selling them at the merchant seemed equally silly, but we have an Innkeeper, unfortunately the Innkeeper was currently only set up to have a dialogue with the player about getting the location of a new dungeon map.

We could make modifications to the Innkeeper dialogue scripts to have an option to buy each of the items but that isn't very scalable if we add more food-like items. We could add the ability to open a shop like experience but right now the Merchant is an entirely different UI panel and we don't have a separate shop UI, so then we would have to create a new UI for a pop-up shop. Suddenly this is looking like a lot of work for something that was supposed to be just a fun little bit of 'frippery' (that's your 0.25 cent word for the day). 

## That's Scope Creep

I ended up dropping it for now, what started like a fun little sounding thing ended up being actual work. Which really got me thinking about how easy it is to scope creep yourself. Back in the day when I was working for game studios, it was not uncommon for a designer or product manager to come up with a little idea that sounded great on paper. That's when one of two things would happen. Either a) they would ask for an estimate and get dissapointed when it turns out that the simple little thing had actual work attached to it that couldn't be justified, or b) it would get pushed forward anyway as a pet project of someone and suddenly timelines are getting blown and other bigger and more important features are getting delayed. Invariably engineering would get blamed for it no matter what. "Engineering is always over-estimating timelines to avoid adding new things, they must hate fun!" or "Why is engineering always slipping and missing their deadlines? Lazy slackers need to crunch to make up the time!" 

Scope creep being recognized AS scope creep and shelved without acrimony was an incredibly uncommon occurance. There are, of course, places that are better at it, but for the vast majority scope creep is rampant and the blame game lands squarely on engineering when it happens. We should be better at communicating about it but for whatever reason, we aren't. Is it ego? Is it a facet of everyone having too much to do already that having a discussion about it falls to the wayside? Is it, in fact, on engineering's inability to properly articulate the technical aspects and costs of a request so that non-technical people can understand the impact? Probably it's a little of all of those things. I can't blame a lack of good communication and ego on Delvers Inc's lack of tacos and enchiladas though. I am a one man shop so I am only having to communicate with myself. Kinda like my wife having a parent-teacher conference when she was home schooling our kids.

## Delvers Inc. Updates

What's up with Delvers Inc though? Well since we last spoke Delvers have gained classes. In the end, I felt that classes just added clarity to what a delver does in ways that a classless system just doesn't. I love classless systems, One of my favorite old-school MMOs was Asherons Call which was famously classless. Special Actions have finally gotten implemented, they are still just called Special Actions for now, but they work! Delvers can also be upgraded outside of their level. You can "consume" three other delvers of the same type and rarity level to upgrade another one to the next rarity tier. 
![Upgrade Delver](/images/upgrade-delver.png) 
This also means that our leveling data now has different values for each level AND rarity tier so that having an Epic Varro Duskrun hits harder than a Common Varro Duskrun. I have been working on some eye candy for the UI to give it a little bit more pop and less of an Excel spreadsheet feel to it, courtesy of the DoTween Pro asset. Finally I cleaned up a few bugs that had been hanging around for awhile which is always a feel good moment.

## The Plan For Next Week

This week I will be focused on getting more of the flash into the UI and into combat (floaty damage numbers anyone), as well as a foray into some sound effects and background music.

Thanks for reading and keeping up with Delvers Inc! We'll talk again next week and in the meantime, follow us on X and Facebook for updates or sign up for our newsletter so that you don't miss a post!

-Arakiel

Cinco de Mayo Update + Scope Creep

# Delvers Inc Update! Also, be careful with Cinemachine

Hello everyone, Arakiel here with a new update on Delvers Inc. 

You may remember from last week's [post](https://www.delververse.com/blog/marchant-updates) that I had managed to give myself a ton of extra work by forgetting that A.I isn't I. Well I finally managed to fix all that. It took all day and then some but I got there and cleaned up the horrible code problems. Things make sense again! Huzzah!

While I was in there cleaning up the disastrous refactor, I got equipment equipping again. Then I went on a cleaning spree. We now have TownData which will be and is, used to define what a town IS and what resources are available to the guildmaster in a given town. Moved from that, on to a camera problem I was experiencing. That one is actually worth a slight side trip to talk about honestly, but first...let's finish the project status update.

Health potions! Got a basic usage system finally put into place so you can now buy and use a health potion if your cleric can't keep up. ![health-potion](/images/small-health.png) And yesterday I finished up the basic party management panel. ![party-management](/images/simple-party-management.gif) No more do I have to live with the party of 4 "Starter" delvers that I set up months ago. Long live Varro Duskrun!

I have the basics of a party formation system in place but that is not fleshed out very well and I am honestly not sure if it will make it for the 1.0 of the game. That might come later.

## The Camera Problem

Shortly after getting the dungeons working and the Delvers delving, it became obvious that I hadn't considered the follow camera showing areas outside the map. The camera would always keep the party of delvers centered as it followed them around but that means as they got close to an outside wall, it would show the... "void" the blank area or unused space in the scene. Very ugly.

I set about finding a way to keep the camera within bounds and quickly hit upon several topics from folks recommending Cinemachine for it. This was a great idea, Cinemachine could also handle the follow logic very well and I could get rid of the camera update code I was using to track the party. In addition, Cinemachine has a Confiner component which will do exactly what I was looking for...keep the camera within a boundary.

I got the latest Cinemachine installed into the project and got to setting it all up only to find that it wasn't working. As soon as I would set the boundary, the main camera would get "lost" off screen. The Cinemachine camera was fine but it's the main camera that wasn't. Cue lots of debugging and hair pulling. I watched many tutorials, I read the documentation, I experimented, poked and prodded and... nothing.

The tutorials I had been watching were all for the 2.x version of Cinemachine so I had to do a little translation since Cinemachine was now on 3.x starting back in September of 2024 but that was fine. It was mostly just component name changes and some slight inspector differences. So it should have still worked, but I couldn't get it to. I then shelved it for a time, I would get back to it later with a clear head.

## The Cleaning Spree

During my 'post-refactor-refactor' cleaning spree I decided that I had lived without a bound camera for long enough and that I was finally going to get that sorted. After diving back in I immediately hit the same wall that I had weeks ago. Everything was setup correctly. I had double, triple and quadruple checked all the settings, revisited the code a dozen times, cleared caches, everything I could think of and it simply refused to work.

## The "Fix"

That's when I decided to downgrade. It was my last desperate attempt to get this to work before I junked the whole thing and wrote my own bound camera logic from scratch. I downgraded to the last 2.x version (2.10.3 if you're keeping track). I had to revert everything back to 2.x namespace and components but that was easy enough and done quickly. I hit the magic buttton aaand.... it just worked. I sat, rather dumbfounded, staring at the screen as my delvers moved around the side of a dungeon and the camera stayed within the dungeon boundaries I had setup. It...just worked...

I posted it to the Unity Discussion forums just in case it was a bug or something with the 3.x versions of Cinemachine since that's certainly how it feels on my end, but for myself I am going to stay on v2.10.3. Someone from Unity responded yesterday and asked for a sample project that shows the error, but I haven't put one together yet since I have a million other things to do. I'll get to it at some point. In the meantime, watch out for Cinemachine. Seems like they aren't yet at feature parity with the 2.x versions.

## What's Next For Delvers Inc.

Next up on the docket is more work on the delvers themselves. I need to get special actions working, I need to come to a final conclusion on whether or not I want delvers to have classes or not because I still waffle on that. Then I need to be able to upgrade the delvers quality tier, not just their level.

That's all for now. We'll talk again next week and in the meantime, follow us on X and Facebook for updates or sign up for our newsletter so that you don't miss a post!

Delvers Inc Update and a Caution with Cinemachine

# Merchant Updates (or, how I shot myself in the foot with AI)

So... mistakes were made.

You may recall from last weeks [Post](https://www.delververse.com/blog/what-is-delvers-inc) that I was working on and planning to finish, merchants so that the player could buy and sell all the phat lootz. Well, things didn't go quite to plan. First of all, I was delayed for some things outside the purview of Delvers Inc and it was unavoidable, I thought for sure I could catch up and get things finished up enough by EOD Monday to put out the blog post. This, it turns out, was the purest of fantasy as I have managed to shoot myself in the foot while simultaneously thinking myself very clever. A horrible combination.

First off, know that merchants exist, and they have inventories of items you can buy from or sell to them. So yay (insert applause). However the real meat of this blog post isn't going to be about that. This is ending up more akin to a recent blog post from Garry Newman whom many of you may know as the gentleman who gave us both Garry's Mod and Rust. That post, entitled quite accurately as [In The Shit](https://garry.net/posts/in-the-shit), can be read at your leisure by following that link.

## How We Got Into This Pile Of Shit

You see, I'm Gen-X and Gen-X isn't always up to date on the latest buzzwords going around even when those buzzwords are in their own particular industry. 

A few weeks back I heard a "new-to-me" one... 'Vibe Coding'. If you're like me and were wondering 'what on God's green earth is Vibe Coding?', allow me to summarize. Vibe Coding is at its most essential, the use of LLM to describe in normal human language, the functionality of a system or application but let the LLM do all the work of actually BUILDING it. 

Up to that point my exposure to AI/LLMs has been what could best be described as an "interesting hobby". I wasn't using the AI to do anything worthwhile and certainly not anything I would try to maintain myself so I figured I would give it a whirl and see what happened. 

This came about gradually you see. It started with an article in Code magazine (which my former employer is still, for some reason, paying for me to receive) in which the author used ChatGPT to remake [Asteroids](https://www.codemag.com/Article/2411061/Can-an-LLM-Make-a-Video-Game). It was an interesting read, as was the follow up article the next issue where the author created a [TTRPG encounter builder](https://www.codemag.com/Article/2501071/The-Infinite-Monster-Engine) that used ChatGPT to build the encounter. 

That lead me to trying a few 'vibe coding' experiments over a weekend. First I/It made an AAX->M4A converter (for ahem... purely educational purposes I assure you), as well as a Todo app since the Microsoft one annoys me and I refuse to spend money on a todo application. Honestly, a text document with [ ] characters has worked just fine for decades. Why mess with perfection? ![Meh...](/images/todos-meh.png) It all went swimmingly. 

I of course, in true vibe coding fashion, learned nothing about the code it was writing because honestly I didn't care. The stuff it was making was working, I was learning how to talk to the LLM to make it do what I asked, it was a fun weekend activity. Life was fine. 

## The First Mistake

Then one day a few weeks back I was working on Delvers Inc and ran into a bit of a problem. You see, at the time I had a single class handling everything visual for the delvers in scene. Nav setup, movement, attacking, healing, equipment visuals, etc... if it had to to with how Delvers looked on screen then it was in this single class. 

As you can imagine this class started off small but as the game got bigger, so did this controller. More and more was getting added for convenience so that I could move on to the next feature and the class had grown out of control. It was huge, it had multiple jobs, it was desperately in need of a refactor. 

When it got to the point that I spent more time scrolling the class looking for the place I needed to make a change then it took to actually make the change, I knew I had a problem. It needed a refactor badly but I was avoiding it because it would be an all-day undertaking and I wanted to do the next cool thing. 

So, here I was, high off the recent 'success' of my vibe coding experiments like a junkie looking for his next easy score. I decided to let Claude AI handle the refactor, after all it had worked so well up to this point and I firmly believed that Claude could get it done in a fraction of the time. 

So I spent a good half hour or so crafting a detailed prompt. I laid out everything it would need for context, what I wanted it to do, even why I wanted it to do it. Then I sent Claude off to do it's thing while I went and did some hoousehold chores. I had to come back and type 'Continue' a few times because Anthropic has some insanely draconian usage limitations but eventually it spit the whole refactor out. I brought it all into my codebase, had to fix some syntax problems, noticed a few immediate errors where Claude decided that some navmesh code I had written before wasn't necessary for some reason but within about 2 hours, I had the whole thing working again under the newly refactored classes. Success! 8-10 hours of work in only slightly more than 2! Honestly it wasn't that bad, and if I had left it at that, then we wouldn't be having this conversation. 

But I didn't, I had to press my luck and that leads us to the second mistake.

## The Second Mistake

At the time that all this went down, I had been working on the Inventory panel. I was mostly done with it, but this panel, much like the delver controller class, had grown too big. It had to handle too much and it was getting difficult to get around the code. 

Having just gotten my recent dopamine hit from the delver control refactor, I stupidly decided to let Claude also refactor the inventory panel code. I crafted another detailed prompt, context was a problem because the Inventory panel was a bit spider like. It had to touch several systems INCLUDING all the new delver control systems. 

I added as much context for Claude that I reasonably could and let it do its thing. This time there were more errors and it took more effort to massage the refactored code into the codebase. In terms of time saved, I figured the refactor probably would have taken half a day or so and it was done in about 2ish hours. So once again, I had "saved" another 2 hours of time. 

Claude had decided to use a command pattern for a whopping total of 3 commands when it really didn't need to, but I left it because I wanted to be done and move on to the next cool thing. Which is why I also didn't inspect the refactor too closely. This was mistake number three.

## The Third Mistake

EVERY SINGLE LLM will tell you, right at the bottom of the screen next to the input box, that the AI can make mistakes and to check its work carefully. 

I did not do this, I had gotten used to it spitting out mostly decent responses, and honestly...when I see those warnings I think more about LLM hallucination problems. Like the AI just making up information that doesn't exist. However, the mistakes that Claude made this time around weren't hallucinations it was because Claude, despite it being called an Artificial Intelligence, has nothing what-so-ever intelligent about it. It didn't *understand* my codebase. It couldn't make decisions based upon that understanding because it doesn't have one. It isn't intelligent, "AI" is just a marketing term for the media, these LLMs are, when you really get down to it, highly sophisticated guessing machines. 

You could make a really fancy and sophisticated machine that throws darts at a dart board with high accuracy...that doesn't make it intelligent. I knew this, but during my experiments with 'vibe coding' I had deceived myself into believing it was "smart". Similar to the para-social connection some people get with their favorite YouTuber who not only doesn't think of the fan as a friend but honestly doesn't know they exist. I had assigned intelligence to the LLM where there was none. 


This was the third mistake but it hadn't hit me quite yet because on the surface everything was fine. Everything appeared to be working, and I had moved on to the next "cool thing".

## Oh...Now You've Stepped In It

![That is one big pile of shit](/images/big-pile.jpg) Fast forward some time. I was working rapidly, new features were getting added, systems were getting improved, every once in a while I would give a side-eye over to the refactored code knowing that I hadn't really inspected it carefully but everything was working so it couldn't be all that bad right? 

I got merchants mostly in place and was doing some testing when it finally hit, that shoe finally dropped. "Uh...why is that piece of armor I just bought from the merchant not showing up on my delver when I equip it?" 

As I step through the code it starts hitting me in waves. 
- Inventory is calling Equip in the wrong place.
- The fact that there are multiple places to call Equip is disheartening all on its own.
- Visuals are not getting updated.
- Effects are getting added to the delver not once but THREE times.
- The refactor had replaced 2 lines of code with 30 and an entire command pattern structure.
- Code was partially missing in places (seriously, Claude had kept the code to handle updating weapon visuals but tossed the code that handled updating armor)
- Duplicated code was all over the place.
- Code doing the same thing but slightly differently was likewise all over the place. 

 It was/is a hot mess. 
 
 I couldnt just roll back, at this point I had weeks worth of changes on top of that refactor, also those spots in code had still needed *A* refactor at the time, that's how we got here, so rolling back wasn't going to work. I have to refactor the refactor. Clean everything up and put it back into a working order that makes sense. 

## So What Are The Lessons Learned

Honestly, this is not a fault with the LLM. This is a ME problem. 

I gave the LLM too much credit, I got too relaxed using it and forgot that it isn't intelligent. It doesn't *think* despite what the vendors want you to believe when they throw marketing terms like *thinking* mode or *reasoning* mode at you. That's just marketing mumbo jumbo for "spending more time iterating over it's fancy guessing algorithm". 

I knew these things but I let myself be persuaded otherwise. This isn't to say LLMs don't have their uses. They do, they can assist and speed things up just like Intellisense did so many years ago, but I balk at the 10x-ing claims some people will make, that is short term thinking. 

That 6-8 hours I had 'saved' myself by letting Claude handle the refactor? Well that is probably what it is going to take me to clean up this mess. Ultimately I saved myself zero time, likely cost myself additional time when you add in debugging the problems. 

You cannot replace software engineering with a guessing machine. Some executives who only think in the short term might want to believe that, but right now they are like me a couple weeks ago...they are in the 'fuck around' stage. Also like me they will eventually hit the 'find out' stage. 

Now, if you will excuse me I have a giant mess to cleanup, so I'll talk to you all next week and as always... in the meantime, Like us on X and Facebook or sign up for our newsletter so that you don't miss out on a post!

-Arakiel

Merchant Updates (or, how I shot myself in the foot with AI)

# Delvers Inc : We Should Talk About What It Is

It occurred to me after posting my previous blog post on bounded random combat systems [Link Here](https://www.delververse.com/blog/bounded-combat), that many if not most of you don't actually even know what Delvers Inc is supposed to be. So we should probably address that for clarity sake.

Delvers Inc is a game where you take on the part of a Guildmaster over a company of dungeon delving adventurers. Every party of adventurers can contain up to 4 different members who dive headfirst into dangerous dungeons, explore their depths, kill monsters, gather up loot, and become more powerful. Or in more game-ified terms, it's a light fantasy RPG dungeon explorer.

It is intended to be easily playable on both computers and mobile devices so that you can jump in, run a few dungeons, kill a few bad guys and then get back to whatever else you were doing until you're ready to explore again. This is not intended as a game that you pick up and lose hours upon hours in, but rather something you play when you have some free time and specifically don't want to get too deeply involved. This isn't 2D Skyrim.

The primary playing spaces are the dungeon maps. Dungeons are scattered all over the game world as abandoned temples, ruined castles, vast caverns, city sewer systems, ancient underground cities, and more. There are towns and villages as well, so that you can recruit new delvers to your guild, find out about other nearby dungeons to explore, sell off the loot you've gathered and don't want, and buy supplies for your parties next delve.

As a top down 2D game, you can point and click or tap to navigate your party through the dungeon, when they encounter monsters to fight they will automatically engage using a series of actions mapped to their own particular style. We talked about combat last week but something to add to our previous discussion is "Special Actions" (better lore appropriate name TBD) which the Guildmaster (that's you, just in case that wasn't clear) can fire off as needed when the delver has accumulated enough power.

Loot is automatically picked up by your party on the death of a monster or the opening of a chest. You can then equip that onto a member of your party if you wish to start using it right away, or you leave it in your inventory to sell later on in town.

Each delver gains experience as they explore and kill monsters and can level up, gaining more health, better attacks and more deft defenses.

## Delvers Inc : Development Progress

Well that's kinda what this blog is all about. Giving updates on what is being developed and why. How things are going, etc... Last week for example was all about getting some of the UI up to snuff, loading and transition screens and getting the travelling to and from dungeons figured out. This week is getting the basics of the merchants in place. What they will sell to the player, how much they will pay for your unwanted loot, that sort of thing. Next week's blog post will probably be sharing some of what has been happening with that.

![Merchant In Progress](/images/merchant-progress.png)
 
Delver movement and the basics of combat are in place, although I haven't yet implemented the, previously mentioned, "Special Actions" system. Monsters will wander around and attack the player, loot gets dropped, chests have loot tables and will spawn around the map. You can hit up town and unlock new maps and recruit new delvers.

Looking ahead, after I get the merchant sorted out, I want to finish off basic combat by implementing those Special Actions next.

## Delvers Inc : Roadmap
![Tiny Map](/images/tiny-map-part.png)
 

While timelines have been pretty loose, and in order to get some vertical slicing going I have been partially implementing some systems so some features are partially completed. The basic roadmap is as follows even though it reads more like a todo list:

- Party Management - Setting what Delvers are in your party
- Dungeon Scaling - As a general rule I am not fond of scaling up a dungeon but rather dungeons will be "banded" 'this dungeon is for parties in the 1-5 level range' that sort of thing.
- Rarity tiers on Delvers and the ability to increase a delver's rarity to make them more powerful.
- Make a final decision on whether I want delvers to have a class. Right now they do not and I did that intentionally but I am running into situations that could be made better if there was a class for a delver, so it is still a decision point.
- Multi-level dungeons that checkpoint. So you can enter a dungeon with multiple levels, complete a level or two and then return to town without worrying about having to fight your way back through those finished levels.
- Consumables! Believe it or not, consumables like health potions are not yet implemented. We need those and a UI for using them while adventuring.
- Boss fights - Each dungeon level should have a harder boss that the player needs to fight to complete the level. These bosses obviously get the best loot in the dungeon.
- Ultra rare artifact items that can really give your delver a power boost but take a lot of adventuring and crafting to acquire.
- Flash and awe, right now fight updates are all via debug message logging. We need particle effects, camera shaking, and floating damage to give fights some impact for the player.
- Flash and awe for the ears - right now there is a grand total of 1 sound effect in the game (opening a chest) we obvisouly are going to need more then that, and some background music to boot.
- Settings menu - because you need to be able to turn sounds off if you want. Personally, if one of my mobile devices makes a noise, it's likely to get thrown out the window.
- Integration with Steam, Google Play, & the App store.
- Data...lots and lots of data generation. New loot items, new delvers, new weapons, armor, shields, helmets, all the things!
- Dungeons...lots and lots of dungeons to explore.
- Monsters...because we have to fill up those dungeons with something interesting to kill.

There is probably a bunch of stuff I'm forgetting...or maybe I just don't want to tell you ;-) but that's pretty good and gives you the idea of where we are headed.

Well that's all for now. Let's talk again next week and in the meantime, Like us on X and Facebook or sign up for our newsletter so that you don't miss out on a post!

-Arakiel

What Is Delvers Inc.

# Creating Fair but Random Combat

## Combat Revamp: Making Battles More Engaging

When I started building Delvers Inc, I originally thought that combat would take a back seat. Early iterations of the combat system used a more 'idle' game mechanic where combat was both auto-resolved as well as auto-hit, I had a weird number crunching scheme to try and adjust for defensive modifiers but it never felt quite right. Like something stuck in my teeth that I couldn't get out but kept ignoring.  Battles felt too same-y all the time and the outcome was never in doubt.

The problem wasn't that the system was broken; it was doing exactly what I wanted at the start. The problem was that it didn't *feel* right to play, didn't feel engaging. One night I happened upon a video discussing the two types of "random" in games (this one if you're interested in watching it yourself: [The Two Types of Random in Game Design](https://youtu.be/dwI5b-wRLic?si=c4ot6US2AdiIsJb2)).  This got me considering that the auto-battle/auto-hit mechanic wasn't right and that I had gone down the wrong path.  This feeling drove me to completely revamp the combat system, searching for that perfect balance between randomness (which generates exciting moments) and consistency (which creates perceived fairness and help avoid rage quitting).

This journey led me to develop a "Bounded Combat Resolver"; a system that maintains the excitement and danger of random outcomes while ensuring players aren't subject to the extreme and often frustrating outliers that pure randomness creates AND removes the same-y-ness (is that a word?) of the auto-hit system.  Inspired by and modelled after HeroScapes Skull & Shield dice system (Rules PDF here if you aren't familiar with it: [HeroScape Basic Game Guide](https://www.hasbro.com/common/instruct/HeroScape_Basic_Game_Guide.pdf)), it has the side benefit of making the math easier and balancing of combat more straightforward.

## Introduction: When Random Isn't Fun

Picture this scenario: Your character has a 95% chance to hit. You're one attack away from defeating the boss. You swing... and miss. You try again... and miss. A third attempt... and miss again.

Mathematically, this streak of bad luck is entirely possible, the chance of missing three times in a row with a 95% hit rate is low but never 0, rare but not impossible. However, when it happens to a player, it doesn't feel random; it feels targeted at the player or worse yet...*broken*.

- **Pure randomness creates memorable moments** when the odds turn in our favor
- **Pure randomness creates rage-quit moments** when the odds turn against us

Unfortunately, Players remember negative outcomes much more vividly than positive ones.  It's just human nature.

The goal of a bounded combat resolver isn't to eliminate randomness but to tame its extreme edges. It's about creating a system where the highs and lows still exist, but extreme outliers (especially negative ones) are far less common.

## The Problem with Traditional RNG in Combat Systems

### The Reality vs. Perception Gap

Traditional random number generation (RNG) systems use flat probability distributions, each outcome within the range has an equal chance of occurring. This creates a fundamental disconnect between mathematical reality and player perception.

Traditional RNG often feels unfair because:

1. **Humans are pattern-seeking creatures** — We instinctively look for patterns even in randomness
2. **Negativity bias dominates perception** — We notice and remember negative outcomes more strongly than positive ones
3. **Flat distributions can enable extreme outcomes** — With pure randomness, nothing prevents multiple unlikely events from occurring in sequence.  They are unlikely not impossible.

In a purely random system, streaks are not just possible, they're inevitable. A 90% hit chance means you'll miss 1 in 10 times on average, but nothing prevents those misses from clustering together. When this happens, players don't blame mathematics; they blame the game.  'The game is cheating', 'The RNG gods hate me', 'This stupid game is broken! &lt;throws tablet at the wall&gt;'

The human brain isn't wired to intuitively understand probability. When we see a 90% hit chance, we expect something closer to "hit 9 times, then miss once, repeat", not the clumpy, streaky reality of true randomness.

## The Rule of Cool: Prioritizing Player Experience

When designing combat systems, there's a critical hierarchy of priorities to consider:

1. **Is it fun?** — Above all else, does the system create enjoyable gameplay moments?
2. **Does it feel fair?** — Do players feel like outcomes reflect their decisions and character builds?
3. **Is it mathematically sound?** — Does the system make sense within your game's ecosystem?

Note the order here, math purity and true randomness take a backseat to player enjoyment. This leads us to what a good Dungeon Master would call "the rule of cool": bend some rules under the pretext of player enjoyment.

A few principles emerge from this priority list:

- **Perceived fairness trumps actual mathematical fairness**
- **Consistency builds trust** in your game's systems
- **Reliable outcomes create value perception** — players feel their time (and potentially monetary!) investment matters

A bounded combat system addresses this by ensuring that, while randomness still exists, it operates within constraints/bounds that align with what the player expects.

## Bounded Randomness: The Best of Both Worlds?

### Alright already, stop beating the drum....so what IS Bounded Randomness?

Bounded randomness is an approach that constrains random outcomes to fall within a certain range around an expected value. Think of it as putting guardrails on your RNG system.

- **They use bell curves instead of flat distributions**
- **They establish minimum and maximum thresholds** based on statistical expectations
- **They still produce varied results** but prevent extreme outliers that cause rage quitting

To put it a different way, imagine plotting 1,000 combat results on a graph:

- **With traditional RNG**: Results would spread evenly across the entire spectrum, with some clusters of extremely good or bad outcomes
- **Bounded RNG**: Results would cluster around the expected value, with fewer examples at the extreme ends

## Building The Bounded Combat Resolver

Let's look at how to implement a bounded combat resolver using the approach developed for Delvers Inc.

### The Core Algorithm

The algorithm uses a few key steps:

1. **Calculate expected outcomes** based on character stats
2. **Determine acceptable deviation ranges** that scale with the input values
3. **Generate a normally distributed random value** using the Box-Muller transform
4. **Ensure minimum satisfying outcomes** even on "failures"

Here's a simplified version of the core damage calculation function but first some background on the combat mechanic itself:
- Every mob in the game has an attackPower and every mob in the game has a defensePower.
- Each point of power is essentially 1 "d6 die roll" where 4+ is a 'success'
- There is no real "to hit" per se, but if a monsters defense success is higher then your attack success then ... you missed.

```csharp
public int CalculateDamage(int attackPower, int defensePower, float criticalChance = 0.1f)
{
    // Calculate base expected damage
    var baseDamage = Math.Max(attackPower - defensePower, 0);

    // Calculate bounded attack and defense values
    var attackSuccesses = CalculateBoundedSuccesses(attackPower);
    var defenseSuccesses = CalculateBoundedSuccesses(defensePower);
    
    // Actual damage is attack successes minus defense successes
    // Remember, this system was inspired by the board game HeroScape
    var boundDamage = Math.Max(attackSuccesses - defenseSuccesses, 0);
    
    // Apply boundaries to keep results within expectations
    // This is a boundary ontop of the boundary because while we used
    // bounded success rolls, even that could lead to problems with extreme outliers
    // so we bound the damage in guardrails as well
    var minAcceptableDamage = Math.Max(Math.FloorToInt(baseDamage * 0.7f), attackPower > 0 ? 1 : 0);
    var maxAcceptableDamage = Math.CeilToInt(baseDamage * 1.3f);
    boundDamage = Math.Clamp(boundDamage, minAcceptableDamage, maxAcceptableDamage);
    
    return boundDamage;
}
```

The "magic" happens in the `CalculateBoundedSuccesses` method:

```csharp
private int CalculateBoundedSuccesses(int diceCount)
{
    // Calculate expected number of successes
    // Expected success rate in our case is 50% (4+ on a D6)
    var expectedSuccesses = diceCount * ExpectedSuccessRate;
    
    // Calculate allowed deviation based on dice count
    var deviation = Math.Sqrt(diceCount) * 0.5f;
    var minSuccesses = Math.Max(0, Math.FloorToInt(expectedSuccesses - deviation));
    var maxSuccesses = Math.Min(diceCount, Math.CeilToInt(expectedSuccesses + deviation));
    
    // Generate a normal distribution value centered around the expected value
    var normalRandom = CountBoundedSuccesses(expectedSuccesses, deviation / 2);
    
    // Round and clamp within boundaries
    var successes = Math.RoundToInt(normalRandom);
    successes = Math.Clamp(successes, minSuccesses, maxSuccesses);
    
    return successes;
}
```

So, here the system:

1. Calculates expected successes based on the dice count
3. Establishes boundaries based on the square root of the dice count
4. Uses a normal distribution to generate results clustered around the expected value
5. Clamps final results to ensure they stay within the established boundaries

The point here is that, as the power level (dice count) increases, the allowed deviation increases as well, but at a much slower rate. This creates a system where high-level characters have more consistent outputs than low-level ones.

## Fair AND Fun

The bounded combat resolver sounds a bit sketchy I know.  It raised some eyebrows on me when I first encountered it as well, BUT it's a player experience solution. By placing constraints on randomness without eliminating it entirely, we create combat that feels both fair and exciting.  We maintain the players understanding that the time they are putting in to make their characters better is worth it and that the game isn't cheating them out of their fair shake.

- Players trust that their character builds matter
- Each combat encounter maintains excitement without frustration
- The system scales naturally with character progression

In the end, this is about finding that sweet spot between chaos and control. A bounded system acknowledges that while unpredictability creates excitement, extreme outliers create frustration.  The goal isn't to eliminate randomness, it's to keep it in check so that it's just enough that players always feel like they're getting a fair shake and that the game isn't cheating, even when the dice don't roll in their favor.

Creating Fair But Random Combat


# Welcome to My Blog!

This is my first blog post on a new devblog for the Delvers Inc game that I am currently developing. I'm excited to share my thoughts and ideas with you.

## What to Expect

In this blog, I'll be writing about:

- Delvers Inc. of course
- Game Development
- General tech thoughts, concerns, rants
- And much more!

Stay tuned for more content coming soon!


Blog

Search & Filter

Tags

Cinco de Mayo Update + Scope Creep

Delvers Inc Update and a Caution with Cinemachine

Merchant Updates (or, how I shot myself in the foot with AI)

What Is Delvers Inc.

Creating Fair But Random Combat

Welcome to My DevBlog!