State of the Game: Video Devlog 8.0 | Balancing
Hi, dungeon-crawling fans!
A lot has happened during the last few weeks. We are now in the polishing phase and plenty of mechanics have been fixed or refined. Please, enjoy this month's video update:
As always, you can find the transcript below!
Best wishes,
Michael
--------------------------------------------------------------
Hi, dungeon-crawling fans!
The first month of polishing is over and there has been so much progress I can barely fit it all in one video. For anyone who doesn’t know: Monomyth is now in its fifth beta phase, which is mostly reserved for visual and mechanical improvements. Most of last month’s time went into the latter, especially with balancing and adjusting mechanics accordingly.
We will take a look at all of this, but first, let’s get the smaller stuff out of the way:
I started the polishing phase with a few simple tasks, the first of which was a quick rework of enemies. I gave rats some additional textures and a few better sound effects. Nothing too fancy.
I fixed a few things in the character state machine and some of the movement, especially crouching, which should now work much more smoothly.
I also fixed a few issues for NPCs. Some of them wouldn’t leave their staggered state. This should now work correctly as well.
Further, I added an item to mark the walls, for example, to denote where you’ve already been.
I made some changes to blacksmithing. All metallic objects should now heat up properly and it is no longer possible to repair leather armor or cloth on an anvil. Equipment durability is scaled by a fragility factor, which decreases throughout the game, meaning that with higher-quality equipment, its durability will be less of a concern. In contrast, during the early game equipment will break more easily and you will depend strongly on whatever you can take from enemies.
Now we are getting to the stuff that took a little more time: During the last beta phase, a lot of items didn’t have proper descriptions. A little while before the last patch I actually changed my approach to writing a bit. I used to write in English only. Now I also write in German and translate whatever I wrote. As a result, it’s much easier for me to quickly produce adequate texts. Ironically, sometimes it’s still easier for me to write in English and then translate it back to German. So the rule is basically, whatever works, as long as a proper text is the end result.
Anyway, I completed item descriptions and then added item names to the UI so you can actually see what you are interacting with. I thought that having a simple text on screen wasn’t all that aesthetically pleasing so I decided to implement a highlighting frame. You may have seen this before in games like Dark Messiah of Might and Magic or Deus Ex. I also added the frame to containers to quickly communicate whether these are empty or locked. You have to interact with the containers once before this is shown though.
One thing that was very important for the polishing phase was getting versioned builds to work. In previous versions, I kept having trouble with UE4’s versioned building process. I could build my projects and deploy them on Steam, however versioned builds that work with a single, compressed .pak file would constantly freeze the building process. I finally resolved that issue and the project size on the Steam servers went down to a third of what it originally was. Additionally, I can finally deploy smaller, iterative patches, so beta testers don’t have to download the full, uncompressed game after every patch.
And now let’s get to the balancing, the biggest part of last month’s work. This took quite a while and most of the time was spent writing spreadsheets and coming up with nice mathematical functions. But let’s start at the beginning:
The point of balancing is, to provide a smooth progression of numeric values throughout the game - everything from attributes to damage, defense, gained skill points, combat vs quest experience, and so on. All of these values need to be properly balanced, otherwise, you’ll get unnecessary spikes or dips in difficulty that will (overly) frustrate or, worse, bore the player. So how did I go about this?
As a very first step, I made a basic list containing the core essential facts of the game. I started out by writing down the number of areas. From that, I would determine how many character levels players would roughly gain per area. From that, I could then determine the maximum level. This was a bit of a back-and-forth, because when I say “area” I actually mean a series of connected zones that could roughly be grouped in the same “chapter” or “tier” story-wise. So with the max level, you can set maximum experience and come up with a nice level curve. I decided to go with a very simple polynomial curve.
With that set in stone, I started developing a table, which all other tables, be it armor, utility items, weapons or enemies would then refer to. This table included, categorized by area, the minimum and maximum attributes as well as the minimum and maximum derived values, meaning health, mana, and stamina. From that, I could develop everything else. I asked myself, how long I wanted the average combat encounter to be, so I could determine the damage ranges, healing factors, defense values, etc.
From this main table, I could develop multiple other tables that would reference the decided values. For example, I developed a table containing all weapons by referring to the damage in the main table and adding various modifiers. The individual weapon damage would then also be influenced by a balance variable that could be tweaked manually. The calculations were done in a way that everything stays nicely within the decided damage ranges.
I did something similar with the armor sets, except with the defense values.
The best part about all of this is, that the final tables can be exported from the spreadsheet editor and go directly into the unreal engine in the form of a CSV file. So if I need to make a change to, let’s say, the damage ranges in a certain area, I just go back to the main table, I tweak the necessary values and all other tables automatically update their respective values. All weapons update their damage, all armors update their defense. I can then just re-import the new tables in Unreal Engine and that’s it. If a formula turns out to be problematic I update it. All respective values update automatically - I re-import the tables and that’s it. No long-winded fiddling with UE4’s table editor, no manual entering of adjusted values, no recalculations necessary - it can all be done with a few clicks. This series of tables forms a balancing pipeline so to speak, which will save a lot of time with any future adjustments.
So let’s quickly go back to that weapon table I mentioned. As I said it refers to the main table for various basic values, but, building upon these, I created a flexible damage calculation. In Monomyth this calculation depends on both fixed and situational components.
The fixed components consist of the base damage (the value referring to the main table), the weapon quality, the corresponding weapon skill, and attribute modifiers.
Each weapon has three physical damage types that are calculated according to these fixed components. The physical damage types are slashing, bludgeoning, and piercing. You probably already know these from games like Dark Souls or King’s Field. However, these types were also present in Ultima Underworld. And much like in Ultima Underworld the type of attack you perform in Monomyth determines the type of damage you deal. There is a swinging motion that deals slashing damage, an overhead strike that deals bludgeoning damage, and a stabbing motion that deals piercing damage. Depending on the weapon the damage per damage type can be very different. A regular sword can be used for an overhead strike or a piercing attack, but its highest damage is dealt in the slashing motion. The equivalent is true for maces and fencing weapons with regard to bludgeoning, respectively piercing damage. Using a mace to “stab” an opponent is not very efficient, however, clubbing him over the head with it will get you very different results.
Likewise, certain armor pieces provide different types of protection. Chainmail armor provides excellent slashing damage protection but falls flat against bludgeoning attacks.
The situational components of damage calculation depend less on the character and weapon statistics and more on how and when an attack is performed. Situational components are whether or not the player has charged his strike, whether he has enough stamina to perform the attack, and whether or not he has a bit of luck, that may lead to a critical hit.
The latter is not entirely situational because the chances for a critical hit can be increased through the dexterity attribute. Likewise, an unaware enemy will always receive a critical hit. The critical hit modifier depends on the weapon type, with fencing weapons and archery providing the highest modifier and maces the lowest. Additionally, archery gains some extra damage by aiming at the head. This is supposed to benefit stealth-based gameplay approaches. As a result, the stealth archer is a viable option in Monomyth.
Talking about sneaking around, the stealth gameplay archetype is not fully polished yet, however, equipment weight is already having an effect. I won’t torture you with inventory weight, however, equipment weight will have an effect on movement speed. If you run around in full plate armor with nine points in strength this will significantly slow you down. Equipment weight will also lower your jumping height and make you a lot noisier whenever you are trying to move silently.
The weight of weapons also affects their attack speed, as does your stamina. If you are low on stamina, your attacks will be very slow and only deal a fraction of the damage.
Now all of these limitations can be broken with a little magic. Most attributes in Monomyth are soft-capped. In this case, this means, implicitly, the maximum amount of points spent on an attribute is limited by the maximum level, however, there is no real explicit limitation in place. This means that spells and potions can easily push you beyond the implicit limitations. Likewise, all derived limitations, such as carrying capacity, are lifted as well.
If I am a battlemage and I cannot for the life of me wear a certain piece of armor without it slowing me down, a proper blessing spell can do the trick.
Besides balancing I also made a major change to melee combat mechanics. Attack animations are now traced. This means, instead of a simple hitscan the swung weapon is checked frame-by-frame for any hit enemies. This also means you can hit multiple enemies with a single attack now. Together with some newly implemented hitstop effects, this makes combat a lot more responsive.
These were most of the changes I implemented during the last month. I hope I can finalize the basic mechanical polishing soon. Most of these changes were made with the melee gameplay approach in mind. I still need to rework magic and stealth approaches and do some more general polishing. Eventually, visual polishing and the open backer beta will conclude beta phase 5.
Until then, I will keep you updated, and see you soon!
)
