Oolite Bulletins

Oolite as a MMORPG, still for free, where we could all fly together in the universe at the same time.

Could even be a separate side project.

Maybe with a slightly upgraded graphic engine but even the current one would work great.

been talked about. and, well...maybe, but not tomorrow...

Getting a MMORPG working nicely isn't trivial, esp. with the modpacks around, it would be easy to design super-ships, with only changing one, two lines in an OXP, and so making the game unplayable... Of course there's a simple solution: no OXP's or very strict rules/testing etc...

I think the time is nearing to try out some of those ideas though, the ports getting there, more people with coding skills around...

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.

I meant OXP's added to the main server-system, sorry for bad expressing my thoughts.
i meant, now you would upload an oxp, test it, like it or not, install it or not permanently.
when people would design stuff for a multi-player, it would get harder to judge what fits and what not...

anyhow, MMORPG doesn't seem realistic, at this point, as you explained quite nicely. Not enough ooliteers, for starters. (Though I personally wouldn't mind flying around w/o much real players... Then again, I'm not the typical MMORPG player, grin...)

well that was very educational.

thanks for the (slightly gloomy) perspective

It's posts like that that make me astonished at the skill of programmers in general.

Plus, coupled with the last few hours of looking through Oolite Objective C Code, makes me appreciate once more how damned clever Giles, Dajt and winston are.

Hats off, guys. I'd buy you all a pint if I knew where you drank...

winston wrote:

Eww. An mmorpg is a giant can of worms.

Heh but the rewards justify the means

I'm glad for this response, just the fact that you thought up and wrote all of this means that you gave it some thought. Giving something thought means there is a tangable way around problems.

Now I'm no programmer, I have no idea how any of it works. But I have tons of ideas and concepts, let me go over what you said here.

winston wrote:

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.

Again my arguement for an upgraded graphics engine, server would be doing a majority of the work, leaving the client machines for graphics.

winston wrote:

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.

I would hope with such an excellent community and a small user base we wouldn't have to worry about hacks as much. As far as user modded ships of course we could not have that but what about an identical version someone can run on their home machine with all the same rules as the server version to test ships, physics, etc. Then those ships can be submitted to the developers who and can what they feel is appropriate. That way in the online version there are only offical approved ships with correct stats and specs.

winston wrote:

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

Well of course I'm not stating launch it tommorrow. But I saying getting a brainstorming sessions started and hey, try it out

My main questions is does Oolite share any code with the original Elite engine or is it a new engine made to look like the old game?

winston wrote:

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

I'm glad someone knows, I have no idea how games are done, but trying to learn more here.

winston wrote:

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).

Wow see now I had no idea about any of that, it's very interesting. So in reality it wasn't really 3D at all. How did that work with multiple ships flaying in different directions.

winston wrote:

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.

Easier is always better

winston wrote:

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!

Ok so what I read was blah, blah, blah but I understand netcode being super important. Thank God that would be left to other people.

winston wrote:

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.

I'm sure most of this is dedicded in Alpha, Beta stages, perhaps even before correct?

winston wrote:

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.

Yes yes unfortunately this is a real problem that would have to be delt with.

winston wrote:

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.

Hmm I disagree here, the whole thing about a MMORPG is "community". I think a small area you described is good. I think astroids and other obstacles for basic collision is good. However I think the FIRST thing that should be honed to a razor edge is the communication ability. Ship to ship communication, ship to station communication.

Making things blow up could come after that IMO.

winston wrote:

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.

I think the trading system could be made even better, but that's a brainstorm for another thread. Yeah the universe would have to be smaller but by the same token could not each star system be a ZONE to load into and out of. The arena could be a whole star system.

Yes it would have to be WAAY smaller, maybe start with it being just the solar system, with realistic distances for a test. I've always wanted Oolite with more than one planet

winston wrote:

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.

I work for godaddy.com, I have my own reseller account which I get a special discount on. I can get a dedicated server with 500 gigs monthly bandwidth, P4 3.0 w HT, 2 gigs of ram, 120 gig hard drive for $1,498.51 for the full year or $166 a month.

Here's a link to our data center - https://www.securepaynet.net/gdshop/hos ... 99&ci=1406

We are the #1 hosting a domain registrar in the world though, trust me our data center is sweet.

I can't see geography being a problem as WoW has a huge european group playing. Alot of MMORPG have US based servers. Again you could start small and see what the needs are. $166 a month is $16 a month for 10 people, I'd be willing to shell out $16 a month for the cause I'm sure 9 other people would as well.

winston wrote:

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.

I don't know I can't see it using more than one server, please correct me if I'm wrong but, if I can run a counterstrike server from a VIRTUAL dedicated server, that is still sharing ram and cpu cycles, how could Oolite which has FAR less geometry to throw around not thrive on a dedicated server with it's own ram and CPU?

As far as the Oolite license, does the engine have any code from Elite, or is it a new engine based on the old game. Call it something different, but make it true to the spirit of Oolite.

winston wrote:

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.

Again we are right on an internet backbone, up and down should not be a problem.

Looking forward to seeing your suggestions, coments, etc.

It would be nice to see a MMORPG of Elite/Oolite, but I can't see it happening.

Besides - I personally would rather see Oolite 'pimped to the max' before thought was given to more versions. A MMORPG development would probably end up taking over everyone's time, and there would be no time left for actually making the single-player game. Plus which there would have to be fully supported multi-platform versions completed and updateable at the same level of ease that Oolite Mac is. It may be a year or so before this happens at the current rate of development, especially on the PC version, which is still in Alpha development.

Besides all this, one simple reason that MMORPG Oolite won't be possible (IMO) is the server hosting and bandwidth costs. In order for a MMORPG server to be set up, someone would have to be shelling out for multi-gigabytes of bandwidth usage plus horrendously expensive dedicated server hosting. You're looking in the region of £2000-3000 per month just for one hosted server. I don't think any of the developers here (or even the community as a whole) could afford that kind of money.

Plus which you would then be asking for financial backing to run an Elite game, which would have Frontier Developments and Old Man Braben knocking on Giles' door with a sledgehammer.

You do put up a good argument, Mr Hanson, but I feel that it's not something that's going to get off the ground in the forseeable future. Sad, but true.

phanson wrote:

My main questions is does Oolite share any code with the original Elite engine or is it a new engine made to look like the old game?
<snip>
Wow see now I had no idea about any of that, it's very interesting. So in reality it wasn't really 3D at all. How did that work with multiple ships flaying in different directions.
<snip>
I can't see geography being a problem as WoW has a huge european group playing.
<snip>
I don't know I can't see it using more than one server, please correct me if I'm wrong but, if I can run a counterstrike server from a VIRTUAL dedicated server, that is still sharing ram and cpu cycles, how could Oolite which has FAR less geometry to throw around not thrive on a dedicated server with it's own ram and CPU?

1. No - Oolite is completely new code. It may share some algorithms though (planet name/description generator, which is really just a fancy pseudo random number generator)
2. Original Elite was 3D, it's just the frame of reference was different - the frame of reference was the player was always at the origin (hence player centric). It was really the only way of doing a 3D game of that magnitude on the hardware of the day.

Now we come to the much more interesting points
The point about lag. WoW is a completely different sort of game to Oolite - Oolite needs network characteristics more like what's needed for a first-person shooter - i.e. low latency. World of Warcraft is more a strategy game and even horrendous ping times aren't really that bad in a more strategically oriented game. Although Oolite isn't a twitch reflex game, when players meet each other in space (particularly if they begin to fight), having a low ping time will be essential.

The reason is this. I get a ping of about 30ms to a server in London. Someone else in France, the UK or Ireland will probably get about the same. So when I hork back on my joystick, 60ms later, the other player will see me do this (the instruction from my client has to go to the server, taking 30ms, and then the server has to tell the other player that my ship has changed course, taking another 30ms). 60ms in human terms isn't very long at all, so the lag will be pretty much unnoticable - and the game experience will be good.

Now let's imagine the server is in Dallas, Texas. I get about 150ms ping to that server. Imagine the other player is in Germany, and gets 170ms ping.

That means now when I hork the stick around, it takes at least 320ms (just over 1/3rd of a second) for my friend in Germany to see it happen. This _is_ noticable by a human being. By the time he shoots, he's shooting at where I used to be, not where I am right now. His client shows him hitting me, but the server doesn't register a hit because by the time the server gets notification of the direction he's firing his laser, I'm no longer actually there - I've gone forward by however far I go in 170ms. Even worse, my client shows me having gone 320ms further. The other trouble with links of this distance going over so many routers (it's around 20 or so hops to get to Dallas from here) that there's considerable jitter in the ping times - one packet may take 150ms, the next might take 200ms, and the next might take 125ms. Or a packet might get dropped altogether, or in a sequence of two packets, the first one get sent might arrive last! There are various techniques you can employ in the netcode to mitigate network jitter and packet loss - but all they do is mitigate it - as Scotty says, you cannae break the laws of physics (part of the increased lag to the US is the much larger number of routers the packet must travel over, each adding to the time it takes for the packet to get there, and part of it is the speed of light - the packet doesn't go line of sight so covers considerably more miles than the straight line distance from here to Dallas - so the speed of light becomes an issue...

To summarize, for a game the style of Oolite, you'd really need a server located on the same continent as you to get a decent combat experience with another player.

As for CPU usage - a virtual server only shares the CPU cycles with the other virtual servers if they are actually doing something - they may well be idle (or just doing something low CPU like serving static web pages or DNS requests). So chances are the gameserver really has the entire CPU to itself most of the time.
The other thing is the M in Massively. Counterstrike isn't massively multiplayer - at most, you'll get around 20 players on one server (if it's anything like TC:E). A massively multiplayer Elite might have 300 battles going on simultaneously, demanding not only a lot of CPU but a lot of network I/O.

I _would_ like to do a (non massively, arena style) multiplayer version of Oolite, but don't hold your breath - I need to learn an awful lot more about the guts of Oolite to even consider doing it.

Selezen wrote:

You're looking in the region of £2000-3000 per month just for one hosted server.

It's not quite THAT bad! (Well, not unless you try and host one in the Isle of Man, grrr). I have 3 dedicated servers (one in Houston, one in Dallas, one in London). The montly cost for all three combined is 180 quid a month. (On the other hand they do make a little bit of pocket money for me too, but not exactly a huge amount, and it's a lot of work!)

winston wrote:

Selezen wrote:

You're looking in the region of £2000-3000 per YEAR just for one hosted server.

Fixed. D'oh!! Sorry 'bout that.

I, for one, never cared much for MMORPG's, primarily due to the problems with cheaters, and dare I say it, "Elitists". The former are merely vermin that upset the gameplay balance. The latter in some ways are worse; whether or not they cheat is irrelevant; they give the noob player a distinct "you're not welcome" vibe.

One aspect of the Oolite "community" that has been a pleasant surprise is that the long-time "Elite"-ranked participants here, up to the author himself, do their best to interact with everyone, including the relative noobs like myself. Any reasonably-asked question or decently-phrased commentary is answered/addressed, and the responses are not uniformily in the RTFM category. I suppose a large part of this can be attributed to the relative maturity of the target audience, many (if not most) of whom graduated from adolesence when the original Elite was current. They've already gone through their l33t phase, and are now truly among the Elite

But I digress. Getting back to the main subject, I can state that my own personal priorities would place network play in general, and certainly MMORPG capability in particular, very low down on the list of priorities for development. If effort were to be devoted to providing multiplayer capability, I'd rather see that effort initially aimed at providing limited local LAN and ad-hoc low player count multiplayer capability. In such an environment, the players are usually known to each other and thus can (usually) be counted on not to cheat; or if they are "cheating", the other players know this ahead of time and accept the consequences. Implementing this sort of limited ad-hoc netplay capability would be something less of a strain on the developers, who could concentrate more on the mechanics of getting netplay to work reliably and well and less effort on developing anti-cheat checks and protections.

SgtSchultz wrote:

Getting back to the main subject, I can state that my own personal priorities would place network play in general, and certainly MMORPG capability in particular, very low down on the list of priorities for development.

I agree with that sentiment also - personally, I'm currently much more interested in having a smooth running game with the features of the OS X game on Linux rather than multi player. And perhaps contributing some new features, such as an advanced combat computer before even thinking about network play!

Firstly, it can be done. Having said that, Vendetta is not open source and has a reasonable number of paying subscribers. AFAIK they have been going a number of years with 4 very smart guys working on it full time. I agree that turning Oolite into a MMORPG is probably not realistic in anything but the very long term, and will almost certainly never happen.

If we remove the 1st M (the one that stands for Massive) then perhaps the task wouldn't be so daunting? Neverwinter Nights only supports 64 players per server, and only 32 with any kind of stability, however the NWN community is very much alive and there are many player-run dedicated servers. Even if I could run a 4 player Oolite server on my cable connection I would be ecstatic, 4 simultaneous connections could support 20 or more players if they are dotted about in different timezones (I accept latency may be a problem). A wise man once said: role play quality decreases as player base increases, perhaps this is even a Good Thing

Of course even this is probably a pipe dream, but I'd hate to see the chance of some kind of networking be discarded just because it can't support 1000s of players.

i have played vendetta for a while. it is very well done and latency is
hardly ever a problem. it has group chat ('im in G-12 come help me!') and
group chat ('yarrrr! drop your cargo and i may let you live').
the vendetta universe consists of some 30 solar systems, connected
by worm holes. you can't just jump from anywhere. you have to fly into
the worm hole. this means that even tho space is really big, youre
likely to run into other players around the worm holes.
the [e|oo]lite universe would probably seem empty even when a substantial
number of players are active.