How does the math work that drives an RPG?

January 17, 2008 10:28 AM

I'm trying to program a role playing game, but I'm not sure how to do the math.

I'm working on a game where one progresses as a character (individual traits, such as intelligence, dexterity, etc.) and will have encounters with other characters that require battles that pit traits against each other. Your typical RPG.

However, I'm not sure how to work all this out. I'm not entirely sure of the theory behind it, such that it takes into account character progression, interesting encounters, game balancing, etc., while maximizing the fun value.

Anyone have any advice about how to think about the internal algorithms that drive an RPG game? I'd love to have some resources to do the research on this, but I haven't been able to find much online, or in print. Plenty of talk about RPG's, but nothing that discusses this particular point in detail.

As an added note, I'm not an uber programmer, so looking at other peoples' code for games like nethack, etc., are sometimes helpful, but often more complex than I can work with. I'm looking more for the theory that doesn't require a math major to interpret. Examples of basic equations and how variables are used would be most helpful. Resources to read up on would be great as well.

posted by SpacemanStix to computers & internet (15 comments total)

There’s a list of notable RPG game systems at the bottom of this Wikipedia article:
http://en.wikipedia.org/wiki/Role-playing_game_system
posted by breaks the guidelines? at 10:32 AM on January 17, 2008

I remember reading a couple interesting forum topics on this subject over at gamedev.net. It's been awhile, but I might be able to dig it up...it covered various topics such as character balance, in game economy, and reward vs. xp level. The gamedev community is great for getting forumulas from though if you bounce the question to them.
posted by samsara at 10:40 AM on January 17, 2008 [1 favorite]

Second the game systems link above, you'll want to look at an established system like d20 or GURPS to base your's on. These systems are used mainly for RPGs where players use dice and pencil/paper to run the game, so the mechanics of the game need to be specified and released to the players, unlike computer RPGs. A nice side effect of this is that your code will probably be fairly simple, because almost all gameplay actions involve rolling dice and computing a simple result.
posted by burnmp3s at 10:41 AM on January 17, 2008

You might also take a look at the roguelike Dungeon Crawl, which is intended to be very extensible and customizable via a scripting system using the Lua language.
posted by breaks the guidelines? at 10:41 AM on January 17, 2008

The feature archives at Gamasutra would be a good place to look.
posted by Riemann at 10:50 AM on January 17, 2008

I'd try modeling your system as P&P in GURPS first. GURPS is pretty much like Rails/.NET/Beans for RPG's, in that it takes care of most of the "core" functionality that is the same across most systems. From there, you'll have a good idea of what can be implemented as a simple "rule" within the framework, and what aspects of your world will require an entirely specialized bit of functionality.
posted by mkultra at 11:04 AM on January 17, 2008

This isn't a matter of math so much as your philosophical approach. It's been a long time since I played RPGs (and those were all paper-based), but as I recall, the common theme behind this kind of thing was that the higher up you get, the harder it is to advance. Runequest had a fairly straightforward approach. IIRC, skills (not attributes) were all rated in a 20-point scale. In order to level up a skill, you had to use that skill successfully a number of times equal to your current skill level on a mission, and then roll above your skill on a d20 after the mission to actually raise it.

Another approach would be to say that a given task is worth N points applied to a certain skill/s, and that to level up the skill requires a geometrically increasing number of points (ie going 1-2 takes 10 points, 2-3 requires 20, 3-4 requires 40, etc).

Representing either of these mathematically is trivial; the latter would would require more scenario-writing overhead because you'd have to say "OK, picking this lock is worth 20 lock-pick points; killing this monster is worth 50 hand-to-hand combat points." Etc. In either case, you'd, say, construct an array of character skills with skill name in column 1, current level in column 2, and points towards leveling-up in column 3. At the end of a mission (or whenever) you'd run through each row and calculate, say,

repeat with k = 1 to [number of rows in skillsarray]
  if skillsarray[3,k] = skillsarray[2,k]^2 * 10
  then skillsarray[2,k] =  skillsarray[2,k] + 1
end repeat

posted by adamrice at 11:09 AM on January 17, 2008

Definitely take a look at rule books from Dungeons and Dragons or other traditional pen and paper RPGs. They're written for the average person to be able to do all the math for an encounter based on stats themselves, in real-time, on paper.

Also consider playing a simpler RPG like Paper Mario, or PM: Thousand Year door. I found their approach of combat doing damage like "5" a lot easier to grasp the functions behind than a typical Final Fantasy game, where I'm left wondering "Now why did that attack do 1367 damage the first time and 1284 damage the second time?"
posted by Durhey at 12:25 PM on January 17, 2008

Why not use the D20 OGL?
posted by WinnipegDragon at 1:07 PM on January 17, 2008

Are you talking about basic stuff like to-hit, or damage rolls, or game balance stuff like making sure characters don't become obscenely powerful by level 5?

How complex an RPG are you looking to make? Something simple like the old door game, Legend of the Red Dragon? A roguelike? A Tactical RPG like FInal Fantasy Tactics or Ogre Battle? Japanese RPG like Chrono Trigger or Final Fantasy?

One thing to do would be to write just the combat system first. Write something that gives each caracter a turn to whack at the other character, give a percent to hit, hit points, and an amount of damage, then just start playing with numbers from there. I think a lot of balancng gameplay and figuring out what works comes from playtesting. It works for Valve, it should work for you.
posted by fnerg at 2:31 PM on January 17, 2008

fnerg, I'm thinking pretty simply right now, along the lines of figuring out how the mechanics of something like a roguelike works. I am interested in game balancing, such that it's appropriately challenging throughout the game experience. I'm not quite sure how to make that work. I suppose a lot of it is simply testing it once the combat system is in place, and making adjustments when needed.

Initially developing the combat system is my primary question, though. Say I start with certain stats, how do I plug these into an equation such that it creates a meaningful (and fun) combat encounter? I think the links here for the RPG game system explanations will be a good resource, as well as the rule sets for pen and paper based RPGs.

Thanks everyone for your suggestions, there are some really good things to follow up on here.
posted by SpacemanStix at 3:21 PM on January 17, 2008

When it comes to balancing I agree with a previous poster that it all comes down to what philosophy you implement. For example, you could work on balancing each character individually so they could have even chances against one another...or you could implement a "rock-paper-scissors" approach where the magician always wins against the warrior, the rogue always wins against the magician, and the warrior always wins against the rogue.

You can accomplish a lot of this by using weights on various things (as much as you'd like to really but i'd avoid making it too complicated). Things like....damage types, armor types, range vs. melee, etc. Each of those variables can have their advantages or penalties when they interact with other variables. For example, ranged weapons hit heavy armor wearers easier without being evaded, but do less damage than if it was light armor.

In D&D a lot of this is done with the random seed weighting from dice rolling. Roll for damage, opponent rolls a save throw, etc.

I really think if you start just making a lot of it up on the fly, it will be a fun practice testing it out against your core philosophy on how it should be. Once the mechanics start to fit the mold of what you envisioned, the project should be near complete save a few more tweaks.
posted by samsara at 3:35 PM on January 17, 2008

This is part of what I do for a living. I had to learn everything from scratch -- there really aren't any good resources online (someone mentioned Gamasutra, for example; I'm pretty sure there's nothing there). It's a black art.

Thus, I would advise using D&D or GURPS as previously suggested.
posted by liet at 6:20 PM on January 17, 2008

The real secret of RPGs, in my experience playing them, is that you work out how the battling works at Level 1, then as you level, you just multiply all the numbers up and up by the same constant (factoring in equipment upgrades.) The real change (and the part that keeps the game interesting) is you introduce some new mechanics for the players and enemies to use. Then, you make sure you rig the experience breaks/enemy spawns so a 'typical' player will hit levels that match the enemies as he encounters them.

Now, the magical part, is that your game is 'self balancing' in the sense that if some area proves too hard for a player, the player can grind up a level or two and come back and beat that area. So, in short, you make the game work at one level and you've done a lot of the work.

Games like Oblivion try to level the enemies with the player (presumably so the player can do the dungeons in any order,) but I don't like this, since, IMHO, it defeats the greatest benefit of the RPG, the self balancing.
posted by blenderfish at 10:56 PM on January 17, 2008

I remember when I was practically addicted to Diablo that the Jarulf's Guide to Diablo had some insanely detailed information (formulas and such) about character progression, weapon damage, and tons of other stuff.

Perhaps you could use some of the stuff from the guide for reference.
posted by ogami at 5:58 AM on January 18, 2008