Yeh... I don't say why your all worrying so much about data bases so much. I'm just going to use the game engine it self. Whilst this system is inherently inefficient (as latency becomes 2x ping + U[0,1), rather then just 2x ping), It is by far the best alternative, as no one really knows the mechanics of how objects work in X3. (So simply, just let X3 handle the mechanics)
The app just links the game's together.
In fact I'm making the app very simply, it just records and feeds numbers from the server to the hosts.
One Idea I have been entertaining however, is rather then uploading the entire universe and everything in it. Just have a couple of "communal" sectors, and then everything else is offline.
And as its going to be primarily based around small private servers, when the games offline, it's just offline.
Also, the majority of NPC's are highly predictable, given the same environment, they will do the same thing. So short of a huge player intervention, it should be possibly to "slow update" the universe.
So instead of updating every ship, every "refresh" get all the ships, and cycle the list over the course of XXX seconds.
Of course, several actions would require objects to refresh in realtime. Namely, the playerships and activesector ships.
Similarly, some actions would require an immediate refresh. Eg, trading a ware should be done immediate, to prevent de-synchronisation.
I'm hoping to be able to achieve this by doing the following
1. Replace some stock script editor commands, with a lib script, designed for XO use.
Eg, buy ware, will be replaced with lib
-> lib.xo.buyware $ware $amt
On the client side, it wont actually buy anything, but send a signal to the server, and wait for 3 seconds (for a return value). If it doesn't come, don't buy, return 0 (bought amount). If it does come, then buy the amount returned from the server.
Similarly for sell, load, unload etc.
Similarly, player ships firing will have to be replaced. (unfortunately). As I need to send some kind of firing signal, I'll just replace firing with a script: *check player target, if in firing cone, fire every 25 ms for 250 ms and return to server, player ship fired on target. Other wise "miss" fire at nothing/dont fire/dont send.
Of course, this can still lead to desynchronization with the server. But hey, these things happen.
One of the issues I'm conceptuatlizing atm thou, is what to do in the event of desync.
One HUGELY tangental idea I've been having thou, is to make X3O more like sins of the solar empire thou. Where essentially, all graphics and hits are eye candy.
But in any case, all this is sort of a moot point, as I'm still wondering exactly how am I going to structure the data... Idealy, just integers, but now that I'm a bit more advance in my bit-array ness, I could restrict the first to 2 bytes + ve, and then construct some kind of variable return system, to allow strings, or integers. But then I'd have to consider.. what do I need strings for?
And yep... conceptualizing
So for now I'm just building the program in a modular design. The server/client program will just send/receive numbers, and the X3 scripts that I will write, will just be able to read/print numbers. Then Ill worry about what the actual numbers should be.
Oh one more thing I need to do. Replace all the randomly generated numbers in current scripts, to read off from an LCG that I create, where I can set the initial seed, for best sync across the clients.
(As a side note, I can see the technical merit in why eve online was designed for there to be only 1 player controllable ship
{perplayer})
Expansion of the LCG idea's, The initial seed can be the objects id from the server. (For LOCAL random numbers, globals will just use the global random number)