Oolite multiplayer.... again.

[Spooky]

I know there's already been a thread on the if's and whynot's of an Oolite MMORPG. I was wondering if anyone is thinking a little smaller? Something along the lines of a LAN or Internet based persistant server for a limited number of players....

The reason for my question is this:

We run a very modified MAngband server at int13h.com. For those who aren't in the know, MAngband is a roguelike dungeon adventure game squeezed rather messily on top of the X-Pilot code. We've done all sorts of rewrites and fixes to the main game code and more importantly the networking code. As a result a couple of the chaps here are really rather at one with the concept of turning a non-player-centric game into a "realtime" multiplayer server and client app.

Now we haven't had too much to do with objc, but a couple of us have been having a swift poke around in the 1.62-3 and 1.63 code and we think that it shouldn't be the end of the world to build a set of simple client/server functions in straight C (based on the Mangband/X-Pilot code) that would facilitate a stand-alone server application running multiple clients in a single persistant universe. Obviously this isn't a task to be taken lightly.

So, the single most pertinent question is...

Is somebody already doing this or something similar? There is no point us re-inventing the wheel only if somebody is about to pull up in an Aston Martin

The next question is...

Would people object to branching off the project at this stage of development?

[winston]

Well, I have considered looking at it myself as a winter project, but tuits have been in very short supply recently and winter's nearly up. I too was thinking of an Xpilot style game, but obviously with Oolite ships and objects (make a game arena no larger than the volume of the IFF scanner, litter it with asteroids, space stations are your launchpoint and of course you have to get the ball!)

Oolite Dogfight is certainly doable.

However, I would recommend sticking with Objective-C and make sure things are nicely abstracted (I'm sure you're aware of endianness issues with your hardware <g>). Obj-C is not difficult to learn if you already know C and $SOME_OO_LANGUAGE.

The most tricky bit will probably be the netcode, since if you're to have any hope of playing it over the Internet you have to take lag into account. I do have a decently-connected server in London if you need somewhere to run it.

I'd also recommend doing it from something later than 1.62-3 since the collision system is being completely overhauled (and the resulting branch merge will be an utter nightmare otherwise).

[Spooky]

Dogfight style multiplayer Oolite would be relatively simple, and not something we'd be interested in doing. Most multiplayer flight/space sims always seem to degenerate into flying in circles around each other. We want to keep the depth of the current gameplay, this may mean slight variations to the timing system, especially for things like passanger runs and witchspace jumps. I don't think trivialising things like new ships and upgrades will make too much difference to game balance, and I'm pretty sure a few ships trading goods wouldn't effect the entire economy of a world. The key emphasis would be gameplay, canonical arguments will no doubt arise but provided we keep things consistent and realtime I think we can reach a workable solution to most problems.

All lot of the persistence processes we would lift from MAngband and our other currently in development project. Things like all player saves would exist server side only, saves only happen in stations and automatically. The server would generate systems on player entry (these would be stored in a universe savefile) and destroyed upon the last players exit from that system. Exiting players would exist for a period after their quitting, and if in space would continue on their last speed and course.... before self destructing.

I'm not saying this is going to be quick or easy, but we think it's very do-able. Just don't ask about time frames yet

I understand the ObjC 'desire' but we already have "endian problem free" netcode. I suppose we could use it as a learning experience and convert it to Objc... I'll see what the chaps think.

The most tricky bit will probably be the netcode, since if you're to have any hope of playing it over the Internet you have to take lag into account. I do have a decently-connected server in London if you need somewhere to run it.

Odd, that's the bit we're most comfortable with Since it would be for a small number of concurrent players 16 maybe 32, we're pretty sure we could run the game engine at 25fps (again we think this should be sufficient) across a T1 line to ISDN/ADSL clients without too much trouble. Compared to entire 80x24 arrays of plain text being sent to each client 50 times a second (MAngband) positional data and delta's for the players current system seems triffling (an over simplification, but you get my point).

We won't lay down a line of code until we've completely dismantled the current Oolite build and diseminated all of the data structures, functions and flow. This will take us a little while... and then we'll start working wrapping simple network broadcasts around things. By which time any major changes to Oolite can be assessed and merged.

[winston]

Ah, you're being quite a bit more ambitious than I thought

If you are going to be going through Oolite with a fine tooth comb, be sure to document it as you go along. http://wiki.alioth.net is a good place to document it!

Now I can't promise to be of any help, but keep me in the loop on your progress with this, I am at least interested in seeing how it's working out.

[winston]

Oh, and when you decide to do it, make sure you use the cocoa-merge branch as your basis (rather than the 1.63-4 tag, which will appear this weekend with a couple of linux-specific bug fix backports) so that the Merge From Hell is avoided.

[Rxke]

Ooh, I just can't believe me friggin' eyes!