As always, when I wrote my last post I was lucky enough to have plenty of time on my hands. Recently however work has been some what manic trying to ensure that our team meets the delivery date for our new feature, which has had a knock on effect with my own projects.

I'm hoping to get back into this CMake work and really revive the JBEngine project but until work lets up I don't think that's going to happen. I'm simply writing this post to try and keep this all at the forefront of my brain. I really don't want my motivation to slip on this again!

​Thanks

So I've decided to revive the JBEngine Project. I gave it up a while ago due to lack of motivation when trying to make it cross platform. The main reason for that was the steep learning curve for using CMake and generally having no real milestones for a very long time. The project was in a state of failing compilation for so long that I ended up giving up. So how am I going to be able to motivate myself this time?

So being a Scrum Master at work for the past work or so I've found out how important it is to break tasks down into small manageable goals/stories. In doing this I will be able to keep myself motivated by ticking things off in my task tracking application. There are still going to be a few problems getting started though.

So during my development almost a year or so ago I had my project in a state where there were many files edited/added such as many CMake files and lots of changes for making the source code cross-platform. Due to my frantic approach at trying to get the project fully working I now have multiple machines with various files edited with no way of knowing which are required, which aren't working correctly and which I need to just get rid of.

I'm going to take things step by step now, just to get the project in a clean state before making any major changes.

• I need to figure out which source code changes are really required and get them checked in.
• I then need to figure out which of my CMakeLists actually work and get the correct ones checked in.
• I will then delete anything else that is not required.

I want 'git status' to tell me that my repo is completely clean before I even consider making any new changes.


That's all for this time,
​Thanks

So for a while now I've been trying to get the JBEngine cross compiling using CMake. I started this off by creating cross platform versions of the most simple libraries first, Maths and Sound. This was easy because they had very few dependencies and hardly and source code.

I have currently managed to build all the libraries, which are:

• ​Maths
• Sound
• Networking
• Physics
• ​Renderer
  
• Awesomium/GUI
• JBEngine

When I have now come to put all this together and compile the Space Invaders executable it has become a nightmare.

​There are just too many errors!

To overcome the sheer amount of issues I have decided to create small test applications with minimal parts of the JBEngine libraries. That way I can narrow down issues, to specific libraries. This is something I had done a while back to check that the Sound library worked. I created an application that loads one sound and plays it on repeat.

Last night I found a tutorial online that uses CMake with glfw, glew and assimp so I managed to get those working nicely. Here is a list of test applications I will make in order:

• ​Window Creation (openGL, glfw, glew)
• Window with fullscreen texture (SOIL)
• Window with single loaded mesh (assimp)

For now this will do, as I'm not sure exactly which libraries will cause the problems.

​I will be separating out the window creation into another library as that seems to make sense. The JBEngine library has become far too bloated, and it will make these test applications easier to create.

Finally I am hoping that by building these test applications, not only will I create a better architecture but I will also keep motivation high. Each little test application can be thought of as a milestone which will be rewarding on completion.

Thanks :)

So the past few days I've been working with CMake to try and get my some of the JBEngine Libraries running for Linux. The first thing I did was use vcxproj2cmake tool to generate the CMakeLists.txt from my already created Visual Studio Project Files. To start with I concentrated on the Maths and Sound Libraries as they were the easiest to do. Maths Libraries only requires some third party includes of glm and the Sound Library only has one library dependency on FMOD. 

To get the tool working I ended up having to copy all it's files into the same directory as the project file. It just didn't seem to work with a path. Secondly I then had to manually change all the paths that I had entered (or Visual Studio had generated) for the include and library directories in the Visual Studio Projects. Microsoft tends to default to using "\" for directories where as Unix system use "/". Once I had done this It finally generated a CMakeLists.txt for me, but this was only the beginning!

Being the naive developer that I was a few years ago I had scattered through my source code the use of the "\" for directories instead of "/". This was one of the first things I had to address. It was mostly the includes in the files so it wasn't too hard to track down. This wasn't too time consuming for the Maths and Sound libraries as there are no more that 5 files in each. Doing this for the whole JBEngine Source may be a little more tedious.

The next problem I encountered was resolved by this Stack Overflow post: Why does MSVC Let me do this. I was essentially passing an anonymous object to a function. It was a little confusing to track down as it wasn't a simple example:
​

void Union(Bounds& bound);
void Union(vec3& v);

void Bounds::Union( Bounds& bound )
{
    Union(bound.GetMin());
    Union(bound.GetMax());
}

What you don't see here is that Bounds.GetMin() and Bounds.GetMax() do not return a reference. This means that the returned vec3 object from the functions are newly created and therefore anonymous objects. MSVC automagically resolves this in some way but g++/gcc does not do this for you. This took me a little time to figure out as I had never even had to think about this sort of thing before.

They were the only real code issues that I faced, the rest was all about learning CMake.

So I started off with an already "complete" CMakeLists.txt which would work for Windows. Unfortunately this was never going to work out the box for Linux. Well at least it didn't for the Sound Library. First of all I had to get the Linux version of the FMOD Libs.

I had quite a bit of trouble getting used to how CMake works, specifically with include and library paths and also using the if(UNIX) branches for OS specific target_link_libraries. I finally managed to get CMake working and now I only had to deal with the make compilation issues.

What I hadn't realised is that fmod had changed significantly since I got the library for Windows so then I had to adapt the code to use the new library. 

Once I had managed this I then created a Test application to play a sound. So it was all quite easy I just had problems with:

1. vcproj2cmake
2. code issues
3. cmake issues
4. library compatibility issues.
5. and then more code issues due to the new library.

It really was a breeze.

On a serious note it wasn't half as bad as I thought, and I've learnt much more about CMake. The next things I will need to look at are:

• Adding CMake Dependencies i.e. JBEngine Library requires all the other smaller Libraries such as Sound, Maths, Renderer etc.
• Ensuring I haven't broken anything in Visual Studio whilst messing around with the project files.
• Looking into Visual Studio Project/Solution Generation from CMake.

So Vulkan was released today! What better reason to do a blog post, when it's been so highly anticipated for so long. I can't wait to get stuck into the API and Reference documents and start trying to throw some tech demo's together. 

I have just got hold of the SDK and had a little play around with the Demo's, I've not managed to get much done but the whole thing does look much more "DirectXy" which will likely have it's good and bad points. for example the horrendously long class/struct names. I've already seen "VkPipelineInputAssemblyStateCreateInfo" as a name and I'm sure there will be plenty longer. It will obviously have it's benefits in terms of performance but I'm not sure we will really experience that for a while. Anyway here is a quick video of me after messing with the textures a little with the cube demo:

As you can see it all looks a little messed up. The cube is spinning incredibly slow as well as I don't think it uses delta time for the rotation, so the recording application almost halted the rotation. What can you expect from a half hour mess around?

It's been a while since my 2015 post-mortem and I really wanted to point out some of the things I will be concentrating on this year. I have just fully moved in to my new flat with Meg in Blackpool so that is the reason I haven't done any real work or blogged for a while. 

So this year my main focus is going to be on:

• Getting my Space Invaders game finished off, and I mean fully polished!
• Developing my skills in Blender.
• Slowly making parts of the JBEngine OpenSource.
• Trying to contribute much more to the OpenSource Community.
• Getting stuck in to Vulkan, hopefully integrating it with the JBEngine at some point.
• Making the JBEngine Cross Platform.

So far I've not done so well on these goals other than the last two. You can't really call a 30 minute play with the demo's "Getting stuck in" though. I have been working on getting the Maths and Sound libraries of the JBEngine to compile for linux. I started using CMake last Saturday and I really feel like I was getting somewhere. I am going to set myself a target of getting those two libraries working for Linux, and OSX in the next week or so which shouldn't be too difficult. 

Anyway that's pretty much it, oh and I did do some work with blender over the past month so here is some dev art to laugh at:

It's supposed to be a Starfish, in case you were wondering. 

​Cheers :)

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 first thing I got to work doing recently is implementing the AI Movement Speed. These utilise the Speed Component that the Enemy and the Player already has but in the AI Movement System the code now uses a timer to increase the speed of the enemies. Initially the speed ups only occur after a few seconds but the timer gets smaller so the speed increases become more frequent. 

The next thing I worked on was a few bug fixes. The player was being deleted when going to the next level. If you clicked "Esc" when waiting for the next level or when you were respawning it would crash the game out. These were easy enough fixes but the last one was a biggee and was actually still there in this video: 

So as you can see the game is coming along nicely, I changed the skybox stars texture to a much nicer one that you can see here. 

The big bug that I managed to catch out was an optimisation problem. My FPS had dropped to ~40 all the time. At first I thought It was something to do with the Entity Component System as it seemed to show up most when profiling, this then caused me to make some changes to use more efficient containers. It turned out it was actually the awesomium texture updates. I was updating the scores and lives every update. This causes a re-draw of the whole html page which is very slow! 

I managed to catch it and my FPS is way back up again now so all is well. 

Oh as an added note I downloaded blender tonight so I will be getting to work on the defence posts soon. 

Cheers :)

So my last post was about how I had become slightly too addicted to playing games and that had taken away from me actually making them. I'm glad to say I have managed to get right back into it again, and quite successfully. So what have I been doing?

So I have been looking into the collision filtering mechanism that Physx supports. The basic mechanism allows you to provide a mask and a group to decide whether two objects require a collision callback.

Although this does seem quite flexible it has some serious limitations, mostly because the mask and group are just uint32's which seriously minimises the number of masks and group you can have for one game. Originally I was thinking about going through and creating some generic groups e.g.:

• Player
• Enemy
• Boundary

The list could go on to name a few more. Basically what you would then do is on a per Entity basis in my engine you would setup a group that was Enemy and it should provide collisions for Player and Boundary. Having all this mask and group stuff just didn't seem flexible enough and I would still then need to provide the game logic to check which enemy it was and which type of boundary to decide the outcome. So instead of this I am still going to use the mask and groups as it provides some optimisations but I just have it decide whether to call the callback or not. i.e. mask can be 0 or 1 and group is always 1. This seems to work well enough, I know it's probably not as efficient but I think making it easier to use is much more important. 

After getting all the collision filtering working properly I had then implemented the Entity Destruction System that listened for kill entity messages.

The physics system would handle the collision logic, i.e. when there is a collision between a bullet and an enemy an EntityDestroy Message is sent for both of those entities. 

There was a lot of bugs that cropped up with this, specifically because my message system is instant i.e. an entity destroy message is sent, the Entity Destruction System will go straight into the handler for this and if the entities was then removed it would cause complications because the physics system is still in a for loop of all the Entities.

To combat this I created a destruction queue and handled this in the update function of the Entity Destruction System.

There were also a lot of random bugs with the entity destruction as I had never really fully tested it that way. The memory was always cleaned up when I closed the program but that was different from choosing an entity in the middle of the container and removing it and all of it's components and the systems it was subscribed to. I also had a similar issue with removing Mesh Instances, I had never actually removed singular instances from the scene before so that had to be implemented.

I got through it all in the end and all seems much better now. Anyway enough talking, here is where it is at:

Oh as an added note I also added some functionality for freezing an axis. The player character was colliding with the walls and then spinning off in directions that I didn't want, now it is fixed on the Z and Y plane allowing only movement across the X.

So there it is, I have what is essentially some of the most basic functionality for Space Invaders:

• Enemy's Dropdown when Colliding with the Boundaries
• Enemy is Destroyed when a bullet hits it.
• Bullet is Destroyed when it collides with an Enemy.
• Player can sideways
• Player can shoot bullets
• Player is restricted by Boundaries

I'm really impressed with how this is going, and I am relieved that I can finally complete a task that I have been receiving e-mail task overdue notifications about for weeks now.

So what's next on the cards? 

I am going to plough on, the next few things that I need to look at are:

• Enemy and Player Health and Lives
• Enemy firing ( initially will be pseudo random )
• Dealing with Game State, Level Start, Level Failure, Level Completion

There is plenty to do but I really think these things won't take long at all. A lot of the groundwork is already in place. 

​Cheers :)

​Okay so this a blog post basically to express my own dissappointment.

I don't normally do negative posts because... well why would you want to be negative? positivity breeds motivation. At this point I think I just need to talk about the reasons I am not being very productive and in talking about it hopefully make a change.

So I went on Holiday a while back and since then my motivation for doing my project is almost none existent. I think the combination of getting back into working life and also getting into a couple of games is the cause of all this. 

For a while I was playing Counter Strike: Global Offensive almost every weeknight. Then on the weekend I was spending time with my girlfriend and seeing family/friends. I got way too into this routine, more specifically I was becoming a little addicted to CS:GO. This was to the point where I would forget to have tea or do any chores around the house. So a week or two ago I realised I had to stop. Playing it wasn't even fun anymore either as I had progressed to a level where it was far too challenging for me to actually get any kills/win many games. So at this point I was just getting frustrated, except I had to play "Just one more" until eventually it was 1am and I had work in the morning.

So the other day I realised (with a little nudge from Meg) I needed to uninstall the game in an effort to hopefully start doing something productive. So I did. I uninstalled it, and this is the first week where I haven't played it at all in a long time. I have however recently bought a load of old school RTS Games (Age Of Empires II, Cossacks:Art of War, Cossacks:European Wars). When will I ever learn! So this week I have managed to play Age of Empires each night and I seem to be falling into the same trap. The only positive from this is that the panning of the camera makes me feel a little nauseous and so I can't play more than maybe 2-3 hours. Because of this panning problem I am hoping I will get bored of playing shortly and then I can concentrate on doing at least a little bit of work on my projects.

Not a technical post, more just a look inside my strange brain. 

I am hoping just putting all this stuff down will help me realise how daft I am for playing games so much!

Thanks :)

So I've started looking at the physics implementation that I currently have in the JBEngine. It uses Physx but when I initially integrated it I must have literally got it working for the exact case that I needed it and then left it. I think that came from my inexperience in programming in general.

After looking through the code and playing with a few things I have managed to get the enemies to have box collision shapes and also have the update from physics to game scene working fairly well. 

I will definitely need to re-factor quite a bit of this code to get it to work in a way that would integrate a little easier with an Entity Component System. I have been thinking a little about my current design and have also made the code that was already there a little more flexible. 

I also got to look at this beauty again as well... The Physx Visual Debugger! It is pretty finicky to manoeuvre the camera but it does show a clear representation of your physics scene which is really good. Unfortunately I couldn't get a video of the physics objects moving so this screenshot will have to do. 

I think the next post will be mostly about the design that I am going to implement before I dive in and start coding. I don't want to make the same mistake as last time ;) 

As another note the fact that Unity uses Physx and also an Entity Component System may make my life a little easier as I can see how they have done it and take some guidance from that.

Would be great to get this physics work integrated fully and in a flexible way soon.

Cheers :)

I've slacked off on development over the past week or so whilst I was playing H1Z1 and trying out my new GFX Card. 

I have managed to get the enemy movement working. It is very simple for the Space Invaders game and I did have the opportunity here to try and make it really generic but I decided against it to try and just complete exactly what needs doing for this game. Otherwise I end up getting bogged down with the design. 

Anyway here is a little sneak peek:

At the moment the drop down and change in direction is triggered by a timer but in the final version and once I have the physics implemented it will be based on collision messages from the wall. 

I am really pleased with progress. The next part might be a little complex as I haven't touched any of the physics code for a long time. 

I also might install blender and have a go at creating some models to get my self a little better before creating the final pieces for this game. 

Thanks :)

Today has been a really productive day and I've managed to add three great advancements to the space invaders game. 

I managed to create a new UI for the game which is all hooked up to the game code as well so as soon as I have some events that will either lose lives or add to the score then the User Interface will look a little more impressive. All this is done using the JBEngine's Awesomium Integration and just shows I have done quite a good job as I've managed to get it up and running fairly quickly.

I have also added some models for the player and enemies which I have on my computer from years ago whilst at uni. These models aren't likely to be the final ones but for now they are much better placeholders than the cube I was previously using.

Finally, I have added a firing sound for the bullet. This again was fairly easy to implement as I had already done a good job with the JBEngine's Sound Library. Okay so I've explained what I've done, here is a video of the game in it's current state: 

So it is really starting to take shape and is looking more like a game now. Whilst on skype to my girlfriend who is currently sunning herself in South Africa (Lucky Sod) we came up with an idea for the theme of the game to change it from space invaders into something more unique that I could call my own. I'm not going to announce anything yet as it's still just an idea at the moment and for the first game I think I might just stick to an exact replica of Space Invaders for Simplicity.

Everything is moving along really well. The next thing that needs doing is sorting out either the physics which hasn't been touched for a long time ( which is very worrying ), or to get the basic enemy player movement done.

Thanks :)

So last time I wanted to focus on getting the Systems working via import/export. I have managed to do this now although It doesn't work in the same way as the components. 

Systems can only be ran once by the engine and entities apply to be acted upon by them. Even though the code allows you to do "entity->AddSystem<RenderSystem>()" what it is actually doing is just adding the list of entities that will be processed by the render system. 

After doing all this and basically getting the ECS in a state where I could start adding the components that were in the level editor I decided to stop. Instead of adding all the old components I am going to steer clear of the level editor for a while and instead focus on a small game. One that wouldn't even need a level editor.

Enter Space Invaders...

So I've decided to remake the classic arcade game but in 3D. The functionality will be very similar to what the original was (unless I decide I prefer something else). You will still be able to play it in the same view style as well i.e. Top Down. Alternatively you will be able to play it in a first person mode as well.

Anyway that's the basic idea here is what I have so far:

It's really not that impressive and creating functionality it a little bit tedious at the moment as I'm having to create loads of classes for the components and systems. Once I have written these I will be able to reuse them for games in the future I hope.

All is going well... Oh on another note I bought a new nVidia Geforce 970 gtx and have just installed it so I may get distracted by shiny new games. 

Cheers :)

Okay so last night I finally started on changing the Component store to get rid of all the statics and instead have the vector of "Component Proxies" populated at run-time. This all went really well and I managed to get it up and running pretty quickly. This then left me with the rest of my evening to progress further with other improvements. 

One thing I changed is that I have renamed the "Entity" class in my new ECS system to "EntityECS" and I will then derive this from a base Entity Interface class. This is so that in the future I could possibly implement a different EntityManager and that could maybe do the classic deep hierarchy approach to entities. I have already changed the EntityManager to "EntityManagerECS" and the JBEngine class has a IEntityManager Interface which you can set so this future improvement shouldn't be too difficult. 

Further on from this I've gone on to attempt to conquer the Entity Parsing for the new ECS

I use a library for dealing with the underlying complexities of parsing XML in from a file. The layer I have built on top of this allows me to perform some handling code at the start and end of xml tags. Within each tag the library collects all the values and stores them in an attribute list that has a "name" and a "value". i.e. name="PosX" value="0.00" 
Here is the basic process I have implemented for creating entities.

1. When I get an <Entity> start tag I create a new entity.
2. When I hit a new component within this <Entity> tag I then use the component store which creates that component by it's name and adds it to the passed in Entity. 
   
3. The component store also returns a "BaseComponent" which I then use the overridden "Load" function to pass in all the values from the attributes list. Which sets the component up exactly as it was stored in the xml.

I was going to try and have the Load function deal with the xml but instead I thought it would just be easier to just use a stringstream and this could then just use the ">>" and "<<" operators for both the Load and Save Functions.

I will have to be careful that the Load and Save functions always remain in sync otherwise there could be a lot of data corruption going on. 

I really like this approach as it means that the class deals with it's own initialisation and nothing else needs to know about it.

Okay next I will be getting on with ensuring that all the load and save functions work for the components I already have. I will also be doing some refactoring as there are a lot of commented out functions and redundant code left over from when I used the old Entity System as a starting point.

Once I have done this I will then think about exactly what components I need to implement, and also to implement all this "Component Store" and Entity Parsing functionality for my ECS Systems.

Thanks :)

Okay so I started looking into re-implementing the entity parsing code and there was so much I didn't like about it the way it was currently done. Clearly in my previous implementation I just wanted to get something up and running as soon as possible, no surprise there. I basically had a class that had a massive switch statement based on the component name and then unpacked the xml and called the constructor. This time round however I wanted to make it as easy as possible for a user of the engine to create new components and start using them, which was the whole reason for the ECS re-factor.

The first and main idea I found was based on an article written back in 1998 by Jim Beveridge called: self registering classes in C++. Essentially this approach used static initialisation to add an instance of a proxy object for each component to a vector which could then be used to create instances of the component itself. 

At this moment in time it is actually the way I have it working but at the time of writing this I am thinking about trying out a different method.

This approach does work at the moment and the main advantage of it is that all that needs to be done is that after the definition of the new component you just have to create a global version of the proxy templated with the new component and away you go, you can create instances of your new component based on it's name.

There are a lot of reasons I'm sceptical about this:

• Wow does this seem incredibly hacky!!
• From what I've read in forum posts across the internet static initialisation can cause incredibly hard to track bugs.
• Static initialisation can act differently depending on compiler, meaning this code may not work correctly when compiled on linux( something I'm wanting to do in the near future )
• There will be tons of globals all over the place
• A component will always be available if it's being compiled, unless you remember to remove the global proxy declaration.

So like I said I have literally just thought about trying a different way and here it is: 

Essentially it will work in a very similar way, there will be the concept of a "Component Store" as noted in the webpage I have linked. This will still hold a vector of proxy objects for creating components. Instead of doing all the hacky static initialisation stuff and having global declarations of things I will just fill the vector at runtime. Right at the initialisation of the engine, before any parsing can be done the Component store will run a function to populate it's vector. This itself has a few drawbacks:

• The Component Store will need to have a huge function adding proxy objects for all the components in the entire game.
• The Component Store will have to #include every component in the entire game. 
• This will cause a slow down at program start up whilst this vector is populated.
• Every time a component is added to the game, the user will have to remember to add it to the list.

Okay that seems like quite a lot of potential drawbacks but If I was to go down the route of the first approach and then come to try and get it to build on Linux or OSX to find it doesn't work then that would require a lot more work. I actually understand how the code works in this second approach as well which is much more valuable than it seems. 

So I have a lot more work ahead of me, I am hoping that this next part converting to the new simpler approach won't take that long. I am really glad I did this blog post before fleshing out the components using the Static Initialisation method as it would have meant even more wasted time. 

Setting myself a deadline of next Tuesday to have the new approach implemented for Components and to have done a blog post about it.

Thanks :)

The First phase was to get the new ECS working minimally with the JBEngine Libraries.The approach for this was to add the JBEngine projects to the ECS Project rather than trying to fit the ECS code into the Level Editor or Game application.

I have managed to do this, it has taken a little bit of work but I think it was actually fairly easy. I have even managed to create a scene similar to the one featured in my Level Editor Demo's:

This is a very basic scene and there is still a lot of work to do. At this point the only Components and Systems that I currently have are:

• Transform Component
• Mesh Component
• Render System
• MovementSystem

From here on I need to start essentially re-implementing all the systems and components that were previously in my Level Editor and Game Applications to make the transition to the new ECS much easier. I will also be re-thinking a lot of the current systems and trying to justify whether they need breaking down into smaller chunks or even needed at all. I  may well do a check in of this code now as well as It is in a fairly stable state and there are going to be many changes to come.

All these entities are currently hard coded into the program as I will need to re-write all of the Entity Parsing code. The Asset parsing can remain as it was i.e. Loading Meshes, Textures, Sounds as that is no different and is already implemented in this. It will just be the specific Entity Parsing and Creation code that will need changing, this will hopefully not take too long so I can get the Level Editor in a stable state with the new ECS fairly soon.

I'm really impressed with how smooth things are going at the moment, I hope It stays this way.

Cheers :)

Tonight I've been trying to come up with a way to merge the ECS into the JBEngine. The past couple of attempts have been a complete failure and there is a good reason for this:

1. There is a lot of template code so what would normally be a simple error is a lot more confusing to figure out.
2. There are a lot of changes to be made as the new system is completely different syntactically thanks to the CRTP and template argument lists. This is easier to use but means a lot of code changes.
3. The new approach now also has the "Systems" store a list of entities they work on rather than the entities storing what systems work on them.

I realised trying to shove this new piece of code into the main codebase isn't going to work as there are still a few bugs in terms of functionality with this new ECS and it's just too big a refactor.

So instead I have decided to flesh out the new ECS with a few of the components and systems that are already created in the old approach. The main ones I'm going to go for is the transform component, mesh component and then the render and movement systems. This is the minimal amount of work I thought I could get away with to get this ECS rendering.

The next thing I will be doing is migrating across a few libraries such as the Renderer library and also the JBEngine main library. I believe with very few changes I might be able to get a window and some basic entities rendered. The Renderer library won't need any work but the JBEngine one will need quite a few. I am hoping that If I create an Interface for the Entity Manager I will then be able to switch out the old ECS for the new one and write some simple client code for creating a few entities. 

This all sounds really simple and I am hoping it will all go smoothly.

So I haven't done any dev for a week or so, this is a combination of being putting a lot of time into work at the moment and also because I've just got a new computer.

I initially was in more of a test role at work but after a bit of pushing and a little bit of extra hard work I've managed to get myself as part of the dev team on one of the new projects which is great. I have had to learn a lot more over the past week or so to do with IBM's specific development tools and about their processes.

I am currently at the design phase of a new project and it is great as I'm getting to be involved with the meetings with system architects and getting to add sections to the main design document. At the moment there is a lot of prototyping and trying out various methods and tools to see what could work so it is all very fluid and quite fun.

At home I've just put together my new computer which ended up taking a while as I didn't realise that I would need a fresh install of Windows 7 (as the drivers would be different in the new mobo) and forgot to create a boot disc before ripping the thing apart.

Anyway after doing a fresh install I have now got to reinstall most of my development tools and do a load of windows updates, and basically get everything back to how it was. sigh.....

The positive is that it is really quick! And it will be even quicker once I've bought a new GFX card.

As another point, with spending so much time on Linux at work I have decided to use my other hard drive for a Ubuntu Install. I am hoping to one day get the JBEngine up and running on Linux, It is quite a long way off but I've used all cross platform libraries so far so the work shouldn't be too difficult.

Anyway going forward I basically need to get Visual Studio installed and then start looking at getting this ECS put into the engine as it's really starting to bug me.

Cheers :)

Okay so I had a go at changing the project libraries to DLL's and although I think It might have made a few things easier there are a lot of complications and changes that come along with that. I just don't see it being worth it and here is why: 

So I tried creating a DLL of one of the smallest libraries I have, the sound library. To make the changes for this I had to add the export syntax to all the classes that could be accessed. I also had to export the std classes I would need. This ended up being a vector<CSound*> forward declaration and the string class. This would lock people into a specific version of the stl and I didn't really want to do that. 

All in all I just thought It was a lot of work to be done to not actually get that much benefit. I think maybe in the future I might have a look at it again if I want to reuse just one or two libraries. It would also force me to create better interfaces for the library. 

Along with doing this I managed to dig out a few of the source code of the 3rd party libraries I use from an old hard drive. I've rebuilt one of them ensuring the correct CRT is used but it doesn't seem to have fixed the Linker Warnings so it must be one of the other libraries I use.

So next up is still to try and integrate the new ECS into the engine. There is a lot of work to be done and first of all I'm going to try and replace the messaging system and see how that goes. Hopefully there won't be too many template related errors.

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

Okay so my first day back into my JBEngine project and I decide to try and integrate the new ECS System into the engine. What a bloody mistake that was! I started off initially tidying up some of the classes of the new ECS and got it into a state that I thought it might merge over fairly easily. 

After swapping all the files across and realising exactly how many problems there were and all to do with classes being templated I quickly realised that it was a massive mistake. 

You definitely shouldn't jump into some code that you've not looked at for months and try and implement a massive piece of new functionality. It was just daft on my part. 

As a positive though at least I have done *something* even if it didn't quite work out this time, it wasn't really a failure:
"I have not failed. I've just found 10,000 ways that won't work." - Thomas A. Edison

Something else I thought I might mention is that I'm in the process of buying a new desktop. I managed to buy a new motherboard and CPU today and after next payday I will be able to buy some RAM and I will be good to go for a while. 

I will still need to buy a new GFX card as I'm still rocking an nVidia GeForce 8800 GTS, but it's not really a necessity for now. I will see how I feel on payday and decide whether I buy one ;)

I have also got another computer that I managed to save from being scrapped at one of my old jobs and I will be taking a few pieces from my current setup and putting it in that to use as a server. That way I can get a proper Server-Client test for my networking code.

Exciting stuff to come if I can keep up the work. 

Cheers :)

I'm now about two weeks into my new job and all seems to be going well. Everyone there is much more friendly than I had first thought they would be. I had this image of everyone being a corporate drone and wanting to just get there work done and go home but luckily this isn't the case.

Over the past few weeks I have been doing a lot of training as I really had no real clue about using Linux or even the products that IBM create there. It is all very much all the things I have stayed away from in the past: Networking and hardware. I have really come to grips with it now and I see how it is such a massive industry. At the end of the day even a small business ends up needing to think about some Networking/Storage Solution.

It was my Birthday on Thursday and I was spoilt rotten as always :)

Turning 24 isn't that special though, I was hoping I could be 21 forever but that didn't seem to pan out. Anyway on the Friday my girlfriend Meg treated me to a relaxing night away in Liverpool. We stayed at the amazing Titanic Hotel and we had a great night. The hotel was huge! It is where the Titanic used to dock and they have transformed into this amazing hotel whilst still keeping a lot of the industrial features. We both had such an amazing time there and spent a lot of time relaxing in the spa as you can see from the photo's.

Anyway that sort of sums up what I've been up to. Okay so there wasn't much talk of actual development but this is the first step towards getting some done. I had my desktop unplugged and out the way for a while but I've got it setup now and I'm hoping this post will spark off some motivation. 

My only worry is that because I didn't implement the new ECS system into my engine when I had my head in the code it might now take me a while longer to get it done.

Take it easy :)

Wow it's been a while since I did a blog post. I've really let it slide for quite a while recently and basically it's because I've not been doing any real dev work outside of work. This is a bit annoying but there are a few reasons for this. 

So last post I was talking about the game I was wanting to develop with a couple of other people. I have pretty much given up on this, there were some differences in how the project should be progressed and motivation for it dropped. I have never really had any trouble keeping motivation high for my own projects so that was an indicator for me that it wasn't working. 

I am going to start back up on my JBEngine project which is great as that is really where my interests lie. I may not have as polished a game as I could using a commercial engine but I think a lot of the satisfaction will come from the fact that I've built it all myself. 

That brings me to something else I have been thinking about. I'm going to really reign in the scope of my JBEngine project and try and create a 3D version of a classic arcade game. This will allow me to create a finished game hopefully and then I can polish and have a product that I can actually say I've completed. 

I've just got myself a new job as a Software Developer at the IBM Manchester Lab. I'm pretty damn excited about it and will hopefully be a massive career boost for me. The only thing I'm really nervous about is that they use Linux which I have never used before. This past week I have been getting myself up and running getting used to using Linux for development in preparation for starting on Monday. 

I will be fairly sad to leave Inspired Gaming as it was a really fun job and I got along well with everyone there. I've learnt a lot from the people there, and had much more experience working closely with a tester and project manager than I did at Arden. 

My new job will hopefully bring a lot more experience with it being such a different area to what I'm currently used to. 

I hope to back up and running with regular dev updates soon.

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