Hey guys (and gals),

I am currently working on a very very very simple dungeon crawler.

You have a profile that contains all items and stats of the player.

The inventory can contain a certain amount of items (currently 30...totally made up on the spot) and you can equip one of each equipment type (except for valuables).

The shop and profile management (call it town/camp if you like).

You can see the current state here: https://seelengeier.github.io/projects/rbdc/src/index.html

Ignore all values for the prices and durability, I don't have any serious data yet.

All data and numbers have been added as "to be replaced during the balancing phase".

Now I need to implement the dungeon part of my game (going right in the profile overview aka. camp).

My current plan says to implement something like this:

- you go into a room.

- if the room contains a monster, you can fight it

- if the room contains no (more) monster, you can go to the next room

- during a fight, you can only choose to strike or flee

- a strike leads to first the player doing one strike, then the enemy doing one

- fleeing leads to the enemy striking once and the player going into the next room if he survives

- When the enemy is dead, the player can get some loot

- if the player finds a room with a portal or exit or whatever (not sure yet, I don't want magic in the game), he can go back to town with his loot

- Or he can go back anytime (I think that's a bit too "easy mode")

- rince and repeat

I know how to implement the dungeon part, but I am not sure on how to balance it.

How do you balance your games?

Do you just come up with random numbers and tweak them by guessing and listening to your guts until they feel right (I get the feeling this would take ages)?

I don't want to have the player go from fight to fight one shotting every enemy, only to get one shotted back when the enemy gets a little bit harder.

I want the player to be able to go through many rooms with enemies while his equipment is getting worn down little by little.

He should have the mindset "should I go on for a chance of better loot or should I save my current loot".

He is supposed to have a good chance to survive the next room, but run the risk of losing if he is not careful.

How can he be careful if all he can choose is "go forward or go back" even during a fight?

I don't want to implement skills or anything fancy. The player should interact as little as possible with the fight.

All he has to do is decide to either take the risk or not.

Going home with his current loot makes the next run(s) easier due to better loot and the enemies should be easier to deal with in the beginning.

I am currently writing an excel file with all stats but when I look at that I only think "yup...nice stats, but no idea how to make them interact with each other".

So, how can I balance damage types, armor types, equipment durability, enemy hp, enemy damage (same as damage types), time invested, rooms cleared, run success rate (I'm sure I missed something)?

Where do I start?

Thanks,

SeelenGeier

Arriving at balance is recursive over many iterations: quality of gameplay is related to quality of playtesting, which is often dependent on number of effective iterations. Great heuristics are those that help you learn efficiently (high learning per iteration).

Five that have worked well for me in terms of learning quickly are -

1. Describe the intended player experience. Make statements about the player experience you want to create. That helps move faster toward meaningful values for your game. You've done this! I mention it for other readers 
2. Anchor around a centering stat, for which you choose a value with the granularity you require. In your case Health might be such a stat. You have only one strike per encounter so it can center on a small positive integer, e.g. 5. Given a centering value of 5, an "average" attack might deplete health by RNG(1,4)+RNG(1,4) i.e. 2-8. Seeing as your monsters in theory face only one or two attacks, while your character faces attacks up to your number of rooms, you can tell that reasonable starting health for monsters is 5 and reasonable health for characters (given no healing) is number_of_rooms * 5. You now have a standard monster (5 HP, deals 2-8 damage) and a standard character (50 HP given 10 rooms, and deals 2-8 damage). 10/16 times, players kill a monster with one strike. Monsters never kill players in early rooms. You set up your first test bed with some number of rooms, here 10 are assumed, with one standard monster in each, and play that to see how that feels.
3. Make changes that are big enough to learn from. Say you want 10 monsters, all different. You could iterate in small steps to gradually diverge each from the centering values, but I find it I learn fastest by jumping early to extreme values. For instance, to our standard monster you might add a strong monster that deals 10-40 damage, and has 8 HP. Here a spreadsheet becomes quite handy, because it allows you to create tables showing the odds (and especially the combinatorial odds). Players kill this monster only 1/16 times on first strike. It can't kill them in early rooms, but it can possibly kill them after the first two rooms. I might even go with a monster that cannot die on its first strike, say 10 HP. You can see here how our simple anchoring value of 5 HP is working for us. Change only one or two things at a time, but change them quickly. If you change multiple values at once, it becomes hard to tell which change caused the new game balance.
4. Make a config database. If you can, avoid embedding all your values across your code. Ideally you want a config that is powerful, such as one that allows you to change the anchoring value of 5 for health and have that change ripple out everywhere. Thus monsters might have health = health_standard while characters have health = health_standard*10. Again, the point of this is efficient iterations. The value of a config depends on the complexity of your game: you don't want to invest more time making it than would be spent changing the values by hand. On the other hand, it also helps reduce unintended changes by giving you one file for verification. If you use a spreadsheet, you can set it to output configs for you.
5. As you go, identify your key sensitivities. You'll quickly find that changing some values has a much bigger impact on balance than changing others. This is because the emergent dynamic from your collected game functions amplify some values more than others. Consciously note when you identify a key sensitivity.

I should add that the indispensable tool here is a spreadsheet. You should learn how to set up probability density functions etc. You can supplement a spreadsheet powerfully by writing scripts or bots to automate plays. If you do the latter, however, you also need graphs, filters or queries to help you look for features in the data produced. Things become more complex quickly, and a good spreadsheet helps you quickly visualise scenarios. Again, it is all about learning efficiently.

The above is very basic, and depending on how good your mathematics is you can go further. Bear in mind however that the combinatorial nature of events mean that even simple arrangements of numbers can offer very diversified play. As soon as you introduce a healing potion, or say a shield that has a chance to deflect damage (Talisman ftw), things become more interesting.
 

Thank you so much  that helps a lot already.

Especially point 2 is what I will focus on next.

Currently I don't have one baseline to go by and evaluate my stats.

This should help to clear things up for now.

Although finding a baseline stat might be hard when considering that a run could go infinitely if the player is really lucky.

He will lose health due to attacks and his equipment will get damaged and eventually break, but if he is lucky enough, he could go through many more rooms than on an average run.

I will try to set a default when I am done implementing the rooms.

This way I can see how long a room might take and how much rooms on average I want the player to clear.