This tool will dynamically generate an agent based on the Game Description Language used by the General Game Playing project.

It contains a Python program that translates Game Description Language definitions (usually stored in files with .kif extension) into self-contained Soar agents that simulate the mechanic of the game in working memory and productions.

Download LinksDocumentation

Run the translator as follows:

Code:
python translate.py < input.kif > output.soar
where "<" redirects the input file to the program's standard input and ">" redirects the program's standard output to the output file. For Windows users not familiar with this convention please see

http://www.microsoft.com/resources/d...direction.mspx

The generated agent contains productions that initialize the game state, proposal rules that propose legal moves, and application rules that update the game state when legal moves are executed. It does not contain any other knowledge, such as which moves to choose or what kinds of heuristics to use.

Content Descriptions
  • translate.py - The main Python script to run.
  • common.soar - Productions that need to be included by all generated agents.
  • kifs/ - Directory containing example games.
  • trans/ - Directory containing Python code that does the actual work.
Notes

The generated agent will reference the file "common.soar", so please make sure it's in the same directory or edit the first line of the generated agent file.

Generated agents will create two WMEs on the state - (<S1> ^facts <F1>) and (<S1> ^gs <G1>). All static relations in the game are stored under the facts WME, while dynamic relations are stored under the gs (game state) WME.

A GDL relation (on A B) will take the following form in working memory:

Code:
(<G1> ^on <O1>)
(<O1> ^p1 A ^p2 B)
Most of the kif files on games.stanford.edu were written for backward-chaining systems. This means that when deducing the truths of relations based on the game rules, many unnecessary intermediate relations are automatically ignored. On the other hand, the generated Soar agents calculate truth values in a forward-chaining style, preventing them from pruning unnecessary intermediate relations. Many of the agents generated from these kif files will experience explosions in working memory and partial production match sizes, and will slow to a crawl or crash completely after running out of system memory. If you experience these symptoms, you need to do two things:
  1. Modify the GDL rules so that each inference is as constrained as possible.
  2. Use the multi-attributes command to tell Soar about relations that still have a large number of instances so that the RETE delays matching on them until other constraints are in place.
We've included an example of how to modify the mummy maze game to run tractably in the kifs/ directory.

Developer
  • Joseph Xu
Soar Versions
  • Soar 8, 9
Language
  • Python