I'm currently trying to find an easy way to do combat in an RPG.

My current idea is like this:
You have attributes, like strength, decterity, iq, etc. An average attribute would be 25, with something like 50 really good, 75 legendary and everything higher than 90 would be god like.

Every action (attacks, spells, etc) are skills.
Skills have an upper limit of 20 and are based on an attribute.

Club fighting could be a strength based skill.
Defense is either strength based or dexterity based, depending whether he has a shield or not.
Armor gives you a bonus.

Say, Gargle the Dwarf fights againts StoneStick the Troll.

Gargle uses his club:
Club: 5/20 (25%), Str 45 -> Total 45 * 0.25 = 8.5

StoneStick has no defense weapon, so he has to dodge:
Dodge: 2/20 (1%), Dex 18, Armor (stone skin): 10 -> Total 28 * 0.01 = 2.8

Both roll a d100 now.

Gargle rolls a 20
StoneStick rolls a 55.

We multiply the rolled number by the factor:
Gargle: 8.5 * 20 = 170
StoneStick: 2.8 * 55 = 154

So Gargle hits. The damage inflicted is based on the weapon, his club does 4-10 points of damage.

Ok, comments on that system? How are you guys handling combat normally? (Mandrake?)

I'm just not sure if the idea of making the attacks dice based is a good one. I mean, with some bad luck the player could miss all the time..
which would be really frustrating.

Maybe rolling a d10 or d20 might be better? Help?

Hm... is this close to D&D? I only know the 3rd edition, and I think my system is different.

In fact, I'm even considering to allow instant-hits (as long as you don't goof up)...

But then I'm not sure how armor would be used, and how to determine the damage... hints? help?

First question right off the bat: is this a real-time fighting system (where deciding whether you hit/miss is based on whether your sword model/sprite contacts the enemy) or a non-real-time system (where deciding whether your hit/miss is based on a random number)?

If it is the first, then you task is a bit easier: you only have to worry about damage stats (unless you want to get into weapon/recovery speed, where a 2-handed sword is swung slower than a 1-handed sword. If you touch that, then you need to do some damage-over-time balancing, but I digress...).

But, in either case, you do need to do some long-range planning now. First, decide what you maximum level is going to be. In videogames, players expect to level-up fairly often, so having a large level range is a good idea. This means, btw, that the difference between two consecutive levels is not that great.

I would suggest that you have 50 levels or more. Now, there's two ways of going about raising levels.

One way is the common D&D method. Your character is a level-N character. Level N for that character's class(es) provides the following bonuses/detriments in combat. In this case, the player's basic stats don't increase in level, but the player does do more damage with their weapon of choice or gain new abilities.

The other way is that each stat has a particular level. When the player gains XP, he can use those points to buy a level of experience for a particular stat. That way, if you've got a swordsman, you will want to spend time leveling up stats that help his sword skill, not things that make him a better wizard.

The D&D method has several advantages:

1) Easy to balance. Because there is just one number that changes (though potions or the like may change a particular stat, stat changes are rare), it is easy to alter the system. Since the user has little control over it, the user can't find that perfect combination that makes a Level 5 character as powerful as a Level 8 character. You are in full control.

2) Less micromanagement. The user doesn't really have to do anything more than kill stuff. The game will automatically improve their character when he level's up.

But, on the other hand, the second method has its advantages too:

1) Good for a non-class-based (or flexible-class) system. If I want a system where a character doesn't have a particular "class", then I would want to use something like this so that the user can customize the benifits of gaining experience for his character.

2) More micromanagement. Some people like micromanagement (I, personally, prefer just dealing with armor, weapons, and baubles without having to also balance stats). I would suggest, however, that, if you go this route, keep the party small. The total party, not just the number you can bring to a battle simultaneously.

Once you have made those important decisions, you now have one more to make: just how much is a lot of damage, anyway?

The Tarasque, one of the most feared creatures in all of D&D, has less than 200 Hp. A level 10 fighter with 80 Hp is either a fluke of lucky rolling or gets a large constitution bonus (which, ultimately, is the same thing).

On the other hand, in the average Final Fantasy game, 80 Hp is nothing past the middle of the game. The common monster at that point is lobbing 300-400 Hp blows, with powerful boss attacks reacing 1500 or more. The last boss will, likely, have tens, if not hundreds, of thousands of Hp.

One of the reasons for this is obvious: FF is a videogame, while D&D is a board game. In a videogame, you have a large level spread. You, also, have a lot of ground to cover with monsters that are steadily increasing in difficulty. The easiest way to make monsters tougher is to give them more Hp. Of course, this means that your party needs to do more damage per level now.

The way that D&D gets away with relatively low Hp is that they use other means to balance tougher enemies. AC, giving the enemy multiple attacks, making the enemy do more damage to you.

Here's the math of the entire problem. There is a ratio of the following things:

Hp taken by the party
Hp done to a group of monsters

1. of Hp that the party has (modified for cure spells/items)

2. of Hp that the enemies have (modified for cure spells/items)

Now, to complicate matters, the damage is not a simple question of, "how much damage does an enemy take from an attack?", but the average damage over time (DOT). If a sword does 10 damage every second, and another sword does 5 damage every .25 seconds, the 5 damage sword has a greater DOT, and ultimately, greater damage output.

Therefore, to lower the DOT done by a particular attack, you can make it do less damage outright, or make it hit fewer times. If the 10 damage sword from above hit 90% of the time, and the 5 damage one hit only 10%, then the 10 damage sword would have a greater DOT.

D&D tends to balance enemies by giving them a few more Hp, better armor, and more powerful attacks (that hit more often). A party, to defeat these enemies, will need to have a bit more Hp (a level or 2 worth of Hit Dice), more DOT (better THAC0), and better armor (lower's enemy's DOT).

You have to find level equations and so forth that keep this ratio in balance for the entire game. If it goes too far out of balance, then either the game is too easy or too hard.

Also, consider at this point whether or not you want it to be class-based or classless. If it is "classless", how classless is it? 3rd edition D&D has some pretty simple rules for multiclassing, which makes for some customizability in your character.

Now that we have thought through all of that, we come to the really hard work: designing the actual system.

If you're using a single level-based system (like both D&D and FF), you need to determine your min/max levels and min/max stats. Then, you need to decide on an equation that converts these stats, plus the stats of the weapon in question, into damage. It should, also, take into account the armor rating of the character being hit.

Note that D&D does not use armor to lessen the blow of attacks. Armor is only used to deflect attacks. The idea is that the armor either prevented the attack or the full attack pierced it. FF, by contrast, factors the armor into the overall damage done by an attack and, typically, uses just a Dexterity-like stat to avoid the damage. Using this method, it is possible to get a hit that ultimately does no damage.

Your equation may, like FF's, want to take into account elemental affinities of the attacking weapon and the defending creature.

The D&D equation (for a basic fighter) is simple: weapon damage + strength bonus/penalty (if any). FF's equations are, typically, much more complex. Typically, you will want some kind of random jitter to the output of the equation.

If you are going to have to-hit rolls (non-realtime systems), then you have to have an additional equation.

BTW, you should create stats as you need them; don't create them beforehand. If you don't have a dodge-roll, then you shouldn't have Dex/Agility unless they factor into something else (like ranged attacks).

Here's an example (off the top of my head) of both to-hit and damage from a table-top RPG I abandoned. This, btw, is a stat level-based system, so there is no character level:

Character stats:
Strength
Agility
Natural Defense
etc... (don't remember the rest, but they don't matter for melee).

To-Hit roll:
Strength Level + Weapon Attack Level vs. Agility Level + Armor Dodge Bonus

The characters both roll (D100) on the resulting levels. The results are computed by looking up that level's entry on a chart and seeing what color it is (there were 6 possible colors). Higher levels had higher probabilities for rolling the higher colors. If the attacker's color is greater than or equal to the defender's color, then the attack hits.

Damage:
(Strength Level + Weapon Attack Level) - (Natural Defense Level + Armor Defense Level)

The resulting of this is looked up in a different table. This table turns a level into a Hp damage amount. The defender suffers this much Hp in damage.

In this system, the color chart and the damage chart are the balancing factors (along with the power of weapons and the species-based caps on Strength Level).

I could have, easily enough, added a "finess" stat that was used in place of Strength, so that high strength (and therefore, higher to-hit changes) didn't mean high damage. But, then again, given the color chart method of determining hits, I found that attackers didn't miss much unless the levels between them were very large.

Once, I designed a combat system on the presumption that all attacks hit unless the defender avoids them. This makes some reasonable amount of sense. So, the attacker didn't even roll on the to-hit; only the defender did. Granted, this roll took into account the appropriate stats on the attacker, but it required only one roll. Think D&D's THAC0, only the defender does the rolling.

The idea is that the d100 roll is modified by the attack or defence rating. Ín the above example, the Dwarf is 4.7 times more likely to win the contest than the Troll... but you still have some element of luck.

Yes, a dice pool system would be an option.
Main problem here is to come up with a system that is not too close to any of those you mention. Oh, "Vampires of the old world" is using a pool system as well.

Hm..

Anything worth doing is worth doing well, and nothing is ever easy.

Valkyrie Profile's battle system was pretty great. It was both turn-based and real-time - you could toggle characters to attack at any time (if it was your turn), creating some massive havoc if all of your 4 characters were attacking at once (and one hit added to the combo counter, which allowed super attacks when full).

Also if the enemy ended up flying because of someone's attack, and then one of your characters came with a "land" attack, he/she couldn't hit the enemy.

Timing and knowing your characters' attacks was everything.

Quoting Working Designs : "For all the ways that I loved Valkyrie Profile is was the combat that was the real tour-de-force. Battles begin as frenetic swirls of sprites and sounds and button mashing that eventually sort themselves into a rhythmic sort of combat-song. The bangs and crashes and swipes and smashes frame the screamed lyrics of the Einherjar - lines like "My life is strewn with corpses" and "This is the law of heaven." It's almost physical and at the same time sublime, especially the moment you realize that the chaos on the screen is perfectly under your control."

The whole game reeks of mad leetness. Needless to say, I <3 VP.

Star Ocean 1 & 2 had a similar system in a more real-time form.

In Pokémon, each attack have your own success rate:

I.e. a tackle, thunderbolt and surf attacks is 100% hit chance, but other like thunder, blizzard, fire blast, fissure and others are less than 100%.

But remember you can alter this rate using some attacks like flash and sand attack (decreasing attack rate)

So, to calc if the pokemon1 hit the other, do like this:

int hit(PKMN_ATTACK attack)
{
   int n;
   // 0 to 100
   n = rand() % 101;
   if(attack.hit_chance <= n)
      return 1;
   else
      return 0;
}

^__^

I don't think that's going to give the proper behavior. If RAND_MAX (implementation dependent) is not divisible by 100, then your results will be skewed. Don't take this probability skewing lightly; it will ultimately effect how things work out.

Back to the actual question.

OK, so you're looking for to-hit rolls. Step one is to think about what you want.

There are 2 sides to the equation: the attacker and the defender. The attacker has some computation that determine's his attack to-hit (ATH). The defender has a computation that determine's his defender evade (DE).

Now, we need to decide what these numbers mean. Since they are fairly abstract at this point, we only have the relationships between them.

Let's take a simple, and very important, relationship:

ATH == DE.

In this case, what should happen? Does this mean that the attacker should win the majority of the time, the defender should win the majority of the time, or that it should be a coin toss?

I would suggest that it should be a coin toss. Literally 50-50 percentage if they are equal.

Now, another relationship:

ATH >= 2 * DE

The attacker has, at least, twice the value of the defender. I would suggest, depending on what you want, that this means the attacker should will a proponderance of the time. Possibley 75-80% of the hits.

Next:

ATH >= 4 * DE

I would suggest that, in this case, the attacker automatically hits (roll anyway for critical fumbles/hits if you want them).

The probability relationship seems relatively simple. The probability is based on the following number:

ATH / DE = ProbValue;

The easiest way to implement this in code is to use a bunch of if-then statements on the value of ProbValue, and interpolate the probability between two ProbValue numbers. Take the following:

iToHitNumber is then tested against a D100 roll. if(iToHitNumber < roll), then you hit. Otherwise, you miss.

BTW, note that, if you're paying attention and thinking about code, you can see classes and object naturally develop from the above. You can see you'll need a class that can generate ATH and DE for a given type of attack. You will, also, need a mediator class that will take ATH and DE, do the required probability roll, and get the results.

The good thing about this method is that it is open-ended. ATH and DE are both floats and are computed in a completely unimportant way. There are no limits placed on ATH or DE; they could be between 0 and 10, or they could be any arbiturary number. This way, all you need to think about in terms of balancing this method is what factors into ATH and choosing good monster DE's so that you get the results you're looking for. If you want lots of hitting on both sides, each side's ATH should be at least 3x the expected DE of the other side. If you like lots of misses (you should make up for this by making monsters die in a very few hits), keep ATH close to DE, or let DE slip a little higher.

Guess I'm using something like this:

resultATK = rollDice() - attacker.attack;
if resultATK >= 0 {
     resultDEF = rollDice() - defender.defense;
     if (resultDEF < 0 || resultATK < resultDEF) {
          /* attack succesful */
     } else {
          /* defense succesful */
     }
}

This seems to be the most simple solution
And I want to have something very simple...

Because that means that the attacker spoiled his attack role. He managed to roll a number larger than his skill... so it's a failure. No need for the defender to defend... the attacker will miss the target by a mile.

Displaying "Miss" or something would do the job

Agreed. This was more meant to be pseudo code. But you won't use ATK and DEF for magic

Damage will be based on the "quality" of the result (so how much larger resultATK is than resultDEF) and a weapon modifier.

I'm always open for new idea
My bookshelf is full of RPG systems (gurps, d&d, palladium, shadowrun, ars magica, rolemaster, vampires of the old world, and some lesser known ones) and source books.

If you have good ideas, let's discuss them
I might have found the system I'm going to use for that project, butu it doesn't mean we can discuss other systems...

almost, but not quite:

/* removed unnecessary variables, casted rand() and RAND_MAX to float(result would always be 0 otherwise), which, after being multiplied by 100(max), recasts to an int */
int d_100(void)
{
return ((float)rand() / (float)RAND_MAX) * 100.0;
}

Chris: Yes, some optimizations will be good in my little function, I know

spellcaster: But... this is the same thing I've done before... the probability is different for each result, like korval wrote...

Yes, great idea too!

^__^

Well, unless your RAND_MAX is 0x7FFF (32767), of course. VC++'s RAND_MAX is.

BTW, you're cheating. By your equation, the percent can't be anything but 1%. Observe:

Before the divide by 100, "ave" will guarenteeably equal MAX_TEST. Just look at the code: for each MAX_TEST number of times, some entry in count[] is being incremented. Add all of these up, and you get MAX_TEST. Therefore, the percentage is computed as follows:

((MAX_TEST / 100) * 100) / MAX_TEST. This is precisely 1.0f, regardless of which element we choose to increment in count[].

The correct analysis would be to take the count[] variable and do some statistical analysis techniques on them. I don't remember most of my statistical analysis from chemistry, but there are ways to determine how far off your probabilities are from the true amount.

Besides, you haven't even attempted to answer my logical argument above. Just because you can write code that looks like it isn't broken doesn't mean that it isn't. Trust me; just do it the right way.