https://github.com/radicalzephyr/team103

Battlecode 2011 AI
https://github.com/radicalzephyr/team103

Last synced: about 1 hour ago
JSON representation

Battlecode 2011 AI

• Host: GitHub
• URL: https://github.com/radicalzephyr/team103
• Owner: RadicalZephyr
• Created: 2011-01-12T03:47:18.000Z (almost 14 years ago)
• Default Branch: master
• Last Pushed: 2011-01-23T06:35:21.000Z (almost 14 years ago)
• Last Synced: 2024-12-24T08:50:10.478Z (5 days ago)
• Language: Java
• Homepage:
• Size: 109 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README

Awesome Lists containing this project

README

        
Written by Geoff Shannon in January 2011.

Basic Class structure:

RobotPlayer is the interface that the battlecode framework uses.

Every time a new robot is created, it gets its own instance of

RobotPlayer, the constructor is called, and then the run method is

called.

If control ever reaches the end of the run method that robot is

destroyed.  This is why we have a while (true) loop at the end of the

run method as a catch all.

All actual functionality of the robot is contained in the

RobotController class that is passed to the RobotPlayer's constructor,

thus the RC is what actually needs to be passed around.

The basic control structure is that the RobotPlayer acts like a

dispatcher.  It owns an instance of the StateMachine class, which is

the dispatcher for handling the grunt work of swapping to different

states.

The StateMachine in turn has a pointer to an instance of an Actor

class, or one of its descendants.  The purpose of the actor class is

to provide a higher level view of the functionality prevented in the

RobotController class.  One of the reasons for this is to tailor the

high-level abilities provided to the actual hardware that is present

in the robots.

In addition, every State that gets instantiated contains a pointer to

the controlling StateMachine and the Actor class.  This has several

implications: first, it allows the State to do ANYTHING.  It can

change what the Actor class is, it can initiate state changes.

Second, yeah... anything.

Right now, there's a single catch-all state InConstruction that is the

first one entered by every robot.  New robots should default to

turning off so that the building robot can finish building them before

the try to do calculations.  Since when every robot is created it

should only have one component (the motor), that's the test we use.

In addition, as a sanity check, we don't turnOff if this robot has

been turned off before.