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

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