Dev Blog #1: Design Philosophy and Data Driven Approaches

Introduction:

Hello everyone, Kincade here -- head developer of RhizomeMUD and coincidentally the author of this development blog!

This forum will serve as a living document of the thought processes we use when designing our game systems, interesting observations we make during the design, and the intentions behind what we're trying to pull off. Hopefully this will provide some good insight into what goals our systems are angling towards, and help inform discussion around feedback if the community feels we're off target on what we want to intend -- or if what we're going for is in the wrong direction to start.

A bit of background on myself to start -- RhizomeMUD has been in development since February of 2019, and started out as a casual experiment from two RPI players. It's evolved into sort of a love letter to the genre, so I'm excited to start sharing with you all. Like many hobbyists, I'm not a game developer by training, or even a SWE. Rather, I'm a hardcore data-science guy with a strong background in systems biology, evolutionary biology and population genetics. There's a lot of coding and methods development in those fields, but definitely no game design, and I've found that kind of background has strongly influenced our approach to developing Rhizome. We're data forward here.

A data-forward approach to game design:

So what does that mean, exactly?

In data science, it's common to run massive simulation studies on synthetic data before you ever start actually analyzing the data you're truly interested in. This lets you appraise whether the algorithms and approaches you're relying on behave the way you expect, giving you a baseline of what to expect in controlled circumstances. This also provides an opportunity to adjust course before committing to analysis. In the case of Rhizome, this means we run large simulations on proposed design elements before committing to them, allowing us to get a sense of how things will function before designing large amounts of coded infrastructure that we might have to dump when we later find our first principles aren't sound.

Here's an example of what I mean:

This is a simulation we ran in order to fine-tune the NPC wildlife spawning systems currently active in Rhizome. We had four competing ideas at the rate at which NPCs should repopulate, including several that scaled with the density of NPCs in that area already -- wipe out a zone, and it takes a long time to come back, but if the population was near carrying capacity, few new entries would spawn as well. In order to decide between the various implementations of these algorithms, we simulated how ecosystems would act under each potential choice. These simulations helped us identify important trends, like that the linear-scaling deficit model wasn't able to sustain hunting pressure from PCs nearly as believably as a logistic curve approach.

Practical Consequences:

One practical consequence of this is we let the data shape the form our algorithms take, so our calculations can be relatively granular and complicated in a way that a lot of more familiar RPG systems cannot. Let's compare and contrast what going into a basic sword swing in a dice system like Dungeons and Dragons versus a system like Rhizome. Dungeons and Dragons has a lot of additional affects (advantage, so forth), as does Rhizome (weather, hunger and thirst penalties, so forth), so we'll take the simplest case for both.

D&D: attacker d20 + attacker-to-hit - defender ac

The strength of a dice system is it's very easy to calculate using... well... physical dice. A dungeon master and his players can rapidly calculate hit and being hit, allowing the game to proceed smoothly without complex math. Here's Rhizome's most basic attack formula, derived from a simulation that produced the curve we liked the most:

Rhizome: 2*(attacker offensive skill - defender defensive skill) + attacker d100 - defender d100

This isn't exactly differential calculus, but it is more complicated than dice plus integers. Now both attacker and defender are rolling, there's contribution from baseline skills from both sides, with a greater emphasis on skill over random dice roll (67% weight from skill, 33% weight from rand).

This complexity isn't really desireable for a tabletop RPG. The beauty of game engines is they can handle this math -- and in fact much more complicated maths as we'll discuss in future blogposts -- much more smoothly, with no obvious difference, allowing us to escape from dice based rolls. A lot of early MUDs, and even some modern ones, gravitated to dice-rolling because it is familiar, but dice based approaches have serious implications for player experience.

Let's check the actual curves of these approaches:

The difference is pretty immediate, and it's not just because we're using a d100 -- you'd see 100 little steps in Rhizome if that was all that was different. The skill component is what provides a spline effect and makes the distribution so much smoother. Instead of jerking up hit probabilities 5% of the time as with a d20, increasing your skill against an opponent has a smooth, sliding effect. This specific shaped curve is widely used in game design and is called a 'smoothstep', which we settled on, and tuned to the shape we wanted based on our skill weights and dice sizes.

This has pretty strong effects on player experience: if you're close to your opponent in skill, each point of skill you gain or lose on them make a lot of difference. If they're already outclassing you by a lot, losing ground on them in skill doesn't make a huge difference; missing someone every time by six inches has the same practical result of missing them by eight. Similarly, if you already outclass them by a ton, each point of skill you gain over them gives diminishing returns. You find it harder to hit them better than the really good job you were already doing.

Natural 20s always hit in D&D, setting a 5% floor; the proportion that the proficiency of the character is playing at +10 is exactly 50% as you would expect. At exactly half as much proficiency (+5), the proportion coming from skill is exactly half of that: 25%. It's a perfectly linear relationship. In Rhizome, 50 offense against 50 defense is 50.5% chance to hit, the half percent coming from ties going to attacker. At 25 offense, exactly half of the midpoint, it's down to 12.75. This really emphasizes character skill and makes winning and losing fights (or even missing individual blows) feel earned, without making a skilled opponent ever truly untouchable by someone weaker than them.

Conclusion:

This was a brief dive into some of the approaches we use -- simulations and data driven parameter tuning -- in order to achieve the look we want in game. While we touched on spawning and combat, this post was not the ecosystem or combat dev-blog post... those are coming soon! Rather, I hope this provided some insight into the order of operations of how we make decisions when it comes to the underlying game engine in Rhizome, and shows a reasonably straightforward example of how visualizing simulated data can reveal interesting consequences in choosing one route (e.g., dice) over another, and helps inform which path we walk down as we have and continue to develop this world!

Thanks for reading!