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

I just wanted to put a quick post up about some prototyping I am doing at work. I have been given the task of creating a dummy web application which has taken me into a realm I am not familiar with at all so I thought I would talk about it a little. 

I basically had total control over what technology I used for this application and someone suggested to use Perl as people had used it for other application we have. I really didn't want to use Perl and there is a couple of reasons for this:

1. If I have to learn a new language I would rather it be one that I like the look of
2. I would rather learn one that is becoming more popular rather than one that is dying off.
3. There are a few people in work that are willing to help with this little prototype and they have more expertise with python.
4. Python has SQLAlchemy which supports both database types we will need to use.

I will now talk a little bit about the other choices I have made in terms of tech: 
I've decided to use Flask as it is a lightweight web framework which will allow me to do exactly what I need. This web application isn't complex so I didn't really want something large and all encompassing.

As the Web application has to use DB's I've decided to use SQLAlchemy as it seems fairly popular, has support for MySQL(The Test DB I am using for this) but also support for DB2(What we will likely deploy it on). 

Finally virtualenv. This is something I've never used before but it seems like it is going to be really useful as deployment to other machines can be done without worry as It won't matter about them having the correct python version or flask version installed. 

All in all it's been great, I've had to learn a lot so far and I'm finally getting the hang of how it all fits together. I've been lucky enough to have another application to use for guidance through this development and so I should have it up and running in no time.

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