C plus plus refactoring - Revision history

Numsgil at 07:40, 5 November 2006

2006-11-05T07:40:23Z

Numsgil at 07:36, 5 November 2006

2006-11-05T07:36:26Z

Numsgil at 07:32, 5 November 2006

2006-11-05T07:32:59Z

Numsgil: Starting page

2006-11-02T06:58:17Z

Starting page

New page

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.

@@ Line 3: / Line 3: @@
 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#).
+The GUI and IO code will probably be written in either VB.net or C# (I'm leaning towards C# [http://www.andymcm.com/csharpfaq.htm#1.]).
 The engine runs in one of the following modes:

@@ Line 1: / Line 1: @@
 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 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#).
 == Engine code ==

@@ Line 1: / Line 1: @@
-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#.
+This page uses alot of programmer jargon, please forgive me.  It's primarily a way for me to organize my thoughts for myself.
 == Engine code ==
@@ Line 39: / Line 43: @@
 *Networked sharing
 *Loading settings, robots, etc. from disk, and saving them to disk as well.