(Before you read this, read today's earlier post about games.)
Kevan, who has done more good thinking about games than I, replies in email to my earlier post about games. He provides some links to nomics (games that change the rules from within the game) more complex than I knew about.
Synchroncity at cityofsound: Modelling Urban Behaviour Amidst Networked Ultraviolence talks about how Grand Theft Auto 3 probes the edges of games. The city changes over time; you can alter your environment in expected ways. (Some superb links in that post to, to discussions about the game universe.)
So I'm gradually more convinced that rules in games are black-and-white approximations of what is really combinations of costs and least-resistances in an incentive space. Breaking a rule (or rather, paying a cost (say, spending hours gathering weapons to break down a wall -- I've never played GTA3) to not follow the rule-habit) should have a consequence within the game, whereas games like Monopoly undergo system crash if their rules are broken (that's crash as in environmental crash, a downward spiral). Furthermore rules shouldn't always be explicitly made or broken. In the real world even a move may reinforce or weaken rules, or even make new ones. And by 'move' I mean the process of following a least-resistance path.
On a sort-of tangent, and because I've been reading a lot about the REST www-architecture recently, we could couch the old-style rules-and-moves version of games like this: A move is like a GET on a resource on the www, an idempotent request, it always has the same result. A GET returns a resource which says which other resources you can move to Setting a rule is a POST, it places the rule on the server (in the game) but how it actually gets merged into the resource-database is up to the server itself.
But this is the node-arc model, the filesystem model. This is treating a game as if it's moving around a map, and ties in with the sameness of interfaces. And games aren't/shouldn't/don't-have-to-be like this! At the very least making a move doesn't just alter the physical pieces-on-the-board representation, it adds that move into the history of the game. But more than that a move may change the rules themselves, as a side-effect, without the player intending it.
(Before you read this, read today's earlier post about games.)
Kevan, who has done more good thinking about games than I, replies in email to my earlier post about games. He provides some links to nomics (games that change the rules from within the game) more complex than I knew about.
Synchroncity at cityofsound: Modelling Urban Behaviour Amidst Networked Ultraviolence talks about how Grand Theft Auto 3 probes the edges of games. The city changes over time; you can alter your environment in expected ways. (Some superb links in that post to, to discussions about the game universe.)
So I'm gradually more convinced that rules in games are black-and-white approximations of what is really combinations of costs and least-resistances in an incentive space. Breaking a rule (or rather, paying a cost (say, spending hours gathering weapons to break down a wall -- I've never played GTA3) to not follow the rule-habit) should have a consequence within the game, whereas games like Monopoly undergo system crash if their rules are broken (that's crash as in environmental crash, a downward spiral). Furthermore rules shouldn't always be explicitly made or broken. In the real world even a move may reinforce or weaken rules, or even make new ones. And by 'move' I mean the process of following a least-resistance path.
On a sort-of tangent, and because I've been reading a lot about the REST www-architecture recently, we could couch the old-style rules-and-moves version of games like this: A move is like a GET on a resource on the www, an idempotent request, it always has the same result. A GET returns a resource which says which other resources you can move to Setting a rule is a POST, it places the rule on the server (in the game) but how it actually gets merged into the resource-database is up to the server itself.
But this is the node-arc model, the filesystem model. This is treating a game as if it's moving around a map, and ties in with the sameness of interfaces. And games aren't/shouldn't/don't-have-to-be like this! At the very least making a move doesn't just alter the physical pieces-on-the-board representation, it adds that move into the history of the game. But more than that a move may change the rules themselves, as a side-effect, without the player intending it.