As any game I'm hoping to make is going to involve some sort of multi-player functionality I decided I needed to look into how this should be implemented very early on. It seems that whether a game is Multi-player heavily influences the structure of the game code.
After doing some searching around I found a popular Networking Library called RakNet. The library seems very well documented which is a massive plus and has lots of added features for things like VOIP.
Okay So I managed to get a simple console application demo up and running quickly. It just allowed the server and client to communicate a simple chat message.
I then wrapped this functionality into some classes so that I would then be able to integrate it easily into the JBEngine. These classes are provided here and can be used as a starting point for anyone else that is starting to implement networking.
There is a working visual studio 2010 demo here. This allows for a two instances of the program to be ran, one as the server and the other as the client. Once the client has connected to the server the client can then send messages to the server which are displayed in the console.
So I then went on to implement this in the Engine which really didn't take much work at all, I simply send a packet to the other computer and they then apply that packet in the game code. Here is a demo using the movement of a player in a game:
After doing some searching around I found a popular Networking Library called RakNet. The library seems very well documented which is a massive plus and has lots of added features for things like VOIP.
Okay So I managed to get a simple console application demo up and running quickly. It just allowed the server and client to communicate a simple chat message.
I then wrapped this functionality into some classes so that I would then be able to integrate it easily into the JBEngine. These classes are provided here and can be used as a starting point for anyone else that is starting to implement networking.
There is a working visual studio 2010 demo here. This allows for a two instances of the program to be ran, one as the server and the other as the client. Once the client has connected to the server the client can then send messages to the server which are displayed in the console.
So I then went on to implement this in the Engine which really didn't take much work at all, I simply send a packet to the other computer and they then apply that packet in the game code. Here is a demo using the movement of a player in a game:
It isn't a great demonstration but It was just the first thing I managed to get up and running. It is also a very simple way of communicating and not how the final implementation will be. In the video every time a movement key is pressed a MoveMessage is sent to the other computer and it moves by that set value. This is essentially a peer to peer model at the moment where as I will be implementing a Server-Client Model in the final product.
Next Few steps are to think about the format of the packets i.e. send a MoveMessage that just triggers the movement and a StopMovement Message, that way there isn't a continuous number of packets being sent to the server to move by a small amount.
Another thing I will need to think about is the difference in packets being sent to or from the server. The ones to the server will more than likely be very minimal and mostly based around input, where as the server will be sending back much more data. The server will need to send every so often a packet to inform the client of the current game state. This is so that the client can correct itself if it has become out of sync because technically the game is only being ran on the server, the client just simulates a possibility until it gets the final word from the server.
Plenty more to think about and implement, but this stuff is pretty exciting.
Keep Coding :)
Next Few steps are to think about the format of the packets i.e. send a MoveMessage that just triggers the movement and a StopMovement Message, that way there isn't a continuous number of packets being sent to the server to move by a small amount.
Another thing I will need to think about is the difference in packets being sent to or from the server. The ones to the server will more than likely be very minimal and mostly based around input, where as the server will be sending back much more data. The server will need to send every so often a packet to inform the client of the current game state. This is so that the client can correct itself if it has become out of sync because technically the game is only being ran on the server, the client just simulates a possibility until it gets the final word from the server.
Plenty more to think about and implement, but this stuff is pretty exciting.
Keep Coding :)
RSS Feed
