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

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

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

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

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

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

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

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

So I managed to get most of the awesomium refactoring done last night. I now have an Awesomium library that depends on the JBEngine library. the JBEngine now makes use of a IGUIManger object and I have created a new AwesomiumGUIManager in the Awesomium Library. 

So this is now much more abstract and I will be able to very easily create a different GUI for the Game project simply by linking the new awesomium project and adding a new HTML page. I will make a video of the two different GUI's in use as soon as I get them up and running. 

There is still quite a lot more to do before the Awesomium code is flexible enough that I am happy with it. I need some standard way of communication between the GUI Layer and the Game Logic. As soon as I have that set in stone I can really start to make full use of the user interface.

After realising how large my project had slowly become I thought it was time to see where I could trim it down.

First of all I realised that a lot of my include files for each project were repeated, and so were my static library files. just checking a couple of these I realised that had to change as some of the libraries were 50-100mb which is just not reasonable to have dotted all over the place.

I have now created Include and Lib Folders at the solution level of my directory. This will also reduce the risk of having different versions of a library or include files for different projects in my solution. All in all it seems like a good move. I have also tried to get rid of any files/directories that projects wouldn't need to know about. There were a few that were left over from copying project files and directories when creating new projects.

All this changing round has taken me a while though, flicking through different projects altering Lib and Include Directories actually takes a large portion of time.

I'm pretty damn motivated at the moment which is great :) 

hoping to get something a little more impressive to show fairly soon. 

Cheers.

Over the past couple of months there has been quite a lot going on in my life, namely moving to Manchester City Centre and then more recently getting a new job. Unfortunately with everything going on something had to give, and that ended up being my project development. 

Now I am a little more settled I am hoping to start back up again and with extra experience I have gained since starting my new job. So far I have really enjoyed working at Inspired, I am finally able to use Visual Studio again for my day to day work which is a massive plus! 

In terms of the work I am doing at Inspired I'm not sure I am allowed to divulge exactly what it is, but It is all exciting stuff and I'm really looking forward to the direction that the company is heading. 

Okay so I need to re-motivate myself and what better way to do it that with a little refactoring. I have given myself a couple of hours tonight to crack on with getting the awesomium code into it's own library and creating an abstract way of creating User Interfaces.

Currently the Awesomium code is all dumped in the Level Editor project, which means I can't even use this stuff within the game at the moment. The Awesomium code makes use of the Texture and GUI Classes which I am thinking I would like to change. I will keep the old method of creating a GUI but I am now going to have an Interface IGUIManager which I will then derive a new manager for dealing just with the Awesomium GUI.

The main reasons for this is because the other GUI Manager has lots of features which are just not necessary for the Awesomium stuff and it will just bulk up the source code. I am hoping to get rid of the old GUI code all together once I clarify that the Awesomium code does everything I need.

So there is the plan, wish me good luck :)

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

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

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

At the moment I have:

• JBWebCore
• JBMethodHandler
• LevelEditorMethodHandler
• JBWebView

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

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

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

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

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

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

Keep coding.

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

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

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

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

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

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

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

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

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

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

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

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

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