Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Milestones and Interesting Topics that I encounter on my Indie Dev Journey

Entries in this blog


Why iOS's New App Store Subscription Revenue Model is Great News for Indie Developers?

[font=arial]Original Post at: jordabonser.com?[/font] [font=arial]A pre-WWDC announcement has been made by Apple to inform of a new app store revenue model, but how does this effect indie developers?[/font] [font=arial]The New Revenue Model[/font]
[font=arial]This new model is an extremely positive change for both developers and users if done properly. The model allows for subscription based revenue with the a 70/30 split in the first year moving to a 85/15 split if a user is still subscribed to the app after a year. [/font] [font=arial]Problems with the Current Revenue Model[/font]
[font=arial]The current revenue model is a 70/30 split between developer and Apple, with the main sources of income being:[/font]
[font=arial]Paid app[/font]
[font=arial]Free app with Adverts[/font]
[font=arial]Free app with in-app purchases[/font]
[font=arial]Paid Apps[/font]
[font=arial]When the app store was first released the paid app was the most obvious approach as that is how software has been sold for years. The main problem with this is that nobody wants to pay GBP2.99 for a game that might be fun. The risk to a user is just too high especially when you combine this with developers that abuse this risk by saturating the market with low quality games as a get rich quick scheme. Even if it is a quality game, a user may not know whether they will actually like the game which is why the other approaches spawned.[/font] [font=arial]Free apps with adverts[/font]
[font=arial]This approach was often used to allow a developer to get there app to the widest audience. If all users could use the game without paying then the barrier for entry is non-existent. The problem with this is that due to low screen real-estate these apps caused frustration. This approach was often used in combination with paid apps but there was a difficult balance between how much you should give for free. If you give too much then there is no reason to buy the paid version. If you give not enough then the user will just be frustrated and not bother with the app at all.[/font] [font=arial]Free apps with in-app purchases[/font]
[font=arial]?This approach has become much more popular over recent years as a way of keeping the barrier for entry down but also having a way of gaining revenue. The problem from a development point of view is that there is a risk in that the game would need to be such a high quality to make users want to buy additional items in the game to further their progress. This often discouraged indie developers from this approach and was left to the large development studios that had the time and resources to ensure that high quality.[/font] [font=arial]How will the Subscription Model Solve these Problems?[/font]
[font=arial]The advantages that I'm going to talk about are reliant on Apple implementing the model to allow:[/font]
[font=arial]low subscriptions i.e. as little as 10p, 5p[/font]
[font=arial]users to freely end the subscription on a monthly basis by uninstalling the app i.e. not be contracted to pay the subscription for 12 months.[/font]

[font=arial]?As a user I believe that this new revenue model will essentially create games of a much higher quality. Indie developers will now have an incentive and a means to fund the on-going work to create content for a game. Indie developers will also have less risk when coming up with game ideas. A cool idea for a game or a unique mechanic can be released into the wild with a few levels to gather user feedback in a similar way to how Beta's work. The users will be more inclined to try a game if they can potentially pay just a low cost one month subscription to try it out. If this idea takes off then more content can easily be created without the developer having to staple on some annoying revenue scheme such as in-app purchases. If it doesn't gain popularity then the developer can move on without having invested too much time. Users can play a new game without having to put up with any annoying adverts or in the knowledge that they will never be able to complete it without buying something from an in-app store. This will allow them to actually be immersed in the game in the way the developer originally wanted. To summarise I believe this new model will support creativity and give reassurance to users and developers:[/font]
[font=arial]Users will be able to try apps out without fear of being ripped off.[/font]
[font=arial]Developers can create apps without the fear of not being rewarded for their time and effort.[/font]
[font=arial]I believe I would actually consider becoming an iOS developer if this subscription is done the way I hope. Cheers[/font]




CMake: Changes for Linux

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. [font=arial]Working with vcxproj2cmake[/font]
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! Creating Cross-platform code
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:
part of the bounds header:
[code=:0]void Union(Bounds& bound);void Union(vec3& v);
implementation of Bounds Union function
[code=:0] 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. 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:
code issues
cmake issues
library compatibility issues.
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.




OpenGL Vulkan and What to expect this year...

[color=#000000]Originally posted at: [/color][color=#000000]http://www.jordanbonser.com/blog/february-16th-2016[/color][color=#000000] on 16th February[/color] [color=#000000][font='Open Sans'] 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. [/font] [font='Open Sans'] 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 I 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:[/font][/color] [color=#000000][font=Roboto][size=2] [/font][/color] [color=#000000][font='Open Sans'] 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?[/font][/color] [color=#000000]So what will I be doing this year?[/color][color=rgb(102,102,102)][font='Open Sans']
[color=#000000]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:[/color]
[color=#000000]Getting my Space Invaders game finished off, and I mean fully polished![/color]
[color=#000000]Developing my skills in Blender.[/color]
[color=#000000]Slowly making parts of the JBEngine OpenSource.[/color]
[color=#000000]Trying to contribute much more to the OpenSource Community.[/color]
[color=#000000]Getting stuck in to Vulkan, hopefully integrating it with the JBEngine at some point.[/color]
[color=#000000]Making the JBEngine Cross Platform.[/color]

[color=#000000]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:[/color] [color=#808080][/color][/font][/color]




2015 Post-Mortem and What's Next...

[color=rgb(102,102,102)][font='Open Sans'] [color=rgb(0,0,0)][font=arial] Whilst trawling the [/font][/color]gamedev.net[color=rgb(0,0,0)][font=arial] 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...[/font][/color] [color=rgb(0,0,0)][font=arial]2015: Looking Back[/font][/color] [color=rgb(0,0,0)][font=arial]Game Project[/font][/color]
[color=rgb(0,0,0)][font=arial]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![/font][/color]
[color=#000000][font=arial]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++. [/font][/color]
[color=#000000][font=arial]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.[/font][/color]
[color=#000000][font=arial]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. [/font][/color] [color=rgb(0,0,0)][font=arial]Career and Development[/font][/color]
[color=rgb(0,0,0)][font=arial]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. ?[/font][/color] [color=rgb(0,0,0)][font=arial] Inspired Gaming?[/font][/color]
[color=rgb(0,0,0)][font=arial]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:[/font][/color]

[color=#000000][font=arial]Proficiency with Visual Studio[/font][/color]
[color=#000000][font=arial]Better Multi-Threading Knowledge[/font][/color]
[color=#000000][font=arial]Visualising Program Architecture[/font][/color]
[color=#000000][font=arial]Working on a single project through Requirements/Design/Implementation/Test and Deployment[/font][/color]
[color=#000000][font=arial]Working closely with Project Managers/StakeHolder and Testers.[/font][/color]
[color=#000000][font=arial]Time Management?[/font][/color]

[color=#000000][font=arial]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.[/font][/color]
[color=rgb(0,0,0)][font=arial]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.[/font][/color] [color=rgb(0,0,0)][font=arial] 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.[/font][/color] [color=#000000] [font=arial]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: [/font][/color]
[color=#000000][font=arial]Learning to various Linux distributions[/font][/color]
[color=#000000][font=arial]ssh'ing onto various machines and having to perform tasks using the command-line only[/font][/color]
[color=#000000][font=arial]Using Eclipse[/font][/color]
[color=#000000][font=arial]RTC (Rational Team Concert)[/font][/color]
[color=#000000][font=arial]python, with Flask, SQLAlchemy and virtual env[/font][/color]
[color=#000000][font=arial]Using Virtual Machines[/font][/color]
[color=#000000][font=arial]Connecting Hardware/Server Room knowledge[/font][/color]
[color=#000000][font=arial]People Management/Project Management skills[/font][/color]
[color=#000000][font=arial]Program Design[/font][/color]
[color=#000000] [font=arial]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.[/font][/color] [color=#000000] [font=arial]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.[/font][/color]
[color=rgb(0,0,0)][font=arial]?Social Life[/font][/color]
[color=rgb(0,0,0)][font=arial]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.[/font][/color]
[color=#000000][font=arial]?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.[/font][/color]
[color=rgb(0,0,0)][font=arial]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.[/font][/color] [color=rgb(0,0,0)][font=arial]Conclusion[/font][/color]
[color=rgb(0,0,0)][font=arial]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.[/font][/color] [color=rgb(0,0,0)][font=arial]Happy New Year [/font][/color][/font][/color]




Entity Component System: Messaging with CRTP

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 MessageListener{public: virtual void HandleMessage(MessageType* message) = 0;};class MovementSystem : public System, public MessageListener, public MessageListener{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(this); mMessageManager->RegisterListener(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( newEnt ); newEnt->AddComponent( newEnt ); newEnt->AddSystem(); messManager.SendMessage( 40.0f, 0.2f, 0.0f ); messManager.SendMessage( 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.





Level Editor Export and massive refactor!

[font=verdana] Exporting...[/font][color=rgb(90,90,90)][font=Arial]
On Thursday I managed to get the Export of the Levels to work. This involves exporting the Assets ( Meshes, Textures, Sounds ) and the Entities( Components, Data Components ). After doing this the only thing I had left to do is allow editing of the rotation of the entities, which posed a problem. Up until now I had been directly editing the Matrix of the Mesh Instance I had selected. This was fine except to do rotation I would need to store the Euler Angles that could be edited from the User Interface.[/font][/color]
This got me thinking, I should be using the Entity Component System(ECS) for all of this data realistically, and I will also be wanting to edit values of the Data Components from within the Level Editor as this will make entity creation much better. In my current system for ECS there isn't any way of getting a Data Component for an Entity without doing a dynamic cast based on some sort of ID which could potentially go wrong. So I started looking at different solutions for ECS since my first initial implementation. I came across this post: ECS, Component, Entities and Systems, which suggests the use of the Curiously Recurring Template Pattern(CRTP) for the ECS. [/font][/color]
[font=verdana]First Attempt[/font][/font][/color][color=rgb(90,90,90)][font=Arial]
Most of Thursday night was spent refactoring my current ECS from a virtual inheritance style hierarchy to this CRTP version. Needless to say after a lot of Linking Errors and all sorts of crazy going on I decided to scrap it and revert my changes.[/font][/color]
[font=verdana]Second Attempt[/font][/font][/color][color=rgb(90,90,90)][font=Arial]
So for my second attempt I decided to create a seperate project for my ECS and get it all set up with the templates before integrating it into the engine. I am part way through this, I've got all the Components and Data Components working I just haven't dealt with the messaging yet. I have really mixed things up, instead of storing Components within the entity I have created pools of all the same types and they just have reference to their entity. This way has a few benefits such as cache coherency,

the updates will also be Component Priority dependant rather than Entity Creation dependant. This approach will also give me better opportunity to perform multi-threading when the time comes, each pool could use worker threads to update chunks of the Components.

One thing I am likely to change is the wording I previously used, in most descriptions of an ECS the words System and Component are used where as mine uses Component and Data Component which really confuses things as:

Component = Data Component
System = Component

For the sake of anyone wanting to use the Engine and reading up on Component Systems it seems more appropriate to use the most common terminology.

Okay so finally a demo of what access to the new Components will look like:[/font][/color][color=rgb(90,90,90)][font=Arial]
auto posComponent = entity->GetComponent();also as I have used Variadic templates so the adding of Components to entities is clean and simple:

entity->AddComponent( x, y, z );Okay so there is still a lot of work to be done but I'm hoping to get this all nailed pretty soon so I can really start using the ECS.

Cheers [/font][/color]




Level Editor and Game GUI working!

[color=rgb(90,90,90)][font=Arial]I have just been implementing the two different GUI's for the Level Editor and the game project. Currently they aren't that impressive, although the Level Editor GUI does let you alter Entities positions in the scene which is great.[/font][/color]
[color=rgb(90,90,90)][font=Arial]The Game's GUI is just a simple box that lets you choose whether you want to start a Client or Server Game so it does pretty much exactly what the old GUI did ( Except it looks a lot more shiny ). [/font][/color]

[color=rgb(90,90,90)][font=Arial]Anyway enough talking here is a quick video of the two GUI's in use:[/font][/color]


[color=rgb(90,90,90)][font=Arial]Things are really starting to come along and my aim for this week is to have a bare bones Level Editor up and running. This seems like quite a lot from what is already there but the only things I need to implement are:[/font][/color]
Rotation and Scale applied to models ( Will need to store Euler Angles )
Add GUI functionality for displaying all loaded meshes
Add GUI functionality for adding one of the meshes to the scene ( Might just spawn at 0,0,0 )
Make the assets export on one of the File Menu drop down buttons

[color=rgb(90,90,90)][font=Arial]I would say the largest chunk of work is going to be the parts with the GUI, particularly as I'm still new at using JavaScript but I should be able to throw something together pretty quickly. [/font][/color]

[color=rgb(90,90,90)][font=Arial]It is all very exciting, as an added note I have decided I am going to go with the .md3 .md4 .md5 model files for import into my engine. There seems to be pretty solid exporters out there for blender and it is the most stable file format that works with my engine, specifically the animations. [/font][/color]

[color=rgb(90,90,90)][font=Arial]I should also mention I have used models from another project as placeholders for now, here is a link to the sourceforge project: [/font][/color]Mundo Game

[color=rgb(90,90,90)][font=Arial]Anyway until next time,[/font][/color]
[color=rgb(90,90,90)][font=Arial]Cheers [/font][/color]




Awesomium Library and a massive tidy up!

[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[color=rgb(90,90,90)][font=Arial] Project Includes and Libraries[/font][/color]
[color=rgb(90,90,90)][font=Arial]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.





New Job: Inspired Gaming and getting back on track...

[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[color=rgb(90,90,90)][font=Arial] Back to work: Awesomium continuation...[/font][/color]
[color=rgb(90,90,90)][font=Arial]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 [/font][/color]




Awesomium Refactor and Input Changes

Awesomium Refactor and Input Changes

[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[color=rgb(90,90,90)][font=Arial]At the moment I have:[/font][/color]

[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[font=arial]Input Changes[/font]
[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[color=rgb(90,90,90)][font=Arial]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 elements in the webpage then the click's after this would only be sent to the Webpage and not to the Game Scene. [/font][/color]

[color=rgb(90,90,90)][font=Arial]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.[/font][/color]
[font=arial]What's Next?[/font]
[color=rgb(90,90,90)][font=Arial]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.[/font][/color]

[color=rgb(90,90,90)][font=Arial]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 [/font][/color]

[color=rgb(90,90,90)][font=Arial]Keep coding.[/font][/color]




Level Editor: Input Refactoring & Awesomium Integration

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.[/font][/color] Input Refactoring[color=rgb(90,90,90)][font=Arial]
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. [/font][/color] Awesomium Integration[color=rgb(90,90,90)][font=Arial]
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:[/font][/color][color=rgb(90,90,90)][font=Arial]
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.[/font][/color]




JBEngine: Awesomium User Interface and Artwork progress

This past couple of weeks I've been playing around with 3ds max a little more and working on creating animations. Using these animations I realised that my engine can't handle FBX files very well, and in fact the example Model Viewer I got couldn't either. This meant going back to the drawing board and figuring out why FBX animations weren't working. I soon narrowed it down that the use of FBX and the
biped objects in 3DS Max were making it really difficult to import into certain pieces of software. Due to this I am not resorting back to using Collada as my main import type as it is the most standardised and it will work for animations as long as I don't use the biped.

This has caused a lot of frustrating as now I am having to create all my bones and animations by hand, in the long run I think It might be slightly easier as the biped can't really do everything I need it to.
[/font][/color] Awesomium[color=rgb(90,90,90)][font=Arial]
I found a piece of middleware called Coherent UI which allows the use of HTML webpages to display GUI's in games and other native applications. This seemed really powerful and from the look of their website appeared to do everything I wanted it to do. The only issue is that their licenses were a bit limited for what I needed it for. I realised afterwards how useful this middleware would be to me as I would then not need to create all the GUI elements for the engine and would increase productivity rapidly, so I went on the lookout for a similar library which i could use. This is when I stumbled upon Awesomium. It also allows application to take a webpage and render it to a texture, more than this you can interact fully with it using JavaScript for callbacks to C++ functions.

I have been playing with Awesomium over the past week and have managed to get something up and running, rendering the google homepage and allowing some interaction with it. There is still plenty more to be done and it does seem that there is a large performace issue with it at the moment. I believe this is due to the texture being overwritten almost every frame and then uploaded to the graphic card again, although I am yet to profile it.

If i can manage to get these performance issues out the way I will proceed further with it and hopefully be able to throw together a new UI for the game and also the level editor. This will give so much flexibility and also the ability for users to mod the game. they can simply create their own UI by overwriting the current webpage with whatever they would like to display.

Plenty to be looking forward to and I will hopefully have a demo usage of the awesomium up soon.





JBEngine: Level Editor Export, Artwork and Library updates

Okay so I really haven't managed to get much done in terms of coding but I have learnt quite a bit that will hopefully be very useful.

Okay so I started off by creating the Export part of the Level Editor which means I now have a full pipeline for level production, I can create assets, place them in the scene and then save them to an XML file. This XML file can then be either imported into the Level Editor again for further work or can be used in the game. [/font][/color] Artwork[color=rgb(90,90,90)][font=Arial]
I have been getting used to using 3DS Max and I have become much more efficient with it, learning to model and texture objects. I have also learnt to use the biped tools to create simple walk and jump animations.

This is when I ran into some troubles as when I exported my model to collada I couldn't get the animations to export properly. I initially thoguht this was an issue with my engine but as I tested the animation in two other assimp featured model viewers I decided it was an issue with the file format.

To combat this I decided to try and export the model as an .FBX which worked with the modelling programs. .FBX is only supported in the newer version of the assimp library that I didn't have at the time so it was time to update the library.[/font][/color] Updating the Assimp Library[color=rgb(90,90,90)][font=Arial]
Okay so I set off downloading the newest version of the assimp library. The first time I compiled assimp it came with a setup visual studio solution so I simply had to compile the program and it would create all the files for me.

Since then they have decided to go for a CMake alternative as it is the most cross platform approach and I'm guessing take the least work on their part.

I had never used CMake before and was a bit worried about using it as it all seemed overly confusing. After reading up a bit on the internet about Make Files and how to use CMake I finally managed to get the assimp library to compile.

It was actually not as difficult as it first seemed and I will will more than likely use it many times again with other libraries that I need to update.

As a final note I still haven't got the character to display properly as there is an issue with how the bones are setup in the engine. I know this file format does work as it has worked with the model viewer so I will just need to do a little more debugging to figure out what is going on.

I really need to get something demoable very shortly as this is making me lose motivation some what. Once I have my character model in and walking round I will feel much better.

Cheers [/font][/color]




JBEngine: Level Editor Initial Development

[color=rgb(90,90,90)][font=Arial]Okay It's been a while since my last post and I have been slowly working my way through creating some of the initial GUI Elements for my Level Editor, and eventually the game. [/font][/color]

[color=rgb(90,90,90)][font=Arial]I have just added a checkbox class and an Editbox class that will allow the user to enter data. As a starting point these really are the only two extra elements I need. The editboxes are needed to allow the user to edit things like, Entity Name, position, scale and rotation and obviously the checkboxes are great for turning things on and off. [/font][/color]

[color=rgb(90,90,90)][font=Arial]Anyway enough of my ramblings, here is a short demo of some of the functionality of the Level Editor:[/font][/color]

[color=rgb(90,90,90)][font=Arial]So the video is pretty minimal at the moment but even now this is going to make life much easier than editing values in an XML file to add objects to the scene. [/font][/color]

[color=rgb(90,90,90)][font=Arial]Next steps are:[/font][/color]
Allow the user to specify an object to place in the scene
adjust rotation and scale as well ( fairly low hanging fruit )
start work on the XML exporter
Add extra GUI Elements( Dropdown list and Listbox with scroll bar )

[color=rgb(90,90,90)][font=Arial]I definitely need to get started on the XML exporter, although it shouldn't be too difficult it will be a time consuming thing to get right. I already have a specific format of how the file should look, due to having to write the importer so I want to get that nailed as soon as.[/font][/color]

[color=rgb(90,90,90)][font=Arial]The other bits and pieces are just general improvements to the Level Editor which will be implemented over time. I really want to keep this level editor as minimal as possible so I'm having to assess each of the functionality I want to add and think about whether I really need it.[/font][/color]

[color=rgb(90,90,90)][font=Arial]Happy with Development at the moment,[/font][/color]
[color=rgb(90,90,90)][font=Arial]just need to keep motivation high![/font][/color]




JBEngine: More Housekeeping and GUI Improvements

[color=#000000][font=Arial] So I have done more housekeeping, it can be sightly tedious but the feeling at the end is amazing. Just knowing that your code is abstract and reusable, along with smaller compile times is ace. I have taken out all the game specific code and put it into it's own project and the JBEngine project is now compiled as a library and linked to from the game project. I have also added a Level Editor project which is where I will more than likely be doing most of my work for a while. This is going to give me a great chance to test out my GUI elements fully and add any new bits that might be necessary. [/font]

[font=Arial]After doing an initial look through of my GUI elements I realised I needed to sort out how the font size would work with the Text and also that the calculations for figuring out the actual size and offset of the images was far too complicated. I have managed to sort out the calculations, which took a while as I was getting confused between user co-ordinates, internal co-ordinates and then screen space co-ordinates. [/font]

[font=Arial]User Co-Ordinates: 1-100[/font]
[font=Arial]Internal Co-ordinates: 0 - 1[/font]
[font=Arial]Screen Space Co-ordinates -1 to 1[/font]

[font=Arial]To overcome this, instead of passing the scale and offset of the textures in screen space coords I instead changed the Quad I was using for the full screen from ( -1 to 1 ) to ( 0 - 1 ). This meant that all my calculations could be done in the 0 - 1 coords and then finally in the vertex shader just do a conversion to get the vertex positions in ( -1 to 1 ). [/font]

[font=Arial]It was all a bit of a headache really but the code is much simpler now and it also made it easier to sort out how the font sizes would work. I ended up settling on using pixels to decide font size, meaning that the text will scale when the resolution changes. This seems to be the way most games are doing it now. This is still to be fully implemented but It shouldn't take too long. [/font]

[font=Arial]The Level Editor should come along fairly quickly as the majority of the functionality is there already within the engine so it will just be a case of setting up all the GUI elements and adding the logic for the editor. This is still a sizable amount of work and could easily get out of hand if I don't keep tight goals on it. [/font][/color]

[color=#000000]Should be some videos and images soon so these posts don't seem so boring.[/color]
[color=#000000][font=Arial]Plenty to do so I best get cracking [/font][/color]




JBEngine: Housekeeping

[color=rgb(90,90,90)][font=Arial] Recently I have been looking at the overall design of my game/engine and decided it needed a bit more housekeeping to ensure that there is a good level of abstraction so I can replace or rip parts out if I ever need to. A while back I managed to create two seperate libraries for Sound and Networking, meaning that those two could be used within any other project fairly easily.[/font][/color]

[color=rgb(90,90,90)][font=Arial]This time round I'm having a look at seperating out all the rendering code into it's own library which is a little bit more difficult as it is a much larger portion of the codebase. Whilst doing this I realised that the rendering code and also parts of the engine code both rely on some of the maths classes that I've created so I decided to seperate that out as well and have both libraries depend on the Maths Library. [/font][/color]

[color=rgb(90,90,90)][font=Arial]After some thought I cracked on with doing the housekeeping and started by splitting the GUI parts of the rendering from the normal scene rendering as the GUI part will eventually be going into it's own library. For now the GUI parts are staying as part of the Engine as I didn't want to try and do too much at once. This new Renderer Library is now complete along with the Maths Library. [/font][/color]

[color=rgb(90,90,90)][font=Arial]In total I now have these libraries as part of my visual studio solution:[/font][/color]

[color=rgb(90,90,90)][font=Arial]The next part I need to do is to take out any application specific code that I have put in the JBEngine project. This will allow me to compile the JBEngine as a library and use it as part of a new project which will either be the game or the level editor or any other application I want to use it for.[/font][/color]

[color=rgb(90,90,90)][font=Arial]All is going well just need to crack on with these few bits and I will feel loads better about the whole design of the engine...[/font][/color]
[color=rgb(90,90,90)][font=Arial]Keep Coding [/font][/color]




JBEngine: Demo Functionality and Physics

[color=rgb(90,90,90)][font=Arial]I have just been working on a couple of bugs with my networking that have been annoying me, particularly the camera and player model becoming out of sync and also the spells were being fired in the wrong direction. I have now fixed both of these issues and I can now seamlessly fly around my demo level shooting spells, which is a relief.[/font][/color]

[color=rgb(90,90,90)][font=Arial]Next week me and a colleague are going to demo some of the functionality that has been added to our projects. We have been doing this every so often as I think this keeps motivation quite high and can spark some interesting discussions about implementations. For this demo I want to be able to have two clients connected to a game, flying around damaging each other with spells. This does seem quite achievable but It means I will need to put some extra work into the physics integration in my engine. [/font][/color]
Physics so far...
[color=rgb(90,90,90)][font=Arial]Currently the physics implementation is fairly minimal, allowing for collisions to be resolved and callbacks to be triggered for the two entities involved. I want to go much further than this and allow the new bounds functionality to be used for the physics shapes. I also want to allow the change of certain properties like restitution and friction for each physics object.[/font][/color]

[color=rgb(90,90,90)][font=Arial]Currently the physics code is not being sent across the network which is also something that will need to be resolved. each client will still need to do some sort of collision resolution to keep the game looking smooth, but the server will once again need to have the overall say so this will be a challenge. [/font][/color]

[color=rgb(90,90,90)][font=Arial]I'm excited to get this demo up and running [/font][/color]




First Entry: What I have been up to so far...

Over the past year or so of starting at my new job I decided to start work on an OpenGL renderer as it would increase my knowledge and put me in a better position to work my way into the 3D side of our CAD Software.

Since then this project has escalated incredibly and is now the Engine Framework for what will hopefully be my first released game. This is still a far way off especially with motivation coming and going at random intervals, which is a massive problem with an Indie project.

Here is a list of some of the current features and libraries used in the JBEngine:

Model Importing with Textures and Animation
Phong Lighting
Skeletal Animation with Blending
Physics ( Very Minimal )
Networking( Client/Server )
Basic GUI and Bitmap Font Rendering
Entity Management
Input Management
XML based Asset/Entity Importing

nVidia Physx

This post is mostly just a motivational spur, as seeing what work I have done already will hopefully give me the energy to carry on with my development.

To see some of the progress and the decisions I have been through over the past year or so, you can check out my main blog at:


Upcoming tasks are to develop the Networking further, working out a couple of bugs. I have also just about got Camera Picking working which is a big step toward making a small level editor for my game although the GUI will need Improving considerably before then.

Cheers :)



Sign in to follow this  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!