Go Back   Orbiter-Forum > Blogs > Izack
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Rate this Entry

Design philosophy

Posted 09-29-2013 at 01:38 AM by 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.
Posted in Uncategorized
Views 5799 Comments 2
« Prev     Main     Next »
Total Comments 2


  1. Old Comment
    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.

    HUMONGOUS IMS shipbuilder
    Posted 09-29-2013 at 03:12 AM by Dantassii Dantassii is offline
  2. Old Comment
    Urwumpe's Avatar
    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++.


    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.
    Posted 09-29-2013 at 06:26 AM by Urwumpe Urwumpe is offline

All times are GMT. The time now is 01:12 PM.

Quick Links Need Help?

About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.