Sorry if it has been suggested but, has no one thought this?

[Catsy]

If you want an Elite-like MMORPG experience, give Jumpgate a look.

I like my Oolite single-player. :)

[Hawk]

Hello everyone. Can I recommend the name Moolite (Multiplayer Oolite) if you do ever make an arena version?

[Chrisfs]

Hello everyone. Can I recommend the name Moolite (Multiplayer Oolite) if you do ever make an arena version?

It's great but I think it's already taken as the name Oolite goes by in systems with intelligent bovine lifeforms.

[JeffBTX]

... who REALLY, REALLY resent the practice of "cowtipping".

[Diziet Sma]

wl its needed

Well, read this then.. the definitive discussion thread for Multiplayer Oolite.

[DaddyHoggy]

wl its needed

Well, read this then.. the definitive discussion thread for Multiplayer Oolite.

FYI ruchicoool has been tagged as a spambot...

[Diziet Sma]

You mean spambots now make sorta relevant posts? wow..

Ah well, the link I posted is still a good thing to have here for newcomers, I guess...

[Disembodied]

Plus, the post you're quoting from seems to have disappeared from the thread ...

[Commander McLane]

...plus: I hope you new posters have noticed that this thread is more than four years old, with no posts for three-and-a-half years (although, admittedly, it was an interesting read into the very early debate about multiplayer Oolite ).

[Diziet Sma]

Yep, I did.. but it's all Hawk's fault..

[hiran]

Eww. An mmorpg is a giant can of worms.

OXPs aren't actually the problem. In an online game, the client is merely a way of displaying the graphics. The performance characteristics of the ships, the NPC ships et al., collision detection, getting shot, being blown up, your speed, shield and energy situation would all be determined by the server. OXPs would merely provide the model and textures to display. If someone edits the SuperCobra OXP to make the SuperCobra top speed 600 instead of 450, it won't make a jot of difference because the server will only let it go at 450. Similarly, if someone modded the client to give them immortal shields, it won't make a scrap of difference because the server will still decrease the shields, and the important state information will be on the server. At worst, the client will just display the wrong information and the hacker will find his ship unexpectedly exploding when they supposedly have full shields.

Walking should be attempted before running, too. No MMORPG until a successful arena deathmatch or CTF game can be run reliably.

Anyway, let's look at what would need to be done:

Oolite, unlike original Elite, is actually a practical proposition. The original Elite was (in all the incarnations I know of) player centric, mainly because it was really the only practical way of making Elite work on the kit that was available. I looked quite closely at the TNK source to see how it does.
What do I mean by player centric? Well, in the Elite universe, the player was always at the cartesian coordinate (x,y,z) of 0,0,0 and was superglued to that location. The player never actually moved. The player in fact always faced the same way. What happened was the universe revolved around the player - literally (Skip the bad jokes about the Brabster!). Roll the ship, and the entire universe rolled. Pitch and the entire universe pitched. Switch to left view, and the entire universe instantly yaws by 90 degrees. You didn't fly to the planet, the planet came to you. A player centric system like this is utterly impractical to make multi player (it COULD be done by translating the coordinates of objects before displaying them, but it would be a monumental pain in the arse).

Oolite on the other hand is not player centric. I think 0,0,0 is the witchpoint beacon (I could be wrong, I've really not looked that deeply at those bits of the code). Everyone would have a common frame of reference and a common origin. That already makes the job 100 times easier.

Now we've got that out of the way, let's look at what has to be done.
1. A daemon has to be written. Probably by pulling out some of the code (the code that makes stuff move in the universe) and separating it not by objc message passing, but UDP packets. Of course, it would be possible to rewrite it in straight C, but then we lose all the effort that's already gone into making the universe run, and having a server process rely on the GNUstep Foundation is not really so terrible. It provides a pretty nice object oriented library anyway (and would keep all those plists compatible). Of course, this is all available by default on a Mac server.
2. Net code. SDL provides platform independent net code (that I've not yet looked at), but you'd have to write your own code to handle lag in the context of Oolite. You'd want to use the SDL netcode as a general interface since not the whole world is a Mac. Macppc is big endian, i386 is little endian. And not the whole PC world is i386 either - we now have amd64 which (I assume) has bigger floating point types than i386 (I'm making the assuption that SDL net has functions that allows you to transfer floating point values, integers etc. in a platform neutral manner).
As for keeping the universe up to date, the simple way would of course to just have the client send its command to the server, and not update what's really happening until the server sends a universe update. This is simple and works fantastically well on a LAN.
The rub is it's totally unsuitable for the Internet. Even the slightest bit of lag makes the game unplayable if you make it work like that. So what you need is the client to react instantly to the user's input, fire the packets at the server and hope for the best, then if things get out of sync due to packet loss or lag, the client and server can get back in sync without warping the ship around (which is very confusing to other players - and it happens in FPS games occasionally when things get laggy). Now it'd be easy to just have the server believe the client if it gets laggy, but that just allows blatant cheating (someone modifies the game client to allow a pitch rate twice of what it should be, the server thinks its out of sync and believes the client - so you have to have the server sanity check what the client is saying to avoid blatant cheating like that). Getting the netcode right is far from straightforward!
Then we get to network bandwidth. We've got to delegate some things to the client (we can't have the server sending the location of every particle of an explosion or the bandwidth requirements will get ridiculous) but we have to have the server maintain control of some things. We may need to make some objects immovable and indestructable (such as large asteroids and space stations) so we only need to ever send them once. We need to decide what information to send. For example, you'll want to have frequent updates of objects on a player's scanner, but not send any data about a distant battle that the player can't see - except of course for the explosions, which can be seen at any range.

Then there's the problems with aim bots.
And verifying the client isn't hacked (tricky to do with an open source game!)
And the equivalent of the wall hack (making the client not render asteroids so the cheat can see another player trying to lurk behind an asteroid). Even in a non-MMORPG, people will cheat.

Anyway - pull these off and you can make Oolite Arena. I would envision a game somewhat similar to XPilot, but 3D. Start off with a game with boundaries meaning the volume of available space is no larger than the scanner range (and you get stopped if you try and escape, or even better, blown up), litter it with very large asteroids, put in a couple of CTF objectives and perhaps the odd XPilot style piece of equipment that can be fuel scooped.

So now you have a networked game so you can start working on the MMORPG?

Well - again, now there's a lot more work to do! Trading systems, bulletin boards, all the things you'd need to do to make an MMORPG actually spring to life, and not just be a very large version of the Arena game. You'd need to continuously add missions (or perhaps have the players do it). You'd also have to make the universe significantly smaller too, with 2048 star systems, even during the busy times, you'd hardly ever meet anyone if everyone went travelling. So you'd perhaps limit the universe to maybe 20 or 30 star systems so there is a reasonable chance that people will actually meet.

Then the servers

With 20 star systems, really you'd need on average 15 players continuously on each to make it worthwhile for most people. That's 300 simultaneous users (minimum). Assuming that the total average bandwidth per player is 5kbyte/sec (0.005 Mbit/sec), that requires 1.5Mbit/sec sustained, or a maxed out T1 line. You'd transfer about 13 gigabytes a day, or 390 gigabytes a month. Most UK dedicated host providers only give you an allowance of 150 GByte/month! (US providers, such as where I host alioth.net, allow 1.2 terabytes a month, but since hardly any Elite players are in the US - Elite is almost exclusively a British phenomenon - yes, we have European, Aus and US players, but the rest of the world put together probably is only a fraction of the British contingent) hosting in the US is a non-starter because the lag will be too bad for most players. Indeed that brings up a new point - each geographic area would need their own Ooniverse.

The CPU load would also require you to run more than one server. 300 simultaneous users on a game that does lots of maths all the time will hammer the typical Celeron server you get at a hosting provider. This is of course OK most of the time, as it'd be fairly easy to put different star systems on different servers. But if there's all of a sudden a convention on Tionisla... How many servers? I dunno how much load Oolite minus graphics would cause, but I bet you'd really need a minimum of 4. At 60 quid each a month (that's the price of the cheapest decent quality dedicated server in the UK)...or 240 quid total a month, or nearly 3 grand a year! It starts getting really expensive really fast, and if the game catches on, the cost as you add servers begins to sky rocket. You can't commercialize it because of the Oolite license (and if the license allowed it, if you DID commercialize it, the Breadbin Smackdown would be coming to a lawyer near you). You may be able to pull it off if you found someone nice enough to let you suck up 1.5Mbit/sec of their bandwidth and build the most massively powerful server you can find to put in their rack.

And no, domestic ADSL or cable won't do. The upstream is too constricted, and your ISP would cut you off for using too much bandwidth. I suppose you could massively distribute servers (one server per star system) which would probably make a volunteer effort on consumer ADSL work most of the time - but considering the server owners essentially have the keys to the castle (and will probably be players too) you have to make sure you vet them so THEY don't cheat! (Or help others cheat). You'd also have the hypothetical Tionisla gathering to worry about, where all of a sudden one server is going to get mullered by all the players.

Long post, but a lot of time has passed and I expermiented a bit with https://bb.oolite.space/viewtopic.php?f= ... 3&start=15 and https://bb.oolite.space/viewtopic.php?f=4&t=21033. So let's dissect the above claims...

1. A daemon has to be written. Probably by pulling out some of the code (the code that makes stuff move in the universe) and separating it not by objc message passing, but UDP packets...

Well, we have the Oolite Communicator. It is not C but Java, still it runs besides Oolite and the two communicate via TCP/IP. It is currently the Debug Console Protocol and it seems sufficient for now. Besides being a daemon, it also has a UI to show it's own state or offer functions not (yet) implemented inside Oolite. One example: It shows the other players participating.

2. Net code...

Java contains a lot of net code which is actually in use already. While the communication to Oolite is the Debug Console Protocol, communication on the other side is performed via XMPP. There are nice libraries out there to be used in Java. We still need to learn about the lag, especially when many people want to play together. While the lag cannot be reduced there may be programming patterns that may mitigate the effect on the simulation. Otherewise I'd wonder how other games can do multiplayer via internat today since they all must be sufferering the same kind of lag.
Bandwidth should not pose any problem - even small broadband home connections are faster today than what was standard for companies back then.

And verifying the client isn't hacked (tricky to do with an open source game!)

This is no problem at all. Yes, the code is open source and anyone can compile it himself. But would you be able to forge a digitally signed archive? Such practices did not exist back then although encryption and digital signatures did exist. So we can prepare a client distribution, sign that off and the client has to prove that this signature is still valid. Which could be done if the private key is derived from the deliverable itself. Then the signed public key (=the certificate) would only match on original clients that have not been tampered with.

Anyway - pull these off and you can make Oolite Arena. I would envision a game somewhat similar to XPilot, but 3D. Start off with a game with boundaries meaning the volume of available space is no larger than the scanner range (and you get stopped if you try and escape, or even better, blown up), litter it with very large asteroids, put in a couple of CTF objectives and perhaps the odd XPilot style piece of equipment that can be fuel scooped.


This sounds like a nice paintball game in space. Definitely worth trying.

Well - again, now there's a lot more work to do!

Oolite Communicator, if done right should be a modular thingy allowing missions to be plugged in. At least that is my intention, and we are not there yet.

Then the servers

The servers would be a problem if the whole simulation had to be done by them. However if we have trustworthy clients and distribute that load (every player is anyway simulating the star system he is in) there is plenty of compute power, and we just need to pass suitable amount of messages to keep them in sync. As mentioned above, due to lag they will get out of sync, and we just need good algorithms to go to an eventually consistent state.

The intention is to start with less problematic effects. Players passing messages and goods is not time critical as the Oolite Arena, but would already allow some interaction. Once this works we can get closed to the arena part.

[hiran]

If you want an Elite-like MMORPG experience, give Jumpgate a look.

I like my Oolite single-player.

I just tried to find Jumpgate and stumbled over http://jumpgate-tri.org/downloads.html.
Unfortunately it is just Windows-based.