Difference between revisions of "Structure (C plus plus)"
(→Simulation engine: ->Numsgil) |
|||
(3 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
<center>''This is only a proposal initiated by [[User:Sprotiel|Sprotiel]].''</center> | <center>''This is only a proposal initiated by [[User:Sprotiel|Sprotiel]].''</center> | ||
+ | |||
This page defines the algorithmic structure of the program in terms of objects, without going into too much coding details. | This page defines the algorithmic structure of the program in terms of objects, without going into too much coding details. | ||
+ | |||
+ | == 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 == | == User interface == | ||
Line 7: | Line 12: | ||
== 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. | + | === Discussion === |
+ | 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.) [[User:Sprotiel|Sprotiel]] | ||
+ | |||
+ | :<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> [[User:Numsgil|Numsgil]] | ||
+ | No, on this page I'm only talking about logical organisation, though it'd be nice if the way code is distributed amongst the files minimised the number of #includes and more or less mimicked the organisation of classes. [[User:Sprotiel|Sprotiel]] 15:31, 7 Jan 2006 (MST) | ||
+ | == Robots == | ||
+ | == Shots == | ||
+ | == Ties == | ||
== Comments by Numsgil == | == Comments by Numsgil == | ||
Line 23: | Line 35: | ||
The non-Core engine (things like mutations, DNA parsing, etc.) hasn't been worked over yet in thought or in code. | The non-Core engine (things like mutations, DNA parsing, etc.) hasn't been worked over yet in thought or in code. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
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. | 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. |
Latest revision as of 17:31, 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
Discussion
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.) Sprotiel
- 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. Numsgil
No, on this page I'm only talking about logical organisation, though it'd be nice if the way code is distributed amongst the files minimised the number of #includes and more or less mimicked the organisation of classes. Sprotiel 15:31, 7 Jan 2006 (MST)
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.
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.