Design theories behind the Universe class:

The Universe class will encapsulate all permanent state information.
It will accept messages (read: method calls) and react apon them.
All functions will be non-blocking, and will return
quickly. (hopefully)

Basically the Universe class will sync to disk every X minutes. this
will be automatically done by a method like:

void syncToDisk(void);

the main loop which calls select(3) will timeout every so often and do
things that need to be done (ie: sync to disk, do other automated
stuff, like move AI players, etc etc etc)

Universe will have to have some way of updating permanent state
information somehow. For example: the UIHandler's will call Universe
to move a ship from sector to sector, so there will need to be some
kind of way to pass information about changing the ship
information... obviously using 5000 methods is the C Way Of Doing
Things (tm) and we are using C++... so we can use classes.

Obviously storing 5000 SectorObject is just a bit wasteful. So
instead there could be a call which acts as a "Factory"... so you
could call:

SectorObject * retrieve_sector(int secnum);

which would construct a SectorObject, and pass it back. The
SectorObject could have a reference/pointer to the Universe object in
which it could call back and have stuff done (good idea). So
essentially you get this SectorObject, and call methods on it, and it
would in turn call methods in the Universe class which would do stuff.

The alternate way is: once you retrieve the SectorObject, you modify
it, then "write" it back to the Universe object... but that wouldn't
be a good idea, because the 'master' sector information and the
information stored in the SectorObject could quickly become out of
date. In fact by using SectorObject you are just externalizing the
interface to the sector modifications. We could achieve a slightly more
efficient approach by doing something like:

class Universe {
public:
	int sectorGetLimpedMines(int secnum);
};

and so forth. 

Which is better... the SectorObject way is more "OOPy"... but we are
striving for efficiency... but with the SectorObject way it makes for
an easier way of abstracting stuff, and also separating code and
keeping the main Universe class "clean" and not highly cluttered with
a few hundred function/state calls.

So far this issue is open.

-ryan

--== Update ==--

Thinking about it, in keeping with the idea of iterators, I think it
would be a good idea to "externlize" the interfaces to different
classes. This doesn't necessarily have to be a degradation in
performance. Take this C++ example:

class SectorObject {
private:
	SectorObject();
public:
	~SectorObject();
	friend class Universe;
/* imagine all the calls to get and set sector attributes now */
};

class Universe {
public:
	SectorObject *getSector(int sectorid);
	friend class SectorObject;
};


Now the SectorObject has full access to the internals of Universe,
and Universe has full access to the internals of SectorObject. The
SectorObject's constructor is private so random people can't make
them, they have to get Universe to do the deed for them. Also in
addition the Destructor for SectorObject is public so anyone can
destroy a SectorObject without having to ask Universe to do it for
them.

Because the SectorObject has full access to the internals, the
SectorObject can have all the algorithms for changing the Universe
data structures. So we can have the best of many worlds: we have a
SectorObject which represents one sector, and we can do stuff with it,
(ie: copy it, etc etc) but because it really doesn't store anything
(except for the sector number id) permanent, it can be destroyed at
any time without losing data, and because of the friend class thing we
don't lose much efficiency. But we still maintain the OOP methodology.