Botworx

Behavior Language

2009-12-09T22:16:00.001-08:00

WIP:


namespace SequenceTestNamespace

using System
using System.Collections.Generic
using System.Text
using System.IO

using BwBot.Runtime
using BwBot.Runtime.Tasks

class SequenceTest()
    def Main(sequence-test)
        {Console.WriteLine("a");}
        sequence
            {Console.WriteLine("1");}
            {Console.WriteLine("2");}
            {Console.WriteLine("3");}
        {Console.WriteLine("b");}
        sequence
            {Console.WriteLine("1");}
            {Console.WriteLine("2");}
            {Console.WriteLine("3");}
        {Console.WriteLine("c");}
        sequence
            {Console.WriteLine("1");}
            {Console.WriteLine("2");}
            {Console.WriteLine("3");}
            
sequence-test

Redo

2009-06-16T21:39:00.000-07:00

I finally decided to go forward with a C# redo since the C++ version is too long and hard of a row to plow.

I've also cooked up a new syntax that is basically a prefix version of Python's syntax.


class Test():
    def Foo1($x is foo): #forward chaining method
        rule:
            $x has $y
            $y is bar
            -->
            $y is foo

I've already written a simple tokenizer based on this article about regular expression parsing in C#. Another article that was helpful was Python: Myths about Indentation. That only took one day. The rest of the week was spent agonizing whether to have the parser just read the token list or convert to s-expressions and then parse.

I finally went back to an earlier idea of writing a class called TokenTree that extends List(object) where each element is either a token or a subtree. This should make things easier on the parsing end for various reasons. The s-expression idea was kind of neat but it seems redundant since I need AST classes anyways.

Later on I'll have to dump the RegEx stuff and write a more sophisticated tokenizer but at least this was a quick way to get started. For now I need to start writing the recursive descent parsing functions and the AST classes.

Agent Language Preview

2008-12-11T02:23:00.000-08:00

This is a preview of the Agent Language I'm working on. More details will go in a Wiki or something.

Methods are triggered by the addition and deletion of facts within the state. Methods without triggers are evaluated upon state creation. Rules within the methods are evaluated sequentially. States are evaluated until no new information can be generated at which time any facts that were proposed will cause the creation of successor states into which those proposals will be added along with any other facts in the current state.

This is a work in progress therefore any and all comments or criticisms are extremely welcome!

$ = Logic variable
. = Property of the rule, method, state, or agent


;
; BwAi - Missionaries and Cannibals 
; Based on the Soar Version 
; Kurtis B Fields - 2008
;
(domain Mac ()
 (method main ()
  ;state success
  (rule
   (topic $g (type goal))
   ($g object $bank)
   ($g missionaries $m1)
   ($bank missionaries $m2)
   ($m1 = $m2)
   ($g cannibals $c1)
   ($bank cannibals $c2)
   ($c1 = $c2)
   ($g boat $b1)
   ($bank boat $b2)
   ($b1 = $b2)
   ==>
   halt
  ) 
  ;state failure
  (rule
   (Bank-1 missionaries $m1)
   ($m1 > 0)
   (Bank-1 cannibals $c1)
   ($m1 < $c1)
   -->
   (assert(.state fail "Too many cannibals on Bank1!!!"))
   ==>
   fail
  )
  ;state failure
  (rule
   (Bank-2 missionaries $m2)
   ($m2 > 0)
   (Bank-2 cannibals $c2)
   ($m2 < $c2)
   -->
   (assert(.state fail "Too many cannibals on Bank2!!!"))
   ==>
   fail
  )
  ;state failure
  (rule
   (.parent (.goal missionaries $m1) (.goal cannibals $c1) )
   (.goal missionaries $m2)
   ($m1 = $m2)
   (.goal cannibals $c2)
   ($c1 = $c2)
   -->
   (assert(.state fail "State undoes parent goal!!!"))
   ==>
   fail
  )
  (rule
   (topic $g (type goal))
   (not($g is achieved))  
   -->
   (temporary(.agent achieve $g))
  )
 ) 
 (method MoveMissionaryPropose (.agent achieve $g)
  (rule
   (topic $bank1 (type bank))
   ($bank1 boat $boat)
   ($bank1 missionaries $m)
   ($m > 0) 
   (topic $bank2 (type bank))
   ($bank2 <> $bank1)   
   -->
   (propose((.agent move-boat $boat)
    (missionaries 1)
    (cannibals 0)
    (source $bank1)
    (destination $bank2) ) )
  )
 )
 (method MoveCannibalPropose (.agent achieve $g)
  (rule
   (topic $bank1 (type bank))
   ($bank1 boat $boat)
   ($bank1 cannibals $c)
   ($c > 0) 
   (topic $bank2 (type bank))
   ($bank2 <> $bank1)   
   -->
   (propose ((.agent move-boat $boat)
    (missionaries 0)
    (cannibals 1)
    (source $bank1)
    (destination $bank2) )
   )
  )
 )
 (method MoveMissionariesPropose (.agent achieve $g)
  (rule
   (topic $bank1 (type bank))
   ($bank1 boat $boat)
   ($bank1 missionaries $m)
   ($m > 1) 
   (topic $bank2 (type bank))
   ($bank2 <> $bank1)   
   -->
   (propose ((.agent move-boat $boat)
    (missionaries 2)
    (cannibals 0)
    (source $bank1)
    (destination $bank2) )
   )
  )
 )
 (method MoveCannibalsPropose (.agent achieve $g)
  (rule
   (topic $bank1 (type bank))
   ($bank1 boat $boat)
   ($bank1 cannibals $c)
   ($c > 1) 
   (topic $bank2 (type bank))
   ($bank2 <> $bank1)   
   -->
   (propose ((.agent move-boat $boat)
    (missionaries 0)
    (cannibals 2)
    (source $bank1)
    (destination $bank2) )
   )
  )
 )
 (method MoveMissionaryCannibalPropose (.agent achieve $g)
  (rule
   (topic $bank1 (type bank))
   ($bank1 boat $boat)
   ($bank1 missionaries $m)
   ($m > 0)
   ($bank1 cannibals $c)
   ($c > 0) 
   (topic $bank2 (type bank))
   ($bank2 <> $bank1)   
   -->
   (propose ((.agent move-boat $boat)
    (missionaries 1)
    (cannibals 1)
    (source $bank1)
    (destination $bank2) )
   )
  )
 )
 (method MoveBoatApply (.agent move-boat $boat)
  (rule
   (.thought source $bank1)
   (.thought destination $bank2)
   (.thought missionaries $m)
   (.thought cannibals $c)
   ($bank1 missionaries $m1)
   ($bank2 missionaries $m2)
   ($bank1 cannibals $c1)
   ($bank2 cannibals $c2)
   -->
   (retract 
                ($bank1 boat $boat)
    ($bank1 missionaries $m1)
    ($bank2 missionaries $m2)
    ($bank1 cannibals $c1)
    ($bank2 cannibals $c2)            
            )
   (assert 
    ($bank2 boat $boat)   
    ($bank1 missionaries (- $m1 $m))
    ($bank2 missionaries (+ $m2 $m))
    ($bank1 cannibals (- $c1 $c))
    ($bank2 cannibals (+ $c2 $c))   
   )
  )
 )
)
;
;
;
(problem Mac
 (topic Boat-1
  (type boat)
 )
 (topic Bank-1
  (type bank)
  (missionaries 3)
  (cannibals 3)
  (boat Boat-1)
 )
 (topic Bank-2
  (type bank)
  (missionaries 0)
  (cannibals 0)
 )
 (topic Goal-1
  (type goal)
  (object Bank-2)
  (missionaries 3)
  (cannibals 3)
  (boat Boat-1)
 )
)

Syntax Highlighter Test

2008-12-11T01:36:00.000-08:00

I found a way to insert code snippets into the blog. As long as you can find somewhere to host the files SyntaxHighlighter seems to be the best solution. Here is a good tutorial to get rolling.


class MyClass {
    bool blah(){
        return 2 > 1 ; 
    }
}

Looks are Everything

2008-05-11T20:40:00.000-07:00

Well, I managed to rearrange and rebuild everything with Visual C++ 2008 express.

Now it's time to get rid of the uglies!

I went over to a place called Psionic where most Ogre folks get their free models.

Thankfully I found a patch for the Ogre Blender Exporter that does the axis swapping again.

Only problem is that the Jeep model is still backwards. Either I research how to rotate vertices in Blender or I can just rotate the mesh in Ogre.

It's never easy.

Rock and a Hard Place

2008-05-09T03:26:00.000-07:00

Now I'm in a real dilemma.

I'm having a problem with Boost 1.35, CeGui, and vc7.

There isn't a problem with vc9, so it must be a bug in vc7 that they haven't done a workaround for yet.

I could go back to Boost 1.34 but then I'd have to include ASIO separately and I'm not sure if I can use vc9 with it.

Hmmm...

Shaking the Tree

2008-05-08T13:53:00.000-07:00

Sometimes when your stuck in a rut it's time to shake things up.

My way of shaking things up this time is to upgrade to Boost 1.35 and creating a build system for Visual C++ 2008.

The reason for upgrading Boost is that ASIO is now an official part of the library and I need to replace the socket classes I wrote to make Botworx more portable.

Unfortunately, they totally rewrote the thread library and the locks and mutexes I was using caused things to hang. All that synchronization stuff probably needs a rewrite anyhow.

I think I'm going to dump ODE and Bullet and just go with PhysX. I can't count the hours I've spent making a hybrid system work. It works, but ... time to move on.

Back to the Grind

2008-05-07T21:13:00.000-07:00

Well, PyWeek ended about a month ago but I kept fiddling with RoboCute until I could decide how to proceed with trying to beat this framework into shape. Now it's back to C++. Yay.

Project on Hiatus until 4/7/2008

2008-03-27T12:23:00.000-07:00

Yep, PyWeek is more important.

Methodology to the Madness

2008-03-20T10:14:00.000-07:00

It just occurred to me that the way I'm getting this ready for publication is worthy of comment.

I am restructuring this thing top down. Starting with the top level concepts and classes to do some much needed refactoring, plus rearranging file directories and files in the process. I am also going to throw out a bunch of failed and half complete experiments along the way. They can be reincorporated later if desired.

After this restructuring/reevaluation phase I need to re-implement certain things from the bottom up. The main thing is object lifetime. That's always a ball of wax.

The Applet Concept

2008-03-20T10:05:00.001-07:00

This concept is not to be confused with Java Applets. The Applet concept goes further back if you look at the Wikipedia entry here.

I had been tempted just to change the name to Application or App for short. I'm going to stay with it in the eventuality that we may wish to run several of these side by side or embedded in a web page. That makes the name stick.

The Applet's main role is to serve as the root of the simulation heirarchy.

Applets are derived according to which GUI system the user plans on using. CEGUI and wxWidgets for now. More to follow.

The User Concept

2008-03-20T06:37:00.000-07:00

Each Scenario creates and owns a User object.

The User object is created via a factory method of the Applet. (Need to define Applet soon!)

Each User class is specific to a particular GUI system. CEGUI, wxWidgets, etc.

Each User has a UserMode tree.

A UserMode is a class that can be either an action, a UserMode group, or a mode of some kind. For instance a dialog.

User interaction consists of drilling down and escaping back out of this tree.

It makes it extremely easy to implement user interfaces and is more intuitive than your average GUI with it's multiple menus, toolbars, etc., although these elements could be integrated into the User framework as well.

Fire Bad!!!

2008-03-20T06:27:00.000-07:00

This thing is a Frankenstein creation for sure. It's cobbled from open source components and it has graphics only a mother could love.

I'm not sure when, or even if it's going to appear. I'm not even sure about the license type yet.

So ... I'm just going to keep throwing details on this Blog for no apparent reason. :)

Requests For Comments

2008-03-19T09:03:00.001-07:00

I'm going to start tossing some RFCs up here to help resolve issues that I can't make a clear cut decision on, even after endless hours of searching the internet.

Hopefully SOMEONE will participate.

Thanks!

GUI Madness

2008-03-18T23:31:00.000-07:00

I'm probably the only person whose nuts enough to implement GUI interfaces for multiple GUI systems on a per scenario basis.

It all got started because the 'in-game' GUI looked like crap inside wxWidgets.

You could have GUIGUI wrappers but that would be insane, trying to wrap each element for each GUI system.

The solution is to have a factory function that returns a User object specific to the GUI that creates the interface and manages event routing.

This might be interesting in the fact that you could have the factory function create different interfaces depending on certain modalities: play, edit, etc.

Hopefully I get it refactored and working properly by days end.

Botworx and wxPython

2008-03-18T13:37:00.000-07:00

After posting pics of the wxWidget integration it occurred to me that having a wxPython widget would be the bomb.

This would allow rapid prototyping of editing and debugging aids.

Of course that also means providing scripting support for a lot of the guts.

That's probably aways down the road. I need to clean this thing up and bang it into shape first.

Fixing wxWidgets Integration

2008-03-18T10:25:00.001-07:00

Oh boy. This is setting off a whole chain reaction of refactoring I put off for a long time. :(

The upside is that it should make adding more GUIs in the future easier.

It's also getting rid of a lot of redundancy that existed between the CEGUI & wxWidgets wrapper classes.

.5 Roadmap

2008-03-17T06:33:00.000-07:00

This roadmap is contingent on interest in this project and the willingness of others to participate!

Distribution will be in limited form and start at version .1

Distribution of .1 will be somewhere between April and May of '08.

Distribution of .1 will only be on an invitation basis. Mainly to AI teachers, students and game programmers.

After the period of about 1 year or I think it deserves a .5 moniker then it will go into general distribution. Whichever comes first.

The reasoning behind this is that I don't want to be a one man support team for a free product!

The Scenario Concept

2008-03-17T05:52:00.001-07:00

This class is equivalent to a game 'level' in a game framework.

It occurred to me while thinking about the text for this article that this would be closest to the Sandbox concept.

I've managed to move a lot of functionality that used to be in the main application into Scenarios.

That means they manage their own scenegraphs via the Scene class, have another component that wraps up a GUI, and also manages the World and physics engines.

Now that I think about it, the ultimate goal is to rework the reference application into a more generic IDE and call it BotworxApp for the raw fullscreen executable, and BotworxWx for the wxWidgets version.

These also should be turned into .dll/.so file projects.

Project wizards for Scenarios should be implemented even before an application wizard.

You'll have to forgive me. I haven't worked on this for awhile. I'm just going to slap up information and tidbits as they come to me and reorganize into Wike format later.

Botworx Simulation Overview

2008-03-17T00:59:00.001-07:00

Botworx uses a dual phase stepping approach. Step and PostStep. I thought about adding PreStep but it doesn't seem necessary.

I'm aware that scenegraph libraries such as Ogre can get by with just one pass and lazy updating but I don't know if it's possible here.

Besides, I've seen physics and AI code that use dual phase so I won't obsess about it until someone proves me wrong.

The Step Phase

Here is the stepping order:

Application
Scenario
... World
...... Spaces
... Physics
... Renderer

The PostStep Phase

Nodes in the SceneGraph get updated in this phase.

The Wrap Up

Yeah, I know, sketchy. All of these articles are works in progress.

The Ultimate AI Sandbox

2008-03-16T23:57:00.000-07:00

It's always good to dream about the ultimate and then scale back to the achievable.

What features would our dream framework have?

Project Wizard

This is what I had earlier called an Automated Sandbox Generator. It would be nice to have a wxPython application that can generate C++ projects once you tell it what platform and options you need.

This made me think about the Sandbox concept in general. (More research!) Maybe some people think it should just be a single application. If you want to write usable AI or get a job in 'The Business' seems like you need to be writing some C++ anyhow. This could change once/if scripting support gets implemented.

3D Graphics

I think Ogre fits the bill nicely. I put the visualization code into it's own subcomponent and used a separate math library if I ever decide to go with something different. A renderer plugin system would be nice where you could switch between libraries but that would be a lot of work and it seems unnecessary.

Physics

I am almost to the point of implementing a physics plugin system. Right now they are implemented as static libraries. One is a wrapper for ODE. The other is a templated impulse based engine I wrote. I may decide to just use Bullet's impulse system instead.

PhysX integration? More research on my part. Doesn't look as flexible as ODE and Bullet.

Path Finding

People could just use Boost A* like I do, or design a path finding engine interface. Not sure.

Steering

Right now I'm using OpenSteer, it might be fun to do an in-house library though. Turtles! =)

Messaging

Botworx has a messaging system I wrote that uses Boost for serialization support to send them between processes and machines. It works for me!

Networking

I need to toss out the socket classes I wrote and replace them with Boost ASIO is what I'm thinking.

Scripting

More work.

The Wrap Up

That is all I can think of right now. It seems like they are listed by priority also. Leave a comment if you think of anything!

Botworx and wxWidget Support

2008-03-16T23:34:00.000-07:00

Unfortunately I broke it during the last total overhaul. It should probably be fixed by the time I release the first .5 sample. At least I think that should be the version number. You decide!

The main thing that needs to be implemented is a unified user interface system for both CEGUI and wxWidgets. I'm having to implement redundant menu items and actions for both. Negative!

Automated Sandbox Generation

2008-03-16T23:31:00.001-07:00

Your eyes probably popped when you saw the title. :)

Sorry, this is an idea I just had to automatically generate Sandbox/Game projects using Python.

You could probably get nutty with it by using XML to specify various options / flavors of the Sandbox.

BuggyBots: Reference Application and Library

2008-03-16T23:13:00.001-07:00

I broke up BuggyBots into a static library and a very thin executable project. This enabled me to easily create a wxWidgets application that is basically the same 'game' with a minimal amount of extra code.

This should probably be further refined by implementing a library that only contains Bots & Props.

The goal is to write a tutorial that explains how to create your own project as simply as humanly possible and then make the necessary refinements to the framework. It'll get there. This is only .5!

Core Concepts

2008-03-16T22:36:00.000-07:00

Actor

This is probably the most important class in the whole thing. It's not an Actor like in PhysX. It's a more general concept that gets used throughout the whole framework. It's basically a class with a 'stepping' interface.

Stage

Normally this wouldn't be it's own separate class. This is a class that acts as a container for Actor children and also manages / propagates the stepping. This may get implemented as a template instead. It's up for debate.

Space

This is what can be thought of as a Game Object. It has a position, orientation and pointers to various components. This may or may not be a confusing name. Some may think that spaces are fixed. There is a class called Place for that.

Shape

This is a space that that has geometry used for collision testing. It does not have to be a solid.

Group

Most people cram as much stuff into a base class that they can get away with. I like to break things out into branch and leaf nodes. It saves space in the base and compartmentalizes behavior. But that's just my opinion.

Place

This class extends Group and the name explains it all. A Space that doesn't move.

World

This class is used to implement the root for the whole space heirarchy. Actually, any Place derivative could be used as well.

The Good, the Bad and the Ugly

2008-03-16T20:13:00.000-07:00

I was going to use a picture from the film from the Wikipedia entry here, but after reading all the legalese I figured you can just click the link. :)

I'm just going to slap things up on this Blog and organize it into a Wiki at a later date. The writing style will be informal and slightly slapstick. This makes things more entertaining for both the writer and the reader.

The Good

Botworx is amazingly stable. You are not going to have the application just quit for no apparent reason. I must have some knack for writing robust systems. I think it's really a philosophy of keeping things as simple as possible.

The Bad

Botworx has more dependencies than I care for but that's just the nature of the beast. If your going to help work on it or use it to carry out your mad AI experiments be prepared to compile some of those dependencies from source.

The Ugly

I wrote this thing in my spare time. If you take Ogre3D as an example, it may take another 3 years to attain the same quality. And that means coders helping out.

While we're on the subject of ugly, I did the Buggy skin etc. myself just to have something to look at. I could have used third party, but that means work trying to massage it to get it right for the game. People who like to skin and animate would be heartily welcome also!

Screen Shots

2008-03-16T05:45:00.001-07:00

Here are some Screenies. I'll try to elaborate on these in the future.

wxWidgets Integration

Buggy Gazing from Afar

Buggy with Laser Lance

Buggy Blowing Stuff Up with Missiles

Oops, I Made a Mess

Ninja and Robot Soccer

Hide and Go Seek

UFO Over Terrain

Buggy and Crawler on Terrain

Introduction

2008-03-16T04:37:00.001-07:00

I've spent an inordinate amount of time on an AI Sandbox / Game Framework over the past 3 or 4 years.

I'd like to keep the emphasis on the AI to keep from going off on a million different tangents, but who knows? Maybe it could evolve into a more general game framework.

It's written in C++

Required Dependencies

Boost
Ogre
Open Input System (OIS)
Crazy Eddie's Graphical User Interface (CEGUI)
Open Dynamics Engine (ODE)
Bullet
Generic Math Template Library (GMTL)
Open Mesh
Open Steer

Optional Dependencies

wxWidgets
SCEA COLLADA