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:

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 :)

Since last post I have been working on the parsing of entity instances from XML just like how it does for the Assets. This did bring up some interesting questions about entity communication and caused a fair few changes. Currently in XML there are a pair of <Entity> tags inside which there are a number of <Component> or <DataComponent> Tags. These in essence define what the entity is which is really generic and great for re-usability.

The problem is that a lot of entities need to send messages to specific other entities for example a lot of entities may want to know the players ID to send messages specifically for that entity. Previously the Entity ID's were just unsigned int values that were generated when an Entity was created, which made it impossible to know which entity was the player unless the order stayed the same. 

To overcome this I have now changed the Entity ID system to be a little more flexible, initially an Entity has an EntityType and an EntityName. An example of this could be "GUI" and "StatsBar", this along with the original unique ID now combine to make a unique ID such as "GUIStatsBar34". I know what you're thinking: "But that doesn't overcome the not knowing the player ID problem". Okay so to overcome this, you can either provide Entity Type and Entity Name or specify the Unique ID yourself. So for the player the UniqueID is "MainPlayerID". 

This overcomes the issue of knowing a specific entities ID and also gives some better debugging information. Previously an Entity would have an ID of 37 and I would have to guess what it was from the Components and Data Components that it had. Now I can just look at the ID and it should give me some hint as to the object I am dealing with.

Okay so not much to show this time but there has been quite a bit of work behind the scenes. Next few things on the cards are to get the networking aspect of the engine setup before going much further, especially as this may involve some changes to the messaging system and general game architecture. 

Happy Coding :)

Today I made my first development tool to go alongside the engine. To be honest it was more something to make my life a little easier. As the JBEngine uses an Entity Component System I found that I was having to create a lot of classes for these components which to start off with all have the same signature. This meant I was copying and pasting a component and changing the class names A LOT!

So now I have the JBEngine Component Creator (JBCC). It is just a simple WinForms application to generate a component class with a specified name and a priority value that is assigned to each class.

Okay so it is pretty basic but I thought it was worth noting, seen as it will probably be the first of many development tools that will be created alongside the JBEngine. 

I have also started work on the Entity XML Parsing so I should hopefully have this done shortly.

Happy Coding :)