Network multiplayer game advice needed.

Hi all

Hope someone can help me with this, I’ve been playing around with the Lidgren library recently and got a basic understanding of using it and sending “commands” between client and server. Now my next issue comes to Design - how & when to send information etc. Let me give you an example of a game, and what I need is advice on what information I need to send back and forth, what is worked out on the clients only etc.

OK, very basic game design - remember the game space invaders from the early days? now, turn that basic game into a 2 player game, where both players are moving the defender objects at the bottom of the screen and shooting up (at the same time), you have the invaders going left/right, the odd mother ship flying across the screen at the top, the defence bunkers that take damage. It’s all action and fast past (vs a turn based game)

Now my idea is to build into the game (same application) a connection screen & a lobby, one of the players will be the SERVER and the other player would join, then the game will launch - so basically player one will have a ping of zero to the server, since it’s the same machine/application, the other player could have a greater ping due to his location (say other side of our world).

Now since the host is both client and server I would need to store duplicate lists of objects, e.g. list of players the “player” knows about, and a list of players the server know about - when the server sends player information out to the players, the player list would get updated - sort of a client area & server area namespaces.

As for the rest of the information, how much info can you really send every update every 16ms (for 60 fps) can the server constantly send out the invader locations, the bullets, the movement, player scores, mother ship etc.

Any advice will be most helpful - or sample games if you’ve done something like this already I would welcome the code to look at.

Thanks again for any help / pointers.

EDIT - Just thought of something else - MOUSE - think of the game Missile Defence where the player moves the mouse and shoots the missiles - now what I want to do is have the turrets rotate at the bottom to point in the direction of the mouse location on screen - Great one player easy, no problem - but MULITIPLAYER - player two needs to see what direction player one is facing - so the mouse move location needs to be sent to the server constantly and out to the players (e.g. ever 16ms/update) it’s this sort of thing I’m worried about.

Being that its lidgren, its basing UDP… which sure it can do all that, but consistency on the timing is something that may or may not be an issue especially the more connections you try to maintain.

Thanks for the quick reply, so basically just do it and see what happens, I’m not looking at massive multiplayer games, maybe 2-4 players. As for UDP / TCP - I know they are protocols, but not really sure of the difference each would make Lidgren is just UDP, or what they can handle.

I’ll think about my current game idea and what needs to be transferred back/fourth and try and keep it as small as possible, but I can see it being a lot of information as things will be constantly updating on screen.

UDP sends data out and usually is used when you dont care if “all” the packets make it out… Lidgren however does some pretty screwy stuff to make sure the other end got the data which meens a good few packets are sent back and forth just to count the 1… UDP can also have more issues when the distance of the servers between host and client are farther apart… TCP is more direct with some better security out of the box, but on large scale can end up being really slow(In your case since you intend on it being small it wouldnt be bad to go with TCP if you know anything about setting it up)

On a side note: When you are trying to send locations, instead of such rapid updates you can try and send booleans and floats, the boolean being “if moving” and the float for “the direction” and make a algorithm to calculate what position it should be at reletively and send out updates much less often(would give much better results even with a bad network or connection)

Alternatively if you would LIKE a free TCP based network to use(Comes with examples in C# and with some good cut and paste code to get started really quick and is simple to use and setup) I made a library with the help of a couple of guys like me who often study low level code/langs… Ive also had the help of a guy who teaches C at a college who helped ensure quality on it :wink: (lib is open source too)

It does include UDP but without Upnp hole punching hacks and autoportforwarding methods used in Lidgren… (This would require users manually port forward if using the UDP in the lib)

@SpiceyWolf Many thanks for the responses and the offer of your library, much appreciated. I’ll try and get Lidgren working and see how it goes, if things don’t go as planned I’ll come back and ask you about the TCP library.

When I get around to looking at what actual information I need to transfer I’ll keep the “don’t care if all packets make it out” in mind - I’ve seen the parameter for this in the example code I’ve been playing with - so e.g. the mouse cursor position could be set to this.


ok, just a heads up, if you decide u need it you can just search SpiceyWolf on github to find my upload of it. Its called ArchaicNet

Great, thanks - I’ve downloaded this and will take a better look later, at first glad it does look easy to use. You mention that on a large scale TCP could be slow, so is it better to go with UDP?

UDP is better for fast paced games like yours. TCP just provides a reliable connection meaning it will get packets to the other side in the right order, but it they might arrive late because it was lost or some need to be dropped because they are out of order. If a packet is lost once, it’s no longer relevant because the time it had information on has already passed. UDP is best effort, it will not resend packets automatically so you’ll want to account for losses, but not jut resend the same packet in most cases :slight_smile:

General rule: TCP if packets HAVE to make it. UDP if packets dont always have to make it.

The reason i say TCP could be slow on large scale is because when the network traffic becomes heavier then guarenteeing a secure connection and packet flow requires alot more CPU whereas UDP expects to send it and be done with it -> UDP is connectionless so it doesnt have the extra work on maintaining connections and active flow/checks that packets and connections are still existing.

on a small scale project that doesnt expect alot of players you could use the UDP, but with TCP it should be good enough performance there even for fast paced games.

On a larger scale game you would want to maintain a good balance between both so you can maintain packets that have to be ensured with the least amount of time/effort and also be able to send out like Jjagg said fast with irrelevance if some packets are dropped because its no longer relevant.

Sorry for such a late reply, I dont stay on websites for such long periods of time unless i need a response for something as my internet is garbage…

If you have any questions for me (that need more immediate response) you can reach me at

Hi, Many thanks for taking the time to respond, there is no rush as it’s mainly information gathering at the moment and researching. The responses have helped a lot.

Now I just need to get cracking on and see what I can do in actual code. What I’m thinking about is having a few screens in monogame where 1st screen is the “connection” screen where you can either host the server or join a server, the 2nd screen being the Lobby, where the host can see all the players connected and when all ready, the 3rd screen will be the game.

I’ve managed to find this code (below) called syzygy, it’s not monogame, (not sure what it uses), but it uses winforms for the 2 screens I mentioned, so going to take a look at that to see how it all works.

Alternately - create a separate console application to be the server rather than in bed it into the same monogame application.

If u use my network keep in mind that i gotta fix the UDP(if you need it), i didnt know there was a method of using it where only the server needed to port forward(without Upnp hax) -> i developed the UDP on my own about a week ago so that will need tweaked soon.

Thanks spiceywolf will keep that in mind.

As for more about game advice, I’ve been looking at the code supplied with the below video. So far I’m use to the “Game1” class with in monogame and using the update/draw function which are automatically fired by the framework to update my game data etc. Now I’m looking at MP system it looks like I need to look at the system from a different angle regarding updating moves, collision detection etc.

The developer creates a “GameRoom” class on the server for the players, and I’ve noticed he has a while true loop which uses a timer to update the game (e.g movement, bullets move etc) (code pasted below)

Is this way of “updating” the game the normal way to go for a MP game where a server application is used?

Thanks again.

		private void Update()
			var lastIterationTime = DateTime.Now;
			var stepSize = TimeSpan.FromMilliseconds(16);
			while (true)
				if (_cancellationTokenSource.IsCancellationRequested)

				while (lastIterationTime + stepSize < DateTime.Now)
					switch (_roomState)
						case RoomState.WaitForPlayer:
						case RoomState.Run:
							throw new ArgumentOutOfRangeException();
					lastIterationTime += stepSize;

generally yeah, thats a common way to handle updating logic for a game(on the server side) though since that is using a while(true) --(i havent watched the video dont really have the net for it)-- i wouldnt recommend doing it on the same thread that the game is going on if you run it out of the same application the game is specificly being played on.

Great thanks, Since posting that I’ve done a bit more investigation on this and have come up with the following.

  1. Server app is a WinForm application. - with a start/stop button (also lists clients connected etc).
  2. Clicking start starts the server in a NEW thread - so the UI can still run. The server when start has a similar loop for checking the net messages incoming.
  3. The server app has a List of “GameRooms” (one of which is the lobby).
  4. When a client joins they go into the lobby, from the lobby the client can create a new room.
  5. When the server gets the create new room command a new GameRoom is created, this then has it’s OWN while(true) loop - but the server sets the game room in another new thread. So every game room runs in its own thread.

The server thread controls ALL incoming messages (even the game ones (fire, move, etc)). The server will know which “client” sent the “fire command” so will find which game room that client is in and then push the command to the game room queue for processing in it’s updates.

The Gameroom threads will control the “Updates()” etc and sends out the new positions etc.