Page 1 of 1

Roger and RobotPlayer

Posted: Fri Feb 27, 2004 5:56 pm
by David
I really jumped into this auto-pilot thing without adequate research and planning. I've been playing robot programming games (Robot Battle) since '96 and couldn't wait to see what I could do with Roger. Now that my copy of Roger has grown to over 700 lines from adding improvements in the order I think of them I should probably rethink my approach. I reinvented a bunch of code without checking to see if RobotPlayer did the same. My semi-random pathfinder, although it works good on some maps, will often shake violently when crossing the line between one path appearing better than another, while RobotPlayer seems to always find a good path as long as there's no jumping involved. Also, there really shouldn't be two robots (RobotPlayer and Roger) with incompatible interfaces.

I'm thinking of making the following changes to allow for unlimited robot AI's and have them work with both robotplayer and auto-pilot. I'd like to hear your opinions on it:

* Create class RobotAI. Accepts a Player (or LocalPlayer) object upon construction. AI's do not take direct action. Defines virtual methods to get the AI's opinion of what should be done (speed, rotation, shoot, jump, target), to tell the AI what action was taken, and to set/get the skill level. Except in rare instances, the action taken should be exactly what was recommended, unless impossible, like jumping in the air or shooting before reload.
* RobotAI could/should define a static function to create an instance of an AI by name, maybe also accepting a string parameter to pass to that AI, such as a script filename if someone decides to add scripted robot support. It could/should also store a list of available AI's and whether or not each accepts a parameter.
* Move the RobotPlayer's AI into its own class overloading RobotAI. Reusable code like target prediction should be declared as static. Perhaps add simple skill level support. What should be left in RobotPlayer is code to instantiate and use the AI.
* Completely dump auto-pilot and replace it with calls to a RobotAI.

Posted: Mon Mar 01, 2004 1:05 am
by triclops

Tomorrow I'm about to start some pretty intensive bot work for my undergrad thesis, hopefully in the next couple of weeks I have a fairly complete API implemented.

My idea is somewhat similar to yours, but rather than having a whole stack of methods that get the AI's opinion, I plan on having each instance having an update method that gets called. From within that update method it will attempt to jump, shoot, rotate, etc and will only carry out that action if it is possibly.
For other events, such as being shot, other methods will be called. I'm also considering providing methods that provide information about the world in a form that prevents cheating bots.

Check out for a bit more info (i haven't updated it since uni finished last year)


RE: Roger and RobotPlayer

Posted: Sat Mar 06, 2004 2:31 am
by triclops
Okay, here's un update for what I'm gonna do. I've spent the last few days trying to figure this out.

My plan is to implement a Player Controller object that handles all the necessary ancillary function for maintaining a single player - remote or local. It receives specific events from the underlying network layer and world and updates the player object, sound, and forwards particular events onto an Intellegence object.

The Intellegence object is where the intellegence for a player is specified and interacts with the Player object through the Controller (which essentially becomes the long sort after API).

So the Intellegence object will be overloaded to provide a HumanIntellegence object, which takes the input from a keyboard, joystick and/or mouse and updates the player and may update particular elements of the hud that are specifically related to this player (although this my occur in the Controller not sure yet).

It will also be overloaded to provide a RobotIntellegence object where people can easily specifiy their automated robot routines and not fear stepping on anyone elses toes.

On top of the new Controller and Intellegence objects will be a PlayerManager that handles the dispatching of the incoming events to the appropriate controllers. It will be designed to wrap up the Player and ServerLink object (where appropiate) in a nice consistant interface.

Finally this should be generic enough to fit inside the game library so adding some more state to the server could potentially become much simpler.

Beyond that I have a few more ideas of how I intend it to work, but otherwise its still not 100% clear in my mind.

Comments are appreciated.


Posted: Thu Mar 18, 2004 12:24 pm
by triclops

Futher update. (I feel like I'm talking to myself)

Check out some pretty diagrams on my bzflag site (excuse the problems Windows people). Hopefully they paint a prettier picture.

I'm really looking for a creative solution to my API problem atm. I don't see the point in rewritting nearly the entire Player class, but can't think of another way to provide 'security'.