C plus plus refactoring

The main engine will exist seperately from the GUI and IO in a DLL. The DLL code will be cross platform, the GUI and IO code will probably be written in either VB.net or C#.

Engine code

Here's my class hierarchy I'm thinking at the moment.

• Robot class - inherits or creates instances of the following:
  • EngineInterface - a class that specifies the interfaces for how to update the robots over a cycle. No data, just methods.
  • Physics Entity - a physics entity is a primitive used in the physics engine. The physics entity contains data on mass, shape, size, position, velocity, and other data of similar sort. The shape is a sphere.
  • DNA - a class to handle the DNA. The interface will hide any issues like Codules from the other classes.
  • Memory Abstractor - Tie communication demands an ability to store information sent to a bot during a cycle seperately from what the robot itself is doing to its DNA, which is seperate from the underlying memory.
  • Pointers to ties
  • Life properties (nrg, slime, generation number, etc.)
  • Eye Entity (eyes are "attached" to robots in the same way as physics entities. The eye entity handles any optimizations the program may make for vision. It links to the physics entity for matters of position and orientation.

• Shot Type (-1, -6, etc.)
  • Abstract Shot - an abstract class is used so we can used pure virtuals for what to do when a shot collides with a bot
    • Physics entity - shape is a point

• EngineManager - Singleton
  • DNAParser - Executes a DNA instance and applies its effects on a robot instance. No data, just methods. Singleton
  • PhysicsEngine - Performs physics calculations and integrations on physics entities. No data, just methods. Singleton
    • Any query optimizations (such as a uniform grid) are handled in here
  • VisionManager - Handles all the vision queries of vision entities. Singleton
  • DataManager - A dummy class to hold the lists of data in the program. Singleton
    • RobotList
    • ShotList
    • TieList
    • ShapesList
    • TeleporterList
    • Possibly a physics entity list
    • Possibly an eye entity list
  • CycleManager - A simple method only class that handles the updating of a cycle. This has the possibility of being moved into scripts if I ever figure scripts out. Singleton

• Voyeur - A class that can expose data to other modules, specifically the GUI front end of choice. I haven't worked out the details, but the idea is that a GUI would only need to interface with this single class. The vast majority of interactions would be read only, but some write actions exist as well.

The GUI front end

The GUI handles every thing that's an IO. Included, but not limited to:

• Graphics
• User queries (such as clicking on robot info, etc.)
• Networked sharing
• Loading settings, robots, etc. from disk, and saving them to disk as well.