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

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