[kage]

About my database alternative, I have it pretty much down here, sort of. This is pretty pervasive on the core engine design, and the object interfaces will need to be fleshed out, preferrably early. I haven't 'proofread' it, and there may be parts that seem disjointed.

The basic idea is that every ship has a directory containing an xml file for some 'common' details (names, hull numbers, etc, various such things that appear in a mission editor) graphics files, perhaps sound files, and a .dll or similar containing code specific for that ship.

Interface files could of course be included in that directory; the presence of these interface files could determine if a unit was playable or not.

One could use "dependencies" so as to e.g. keep the SPY-n radars in a 'module' of its own, and used by the ships using it.

I am, for (semi-)obvious reasons, writing this in c++.

class RadarTarget {
    // Another platform is using radar against this. 
    // Horizon is how high above the waterline the other radars horizon is at this distance. 
    // Direction is the relative bearing at which it is
    // This order of parameters is probably rather messed up, but they're only showing a concept.
    virtual float radarfeedback (char band, float horizon, float direction, float power) = 0;
};

class SonarTarget; // with similar content

The idea is that the sonar tonals can be partially randomized,
seeded with only the classname and hullnumber, or such, thereby creating a different sound signature for each hull. Heck, a player might choose to have them further randomized and have fun creating a listing of sound signatures...

Note that the above are all interfaces without function definitions.

class Platform : RadarTarget, SonarTarget   // and of course lots more
{ };
    
// Provides very generic functions based on some typical database-ish data
class GenericPlatform : Platform
{
  // ...
}

The below would, in the 'final' version, be in a dll in a directory

class ArleighBurkeFlt1 : Platform 
{
  // proper function definitions for everything, adjusted so as to fit the Burke.
}

As a guideline, DRY (Don't Repeat Yourself) says that common stuff (like radar direction absolute to relative bearing) should be in the calling code.

This method will easily require a lot more work per platform, but on the other hand it will also offer a sort of flexibility that those using the old-fashioned databases only have wet dreams about.

Oh and... I do volunteer for this project; I've been wanting it for a while myself, but my major project completion rate has been... low.

I do have a lot of knowledge of C++ (I primarily do 'backend' type programming) and, should I say, 'how computers work' all the way down to machine code. I have a subversion server and a bugtracker around as well.