Generic rule parser for RPG board game rules - how to do it?

Question

I want to build a generic rule parser for pen and paper style RPG systems. A rule can involve usually 1 to N entities 1 to N roles of a dice and calculating values based on multiple attributes of an entity.

For example:

Player has STR 18, his currently equipped weapon gives him a bonus of +1 STR but a malus of DEX -1. He attacks a monster entity and the game logic now is required to run a set of rules or actions:

Player rolls the dice, if he gets for example 8 or more (base attack value he needs to pass is one of his base attributes!) his attack is successfull. The monster then rolls the dice to calculate if the attack goes through it's armor. If yes the damage is taken if not the attack was blocked.

Besides simple math rules, can also have constraints like applying only to a certain class of user (warrior vs wizard for example) or any other attribute. So this is not just limited to mathematical operations.

If you're familiar with RPG systems like Dungeon and Dragons you'll know what I'm up to.

My issue is now that I have no clue how to exactly build this the best possible way. I want people to be able to set up any kind of rule and later simply do an action like selecting a player and a monster and run an action (set of rules like an attack).

I'm asking less for help with the database side of things but more about how to come up with a structure and a parser for it to keep my rules flexible. The language of choice for this is php by the way.

Edit I:

Let me refine my goal: I want to create a user friendly interface (that does not require somebody to learn a programming language) to build more or less complex game rules. The simple reason: Personal use to not need to remember all the rules all the time, we simply do not play that often and it's a stopper to look them up each time. Also: Looks like a fun task to do and learn something. :)

What I've tried so far: Just thinking about a concept instead of wasting time building a wrong architecture. So far I have the idea to allow a user to create as many attributes as they want and then assign as many attributes as they want to any kind of entity. An entity can be a player, a monster, an item, anything. Now when calculating something the data is made available to the rule parser so that the rule parser should be able to do things like if Player.base_attack + dice(1x6) > Monster.armor_check then Monster.health - 1; The question here is about how to create that parser.

Edit II:

Here is an example of pretty basic value but to calculate it properly there are lots of different things and variables to take into account:

Base Attack Bonus (Term) Your base attack bonus (commonly referred to as BAB by the d20 community) is an attack roll bonus derived from character class and level. Base attack bonuses increase at different rates for different character classes. A character gains a second attack per round when his base attack bonus reaches +6, a third with a base attack bonus of +11 or higher, and a fourth with a base attack bonus of +16 or higher. Base attack bonuses gained from different classes, such as for a multiclass character, stack. A character’s base attack bonus does not grant any more attacks after reaching +16, cannot be less than +0, and does not increase due to class levels after character level reaches 20th. A minimum base attack bonus is required for certain feats.

You can read it here http://www.dandwiki.com/wiki/Base_Attack_Bonus_(Term) including the links to classes and feats which have again their own rules to calculate the values that are required for the base attack.

I began to think that keeping it as generic as possible will also make it pretty hard to get a good rule parser done.

Answer 1

What you’re asking for is essentially a domain-specific language—a small programming language for a narrow purpose, in this case defining P&P RPG rules. Designing a language is in principle not difficult, but there is a considerable amount of up-front knowledge that you must gain in order to be at all productive. Unfortunately, there is no central reference for this stuff—you’ve got to pick it up through trial, error, and lots of research.

First, find a set of primitive operations whereby other operations can be implemented. For example:

• Get or set a property of the player, an NPC, or a monster

• Get the result of a die roll

• Evaluate arithmetic expressions

• Evaluate conditional expressions

• Perform conditional branching

Design a syntax that expresses your primitives. How will you represent numbers? What does a statement look like? Are statements semicolon-terminated? Newline-terminated? Is there block structure? How will you indicate it: through symbols or indentation? Are there variables? What constitutes a legal variable name? Are variables mutable? How will you access properties of objects? Are objects first-class? Can you create them yourself?

Write a parser that turns your program into an abstract syntax tree (AST). Learn about parsing statements with a recursive descent parser. Learn about how parsing arithmetic expressions with recursive descent is annoying, and a top-down operator precedence parser (Pratt parser) can make your life easier and your code shorter.

Write an interpreter that evaluates your AST. It can simply read each node in the tree and do what it says: a = b becomes new Assignment("a", "b") becomes vars["a"] = vars["b"];. If it makes your life easier, convert the AST into a simpler form before evaluation.

I recommend designing the simplest thing that will work and remain readable. Here’s an example of what a language might look like. Your design will necessarily differ based on your specific needs and preferences.

ATK = D20
if ATK >= player.ATK
    DEF = D20
    if DEF < monster.DEF
        monster.HP -= ATK
        if monster.HP < 0
            monster.ALIVE = 0
        end
    end
end

Alternatively, learn how to embed an existing scripting language such as Python or Lua into your application, and use that. The downside of using a general-purpose language for a domain-specific task is that the abstraction is leaky: all the features and gotchas of the language are still present. The upside is you don’t have to implement it yourself—and that is a significant upside. Consider it.

Answer 2

I would start by determining the different "Phases" of each action.

For example, a Combat Phase might involve:

GetPlayerCombatStats();
GetEnemyCombatStats();
GetDiceRoll();
CalculateDamage();

Each of these methods would have access to some fairly generic objects, such as the Player and the Monster, and would perform some fairly generic checks that other entities can use to modify the values.

For example, you might have something that looks like this included in your GetPlayerCombatStats() method:

GetPlayerCombatStats()
{
    Stats tempStats = player.BaseStats;

    player.GetCombatStats(player, monster, tempStats);

    foreach(var item in Player.EquippedItems)
        item.GetCombatStats(player, monster, tempStats);
}

This allows you to easily add in any entity with specific rules, such as a Player Class, monster, or Equipment piece.

As another example, suppose you wanted a Sword of Slaying Everything Except Squid, which that gives you +4 against everything, unless that thing has tentacles, in which case you have to drop your sword and get a -10 in the combat.

Your equipment class for this sword might have an GetCombatStats that looks something like this:

GetCombatStats(Player player, Monster monster, Stats tmpStats)
{
    if (monster.Type == MonsterTypes.Tentacled)
    {
        player.Equipment.Drop(this);
        tmpStats.Attack -= 10;
    }
    else
    {
        tmpStats.Attack += 4;
    }
}

This allows you to easily modify the combat values without needing to know about the rest of the combat logic, and it allows you to easily add new pieces to the application because the details and implementation logic of your Equipment (or whatever entity it is) only need to exist in the entity class itself.

The key things to figure out is at what points can values change, and what elements influence those values. Once you have those, building out your individual components should be easy :)

Answer 3

I'd take a look at maptool specifically Rumble's 4th ed framework. It's the best system I've seen for setting up what you're talking about. Unfortunately the best is still horribly crufty. Their "macro" system has... let's say... evolved over time.

As for a "rules parser" I'd just stick with whatever programming language you're comfortable with, even if that's PHP. There's not going to be any good way around encoding all the rules of your system.

Now, if you want your users to be able to write THEIR OWN ruleset, then you're looking at implementing your own scripting language. Users script their own high-level actions, your php interprets that into something that actually affect database values, and then it throws a bunch of errors because it's a horribly crufty system that's been shoe-horned into place over the years. Really, Jon Purdy's answer is right on the ball.

Answer 4

I think that you need to be able to be able to think abstractly about what things are going to be in your problem space, come up with some sort of model and then base your DSL on that.

For example you might have the entities entity, action and event at the top level. Die rolls would be events that occur as a result of actions. Actions would have conditions that determine whether they are available in a given situation and a "script" of things that occur when the action is taken. More complex things would be the ability to define a sequence of phases where different actions can occur.

Once you have some sort of conceptual model (and I suggest you write it down and/or draw diagrams to represent it) you can start to look at different means of implementing it.

One route is to define what is called an external DSL where you define your syntax and use a tool such as antlr to parse it and call your logic. Another route is to use the facilities present in a programming language to define your DSL. Languages such as Groovy and Ruby are particularly good in this space.

One trap you need to avoid is mixing your display logic with your implemented game model. I would vote to have the display read your model and display appropriately rather than mixing your display code intermixed with your model.