Design philosophy

[Izack]

So, on returning to the Deepstar 3 codebase and having a look around, I've become unsatisfied with the level of simulation. I started by forking over certain functionality to different classes, and what I ended up with was a system where individual major components (main/rcs engines, fuel cells, environment controllers) became their own class. It's interesting to see the program's structure take on the appearance of the actual spacecraft's.

I do wonder, though, as a still-inexperienced programmer, if this is an effective way of approaching module design. As far as I can understand, it enables easier porting and modification of complex system components, and if it develops farther, perhaps a framework for creating more such components. Complexity = amusement as far as Orbiter goes, and this enables easier development of moderately interesting spacecraft systems. :2cents:

 

[Dantassii]

You might want to check in with the current IMS project (IMS 2.0, not the recently released IMS 1.0 RC3). This sort of question has been discussed in that group and the framework being used in IMS 2.0 is a much more flexible system along the same lines as your thoughts.

Dantassii
HUMONGOUS IMS shipbuilder

 

[Urwumpe]

Generally yes, but you should try keeping the number of major classes as low as possible. For example, it might not make sense modelling a new type of sensor, if only the detection range changes, that you can already cover well by setting parameters.

What happens behind the major classes, that is your choice again... you can have many smaller classes implementing subsystems, so you again have building blocks.

By exploiting inheritence, you can reduce your testing times. For example, you can make an abstract superclass for all engines, and test it with a stub class.

For testing (and many other funny things, that I recommend) you should look at the Boost library for C++.

http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/index.html

Such tools become extremely useful once you have many classes and thus many classes to test. The more tests you can make automatic, the better, remember that you can't test all automatically, but making those automatic, that you can, saves you time for testing the bigger problems.