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.

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 🙂

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.

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.