• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Help Me Understand Networking, Please!

R

Robert

Guest
Hello, I'll try and keep my questions short, so please bare with me. When it comes to writing network code I am still trying to wrap my head around some of the basic things. Reading through the networking documentation in the manual and a couple tutorials has helped a lot and when it comes to buffers and the actual mechanics to sending data over the server I pretty much got the basics down. However, I am still trying to understand some fundamental things about network coding for me to really start working with it.

1) Local Co-Op, how does this work? Is this done by also using the network async event and the network functions?

2) Should the client and server be two different applications? So when a player goes to start a new hosted game then the current running game (the client) would launch the server application (a totally different application on the computer)? Or should they be bundled into the same application?

3) Lets say I have two players in a game and one shoots a bullet. Should I then have the bullet object send a packet every step to the server with its position details so that it can be drawn back on the clients applications, or should I instead just send the bullets direction and speed once on create and then have the clients application motion_set() the object? In terms of efficiency I would think just send the pos and dir on create, but then I feel like that could lead to problems.

4) Lag. I haven't done much yet with networking in GM aside from some simple demos and tutorials so I havne't been able to really test how good works. However I did try the GM Net package from the market place and while it worked pretty well I noticed some rather bad lagging. This was also playing over my local network so I feel like it really shouldn't of had any lag and I am worried that at it's core it might be just that GM doesn't have good networking support. So, my question is, should I expect large spikes and frequent lagging or could this just be from how the default GM Net demos not being optimized properly or efficiently?
 

Binsk

Member
I am unfamiliar with GameMaker's specific multi-player features ever since they switched the system, but I think I can cover a little of your questions nonetheless.

1. By this I assume you mean connections within the same network. It is handled the same way as it would be over a global network. Admittedly things like port-forwarding and whatnot can come into play over a global connection, but that is less a matter of your programming and more a matter of the user's / server's network setup. The only real difference you will account for, I believe, would be which IP address you use; internal vs external.

2. It depends on how you want to program your game. You can even take a look at Minecraft. You can run both the client and the server from the same program while alternatively there is a dedicated server application as well. Not to say that you should program your game this way, but that is a far example of a game that uses both methods. I would not however advise requiring a separate server application to run on the same machine where a user will be playing a game. I would say either plan for a dedicated server if you use a separate application, or integrate it into the same application if that person will be playing as well. This is just my opinion though.

3. Rule of thumb: Use as little data as possible on the network and keep the player's synchronization as perfectly matched as possible. It is possible to flood the network and / or the game with too much data and sending updates every frame could certainly cause this. This is especially true if you have several or more players and / or are doing this for multiple in-game instances.

4. I cannot speak for GameMaker's system nor the extension so I don't know how helpful my note here will be. You will always have lag. Always. It really comes down to sending data efficiently and, just if not more importantly, handling the received data intelligently. You will have to work the system to make the lag as unnoticeable as possible, it will never be a "plug-and-play" system where you just easily pass data back and forth and plug it in to your instances.

An example taken from your above post. Let's assume that your system could handle updating the bullet position every frame like you proposed. In any case of a lag-spike and / or client drop-out the bullet will stop moving. This can bring about frozen instances and / or jumpy bullets. If you just sent the direction and speed then the bullet would keep moving regardless since it is then being updated by the client's computer. This is just a small comparison of how a small decision can make a big difference towards lag.

Anyway, I don't actually have a lot of experience with the strategy behind networking since that is not one of the areas I tend to target. Still, I hope you find my post useful. Good luck with your projects.
 
R

Robert

Guest
I am unfamiliar with GameMaker's specific multi-player features ever since they switched the system, but I think I can cover a little of your questions nonetheless.

1. By this I assume you mean connections within the same network. It is handled the same way as it would be over a global network. Admittedly things like port-forwarding and whatnot can come into play over a global connection, but that is less a matter of your programming and more a matter of the user's / server's network setup. The only real difference you will account for, I believe, would be which IP address you use; internal vs external.

2. It depends on how you want to program your game. You can even take a look at Minecraft. You can run both the client and the server from the same program while alternatively there is a dedicated server application as well. Not to say that you should program your game this way, but that is a far example of a game that uses both methods. I would not however advise requiring a separate server application to run on the same machine where a user will be playing a game. I would say either plan for a dedicated server if you use a separate application, or integrate it into the same application if that person will be playing as well. This is just my opinion though.

3. Rule of thumb: Use as little data as possible on the network and keep the player's synchronization as perfectly matched as possible. It is possible to flood the network and / or the game with too much data and sending updates every frame could certainly cause this. This is especially true if you have several or more players and / or are doing this for multiple in-game instances.

4. I cannot speak for GameMaker's system nor the extension so I don't know how helpful my note here will be. You will always have lag. Always. It really comes down to sending data efficiently and, just if not more importantly, handling the received data intelligently. You will have to work the system to make the lag as unnoticeable as possible, it will never be a "plug-and-play" system where you just easily pass data back and forth and plug it in to your instances.

An example taken from your above post. Let's assume that your system could handle updating the bullet position every frame like you proposed. In any case of a lag-spike and / or client drop-out the bullet will stop moving. This can bring about frozen instances and / or jumpy bullets. If you just sent the direction and speed then the bullet would keep moving regardless since it is then being updated by the client's computer. This is just a small comparison of how a small decision can make a big difference towards lag.

Anyway, I don't actually have a lot of experience with the strategy behind networking since that is not one of the areas I tend to target. Still, I hope you find my post useful. Good luck with your projects.
Thank you so so much! Thinking even more about this I am now wondering if I should instead just be sending some arbitrary script id and args on specific system events. So back to the shooting example, when a player attacks rather than sending the direction and speed of the bullet to the server I instead send the shooting script and the calling object to the server instead. So when the client gets the packet they just execute the script with the arguments, which could be for shooting, walking, or whatever.

Anyways I am still having a hard time understanding where I should execute certain things. So I get that if you have 2 people connected to the server that each one sends the details about their players position and information to the server independently and then the server sends that back out to the connected clients. But who sends out the information about the enemy ai and the environment data? Is that the servers duty to generate and send out that data? So on the 2 connected players computers they both just get details about the position and action of an enemy, the actual execution of the enemy ai logic is done by the server?
 

Binsk

Member
Again, it depends on how you want to program it. If you have a dedicated server where no player acts as the host, then it would be logical to give the server control of enemy instances and the like because the players aren't communicating directly.

Alternatively, you can just make one of the players the host and that player's machine is responsible for updating the world; thus you remove the need for an extra machine and executable. If you have never programmed multiplayer before, I would personally recommend this method as it is significantly more simple in my opinion.

Often there will be an external server that merely provides match-making so players don't need to know eachother's IP addresses. Once the match is made, the players connect directly to each-other and one is assigned as the host. This way you still have the direct communication without the middle-man while also being able to match people up easily. Still, this requires an extra machine and program just like the first method (but I think is a bit easier).

Any one of these three methods are doable. It just depends on what you want for your game.
 
Top