Networking a Dungeon Crawl

You know, it seems to work :slight_smile:

I’ve just tried a pair of clients in the UK against a server running on a machine we rent in Canada. As you’d expect the TCP connection out there isn’t the fastest or for that matter the most consistent.

With the test client (screenshot here) I can watch the simulations running (red dots), move my player around (yellow dot) and watch other clients move (green dot). I can see the simulation time being displayed, the checksum for the game world and the offset to the server time this client is currently running at (not including the time taken for a message to go from server to client).

The observed behaviour is that the TCP connection is relatively stable though you get odd spikes here and there where the client will get slightly ahead of time (which the algorithm auto adjusts for).

Cooler - I can pause the simulation running locally, let the server run off into the future, let the client get way behind where it should be. On starting the client running again it runs a whole bunch of simulation cycles which allow it to catch up with the other client. Once the client has caught up (close to instant) the commands become as responsive as always.

Seems to be ok - though I guess I won’t know until there are more players, more operating systems, more network traffic and a real game to play :slight_smile:

Kev

Update if anyone’s interested, I’ve got this system running with a real client, AI/Steering for the monsters and interactions from the player (i.e. you can attack and kill the monsters).

So far, so good. I get thes same sort of performance and predicatability as a lock step game. However, when one person lags in the game only they’re effected. One of my testers’ connection to my home machine is very laggy (West Coast US -> UK). The TCP stream can paused for seconds at a time. Once he reaches the lag buffer limit there arn’t any messages available hence he sees lag in the form of his game being frozen (whcih eventually I’ll add a message explaining whats going on) - however, once the connection frees up again the simulation catches up and his game continues.

During this lag period everyone else is free to continue play. Its just their friend might get left behind on the adventure.

I’m still not conviced it is just lag causing the problem (since I’ve never seen a TCP connection that lags for 3-10 seconds) but so far there isn’t another explanation.

I’m also not entirely convinced there isn’t something I’ve missed and this method is going to fail in some ornate way eventually.

Kev

Is he on an analog modem? If so that sounds like a modem retrain pause.

Have him force his moden to connect at a slower speed then he is connecting at now and see if that helps.

Actually, he’s on a cable line :confused:

Kev

Several MMORPG’s do this. It’s usually catastrophic - freiend de-lags in middle of group-only dungeon to find themslef totally outclassed and dead the moment they walk around a corner and meet any monster at all.

Well, since during that pause hes not sending moves either you could attack that be either
(a) makign him temporarily invulnerable
or
(b) making the monsters only target responding players.

As for his friends leavign him behind, if they do that then they arent very good frei nds, are they? :slight_smile:

Which is exactly my thinking! Multiplayer games are about working together… if you don’t, you lose.

Kev

This is looking fantastic…you doing your own art? as usual…I am jealous. :stuck_out_tongue:

Models are sources from the Wc3 community pages which may or may not have some problems with copyright issues. However, once the game is up and running I’d hope to attact an artist.

Thanks for the nice comments MB :slight_smile:

Kev

Interesting outcome - my TCP version was indeed suferred large lag spikes which I believe was down to backoff and resend times in the TCP stack (which I can’t configure from the user API).

So, I went on and implemented a UDP version which ensures inorder delivery of commands - basically the same properties as TCP but no where near as complicated. I get a better granularity of packet control that just turning nagles off, I get to choose back-off values (i.e. I don’t have any - yes, this would screw up a low bandwidth network) and resend times (current a constant). Its given me a smooth stream of commands that arrive in a timely fashion and the lag spikes are no where to be seen.

I think basically that TCP streaming properties are designed to adapt for busy networks by detecting lost packets based on timeouts and then backing off before resending. While this is a great strategy for improving network usage, I’m finding that across a long distance network connection the configuration of the TCP stack isn’t suitable for keeping a consistently smooth stream of information.

I think the UDP vs TCP debate resolution still stands - only implement a streaming UDP protocol when you absolutely have to - I just had to in this case :slight_smile:

Kev

May I ask what may be a dumb question? Classic IO or NIO ?

I’m using classic/normal IO at the moment. I fear change :slight_smile: - or rather I fear the bugs that seem to be associated with NIO atm and since I’m talking 4, maybe 8 players I just don’t see the point in NIO for this.

Kev

I may have to use the same logic, though I am hoping for about 75-100 players. I am ready to put my NIO version on a disk, and toss it in the fireplace. :o

My have to create another version for testing. COuld I see your udp network code? ;D

Sure MB, my whole code base for ASD is available here:

http://bob.newdawnsoftware.com/~kevin/asdsrc

Kev

Thanks, and as usual, wonderfully beautiful code.

the ‘ack’ is simply acknowledgements of receiving commands?

Yep, ack = acknowledgement. However, in this case (like q3 networking) I only need to send an Ack the highest sequence number recieved since all the previously unacked messages are sent in each packet.

Kev

Is it safe to assume that ASD is coded in a fashion so the first player creates the server?

Yep, thats true.

Kev