Difference between revisions of "C plus plus refactoring"

Latest revision as of 02:40, 5 November 2006

This page uses alot of programmer jargon, please forgive me. It's primarily a way for me to organize my thoughts for myself.

The main engine will exist seperately from the GUI or any IO at all. It's written in OO C++ and is compiled into a DLL. The engine is written to be ANSI C++ that is cross platform. The idea is to encapsulate the actual simulation away from the GUI code, since GUI code is probably going to be rather platform specific.

The GUI and IO code will probably be written in either VB.net or C# (I'm leaning towards C# [1]).

The engine runs in one of the following modes:

• Run continously
• Stop after every cycle (the GUI will have to reactivate the engine)'
• Debug DNA mode
  • Continue (to next breakpoint)
  • Set Breakpoint at X bp of Robot Y
  • Advance one element (if currently in DNA debug mode and waiting on the GUI)
  • Stop DNA debug mode

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.
• A seperate module will probably handle statistical tests, gathering data from the simulation. The GUI will be responsible for feeding data into and gathering data from the stats module.