Hi Dreamincode,

I'm searching for some simple but effective resources on how to write a drop rate algorithm for treasure and items that drop from creatures/enemies etc.

I just looking for something simple as im not a mathmatician but understand basic stuff. Hoping you would know of some online and free articles on the subject.

I'm thinking about having an enemy store 2 items on its possesion but there are randomly appearing monsters that spawn so how would I calculate what items it had on it when its killed and looted.

Many thanks,

Novos

The way I handled this in my Torque game "Combat Mechanix" was pretty simple. The AI class was inherited from the Player class, so it inherited all the item handling functions that the player used, so the AI had an inventory, the ability to pick up items, and the ability to drop them onto the ground from their inventory.

The dropping loot when killed was trivial, they simply dropped on the ground everything in their inventory. If they weren't carrying it, you wouldn't find it on the ground after a kill. I was going after a realistic loot system, and was planning on implementing a system where monsters would drop whatever they were spawned with (weapons, ammo, food) plus the loot they found walking around. This type of system was also implemented in Legends of Kesmai, an iso tile based RPG that people still play today. It's frustrating because the mobs can loot you when you die..so your friends have to go and kill the monsters to find your gear.

This can easily be modified to just spawn the monster with the loot and not allow them to pick anything up.

One algorithm used to decide what the mob is given at spawning is to use a set of loot tables. The area of the game you are in has a specific loot table associated with it. All loot from this area is generated by getting a random number and then selecting that index from the table. The item in that row of the table is the loot. You can only get loot that is in that table, so it prevents you from getting items like a FrostCap in a dessert area. Or have a super uber item drop in a low level area. Not only could you have the tables broken up by area, but also by loot rarity.

This setup can be augmented by adding a coomon loot table of items that can be found in any area, cash, junk items, etc..

The process can be further enhanced by randomly generating the random rolls.
For instance.. one mob from that area might receive one roll from the common loot table and one roll from the rare loot table. Now IF every mob received the same two rolls from the common and the rare tables, the rare tables wouldn't be so rare after a while. So instead, you might have something like.. monster level divided by 3 = total rolls..

so a level 21 monster would get 7 rolls. The random rolls generate seven numbers of 1-100 ... lets say we end up with 12, 25,29,41,48, 77,81 You have set up your tables so that 50% of the time you get a common loot item, so the monster ends up with a roll from the common table for 12, 25, 29, 41, and 48.
on rolls of 50-75 you get a semi-rare loot drop so you would not get any rolls from the semi rare table.
and rolls 76-90 the rare items are dropped, so two rolls from that table would be added to the monster's inventory.
The elite items table 90-100 were not rolled.

Anyway.. just ideas to help organize what loot is given to a monster using it's location and level to determine the loot amount and rarity.

Some games also use Boss specific loot. Items that drop only from that specific monster.

This is just one of many possible implementations. Think of your own.. and tweak it to make it work how you want.. that's the fun of making games.

Aet

Having thought about what you advised, I managed to come up with a simple solution that requires no floats or any tricky calculations.

Basically I have created 3 loot tables being a common, rare and epic loot table.
I then just pick a random one from the table based on a call to the rand function.

Thanks!

great job, Im a big fan of get it working first, then work at making it better later.

You can always come back to this if you find it was implemented too simple the first time.

Good Luck,
Aet