Last night I managed to get the Raknet Libraries built in Vis 2013 and I now use the DLL instead of the static library. I've removed the CPP files from the JBengine source control as I think it is a bit unnecessary. 

I also messed around with a hell of a lot of visual studio's project settings, which was a nightmare but I think everything is set up a little better now. All my libraries output the correct /MD /MDd version depending on Configuration, and they also all link with their own correct versions respectively. i.e. Release JBEngine Links to Release Renderer Library. 

I still have a load of LNK4098: defaultlib "library" conflicts with use of other libs; use /NODEFAULTLIB:library. This is because of the use of different C Runtime libraries in the 3rd Party libraries I use. I don't really want to start rebuilding every 3rd party library I use because that would take a lot of time and I'm not even sure I still have the code for these. 

I have thought whilst doing all this that I am going to convert all my libraries to DLL's rather than static libraries. I am hoping this will help in a couple of ways:

1. I hope that this will narrow down the LNK4098 errors to just the projects that the library is included in. e.g. if the RakNet Library was built with a different CRT libs then it would only show in the Networking linking and not in any projects that use the Networking DLL. (if that makes sense) 

2. It's then easier to ship the DLL's for use with other programs.

Still need to try this out and see if it does what is expected.

Cheers.

Okay so last time I tried way too much and ended up just having a project that I couldn't run and did absolutely nothing. This time I thought first thing I would do is make sure that I can convert my 2010 JBEngine solution into a 2013 version. This brought quite a few problems:

First of all there were issues with me having used NULL instead of nullptr's for the std::function objects I've used in a couple of places. This was fairly straight forward. 

The next thing that hit me and set me back a little is that I was getting a LNK2038 error because of the 3rd Party Networking library I was using (RakNet). This error basically meant that It was compiled in a Visual Studio Version that wasn't compatible. 

So I had to download the source and re-compile it in Vis 2013. A bit of a pain but it needed doing. Also whilst I'm doing this I am going to have a look through and make sure I create as many of the libraries as I can and link with them where needed. i.e. MTd, Mt and also the dll version. I think using the dll version would be more beneficial but I had this idea in my head about shipping my "Engine" as one binary but in terms of flexibility and general ease I will probably use the dll instead to avoid this happening again.

Another added note is that I'm going to keep hold of the source so that I can use it to make the Linux library when it comes time to doing cross platform development. 

One final annoyance was that the project wouldn't seem to build because Vis couldn't find rc.exe so after copying and pasting it to the correct path It all started working. ( Only took an hour or so! )

Okay so yesterday my motherboard and CPU arrived and I was really excited so I went and bought a little set of tools so I could get cracking on it when I got home. My thinking was, I don't need to bother buying RAM yet I can just stick my old RAM in for now and I will make do with 4gb. I had forgotten that my current desktop was over 7 years old now and only had DDR2 RAM.. Well done Jordan!

So I have a new Mobo and CPU sat in the corner of my room until I have the money to dish out for the RAM. The only positive I have taken away from this is that I hadn't actually started taking anything apart before realising this.

Okay so next on the cards is to finish off these library bits and pieces and then get it all checked in to git. I will then look at my new messaging implementation and try and get that integrated into the engine. This is sort of phase 1 of the new ECS Integration.

Cheers :)

It has been what seems like an age since my last post, and I have been holding off because I wanted to get something a little more substantial before I posted an update. 

I have been working mostly on the Networking but also sorting out some issues that I was having with my matrices due to the library I am using ( which I ended up writing some of the functions myself ). This means that now my FPS Camera is fully working which is a massive relief.

Now that I have got that out the way let's talk about some of the Networking I have been doing. As a starter I suppose it is best to mention that I created all this networking code as a separate library that is used by my Engine. This took a little bit of refactoring and some tinkering with the Visual Studio Project options but was a great learning curve as it has made me think of the other parts of my code that could be their own projects. particularly:

• Sound ( Now Done )
• Physics
• Rendering
• Input
• JBEngine

The first three libraries will be a great start and will be the easiest to create, these will then be part of the JBEngine project which will be the product as a whole. 

Doing this means that If i want to create a development tool such as a level editor I can just link the Rendering, Physics and Input libraries and build the application code on top of that and there won't be any extra bulk that I don't need. 

I have been adding a lot of code for various "packet" classes and sorting out exactly how a client and server communicates with one another.

The basics of it is that I create a specific packet object such as a Camera Movement Packet and this class alone deals with both stuffing its data into and out of the packet class of the Network Library.

This has made it fairly flexible and easy to implement passing new data between the client and server. 

Anyway without any further ado, here is where the project is currently at: 

There are still some major issues that I need to sort out, specifically the camera getting out of sync with the player model. This is due to some latency issues and I should have it sorted fairly soon. 

Overall I think It is still going very well, although I think I need to up productivity massively.

Cheers :)

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