Difference between revisions of "Structure (C plus plus)"
(a bit more) |
|||
Line 13: | Line 13: | ||
== Simulation engine == | == Simulation engine == | ||
We should have a top-level object which has all the information needed to run a sim. Right now, it's the rather meager EngineClass. Most globals should be integrated into it. It might be useful to separate its purely physical part (that handles dynamics and collision and needn't know anything about the internals of the objects) from its biological part (metabolism, reproduction, etc.) | We should have a top-level object which has all the information needed to run a sim. Right now, it's the rather meager EngineClass. Most globals should be integrated into it. It might be useful to separate its purely physical part (that handles dynamics and collision and needn't know anything about the internals of the objects) from its biological part (metabolism, reproduction, etc.) | ||
+ | |||
+ | <font color="Red">Do you mean how the source code files are organized, or the logical segregation of classes? I am reluctant to segregate the physical files into folders more than they are already because it makes the include file paths unwieldly. However, I've created logical files to group the source code into in MSVC, which is what I'd suggest doing. I'm sure Dev-C allows you to do it too.</font> | ||
== Robots == | == Robots == |
Revision as of 17:06, 7 January 2006
This page defines the algorithmic structure of the program in terms of objects, without going into too much coding details.
Contents
Modularity
The program should be a set of interconnected components, which can be changed and replaced without affecting the others. One way to achieve this is to use as much as possible abstract base classes from which the actually used classes derive.
User interface
If DarwinBots is to become a serious program, it should be able to run from batch files and/or (Python) scripts. Obviously though, a GUI is the prefered mode of interaction for most people and has to be the top priority. However, it should be thought of as a front-end and not be too tightly integrated into the core engine.
Simulation engine
We should have a top-level object which has all the information needed to run a sim. Right now, it's the rather meager EngineClass. Most globals should be integrated into it. It might be useful to separate its purely physical part (that handles dynamics and collision and needn't know anything about the internals of the objects) from its biological part (metabolism, reproduction, etc.)
Do you mean how the source code files are organized, or the logical segregation of classes? I am reluctant to segregate the physical files into folders more than they are already because it makes the include file paths unwieldly. However, I've created logical files to group the source code into in MSVC, which is what I'd suggest doing. I'm sure Dev-C allows you to do it too.
Robots
Shots
Ties
Comments by Numsgil
Basically, the code is divided into 3 primary areas:
GUI, GFX, and Engine, each doing their obvious respective function.
GUI is written in a library called "FOX GUI Toolkit", which was picked rather arbitrarily because it was one of the few GUIs I could figure out. Most of the code up till this point for the GUI has been written by Wolf. The GUI is also (at the moment) the frontend into the other three modules. So the GUI is also the central regulating machine.
GFX is written using openGL, with the consideration of allowing it to, in the future, be expanded to 3D. It's probably done really inefficiently, but I can't find anyone who knows more openGL to work on it with me.
The Core Engine (things that are called every cycle) is written with the consideration that Darwinbots has procedurally written in the past. And I have been a procedural programmer in the past. And Darwinbots needs to be fast and readable. All this results in a style more reminiscent of C (with some classes thrown in) than C++ (with it's crazy templating and polymorphism and fun things like that).
The non-Core engine (things like mutations, DNA parsing, etc.) hasn't been worked over yet in thought or in code.
Coding style
This is how I code:
void function(parameter 1, parameter 2) { for(some; things; inside) { blah; } }
Notice the 4 space indentation.
I don't care how you write code, so long as I can read it and understand it. When we edit each other's code, we should endeavor to maintain the same style as the rest of the function we're editing. That is, don't mix styles in the same function.
If you don't like the idea of mixing styles at all in the whole project, feel free to adopt my style. ;)
If you're adding a line that isn't very reader friendly, please comment in thoroughly. Write the code as if a bunch of non-savvy beginning programers are going to read and edit it. No fancy programming tricks please. Do in 8 lines what you can cram into 2 if 8 lines makes it more readable. Use lots of white space. This code needs to be maintainable by anyone and everyone.
My compiler is MSVC++ 6.0, and so that's the official compiler of the rest of the project. If you use a different compiler, I will endeavor to let it compile for you. But the privelege of compiling to the nice sight of 0 errors, 0 warnings is reserved for me and others using MSVC++ 6.0. I can supply versions of MSVC++ 6.0 to some who'd like it.
At the moment, my goals are to get the C++ version equally working as the VB version. So things like batch runs etc. are simply a non-issue at the moment.