Four player udp game, experiences wanted :)

I'm making this bomberman-cloneish game and have the network part kind of up and running, well, the movement and joining/hosting stuff. Client and server is built into the game, so one player hosts the game and joins it, and the other 3 can join whenever they want.

Currently I'm sending a "snapshot" every 10th frame (60fps), which amounts to 10fps. I read somewhere that's what Quake used, so I went with that. Snapshot is very small and contains info on which way the player is pointing, his speed, if he's moving and his x,y coordinates.

The clients only transmit these snapshots if anything's changed, likewise the server only sends out the snapshots to the clients when it's needed. I've also made it so the player movement is smoothed out, so the remote players do not appear jerky on the clients end.

However! I'm thinking this approach may be a bit dated, I don't know. When a player makes a turn (it's viewed from above the playfield, bomberman style), it doesn't always look "neat" on remote clients. Obviously it's due to it only being 10fps packets, but there has to be some clever tricks to make it smoother.

I got the idea of sending snapshots only when something changes, and not every 10 seconds. So if a player moves and stops moving, he will appear to stop moving at the fastest possible moment on remote clients. This will likely take more of a toll on the server, and generate more traffic, but really, shouldn't it be okay with a 4 player game? (I mean, the client sends snapshot if he moves, stops moving, changes direction or anything, server receives it and slams it out to the other clients if it deems it necessary - obviously not always necessary if the client just stopped for 2 frames, but you get my point). Also things such as dropping bombs and other action-related things will also have a package sent from the client to the server, then to the other clients.

I haven't coded the idea yet, but I don't think it will be a problem really. Any thoughts on that?

In any case, I'd like to hear some advice and experiences from some of the old rats here :)

Ps. I know about the security issues as far as sending speed and whatnot, server is verifying that too.

Pps. I haven't gone into deltatiming/other stuff yet. I've worked with delta before, but I'm not exactly a rocketscientist when it comes to math, so the other "fancy" method is pretty unknown to me. Anyone got any ideas here?

Ppps. my snapshots packets are very small, like "101200010231" for one player, but they could be smaller using bytes. I just can't figure out how for instance to something like up to 2000 inside two bytes, I know local mybyte:byte is up to 255, but what's the general rule for using two? Do you just add them or what? I tried searching here for info on byte variables but couldn't really find anything at that simple a level heh.

Pppps. does it really matter that my packets are that small? I read somewhere that minimum packet sizes in for instance windows is like 200b or something..dunno if it's true, I fall asleep reading RFC's.

Hmm, doesn't sound like your packet size is going to be an issue. I don't remember the limit off the top of my head but if you fall under it, windows buffers it with 0's. I beleive the default packet size is defined by the network card driver...


For storing 2000, you use two bytes. basically the first byte is 2000 mod 256 and the second byte is 2000 div 256.

To retreive the value, its simple:

(Byte2*256)+Byte1

:)

60/10 = 6, unless I am missing something. Six frames per second is significantly less than ten frames per second and might have something to do with your perceived performance issues. I can't see the amount of data you're sending being a problem, it seems very small.

You should definitely look into using timing in your game even if it doesn't fix the network issue.

SpaceAce

Check out my bomberman clone, BomberLAN - at my website ( http://www.sergiomarcello.com ). It's really playable in a LAN, and the reason is, only the key informations are sent, that is, when a key is pressed, a coded message is sent, as well as when a key is released.

The rest can be handled by the game itself.

At the beginning of the game, a random seed is generated by the pc hosting the game, and sent to the client, so that everything - from the random walls in the map to the monster movements - is generated randomly using that same seed.

This way you only need a very little amount of data to be sent.

Hope this has sense for you,
Sergio.

Semar uses a good technique but remember to use a custom random function- I'm not sure if its still true in Max, but in Blitz3D, the rand() functions wouldn't always return the same values on different machines.

One thing I do is something I dubbed keyframing. Each game counts how many frames of logic have passed- and clients may vary from this value by N frames (the clients who are ahead of the server wait for the server and all over clients to catch up before continuing).

The higher N is, the larger the lag is but the smoother the game runs. If you are close to the server then 0 or 1 frames are good enough.

Our racer send the positional and orientational data of every object *every frame* (not the best method but it worked) and using it with the above "keyframing", I was able to race with our teammates, who live over in the USA, with a value of 3.

For the technique to work you will need to boot players with a weak internet connection- which is fine by me as it solves lag problems, though it might be annoying to the player. The player who has a weak connection will however, likely experience lag anyway, so its for the best.

*sigh* I want to make a networked demo again. In fact, i'm going to go and think some up. It was great fun! :)

Cygnus, thanks for your info on bytes, very good :) Being math impaired I don't know jack about modulus though.

SpaceAce, haha my math/number blindness skills strike again! Timing aye, it's a must, would be horrible if one of the clients weren't running at 60fps currently :P

Semar, that was my idea, to send keypresses basically. And like I said I'm not sure if it'll be a huge issue with only 4/8 players. The random seed idea is good, just not applicable for my situation, I send out the complete current level to the joining clients.

Cygnus (again hehe), the keyframing idea I like a lot, that will definitely solve some issues in the future, but I'm not 100% sure I understand it completely, perhaps you could elaborate further? I do want to allow players with semi-poor connections/latency to play as well, but that's just a matter of upping the keyframe limit I suppose.

Thank you all very much for your input!!

Should I just go with delta timing or what? I'm not superhappy with having all my timers (I use a lot of them, especially for animation-driven graphics, for instance count up to 10, then draw this new frame, etc.) becoming floats.

Sounds like you got the basic idea. the keyframe can directly correlate with the amount of lag you allow. Basically, each frame your computer counts. the network is updated, and any games too far behind are waited for. after a very small period of time they all synchronise and things speed up.

You can chose to wait for the lagging players frame to catch up, or kick them if they are "repeat offenders". it really depends on the type of game. This is just a technique I tested in a tech demo and I was amazed at how well things worked :)


basically:

Client 1 reaches frame 60, but Client 2 has reached only 57, and the "keyframes" is set to 3, then client 1 will wait for client two to get within 3 frames.

If you know the player has a high latency you can compensate by making increasing keyframe.