Many people have been asking me this question:
But what am I supposed to do with Botworld?
But what am I supposed to do with Botworld?
This indicates a failure of communication on my part. In this post, I'll try to resolve that question. As part of this attempt, I've made some updates to the Botworld code (which is now v1.1) which make Botworld a bit more approachable. A changelog and some documentation are included below.
To clarify, Botworld was devised as a tool for reasoning about different AI formalisms. We're not trying to build a hotbed for programming competitions or anything of the sort. Rather, we need a concrete system with concrete games where we can study how a given agent deals with a given situation. As such, most of our work which references Botworld will describe complex agents playing simple games. A few such posts are in the pipeline.
Benja and I designed Botworld as a universe where we can distill many 'edge case' scenarios that an AI may face, such as having it's source code read or distributing itself across multiple machines. Such scenarios are often handled clumsily by existing AI formalisms, and it is quite useful to have simple, concrete scenarios where we can envision such events.
That's how we use Botworld: we throw different formalisms at different edge cases, figure out where their problems might lie, and visualize solutions. If we encounter problems, we use Botworld as a way to find a minimal example. You'll see one such example in an upcoming post.
So how are you supposed to use Botworld? Well, if you're studying AI formalisms, then you're encouraged to use Botworld to visualize and distill weird scenarios where different agents may run into trouble. Otherwise, we don't really expect you to get direct use out of it.
Don't get me wrong, you're more than welcome to play around, write amusing games, and design programs that do neat things. It's a flexible and fun little system. If you are just looking to entertain yourself, you're invited to:
The display code now lives in the Botworld.Display module. New functionality has been added which allows you to gain much more insight into what happens between steps. The Botworld displays are now much prettier (using ASCII box drawing characters) and much less cluttered.
The new Botworld grid display is quite minimal, displaying only the positions of each robot by color. (Use the displayBotworld function to display a Botworld grid.) Much more data can be had by half-stepping a grid (using the runEnvironment function) and then displaying the resulting EventGrid (see the displayEventGrid function). The Event Grid display works as follows:
Each cell has two rows. The first shows the position of (up to 5) robots in the square by color. The second has information about what is happening in the cell, using the following flags:
Robot movement is shown by arrows breaching the borders between cells. (Diagonal movements are somewhat awkward to display. To see which robots moved in/out of a cell's northwest/northeast neighbors, look at the cell's top border. To see which robots moved in/out of a cell's southwest/southeast neigbors, look at the top border of the cell's southwest/southeast neighbor. It's less confusing than it sounds; the arrows make things fairly clear.)
To get additional information about what happened in a single cell, you may use the displayChangesAt function. This prints a full description of a cell's event. This includes a full robot list (color, action, speed, register count, inventory) and a full breakdown of items (untouched, dropped, and fallen, with fallen items separated by robot and by fallen part vs fallen inventory).
A minimal language 'ct' has been added, which makes writing robot programs slightly less painful. The syntax is as follows:
A register is declared by either a name followed by a colon, or a name followed by a number followed by a colon. The number, if given, is the memory limit of the register. If omitted, the register size will be made to fit the register contents precisely (this is useful when a register holds a subroutine.) Examples:
A register definition must be followed by content. Content may be any of:
Machine instructions compile directly into the normal Constree instructions (Nilify, Construct, Destruct, or CopyIfNil), but they allow you to specify registers by name instead of by number, and allow some simple shortcuts. Accepted instructions include:
> ct2hs Omega > Omega.hs
> ghci Omega.hs
λ :t machine
Four games have been added to the new games directory.
> ct2hs LeftBot > LeftBot.hs
> ct2hs RightBot > RightBot.hs
> ghci PrisonersDilemma
λ :m +LeftBot
λ :m +RightBot
λ run LeftBot.machine RightBot.machine
Okay, so this may be a really stupid question, but would it be possible to use botworld to test decision theories experimentally? Like pitting a bot running TDT against one running CDT in a bunch of partially-randomized scenarios, and seeing who scores higher?
For a given situation, you might be able to work out "what would a TDT agent do", and you might be able to program your bot do that. (These are different challenges, because a TDT agent might analyse its opponent's source code, which is a difficult programming problem.) You might be able to do the same for CDT, and pit the two bots against each other. I guess you wouldn't learn very much from the results, because if you can program the TDT and CDT actions for this situation, it's probably simple enough to just analyze it and work out what happens.
Implementing either of these algorithms in general is beyond our current abilities.