I was pleased to write an article about the net code of Seek & Dread Online (Snd) because the game is relative lagfree for a moogame/mooclick game. If you dont know the game have a look here-> http://www.create-games.com/download.asp?id=5285 first.
This article is intended for people who have already made an online engine and now are troubling how to make it faster and its not intended for nuklear! I wont give you anything to copy/paste or give you a source code I just describe how the net code of Snd works. Well its not the complete net code its just the movement.
At first something general. I would recommand to use mooclick as server and moogame as client, because moogame has the ability to send numbers instead of strings what will speed up your movement engine a bit. Furthermore we dont need a seperator to send something like speed+direction+X_position+Y_position because we parse everything we want with mod or /. For example we want to send the direction and the speed of an object so we send: (directionvalue + 100 * speedvalue). To get afterwards the direction value we parse it like that: (NumberMessage Mod 100) and the speed value: (NumberMessage / 100)
Now we come to the basic of the movement engine. Snd uses the Tigerworks principle for sending movement information that means that only data is send when its really necessary like direction of the player changed, player stopped/started walking. If you dont know exactly what I meant get Tigerworks moogame/mooclick example.
Still we dont have a smooth movement engine because if it lags a bit we see the players jumping so we need to smooth that jumping. Now here comes what Snd does:
Everytime new movement information is received we need to check how far is the player from the original position, if it is too far we leave it by the current jumping movement to not increase the lag. But if its not too far away we move the player pixel by pixel to the new position and as soon the player arrived there the movement starts. Ya youre right that increases the lag so we need to do that better!
To explain that here is a little example:
The player walks to the right and after a while the player goes to the top left, the lag caused a 10 pixel delay. So we dont move the player to the original position that were sent to us. We move the player to original position + the 10 pixel delay. In this case it would be X_original position - 10px and Y_original position - 10px.
That is how the Snd movement works but there is still one important thing. Be sure the sending is reduced to a minimum. Normally if you walk to the right and want to walk to the top left then, the player moves right, top or left and then finally to the top left. So you need to give the control a little delay to prevent that unnecessary sending.
Ya I used Moosock and changed client and server to Moosock. It was much faster but it seems me or Moosock has some serious problem to provide a stable connection. Every 5 minutes the clients got disconnected so I decided to bury that idea.
I see.
Yes there is a problem with MooSock and keeping a stable connection. I dunno if 3ee has any updates comming, but else I expect other extensions to take it's place. When MMF2 comes out all extensions need to be converted anyway, so perhaps it's a good time for an update to the online objects.
Uhm, this doesn't really feel like a clear explanation, lol. Maybe it's just me, but I've made online engines before and totally don't see what you're doing here.
I'm assuming you're moving the objects by sending speed and direction data. However, lag may cause any kind of 'stop' data to arrive late. By that time the object has moved too far. So occasional position updates are sent to make sure all objects are in the correct positions. If it turns out the object's miles out then it jumps instantly. If it's only a little out then it smoothly moves to that position.
After reading what you said Dines, then reading it again. I finally got it properly. It sends data every x seconds, when it needs to (when moving\direction changed). On receiving a message it moves to that co-ordinate (by using some sort of custom movement.), unless the co-ordinate is too far away, in which case it will jump.
The data is sent infrequently, so if the player makes rapid movements, for example in a zig zag movement, then these are not interpreted. In effect it makes the player 'cut corners'.
Advertisement
.
.
