Using Pixel Movement w/ Winsock

[Lavos]

Okay before I get started on working on a new gameplay(modgamelogic) I just need information from people who had done this before. Apparently I've done many research over the web, I've been reading results that vary limitations with winsock sending and recieving packets from any player data being sent, correct me if I'm wrong I just think its just due to bad coding practices. The question is why does it have so much issues with lag?

Is there a proper of more efficient way of working with winsock with a pixel based movement and large frame animation? The only solutions I find are to set the structure from the UDT to enumerations and send it off, would this alone be enough?

[Guest]

Player starts moving (or changes direction) > Sends packet to server with direction and speed > The server sends that packet to the map. Each client on the map then loops through the player array, finds someone who's flagged as moving, and moves them on their screen.

[dimx]

> The question is why does it have so much issues with lag?

You need to understand some basic networking fundamentals. A packet is sent from the server to the client in a physical form bit by bit. This packet might travel in a form of electrical, light, or radio wave pulses depending on how far and where you are sending the information. Now if your server is in England and your client is in Australia you will experience latency. This latency is determined by the time it takes the client to send a bit of information to the server depending on the connection speeds and where the packet travels to get to its destination because not all packets will travel in the same path to the destination always and the time it takes for the server to send back a reply.

This time is usually unpredictable if the packet travels great distances because a router might have malfunctioned somewhere or there is high level of traffic because just like real traffic there is internet traffic as well. So lets say in a worst case scenario it takes 1.5 seconds for you to send a packet to the server that you just moved and the server to confirm that just one movement. In 1.5 seconds you might be 10 steps ahead of the server so the server is behind and is trying to catch up this is referred to as lag. Or lets say that packet got corrupt somehow and it never reached the server. The server is not going to know so when it does its check for movement its going to see you are not on the spot where you are supposed to be and its going to try to fix it this might vary depending on how you program it. It might just put you back to the original spot or do something else.

Now there are hundreds of techniques used to mask the latency so if there was a high level of latency or corruption for some reason the player is not going to notice much of it. You are talking about pixel movement in your case the client could be based on pixel movement and the server could be tile based.

You leave the current tile based movement and just make the character on the screen move every pixel. Then you get the players current pixel location and you divide it by 32 because there are 32 pixels in 1 tile depending on the engine if it uses 8, 16 or 32 pixel tile engine. You are going to then round up or down to the nearest whole number depending on the remainder. Then you will check if the player has actually moved enough pixels to be considered that he moved 1 tile in total. If he has then you send the packet just like you would send them now.

This is one way that you can avoid sending information back and forth constantly but like I mentioned above there are thousands different ways you just need to be creative. I might have not explained the above fairly well or have a mistake somewhere so if someone catches something let me know.

> Is there a proper of more efficient way of working with winsock with a pixel based movement and large frame animation?

Large frame animation? not sure what you mean by this but if you are thinking about sprite frames and map objects like a windmill. An easy way is to just store all of the information for the animations like the frame width height and rows and columns in binaries and save it to a file. Then whenever the client starts up it downloads this information from the server and stores it in cache or client side files so you don't need to keep downloading it over and over unless there is a change to it. Once you have the information in the clients memory there is no need to keep asking the server for the animation information because you already have that info. If you make changes force the client to re download and clear old and store new information that is it.

[Lavos]

> -snip-

Okay think I understood what you said, how about this. Lets say my tileset need to be 32x32, I make a complete map with MAX_X = 50, MAX Y = 50, then I write the player movement based on smooth movement moving by 1 pixel at a time when tapping the controls(WASD), would this be an issue on the long run with collision and server performance?

[Vaughan]

> Player Starts Moving (or Changes Direction) > Sends packet to Server with Direction and Speed, The server sends that packet to the map. Each client on the map, then loops through the player array, finds someone who's flagged as moving, and moves them on their screen, rather than receiving the X/Y position from the server every time someone moves.

It's a shame that alone is awful and will cause clipping and all sorts of discrepancy between clients. You'll need some extrapolation / interpolation, dead reckoning and a good prediction algorithm on the side. =) Oh, and a fixed Hz timestep sending periodic waypoints for movement couldn't hurt, either.

[Guest]

> random spouted-out technical terms.

Uh, okay.

[Exception]

> Uh, okay.

Well, he _is_ right.

Combine your suggestion, Vaughn's helpful theory, and render in the past, and you're onto movement that works pretty well synced, regardless of latency.

[dimx]

You collision detection would be the same when you move your pixel movement will be converted into tile movement and then you check if there is a collision there or not on that tile. Pixel collision detection is a little more complex. It also gets even more complex when you want to get a reaction from the collision lets say two object collide and bounce off one another. I am not sure how in depth you want to get into with this right now I assume you are a begginer and thats is why I am trying to explain this as simple as I can.

It all depends on what you are planning to do. I have used this method to make the ship glide smoothly across the map the collision might not be as accurate but playing just with the graphics and current settings you can get it fairly close without doing much work. Here is a little clip showing the movement and at the end you can see the collision and the ship bouncing off as it collides on the side of the map. The sprite is not properly centered so it does look like its not coliding where its supposed to but with a little alignment it will. 

http://www.youtube.com/watch?v=gcYzetz-bAc&feature=youtu.be

[Lavos]

That is really amazing, I manage to get my maps and sprites to scroll and move like that, though looking at collision with events seem to get my writers block. Any ideas on what method i should try to make this work?

[dimx]

Glad you got it working. Not sure what you mean with collision with events. I don't think I am understanding the question. I am not sure what engine you use but the concept would be the same ill do a little pseudo code for you.

If Map(#).Tile(Player(#).PixelLocX / 32, Player(#).PixelLocY / 32).Type = SomeEvent Then

PlayEvent(#)

End if

Let me know if that's is what you meant.

[Lavos]

I think this is what im looking for, I'm going to give this a try. I looks right by the way i see it.