Here is my idea for an overall design:

the main loop (in function mainLoop() say. its not a part of a class)
will maintain a list of OnlineUser objects (in an array), and it will
also have a sorted list of fd,OnlineUser structs, as described in the
document "FD to Object pointer mapping" (filename idea.txt). It will
block on a select(3) call, and will return every so often to do stuff
like checking to see if its midnight (so it can do periodic
maintaince) or perhaps making AI moves,... basically: whatever.

Anyways select(3) will return, in that case it will do a
fd->OnlineUser map and find the OnlineUser object that has data
pending for it and call OnlineUser::processInput() and call
objects which can be written to OnlineUser::processOutput() (for wierd
socket reasons). So OnlineUser will retrieve the data via various
socket and libc calls and so forth, then call the top object on its
UIHander stack and pass the data to it. UIHandler will actually
impliment the gameplay. UIHandler will be the one which calls Universe
and gets objects to maniupliate. And so forth.

UIHandler will use a callback method as described in "Design of UI
Handling" (filename ui_design.txt) to request for data to be sent to
the client. This data will be buffered and delivered with
processOutput() later so that blocking libc functions dont
need to be called. (ie: most socket calls) 

So we have the game encapsulated in a bunch of UIHandler objects, the
io code encapsulated in the OnlineUser class, and the persistent state
data encapsulated in Universe.

with the main select(3) loop calling the OnlineUser which calls
UIHandler which calls Universe and stuff gets done.

the main select(3) loop will need some kind of way of having timeouts
and alarms and so forth so that it can do stuff at periodic intervals:
ie: call Universe:WriteToDisk() every X minutes (configurable) and so
forth.

A few implimentation notes:
we dont need a dynamic array for most things... there will be a hard
limit on the number of sectors.. and a few other things.

One note is that we will want to make a configurable option for the
number of online users. Because of per-process file descriptor limits,
the max we can hope to get per game is something like 254 (including
one extra for a listen socket). or a bit lower. So we can make an
array of pointers to OnlineUser objects. It will be initally allocated
using new but will never grow. forget about dynamically changing
limits. just restart the server.