Adding a little loot randomness with the Random Distribution System (RDS) Library

Today's project from Mike Barthold is one that will be of interest to those thinking about writing a game. His two articles go into some good depth on providing random loot, monsters and maps... I mean who doesn't like loot!

This is something that ran through my head for a long time, until I finally sat down and started thinking logical about it. While I thought through the requirements such a system has to fulfill, it became clear, that almost everything that happens in those games, from the items a vendor offers for sale, to the loot a monster drops when it dies, and even the spawn of monsters (is it a rare mob or a normal monster, any kind of elite creature, whatever) can be put under the same hood: it is a kind of random generated ... thing. Even random generated maps are nothing else than a "drop of map segments".

Almost every game has things that happen "sometimes". If you are happy with code like "if (new Random().Next(1,10) < 5) ..." then you should probably stop reading - But if you want more than that, if you want to be able to just "design" probabilities for things to happen, if you do not want if...else if...else if... constructs running through random values, then this one here will be a pearl for you. I am quite confident. Go ahead. Read on!

I will show you my all-in-one solution to the "loot-problem", a class library called "RDS" (Random Distribution System) that creates recursive loot-tables, probabilities, result sets and has a set of properties that allows you to control its behavior. To my own surprise, the library was way smaller than I initially thought it would be when finished. The classes are slim, fast and easy to understand; somehow the RDS seems to be more than the sum of its parts. With only a few lines of code you will be able to create fantastic randomized content!

No fancy graphics, no designers, just the core code creating loot for you. It's totally up to you and your imagination, what those classes can do for you and which designers you might want to write to create those tables (SQL based, File based, whatever). Would be great if you'd share some of your ideas with those classes here, too.

...

...

Summary

We created a RDS that allows us to do these things:

Drop any number of... things with given probabilities in a recursive structure

Drop nothing

React on events (or overrides) when certain things happen

Simulate loot behavior of big players in the game industry

Add values or references, re-create instances of living objects

The option to replace the default.net Randomizer with something more sophisticated

Basically you can delegate every random decision and chance in your game to RDS

All we need to have fun while making and playing our games is there. The only thing you have not seen so far is, how that all comes to live. Fortunately there is a Part II, which will exactly do that!

So you have gone all the long path of dry theory through Part I and want to see, how it runs? Welcome to Part II of the RDS article!

I will show you now the "how-to's" with a group of small demos (you find all the demo code in the downloadable source code) - it's a simple Console Application as I promised in Part I "no fancy graphics, no designers, just code" that will output the results of RDS.

...

Demo 4 - Creating (spawning) a group of Monsters, maybe even with a rare mob?

Ok, we need a group of Goblins. Urgent! Shamans, Warriors and, with luck, the almighty BOB! The Goblin the world fears since it heard of him the first time! . Let's find out how we can create a random set up group of Monsters. This demo shows the usage of the RDSCreatableObject class.

The preparation for this demo includes creating a "Goblin" base class (which is basically just the same as the "MyItem" class from the other Demos) , from which we derive the Warrior and the Shaman. The allmighty BOB, our rare mob will be of course a Warrior, so we derive BOB : Warrior. We then set up a RDSTable that will contain 5 Shamans, 5 Warriors... and BOB.

Why 5 of each class? As I want to show in the demo one possible way to have monsters spawn with different levels. For the Demo we set a variable "AreaLevel = 10" as the level of the Area where we want to spawn our group of monsters. We then add 1 Shaman with AreaLevel-2, 1 with AreaLevel-1, one at par with AreaLevel, and one with +1 and +2. Same for the Warriors. The +2/-2 mobs have a lower probability to spawn, and the even level mobs have the highest probability.

And last but not least, we add BOB with a significantly lower probability to spawn. BOB is rdsUnique of course... there can be only one BOB.

Play around with this demo, run it over and over again, until you finally hit BOB. See how the group of monsters looks like in their distribution of levels and types (Shaman, Warrior) and you will see, that this spawns totally random groups of 10 shamans each.

Maybe you want to enhance this demo to make the count of Goblins spawned random, too. Try to add a NullValue or set up another table of RDSValue<T> objects (or just roll a dice) to determine the rdsCount for the table.

...

Demo 6 - Random generating a simple map.

Short demo of selecting 25 map pieces randomly to create a 5x5 map. You can create any map size with this system, of course.

The setup here is to demonstrate a new technique: Dynamically enabling and disabling entries of one single table in the PreResult override, based on the exits a map segment has.

We create a class named MiniDungeon : RDSTable. This table contains lots of MapSegment objects, that derive from RDSObject. Each Segment has four exits: North, East, South and West. Those boolean flags represent the possible exits of a Segment and are used to modify the states of the contents of the MiniDungeon.

MapSegment gets a constructor that takes four boolean parameters, each one describing one of the possible exits. We want to loot only Segments, that can fulfill the needs of the map (i.e. have the desired exits).

In the PreResult override, each MapSegment disables/enables itself based on the requested exits, so that only those Segments stay active that can fulfill the desired exits.

The algorythm of the Map is clearly not the most high sophisticated you have ever seen, but thats not the point of the demo. A demo output of a 5x5 map could look like this, in simple semigraphic console output:

...

I hope you have now a good idea of what RDS can do for you. I think it is a library with very high value that takes away lots of decision work from you if you agree to really implement (inherit) the RDS classes. It all works together fine and you have almost every thinkable freedom with lots of virtual methods to override.

So you want to see it in action? Here's another demo of his RDS library;

OK, this was another short example of what you can do with RDS and there may be a time when you do some card (or: "stack-of-things") simulation and then maybe you will remember this one here and pick up some ideas.

Have fun with it!

As Mike says, it might not be perfect, but it sure beats starting for scratch, doesn't it?

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.