Project on Hiatus until 4/7/2008

Yep, PyWeek is more important.

Methodology to the Madness

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

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

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!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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