oolite-multiplayer

[cybertiger]

I don't have enough free time for this, but I'll do my best to write a multi player patch for the game.

I'm not planning on adding any new features to the game in the process, I'm just going to take the physics engine split it into a client and server version, and write the appropriate networking code to get the two to talk to each other over a LAN and hopefully over the internet (bandwidth/latency permitting).

If all goes well I'll have a nice big patch to contribute to the project (if the maintainers want it).

The alternative is I'll have a lot of broken code and nothing will work (much more likely).

Wish me luck

-CT

[Hoopy]

Are you thinking it'll be a case of:

• start oolite
  select multiplayer
  exit witchspace to find it full of other people

I guess you do it out of system so there's no station and give everyone a cobra 3, a beam laser and no fuel?

cool

edit - that's not how the list command works on this board then... hmm...

[cybertiger]

Are you thinking it'll be a case of:

• start oolite
  select multiplayer
  exit witchspace to find it full of other people

I guess you do it out of system so there's no station and give everyone a cobra 3, a beam laser and no fuel?

cool

edit - that's not how the list command works on this board then... hmm...

Was thinking more along the lines of:

• Someone somewhere runs a server (command line program).
• User runs Oolite.
• User selects [multiplayer]
• User types in a servername and clicks [connect]
• User types in username and password.
• User clicks [connect]
• User is suddenly in a ship, either docked or in space (where ever they last left it).
• User can fly around and shoot at other users who are currently logged in. (Other modes of interactions like sending messages will be dealt with later).
• When user logs out their ship and items are saved on the server until they return (leaving your ships in space might not be a good idea though).

If you want an Elite type multiplayer skirmish mode, you might as well find a copy of netwars (which came with opendos) and figure out how to run it on modern hardware.

[Hoopy]

Your approach sounds more complex than mine. I was just thinking of the easiest way to get it started and sidestepping a load of potential problems, for example:
- There's also the issue of someone turning up in an uber ship and being far too powerful
- The other players not having the OXP for that ship installed
- People with lots of money buying loads of energy bombs
etc

[cybertiger]

Your approach sounds more complex than mine. I was just thinking of the easiest way to get it started and sidestepping a load of potential problems, for example:
- There's also the issue of someone turning up in an uber ship and being far too powerful
- The other players not having the OXP for that ship installed
- People with lots of money buying loads of energy bombs
etc

Your first and second points would also affect your simplified example, and in my design would be solved trivially by the server telling clients the OXPs they are expected to use when they connect. At a later point you would add automatic download of OXPs (but not in the first version).

Your third point would be fixed by players creating their own OXPs which balance things for multiple players, Oolite is a single player game, it would be naive to expect it not to have balance problems if you added support for multiple players.

[Kaks]

This is kind of obvious, really, but probably the best way to avoid oxp problems - in the first version of multiplayer at least - would be to tell oolite to ignore all oxps! I was going to suggest ignoring the AddOns directory altogether, but if someone overrides oolite's log controls & - more importantly - key bindings, they'd do it by adding custom plists to the AddOns\Config directory.

Hmmm, perhaps adding a MultiplayerAddOns directory, and having oolite switch between the two addons directories depending on whether it's in multiplayer or not would be the cleanest way to avoid major headaches in the future... (I'd copy the contents of AddOns\Config inside MultiplayerAddOns\Config beforehand)

Anyway, I just wanted to say good luck!

[cybertiger]

I'm currently stuck on the most basic of things anyway - checkout subversion and compile from the source code, seems to be failing because of a missing include in spidermonkey (jsautocfg.h) using the debian install scripts.

Can't break things if I can't compile it

I have a question if any coders can answer this...

I'm developing on Linux, obviously any code I write has to work on other operating systems.

What network library should I use? My current thinking is to use the Apache Portable Runtime, as it's free and cross platform (writing networking code using #ifdef is sodding painful, been there, done that, got the t-shirt, have no plans to do it again).

It's my understanding you can use C libraries from Objective C, is this correct ? (I know very little Objective C, however I probably fit in the guru category when it comes to Java and I know enough C to write simple multiplayer opengl applications).

The only problem with APR is the damn thing is huge and includes a whole host of other functions which fit firmly in the category "do not want".

Edit: SDL_net whilst being the obvious choice is not usable because it does not provide non blocking io functions.

[another_commander]

Warning: Writing from memory, what follows is best to be doublechecked for correcteness. Anyway:

For Linux you must use Makefile.in to build. Is this what you were using? The file called makefile in the SpiderMonkey folder is Windows specific. The jsautocfg.h is created as part of the build process.

And regarding the question about C/ObjC libraries, yes you can use C libraries from ObjC.

[cybertiger]

Warning: Writing from memory, what follows is best to be doublechecked for correcteness. Anyway:

For Linux you must use Makefile.in to build. Is this what you were using? The file called makefile in the SpiderMonkey folder is Windows specific. The jsautocfg.h is created as part of the build process.

I was using "dpkg-buildpackage" - README.txt says that debian (and I'm assuming ubuntu since it's based off debian) users should use this.

I'm trying to compile from a subversion checkout rather than a source distribution because it makes developing easier and allows me to keep up to date with any changes the devs make assuming they don't collide too badly with my code, it also allows me to generate patches which could be imported by someone with commit access

It's definitely using the includes from

Code: Select all

deps/Cross-platform-deps/SpiderMonkey/js/src/*

As the error messages I currently get point at files in this directory rather than the jsapi headers on my system.

Using make doesn't fix anything, as the dpkg-build thingy just calls the make script.

[cybertiger]

I fixed the make file, here's the diff, my "fix" is a hack and is probably not portable to macos (or heaven forbid win32). It would be better to change the includes to #include <mozjs/jsapi.h> in the oolite source, then the extra include directory would not be needed on linux. I don't know about the locations of the include files on mac os though.

Code: Select all

Index: GNUmakefile
===================================================================
--- GNUmakefile (revision 1515)
+++ GNUmakefile (working copy)
@@ -17,11 +17,11 @@
 endif
        oolite_LIB_DIRS += -L/usr/local/lib -L$(GNUSTEP_LOCAL_ROOT)/lib -Ldeps/Windows-x86-deps/lib
 else
-       ADDITIONAL_INCLUDE_DIRS = -Ideps/Cross-platform-deps/SpiderMonkey/js/src  -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug
-       ADDITIONAL_OBJC_LIBS = -lpng -ljs -lGLU -lGL -lSDL -lpthread -lSDL_mixer -lgnustep-base
+       ADDITIONAL_INCLUDE_DIRS = -I/usr/include/mozjs -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug
+       ADDITIONAL_OBJC_LIBS = -lpng -lGLU -lGL -lSDL -lpthread -lSDL_mixer -lgnustep-base -lmozjs
        ADDITIONAL_CFLAGS = -DLINUX -DNEED_STRLCPY `sdl-config --cflags`
        ADDITIONAL_OBJCFLAGS = -std=c99 -DLOADSAVEGUI -DLINUX -DXP_UNIX -Wno-import `sdl-config --cflags`
-       oolite_LIB_DIRS += -Ldeps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ -L/usr/X11R6/lib/
+#      oolite_LIB_DIRS += -Ldeps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ -L/usr/X11R6/lib/
 endif
 OBJC_PROGRAM_NAME = oolite

Edit: (fail) It compiles and installs, however it does not run because of a runtime incompatability between spidermonkey and oolite. I guess there's a good reason oolite compiles in it's own version of spidermonkey.

[JensAyton]

Edit: (fail) It compiles and installs, however it does not run because of a runtime incompatability between spidermonkey and oolite. I guess there's a good reason oolite compiles in it's own version of spidermonkey.

Yep! :-)

(Oh, and when Firefox 3 comes out, there’ll be various bits of fun in upgrading to the new version…)

As for networking libraries, I’d suggest looking at the NSStream classes, which provide an Objective-C wrapper for native networking and are part of a dependency Oolite already has. (NSStream is used in OODebugTCPConsoleClient.)

[cybertiger]

Alright, progress.

• Compile SpiderMonkey:

  Code: Select all

  cd deps/Cross-platform-deps/SpiderMonkey/js/src/
  make -f Makefile.ref
  rm Linux_All_DBG.OBJ/libjs.so
  cd ~-

  Note: you need to delete the shared object to force it to be statically linked, if you dynamically link it on running oolite you'll get an error about a missing libjs.so.
• Make a minor edit to GNUmakefile

  Code: Select all

  Index: GNUmakefile
  ===================================================================
  --- GNUmakefile (revision 1517)
  +++ GNUmakefile (working copy)
  @@ -17,7 +17,7 @@
   endif
          oolite_LIB_DIRS += -L/usr/local/lib -L$(GNUSTEP_LOCAL_ROOT)/lib -Ldeps/Windows-x86-deps/lib
   else
  -       ADDITIONAL_INCLUDE_DIRS = -Ideps/Cross-platform-deps/SpiderMonkey/js/src  -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug
  +       ADDITIONAL_INCLUDE_DIRS = -Ideps/Cross-platform-deps/SpiderMonkey/js/src -Ideps/Cross-platform-deps/SpiderMonkey/js/src/Linux_All_DBG.OBJ -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug
          ADDITIONAL_OBJC_LIBS = -lpng -ljs -lGLU -lGL -lSDL -lpthread -lSDL_mixer -lgnustep-base
          ADDITIONAL_CFLAGS = -DLINUX -DNEED_STRLCPY `sdl-config --cflags`
          ADDITIONAL_OBJCFLAGS = -std=c99 -DLOADSAVEGUI -DLINUX -DXP_UNIX -Wno-import `sdl-config --cflags`
  

Don't worry, it still doesn't work for me, I get the following error which I'm working on (I just like spamming a bulletin board, just in case anyone feels like helping, and it might always come in useful for anyone else who wants to use the source).

Code: Select all

2008-03-27 02:20:19.468 oolite[12187] [ship.sanityCheck.failed]: Ship <PlayerEntity 0x87ad5d8>{"(nil)" ID: 0 position: (0, 0, 0) scanClass: CLASS_NOT_SET status: STATUS_IN_FLIGHT} generated with infinite top speed!
Assertion failure: (fs->extra & 0xFFFF0000) == 0, at jsapi.c:3693
Trace/breakpoint trap (core dumped)

Edit: Fixed the above bug, I was compiling using the wrong jsautocfg.h, which meant a C structure had a couple of different definitions depending on who you asked, I've tweaked the GNUmakefile diff, it now compiles and runs for me

[cybertiger]

Yep!

(Oh, and when Firefox 3 comes out, there’ll be various bits of fun in upgrading to the new version…)

To be honest my first instinct with regards JavaScript is "why?", what's up with Lua or Python (both of which are used in many commercial games as scripting languages, and both provide stable dynamic libraries you can link against without the maintenance overhead of linking against a moving target like javascript). I realise it's probably far too late to do anything about it now and there are probably good reasons for using JavaScript (many people know it for starters).

As for networking libraries, I’d suggest looking at the NSStream classes, which provide an Objective-C wrapper for native networking and are part of a dependency Oolite already has. (NSStream is used in OODebugTCPConsoleClient.)

Wow, nice API. Unfortunately my cursory glance over the API could not find one important feature; UDP sockets.

I intend to use a dual tcp/udp protocol, because for some of the server<->client messages you do not care if they get lost along the way, all you care about is their timely arrival, for instance, for every non computer controlled entity in space the server needs to constantly update all clients with the position and velocity of every one of these many times a second. It's possible to do it with a pure TCP protocol but it will be susceptible to lag spikes even at very low levels of packet loss between the client and server.

Don't expect it to be really low bandwidth, because adding networking is an after thought I'll be stuck with design decisions made when there was no networking, this will almost certainly inflate the size of the packets I need to send.

Another thing that counts against me is that the control mechanism is 'twitchy' and fairly high bandwidth. Bandwidth usage scales proportionally to the square of the number of people in the area multiplied by the bandwidth of the control mechanism. (this is why most mmorpgs have fairly low bandwidth control mechanisms and discourage players from congregating in large numbers in a small area). I have to say I always preferred multiplayer games with twitchy control mechanisms though, so I'm not complaining

[JensAyton]

o be honest my first instinct with regards JavaScript is "why?", what's up with Lua or Python (both of which are used in many commercial games as scripting languages, and both provide stable dynamic libraries you can link against without the maintenance overhead of linking against a moving target like javascript). I realise it's probably far too late to do anything about it now and there are probably good reasons for using JavaScript (many people know it for starters).

Mine too. The basic reason is that support for a real scripting language happened because someone (dajt) chose a language and ran with it. The choice was based on issues like portability and working Unicode support (not that Oolite lives up to the latter). It also turns out to be a surprisingly nice language (once you shrug off the influence of the web and all those people who “know” it), and some time next year we should be able to switch to a JIT compiler reasonably painlessly, which is a nice bonus.

[cnikiel]

Hi Cybertiger,
have you made any progress in getting the network multiplayer code working?
I have been thinking about some multiplayer code myself and would like to know if there might be any way of joining the effort.
Best regards,
CarsteN