Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Next generation tool

Sign in to follow this  


One of the things I'd like to work on at some point is a compiler for game rule documents. So that you can describe your game rules in a subset of English (i.e. reads like regular English, but some keywords/phrases have special significance), and the compiler can then convert that into a logical model of the game. Eh, it's hard to explain... :(

It's sort of like declarative programming. The ruleset document is a number of 'statements' (which may have substatements). Each statement describes some aspect of the game - general things like the number of players or the types of play tokens, specific things like types of game manouvre, or conditional things like win conditions. So you'd get something like this:

  1. The game is for exactly two players.
  2. All players start with a score of zero.
  3. The game has a cyclical structure.
  4. In each play cycle:

    1. All players select one strategy from a set of three strategies.
    2. Play is paused until all players have satisfied rule 4.1.
    3. If one player selects strategy 1 and the other player selects strategy 2, the score of the player that selected strategy 2 is incremented.
    4. If one player selects strategy 2 and the other player selects strategy 3, the score of the player that selected strategy 3 is incremented.
    5. If one player selects strategy 3 and the other player selects strategy 1, the score of the player that selected strategy 1 is incremented.

  5. If any player has a score of five or more, that player wins.

The game, of course, is Rock Paper Scissors, and my descriptive language is pretty clunky but it's at least comprehensible for a first attempt. A more complex language will allow more natural phrasing of rules.

It's two problems. Firstly, parsing standard English text. There's quite a lot of work on this, and we can cheat somewhat by listening for 'magic' words (such as 'if', 'each', and so on). Secondly, can we develop a comprehensive model of a game ruleset for this to be translated into?

You might wonder what the benefit of this sort of thing is. The benefits are massive. Firstly, it's the starting point for any kind of gameplay analysis; the model can be used to find situations in which the rules conflict, for example. They can be used to control a generic game-playing AI; after deducing game state and permissible player actions from the rules, the AI can choose one of those actions to play. It can build game trees. It can find dominated or dominating strategies. It might even be able to locate conditions or rule interactions which cause gameplay trends (such as the game destabilising too quickly) and suggest rule modifications to help prevent that.

In short, it's putting the gears and axles of our gameplay into a computer so we can run simulations and analysis on it. Everyone else who designs complex machines has these kinds of tools already, and they're doing better than we are, it would seem.

As a general long-term goal or milestone: I want the system to be able to describe and model: a tabletop RPG, Othello, Go, Chess, and Poker. If it can do all of those it should be pretty formidable.
Sign in to follow this  


Recommended Comments

Looks like an interesting idea, it'd take a lot of work to develop it into a useful tool rather than a little demo that allows you to describe simple games like Rock Paper Scissors, Chess etc.

Personally I'd also not focus on having the game rules described only by pure english introducing some non-english elements would make complex rulesets clearer to read.

Share this comment

Link to comment
What sort of non-English elements did you have in mind?

My basic goal with this is to create something that designers can use rather than programmers. So the 'pure English' thing is more just a statement that using a 'rule programming language' is not a valid option, unless it's so abstracted and hidden with syntactic sugar that it looks and feels like plain English.

Share this comment

Link to comment
To be honeset I'm not entirely sure what kind of extra elements you might want to introduce, prehaps it could work with just straight english I guess it depends on how well the compiler can interpret english. Though in your example it does contain indentation and rule numbering which I guess you could call non-english syntax elements.

You'll need to find a sweet spot between a full-fledged programming language syntax (e.g. it looking like c) and it being long overly verbose sentences that are hard to read.

You could experiment with using flowcharting either alongside or instead of just straight sentances describing rules.

Another idea that's sort of related that popped into my head while reading this, is developing a tool that allows a designer with little or no programming ability to rapidly prototype a game. Something like click and play but obviously geared towards game designers. You could integrate this ruleset compiler into it so a designer would actually be able to play a game using the ruleset. Prehaps this is already what you had in mind, it just seems the way you describe it the compiler would give a model you could play around with but would accept input and give output in the form of text rather than giving a proper game prototype.

Share this comment

Link to comment
Yes, I guess indentation and numbering are non-english elements... they're something that you tend to find on a standard rules sheet though (usually broken up into sections, too).

The goal is to create a tool for designers with no programming experience to use. I don't think "programming language" should enter into it - it will be overly verbose if the designer is overly verbose. Hell, once the system has understood the rules it could perhaps suggest ways to rephrase them for greater conciseness/accuracy. Fact is that your average ruleset document is supposed to be non-ambiguous and logical, so that players can always figure out what to do - as such it should be well suited for a machine to understand, and if it can't understand a rule then the designer should be clarifying it anyway.

I'm supposing nothing about the output of the system, that's the point. Perhaps my use of the word 'compiler' has been erroneous - I'm not talking about something that creates a program. That is not what this does. This creates a computer-comprehensible model of the game rules that you could do things with - plugging them into a generalised framework for playing games is certainly one thing (so you get 'instant prototyping' of game mechanics, in executable form). But that's a specific application of this concept.

Metafor is sort of related to this, yes, but it's all in a game-specific context. A key part of developing the model would probably be identifying game objects (like 'player', 'creature', 'card') and the properties and methods of them. But code generation would be a step beyond that, using that info to generate classes, etc - which, if you wanted to do any interesting work with, you'd have to re-parse to work with.

Share this comment

Link to comment
I had an idea like this a while back, but I never felt like diving into it. :) It looked like an endless whirlpool of development.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!