Whilst trawling the gamedev.net developer journals for inspiration, I stumbled across a post that someone had done as a reflection of what he had achieved from the previous year and what his plan was for 2016. I thought this was an amazing idea so I'm going to do it myself. Hopefully this should give me some motivation to finish things off and also some direction with what I want to learn next. So here goes...

Just looking back at my posts from last January I was at that point still developing the in's and out's of my Entity Component System. I had only just implemented Awesomium and was still working on my "Level Editor" for this amazing game I was one day going to make. If I could have given myself some advice It would have been to give up on the Level Editor and the ECS and condense my project down massively. Unfortunately I had to learn the hard way!

I managed to get the ECS working in the end and I am fairly happy with the implementation as it uses some complex patterns (CRTP, Observer) to achieve what it does. Also I learnt a lot about using templates in C++.  

The Level Editor and the original game idea I scrapped although that wasn't until June when I decided to get a fresh project and integrate the new ECS into it. I suppose I can put this down to a learning exercise.

It was August 8th when I decided to create a "Space Invaders Remake" using the new baseline JBEngine and ECS. Since then this project had come a long way and is now approaching the finishing up and polish stage. I am really impressed with the work I have done on this. Whilst working on this game I have had to re-work/refactor a lot of the physics code in JBEngine, which is something that can now be reused in future projects. 

I have come a very long way in terms of my career since the beginning of last year! I had just started out at Inspired Gaming and although I knew I had lot's of knowledge about programming, I still felt as though I was a junior developer. ​

I went through a big change in terms of adapting to a new codebase after being so used to working with Arden's monster of a codebase. Learning an application's flow and the architecture is something that only comes through practice, and working at Inspired gave me that. Some of the key skills I will take away from Inspired are:

• Proficiency with Visual Studio
• Better Multi-Threading Knowledge
• Visualising Program Architecture
• Working on a single project through Requirements/Design/Implementation/Test and Deployment
• Working closely with Project Managers/StakeHolder and Testers.
• Time Management​

Along with the technical skills I have developed much more socially, being able to join a new team and integrate quickly. Joining a new company is difficult but as long as you put in that extra effort at the start to socialise, it makes your job and your life much more enjoyable. I have made some great friends at Inspired and will hopefully be seeing them soon in 2016.

In June of this year I left Inspired Gaming and joined IBM. At the time I was very fearful of this decision as the role was to work as C Developer rather than C++ which I had been doing in my previous jobs. To me this felt like a step back in terms of gathering skills but I also have always wanted to work for one of the Big Blue's so I went for it. I think having one of the industry giants such as IBM on my CV couldn't hurt either.

Whilst working at IBM I have actually only done a small amount C development. Instead I pushed for the opportunity to work on a newly starting project which has required me to use python.

I have learnt a lot since being at IBM specifically more about hardware, networking, storage and virtualisation. A lot of the things I have learnt is how much of a nuisance it can be working for a massive corporation. Having company wide decisions pushed on you when it is not the correct decision for your situation. Here is a list of the technical skills I have learned since being at IBM: 

• Learning to various Linux distributions
• ssh'ing onto various machines and having to perform tasks using the command-line only
• Using Eclipse
• RTC (Rational Team Concert)
• python, with Flask, SQLAlchemy and virtual env
• Using Virtual Machines
• Connecting Hardware/Server Room knowledge
• People Management/Project Management skills
• Program Design

The list could go on and on! The main piece of work that I have worked on at IBM I have been the lead developer on. This has required me to create a design document, providing a solution that we will then implement. I have also had to give direction to and collaborate with a team of 3-6 other developers to allow them to accomplish what is in the design.

I have once again had to integrate myself into another team, this one being now up to 80 people. This has been fairly easy as the work environment at the IBM Manchester Lab is really friendly. I have already made some great friends and feel as though I am now an integral part of the team.

In terms of my living arrangements I have moved flat and I am going to be moving again shortly. I moved from Manchester's Northern Quarter in February of 2015 to a flat just off Deansgate Locks. This has given me the opportunity to see more of the city. Some great bars for the summer like Duke's 92, Rain Bar, Atlas bar and many amazing restaurants.

​For the past year I have been in a relationship with Megan (Megatron). We have had some amazing experiences together already! Going for long weekend breaks to Chester, Grasmere, Windermere. A great holiday in Portugal, going to see Wicked! and a lot of hilarious nights out. I can't wait for the adventures we will be having next year!

In terms of my fitness, whilst being at IBM I've managed to maintain my enthusiasm for going to the gym, and playing squash. I now enjoy playing Table Tennis almost every day at work and playing Football on Monday nights.

So all in all this year has been an amazing one for my career, social life, projects and personal development. I realise this post is now pretty long so I think I will leave the "What's Next" part to be a separate post.

Happy New Year :)

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

So after a long while fighting with templates I have finally got a decent implementation of the ECS. I now have Systems, Components and Component Pools.

There is a Component Pool for each component and that holds every single component of that type.

Each System keeps track of each of the entities that is registered for it and then on update the system loops through all the entities getting the components that it needs for that entity and performing the actions on it.

This new way of doing things, having systems work on their own will give me the opportunity to add thread pools once that is necessary. This will allow me to use worker threads for sections of entities registered for the system.

So that is the general usage of the Systems and Components. The next part I will talk about is messaging, this has been a very tricky part of the Entity System.

I have again used CRTP to accomplish this, and I believe allowing a system to register for messages is easier than ever now.

The Messaging system is technically something completely seperate from the Entity System/Component architecture and because of this it is not just Systems that can listen for messages.

Okay so how does it work?

So the Message class is where the CRTP occurs, each derived message type will supply itself as the template parameter for the base class:

  class DerivedMessage : public Message
 {
 public:
         DerivedMessage();
         virtual ~DerivedMessage(){};
 protected:

 };
 

This allows for much easier dispatch of the messages now to show how to make a class receive messages:

first of all you have to derive the class that will listen to the messages from the MessageListener class supplying the message you will be using:

  template < class MessageType >
 class MessageListener
 {
 public:
     virtual void HandleMessage(MessageType* message) = 0;
 };


 class MovementSystem : public System< MovementSystem>, 
                        public MessageListener< MovementMessage>,
                        public MessageListener< RotationMessage>
 {
 public:
    MovementSystem(MessageManager* msgManager);

    virtual void Update();
    virtual ~MovementSystem(void);
    void HandleMessage(MovementMessage* message);
    void HandleMessage(RotationMessage* message);
    virtual void RegisterMessages();

 };
 

The next step is merely to register to receive the messages of a certain type in the RegisterMessages function. This is called just after creation of any System.

  void MovementSystem::RegisterMessages()
 {
         mMessageManager->RegisterListener< MovementMessage>(this);
         mMessageManager->RegisterListener< RotationMessage>(this);
 }
 

and then of course all that is left is to handle the messages with each of the HandleMessage functions.

Finally this is a little demo program that shows the use of the ECS and messaging:

  int _tmain(int argc, _TCHAR* argv[])
 {
         MessageManager messManager;
         EntityManager manager(& messManager);

         Entity* newEnt = manager.CreateEntity( string( "MyFirstEntity" ) );

         newEnt->AddComponent< PositionComponent>( newEnt );
         newEnt->AddComponent< VelocityComponent>( newEnt );

         newEnt->AddSystem< MovementSystem>();

         messManager.SendMessage< MovementMessage>( 40.0f, 0.2f, 0.0f );
         messManager.SendMessage< RotationdMessage>( 20.0f, 0.0f, 0.0f );

         return 0;
 }
 

I have used variadic templates throughout to make creating Messages and Components really simple.

So I believe this is a fairly flexible approach, there are probably a few more things that I could do to make this better but for now I am going to leave it as it is and try and re-implement all the functionality that is in my previous version of the ECS. Once this is all integrated back into my Engine then I will run some tests and see if there is need for any more changes.

All is going well after a lot of frustrating times with templates. There are still some things that need tidying up to ensure the system is a little more robust but I am very happy with the progress.

Thanks  :)

On Thursday I managed to get the Export of the Levels to work. This involves exporting the Assets ( Meshes, Textures, Sounds ) and the Entities( Components, Data Components ). After doing this the only thing I had left to do is allow editing of the rotation of the entities, which posed a problem. Up until now I had been directly editing the Matrix of the Mesh Instance I had selected. This was fine except to do rotation I would need to store the Euler Angles that could be edited from the User Interface.

This got me thinking, I should be using the Entity Component System(ECS) for all of this data realistically, and I will also be wanting to edit values of the Data Components from within the Level Editor as this will make entity creation much better. In my current system for ECS there isn't any way of getting a Data Component for an Entity without doing a dynamic cast based on some sort of ID which could potentially go wrong. So I started looking at different solutions for ECS since my first initial implementation. I came across this post: ECS, Component, Entities and Systems, which suggests the use of the Curiously Recurring Template Pattern(CRTP) for the ECS. 

Most of Thursday night was spent refactoring my current ECS from a virtual inheritance style hierarchy to this CRTP version. Needless to say after a lot of Linking Errors and all sorts of crazy going on I decided to scrap it and revert my changes.

So for my second attempt I decided to create a seperate project for my ECS and get it all set up with the templates before integrating it into the engine. I am part way through this, I've got all the Components and Data Components working I just haven't dealt with the messaging yet. I have really mixed things up, instead of storing Components within the entity I have created pools of all the same types and they just have reference to their entity. This way has a few benefits such as cache coherency, 

the updates will also be Component Priority dependant rather than Entity Creation dependant. This approach will also give me better opportunity to perform multi-threading when the time comes, each pool could use worker threads to update chunks of the Components. 

One thing I am likely to change is the wording I previously used, in most descriptions of an ECS the words System and Component are used where as mine uses Component and Data Component which really confuses things as:

Component = Data Component
System = Component

For the sake of anyone wanting to use the Engine and reading up on Component Systems it seems more appropriate to use the most common terminology.

Okay so finally a demo of what access to the new Components will look like:

auto posComponent = entity->GetComponent<PositionComponent>();

also as I have used Variadic templates so the adding of Components to entities is clean and simple:

entity->AddComponent<PositionComponent>( x, y, z );

Okay so there is still a lot of work to be done but I'm hoping to get this all nailed pretty soon so I can really start using the ECS.

Cheers :)

Work is progressing massively each day at the moment. I have just implemented the Entity creation code and added the extra functionality to the GUI. 

The rate at which I am creating the GUI is increasing rapidly as I'm getting better with JQuery and also I have now implemented a reload feature so I can just tweak the JavaScript and then reload the GUI without having to stop and start the program. 

Anyway enough chit chat here is a demo of the entity creation in action:

So I have managed to get a couple of things off my check list from the last post off already which is great I now just need to add 

The rotation and scale support and then hook in the export code again and I will have a fully usable Level Editor.

On target to get this nailed by the end of this week and it's about time :)

It's been a while since I actually got stuck in and started doing some work but I've finally managed it. After having a look over my events that I had outstanding in Asana I got a good idea about what were the next few things on the cards. I suppose that is another plus for keeping track of events and bugs, well done me.

So the main things I have been working on is the GUI integration using Awesomium. As a recap Awesomium is a library that lets you create user interfaces using Web based technology such as HTML, Javascript and CSS. The majority of this work had already been done and I had something up and running that could call methods in the Webpage and also the Webpage could callback methods in the C++. There were a lot of design issues with this as it was still in the "Let's just get it working" phase. Now that I had proven that I could get it working and that the library was efficient enough to have as a permanent feature it was time for a little refactoring.

First of all the majority of all the code was dumped in one class, this was the main library object, a web view, the method callbacks and so on. Obviously this all needed changing so I set about refactoring it all into smaller classes and thinking about how I can keep the majority of the Awesomium functionality away from the user.

At the moment I have:

• JBWebCore
• JBMethodHandler
• LevelEditorMethodHandler
• JBWebView

This is as far as I have gone at the moment as I am trying not to over engineer it too much, there are still quite a bit of the Awesomium code in these classes but for now it will have to do. The LevelEditorMethodHandler is a child class of the JBMethodHandler and allows you to overwrite the BindMethods function so you can add your own callback methods that you can call from the Javascript in a WebView.

After the refactoring of the Awesomium class code I went about figuring out the problem of the mouse clicks being registered for both the GUI layer and the Game Scene. To overcome this I used a GUIActive/Inactive member which was checked to decide whether a click should be passed onto the game scene.

This GUIActive/Inactive member was changed by adding a callback into the C++ from the Javascipt in the Webpage. I used the JQuery mouseover/mouseout methods to trigger these callbacks, this meant whenever the mouse hovered over one of my <div> elements in the webpage then the click's after this would only be sent to the Webpage and not to the Game Scene. 

This seems like a fairly decent way for doing this at the moment, although there may come a time when I will want to have a User Input stack. As I currently only have the GUI and the Game scene that needs input I don't feel It would be beneficial to start engineering something more complex.

I did manage to get quite a bit done last night and I am more motivated to get back to it again now. Next on the cards is unfortunately a little bit more refactoring before I can move on. All this Awesomium stuff needs seperating out into it's own library. The only classes that will be exposed to the User will be an interface into the JBWebView class so that the user can keep a reference to it and Bind different method handlers to different webviews, and the JBMethodHandler. The JBMethod Handler will be used merely to allow users to derive their own method handler classes for binding their own method callbacks.

Plenty to do but I know as soon as I have all this Awesomium code seperated into it's own library I will feel loads better, there's nothing better than a good old tidy up :)

Keep coding.

Over this past week or so I have been getting used to using the Awesomium Library. I hit a performance issue fairly early on but that was soon resolved and the webpages now render very efficiently. I was pretty amazed to see how well it actually works and I definitely think this is the way that the majority of my User Interfaces will be done from now on, including HUD's. The input to the awesomium library is done as input injections, such as MouseMove, MouseButtonDown. This got me thinking a lot about how my input actually worked and I decided to refactor it a little.

As a general rule there are two approaches to handling input: Polling and Callbacks. So far in my engine I have been using polling. Whenever an object needed to check for some input it would read something like: 

if( input->GetButton( JB_ENTER_KEY ) == JB_PRESS )

This approach worked and for a long time it was sufficient, but to provide Awesomium with the information it needed I would have to call this every frame for every possible button and that was not realistic. 

I have now implemented a callback based approach which allows different objects to listen for the key presses and mouse movements it is interested in.

For example at the moment I have an "Input Context" that listens for all the keys and mouse movements and the callbacks report to Awesomium about it. 

Another Input context is used for the Level Editor movement and only listens for the WASD buttons and allows the camera to move about when it's callbacks are called.

This approach makes this much simpler and I'm hoping I won't ever have to touch the inner workings of the input again. One thing that could change is adding some input mapping so that different keys could be used for the input i.e. use Up, Down, Left and Right instead of WASD for movement. 

The integration between the JavaScript and the C++ side is seamless and didn't take too long to get up and running. Currently I have callbacks from the JavaScript into C++ but I haven't fully tested opposite approach quite yet, although it seems fairly simple. 

Anyway here is a quick demo of a User Interface I setup for the Level Editor, it doesn't actually show off any of the callbacks in this video but I will soon be showing a fully integrated version:

Okay so this all seems to work well and I'm thinking there has go to be a catch at some point but let's hope I'm wrong. It's really surprised me how little information there is on other people using Awesomium in native applications. I believe this is much better than using any other User Interface Library, even if the performance isn't quite as good as a C++ Library would be. 

I think the largest advantage is the ability to create User interfaces on any computer, currently the engine doesn't work for Mac OSX but I sat there the other day on my MacBook and bashed out this user interface. This also means that when it comes to releasing a game you already allow the users to mod the user interface in which ever way they want. All they would need to do is call the appropriate methods on the JavaScript Object for the engine. 

That is it from me today, I'm hoping to get much more work done over the next week or so to finally get this level editor user interface polished off, and also refactor the design for this Awesomium work.

This past couple of weeks I've been playing around with 3ds max a little more and working on creating animations. Using these animations I realised that my engine can't handle FBX files very well, and in fact the example Model Viewer I got couldn't either. This meant going back to the drawing board and figuring out why FBX animations weren't working. I soon narrowed it down that the use of FBX and the 
biped objects in 3DS Max were making it really difficult to import into certain pieces of software. Due to this I am not resorting back to using Collada as my main import type as it is the most standardised and it will work for animations as long as I don't use the biped. 

This has caused a lot of frustrating as now I am having to create all my bones and animations by hand, in the long run I think It might be slightly easier as the biped can't really do everything I need it to.

I found a piece of middleware called Coherent UI which allows the use of HTML webpages to display GUI's in games and other native applications. This seemed really powerful and from the look of their website appeared to do everything I wanted it to do. The only issue is that their licenses were a bit limited for what I needed it for. I realised afterwards how useful this middleware would be to me as I would then not need to create all the GUI elements for the engine and would increase productivity rapidly, so I went on the lookout for a similar library which i could use. This is when I stumbled upon Awesomium. It also allows application to take a webpage and render it to a texture, more than this you can interact fully with it using JavaScript for callbacks to C++ functions. 

I have been playing with Awesomium over the past week and have managed to get something up and running, rendering the google homepage and allowing some interaction with it. There is still plenty more to be done and it does seem that there is a large performace issue with it at the moment. I believe this is due to the texture being overwritten almost every frame and then uploaded to the graphic card again, although I am yet to profile it. 

If i can manage to get these performance issues out the way I will proceed further with it and hopefully be able to throw together a new UI for the game and also the level editor. This will give so much flexibility and also the ability for users to mod the game. they can simply create their own UI by overwriting the current webpage with whatever they would like to display. 

Plenty to be looking forward to and I will hopefully have a demo usage of the awesomium up soon. 

Thanks 
:)

Okay so I really haven't managed to get much done in terms of coding but I have learnt quite a bit that will hopefully be very useful.

Okay so I started off by creating the Export part of the Level Editor which means I now have a full pipeline for level production, I can create assets, place them in the scene and then save them to an XML file. This XML file can then be either imported into the Level Editor again for further work or can be used in the game. 

I have been getting used to using 3DS Max and I have become much more efficient with it, learning to model and texture objects. I have also learnt to use the biped tools to create simple walk and jump animations. 

This is when I ran into some troubles as when I exported my model to collada I couldn't get the animations to export properly. I initially thoguht this was an issue with my engine but as I tested the animation in two other assimp featured model viewers I decided it was an issue with the file format. 

To combat this I decided to try and export the model as an .FBX which worked with the modelling programs. .FBX is only supported in the newer version of the assimp library that I didn't have at the time so it was time to update the library.

Okay so I set off downloading the newest version of the assimp library. The first time I compiled assimp it came with a setup visual studio solution so I simply had to compile the program and it would create all the files for me. 

Since then they have decided to go for a CMake alternative as it is the most cross platform approach and I'm guessing take the least work on their part. 

I had never used CMake before and was a bit worried about using it as it all seemed overly confusing. After reading up a bit on the internet about Make Files and how to use CMake I finally managed to get the assimp library to compile. 

It was actually not as difficult as it first seemed and I will will more than likely use it many times again with other libraries that I need to update. 

As a final note I still haven't got the character to display properly as there is an issue with how the bones are setup in the engine. I know this file format does work as it has worked with the model viewer so I will just need to do a little more debugging to figure out what is going on. 

I really need to get something demoable very shortly as this is making me lose motivation some what. Once I have my character model in and walking round I will feel much better. 

Cheers :)

Okay It's been a while since my last post and I have been slowly working my way through creating some of the initial GUI Elements for my Level Editor, and eventually the game. 

I have just added a checkbox class and an Editbox class that will allow the user to enter data. As a starting point these really are the only two extra elements I need. The editboxes are needed to allow the user to edit things like, Entity Name, position, scale and rotation and obviously the checkboxes are great for turning things on and off. 

Anyway enough of my ramblings, here is a short demo of some of the functionality of the Level Editor:

So the video is pretty minimal at the moment but even now this is going to make life much easier than editing values in an XML file to add objects to the scene. 

Next steps are:

• Allow the user to specify an object to place in the scene
• adjust rotation and scale as well ( fairly low hanging fruit )
• start work on the XML exporter
• Add extra GUI Elements( Dropdown list and Listbox with scroll bar )

I definitely need to get started on the XML exporter, although it shouldn't be too difficult it will be a time consuming thing to get right. I already have a specific format of how the file should look, due to having to write the importer so I want to get that nailed as soon as.

The other bits and pieces are just general improvements to the Level Editor which will be implemented over time. I really want to keep this level editor as minimal as possible so I'm having to assess each of the functionality I want to add and think about whether I really need it.

Happy with Development at the moment,
just need to keep motivation high!