[barrkel]

May be completely besides the point, but my first OO instinct upon approaching the question is to model rules etc. as objects themselves. Only the most naive OO modeler would think that OO objects must be nouns within some physical analogue of the system - to my mind, anyhow.

[MartinCron]

I've been working on a board-game program lately and I've created a "referee" object that's responsible for enforcing rules, handling workflow, turn taking, etc. Works really well for me.

[dspeyer]

Why would you want to do that? They have no state. You're almost never going to do anything with them except invoke them from specific places. This sounds like complexity for its own sake.

[barrkel]

First up, there's nothing wrong with immutable objects; indeed, immutable objects have benefits that mutable objects don't. So not having mutable state is not a good argument against modeling them as objects in an object-oriented language.

Secondly, rules do have state, in so far as one rule is distinct from another. Perhaps a rule has preconditions (which could be represented as a binary tree and evaluated through recursion) that must be true before the rule is "active". Perhaps rules have effects, a list of state changes that they impose on the rest of the game world. You could model these as functions, or alternatively again as trees, evaluated through recursion. If the rule system needs to be flexible enough, they could be serializable and deserializable from a text or binary format.

If the game is a simple one, with a fixed set of rules that never change, there's little need for this. But if you look at a game like Monopoly, there's a lot of complexity that comes up in real-life games that isn't so simple to encapsulate in rule lists, such as making complex deals, haggling, borrowing money from other players, even receiving charitable donations from other players to prevent the game ending prematurely.

Move further into business rule systems and the need for flexibility increases again. I've architected systems which needed a generic rule-based system for data validation and workflow transitions; and these rules had themselves rules for when they applied, as older rules needed to be grandfathered in to older data, but expired for new data.