Pixel's Development Blog

Work on my game projects currently suspended

2011-08-03T10:04:00.005+01:00

Having discovered the product EKI One from Artificial Technology in Germany I have currently suspended all my game development in order work on integrating this product with Leadwerks Engine 2.

EKI One is an AI Toolset comprising path finding (uses Recast), steering mechanisms for dynamic avoidance and FSM based tools for defining scripted behavior for both NPCs and non character based applications. Although I had made considerable inroads into providing my own path finding solution combined with a working FSM system and was having success with this I always considered Nav Mesh based solutions superior to my own hierarchical grid based system and I have only basic FSM support and no steering system either.

Whilst it's nice to develop these systems yourself, it takes a lot of time and research and having looked at what EKI One offers I was blown away as it would take me years to develop a comparable system with nice toolsets and then it would probably not be anywhere near as well designed as theirs!

That said it was a simple decision to abandon ongoing work on my existing projects in favor of integrating their system with Leadwerks.

Progress has been steady so far. I have practically completed the initial phase which was to write a Leadwerks to EKI One exporter to get the Leadwerks geometry into their Configurator/Sandbox so that nav meshes can be generated allowing AI design to be carried out in their application.

The second phase is to integrate their engine into a Leadwerks framework so the exported AI solution can be used in our Leadwerks projects. This work is ongoing.

Below is a demo video of my Stranded Test Level in Leadwerks imported into EKI One and a simple random movement agent in action:

Integration and consolidation

2011-05-29T16:44:00.004+01:00

It’s been a while since I've posted. The main reason for this being the fact that I got side tracked by virtue of a 'Make A Game In A Month' competition into having a go at making an Adventure type game. The intension was to use what I had and add additional functionality to enable the engine to handle Adventure/RPG style games and produce a small level example.

As it turns out I bit off far more than I could chew and, to cut a long story short, never managed to complete the project inside a month. That said I did manage to produce a complete working inventory system along with a 2D graphics manager so I could pick items from the game world and display them in a skinable inventory box and also display info on them and display other items such as Journal pages/maps etc. All of these used my input manager allowing external keyboard/mouse button assignments to be attached to them. The 2D Graphics manager also should with some additional coding be able to handle skinable menu systems quite easily.

I really enjoyed doing this and also designing a small test level set in medieval times and experimenting with other level items like waterfalls and flowing water.

Suffice to say, I have decided to fully integrate the new features into my game engine in such a way that it is switchable between FPS and Adventure/RPG genres and will inherently support both.

The first stage in this has been to bring my engine Editor up to the latest version of Leadwerks which has introduced a few issues. Some were directly associated with changes Josh had made to the engine since version 2.31 which was the version I was previously working with. Most of these have now been resolved (the change to previously filtered pick items in 2.32 being the one that had me scratching my head initially as I use a lot of picking and it just broke a lot of my functionality). The other main change/update involved leaving framewerk behind and switching to the encapsulated framework. The main reason for this was the need to gain some of the later features such as the contrast/saturation etc setting support and the ability to use the existing LUA scripts and objects. The conversion is now complete all be it with some outstanding issues with refraction and some transparency issues with muzzle flash animations.

The second stage will be to add much better support for external definition of animated NPCs and the loading of such data and an expansion of my existing NPC/AI framework to make it easier to support multiple NPCs with their own individual AI.

The third stage will be to integrate and consolidate the Adventure/RPG functionality from my Kingdom Of Soul game code and the changes to my engine in the Editor such that both will support the full code features.

Following the successful completion of this I will be working initially on expanding the NPC and AI support for the Adventure game and expanding on the test level to accommodate it.

NOTE: Stranded has not been abandoned, the changes to the animation and AI support will benefit Stranded too and after I have completed a small playable level of the Adventure game I will return to Stranded.

Demo of the inventory system:

Demo of animation and pathfinding:

Demo of animated waterfall:

Improved AI and Finite State Machine Tracking

2011-03-10T22:50:00.004Z

Work continues with the AI and in order to facilitate FSM design I've today updated the Editor to add support for getting real time feedback on screen of the NPCs Alert States and current FSM states. Select the State Feedback Option on the NPC tab and click on the NPC you want to track and State information will be displayed in real time. This combined with the ability to slow the animation rate right down allows useful feedback of how the FSM is behaving for any given NPC and in game situation.

Animation Overview

2011-02-22T14:02:00.009Z

It’s been suggested that I might give a bit more insight into my approach to NPC animation handling within my engine which I'm happy to do.

As a result of my inexperience of game engine design I probably have a rather simplistic view still on animation and the control of it within modern game engines. It strikes me however that there are two prominent approaches to this as follows:

Throw as many professional animators at the job as you can producing as much animated output as possible for as many in game scenarios as you can with sufficient animation support in the engine to enable this. The pros to this is you can have animators tailor the animation to fit your game precisely providing high quality animation for all scenarios. The downside of this is the requirement for large teams of animators and a huge size of animation to be handled and the probable complexity of scripting all this.
Design or use a third party locomotion system designed to take a few basic animations attached to characters and through the use of sophisticated forward placement detection, IK and animation blending produce all other animations from these basic sets. The advantages are you get a lot more animation from a fairly simple input set (which is great if you are buying inexpensive 'off the shelf' characters where you don't have access to the animator to tweak or amend animations as required.
Also you gain realistic foot placement and interaction with your game environment, so proper foot placement on steps and slopes. No more 'feet in the air' when walking down slopes for instance! The downside is the fact that these are fairly complex to design and are only now becoming prominent even in the AAA game design studios. Also, non I have seen are perfect and on occasions you can see odd animation or mistakes.

For most Indie developers, the first option is probably still the most widely used so be it with only a small team or even a single animator. With careful level design a lot of the issues can be minimized and the amount of separate animations required reduced (for instance, keep all your step heights the same). Being able to tweak or amend the animations during the
test phase is a huge advantage in providing a final polished look to the animation.

Rune's locomotion system in Unity is a classic example of the second approach and if you’re lucky enough to have access to this level of procedural animation support then it’s very tempting to use it.

From my point of view, concerning my engine design and the use and control of animation within it, I hadn’t deployed anything more sophisticated than the ability to load characters and their animations and use the simple animate function in the Leadwerks API to control movement until recently. I guess I was eager to get on to the design of AI and get some real interaction and game play going.

However, once I had some reasonable AI in place and started testing it, my simplistic animation support was evident ... it didn't look very good!

As I am a programmer, I have only a rudimentary understanding of character rigging and animation. I'm working with an animated skeleton that provides most of the basic animations I need. I don't have access to a skilled animator at this stage in my project; so my decisions and thought train regarding solutions are obviously coloured by this and reflected in some of the decisions that I've subsequently taken.

THE PROBLEMS

The main problems broke down into the following areas:

I had no coded animation blending support, so although all the support was there to have NPCs walk or run along routes determined by my path finding functionality they didn't start and stop smoothly.
No curving through direction changes on paths, this stood out like a sore thumb and obviously looked very un-natural.
Foot skating issues from time to time. Fairly easy to sort out with just a fixed speed for each character when running or walking. But how would you determine this when blending animations, say an idle to a run, where the animation will actually accelerate in the initial blended stage.
Poor character behavior when climbing steps, with having the character mesh parented to the character controller at this point the instant climb in step height was replicated in the character making its movement look very un-natural yet again.
The obvious need to provide some animation support that was inherently just missing, such as the need to aim a characters gun at an enemy that may well be at a different height. Also the need to add some head turning animation to characters in general to simulate them looking around as they move, especially in states of heightened Alert! Also some general gesticulation movement to simulate NPCs communicating with each other. As the first issue is a variable with no fixed animation able to address this it seemed procedural animation would be a good candidate for this and would also provide a solution of the other issues.
The classic feet in the air issue when walking down slopes (as seen is so many games of the past and even today - Dragon Age being the most recent one I recollect seeing it in).

THE SOLUTIONS

Redesign my basic animation support routines.

This involves creating a queued method of adding animations where animations along with some controlling flags, values etc could be simply added to a queue and then popped off and processed. Example flags or values would be 'now' or 'wait' (replace current animation immediately or wait till end of current animation), 'blend value' (the amount of blending to be applied), 'blend speed' etc. All of these values have default values that can be set against the animation concerned but can be overridden by values passed at run time onto the queue (predominately by the AI scripts). Special cases were introduced for animations such as right angle turns where the next to be blended animation would been to be rotated through 90 degrees and blended with the final frame of the turn. Again, this could be defined against the particular animation details for implementation by the animation engine. The character mesh is no longer parented to the controller allowing for independent control of each if need be.
Redesign my path movement control logic to include a rate of turn to be applied to directional changes resulting in a natural looking curve of the NPC's motion. Also work was required to incorporate blended stops to ensure they didn't over-run the end path location and final alignment of NPC was correct especially if a recent turn had been implemented.
Make the movement driven by the animation itself.

In order to get rid of foot skating once and for all and get round the issue of varying speed during animation blending a decision was made to analyze the animation movement ahead of the main animate call and deduce the exact movement required to always match the animation. I used the right and left toe bones for this and its given good results. Now the speed is always matched precisely to the animation even during blending which ensures perfectly synchronized motion and no foot skating under any circumstance. Motion is now directly controlled by animation speed and blending. There are some animations where automatic animation driven motion may not be required so there is a flag for disabling this against any given animation or overriding a default value at real time.
Allow independent control of the mesh height movement

The mesh, now decoupled from its character controller has its height moved at a defined rate when encountering changes in height of the controller over a threshold limit . This allows a more natural step climb feel to the NPC whether going up or down steps.

I also reduce the animation speed under these circumstances (also works on slopes) to reflect a more natural change of pace.
As yet to be programmed.

Procedural animation and blending is what I'm currently working on.
Yet to look at this.

Without an inverse kinematics solver and some trail and error I'm not sure this is possible but I'd like to get back to this at some point in the future to see if I can find a reasonable solution.

I hope this has at least been informative and welcome any open discussion of issues and techniques as this is all completely new to me. I have simply implemented solutions that occurred to me and appear to work reasonably well.

I'll post another video soon once I have the procedural animation and blending up and running and a little more AI in place.

It's never that easy is it!

2011-02-15T10:15:00.003Z

Further testing of the new animation routines now it’s embedded in the editor and using path finding revealed some more subtle issues, especially where blending was used at the end of path finding. There was a tendency to overshoot the destination point and also issues with the final orientation due to adjusting the orientation dynamically based on the target position.

All of this has now been resolved and is working well and looking very natural, so be it with a load more complexity behind the scenes.

Like most areas I've coded for in this little adventure in game engine design there always seems to be unexpected and unforeseen issues which extend the time taken to complete any particular aspect. But again it’s a valuable learning curve and the end results do justify the effort put in, which keeps me motivated.

Procedural animation next on the list which I'm hoping to start on tonight as I'm desperate to get back to the AI design with the improved animation support in place.

New Animation Now Working in Editor

2011-02-05T21:52:00.004Z

I've now successfully plugged the new animation support back into my editor and made a few improvements to the patrol code. I set up a test patrol today with 20 NPCs following an extensive patrol route. The animation looked great and really steady even when cycling my system performance up and down in real time, so well worth the time I've put into this. Having the NPCs curve through direction changes has made it look so much more natural. They automatically slow down slightly on gradients too and speed up again as it flattens out.

Whilst I was making changes to my NPC class update routine I've noticed room for improvement on some of the control mechanisms and flags that I set up for use by the NPC class’s Finite State Machine. I shall be making improvements to that before moving on to adding Procedural Animation support to supplement the skeletal animations.

I currently have about 40 procedures which I'm calling when required from the FSM to provide the necessary AI support, including the ability to post delayed state transitions triggered by timers. I expect this will grow some more too as I extend the AI capability.

Farewell To Foot Skating

2011-01-23T22:47:00.003Z

I've finally converted my animation routines to be animation driven to get around issues with foot skating which were cropping up from time to time. So now the only speed that is ever set is the animation speed and any forward motion of the model is driven by the animation itself. This is really effective with blended animations as the forward motion no longer has to be calculated independently but is now a direct function of the animation and as a result is always perfectly in sync. Controlling the movement of the model directly gives 100% perfect results. Using a character controller (as I am doing) results in a slightly looser control as you are not directly controlling the end position of a movement but effectively applying a force in a direction in order to get you there. However, in practice it's proving to be effective enough with pretty much constant motion with no skating at differing animation speeds and frame rates. I'm satisfied that this is working well enough now to plug it into my Game Engine/Editor.

Next up is work on procedural animations to be blended in with existing skeletal animations.

Latest News

2011-01-03T13:27:00.005Z

Things are developing gradually. I now have cover point functionality in place and that seems to be working nicely. The AI design is proving less of a challenge than I originally thought (at least at this point lol) but finding time is proving more challenging. I am currently working on improving the Animation support I have. Below is a short demo of the Crawler character (courtesy of Hau Nghiep Phan) in action:

New Interface In Place

2010-10-07T16:13:00.006+01:00

Having had some fun and games getting tabs and property pages up and running using the Win32 api I now have it implemented. I think it provides a much better user interface for moving forwards with and lots of room for adding more functionality. Below is a pic of the improved Editor interface when first loaded:

I'm still in the process of pluging all the functionality back into this interface but that should be completed shortly. Then it's back onto AI development with NPC groups and cover points next on the agenda.

You will probably notice that the name of the editor has changed to reflect the name I've given to my game engine.

Moving ever onwards ....

2010-09-01T17:56:00.002+01:00

Up until now the navArea Editor interface has been fine but as the amount of functionality I'm building into my editor increases it becoming impossible to stick with the original interface. So I'm currently looking at adding some tabs and property pages to make it less cluttered and more intuitive.

I'm also currently going through a GLSL shader tutorial and documenting this along with how to interface between shaders and Leadwerks. This is an area I have long needed to get into and have ignored up until now. There is an underlying requirement for some shader writing of which I'm not going to reveal anything as yet.

Meanwhile, I am also putting together the foundation of my cover point functions for NPCs as part of my AI drive. I need this to be pretty good as I want my NPCs behaviour to be convincing and quite a lot is intended to revolve around their use of cover and ability to provide covering fire whilst others move.

Following this my intension will be to look at a separate integration of LUA to enable me to expose my AI and Path Finding functionality to LUA to allow for game flow and AI to be completely scripted ensuring that the engine can be used by both myself and possibly others without having to delve into the underlying code. This is a key part of my overall strategy to produce an engine that has all the functionality built in that the majority of users would want and people can simply supply assets, a level design file(s) and script the whole game flow and AI using feature rich underlying functions exposed to the scripting language. The editor supplying whatever additional functionality is required to aid this.

Latest tweaks to the navArea Editor Path Finding display

2010-07-25T00:59:00.001+01:00

Just a quick update to say that I've now coded some additional path finding visual feedback into the Editor. The 'Test Pathfinding' function now not only displays the final calculated path in blue with an NPC walking it but also all of the grid tiles taken into consideration whilst running the A Star algorithm and displays those in red along with the elapsed time in thousandths of a millisecond using a high precision timer. It will even sequence through these in slow motion (one every 1/4 of a second) so you can see the exact sequence of checks as they occurred when the algorithm was run.

This gives the designer much more visual information on the performance of the system and allows for better fine tuning. This is great for playing around with heuristics and visualising the effects of any changes. It also gives good visual indication of where geometry layouts result in inefficient path finding using the A Star algorithm and allow you to do something about it or at least make decisions about how path finding in those areas will be executed. (This is a well recognised issue with A Star where, in the worst case scenario, certain combinations of start and end points combined with geometry can end up with it searching through practically every node on the grid before resolving the path).

As my system can divide long path searches over multiple frames where needed this is less of an issue but the visual feedback can result in minimisation of these issues by aiding the designer tweak the level design.

I'm off on holiday with my family later tomorrow (a complete break from computers for a while ) but will be concentrating on developing some real AI capability for my engine and editor on my return.

navArea Editor Demo - The final part

2010-07-19T11:43:00.002+01:00

The final part of my navArea editor demo. This demo expands on what we saw in the first 3 and shows it applied to the whole test area. It features 40 NPCs/objects all being simultaneously animated and also demonstrates my destructible object class.

No NPC combat as yet .... that's next on the list!

Part 2b

navArea Editor Demo

2010-07-06T21:43:00.010+01:00

I decided to make some short videos of my navArea Editor to give people an insight into how I create my pathfinding data and some of the AI I'm developing. The first part is complete and is split into two videos due to the time exceeding the you tube limit of 10 minutes. I have to say I've gained a new respect for people who narrate on videos as I found talking my way through it a lot harder than I thought it would be. Anyhow, please find the first three below, there is more to follow (they are best viewed in the 480p setting):

PART 1a

PART 1b

PART 2a

Latest Developments

2010-06-29T21:25:00.003+01:00

Work continues on my AI and Editor. I have today added the ability to add any number of NPCs to the level in the editor and assign patrol groups to them.

One thing that is becoming apparent is the need to change the user interface with regard to function selection and data entry as the functions available and planned have far outgrown the initial concept of the navArea editor and I'm running out of space with the original design. It's not a big job and I'll give it some thought in the next week before deciding on what to implement but I don't want it to hold me back on pressing on with the AI design and testing if I can help it.

Work continues on paper on my cover point design and that's next to be implemented and tested .

Continuing Success

2010-06-24T11:25:00.003+01:00

Things are definitely progressing nicely. I now have in place the ability to shoot NPCs along with body impact position detection and the ability to respond with appropriate animations and other responses. Shoot an NPC in the side and he bends that way, shoot him in the main body and he doubles over forwards, shoot him in the head and he dies, shoot him in the leg and his running and walking speed is reduced.

It's all great fun and really starting to come alive. Watching it unfold in the test editor is its own reward. I'm finding writing states for FSMs really intuitive and am currently only hindered in what I'm achieving by the limited time I have on an evening to work on this.

Next up is cover points and the ability for NPCs to seek cover when attacked or defending. Then it's getting the NPCs themselves to use the 'Line Of Sight' information I already have working to attack me and eventually each other as I introduce NPC Groups and develop factional fighting.

Short Update

2010-06-16T10:13:00.002+01:00

Implementation of my AI design continues with some success. I have coded in Editor support for adding infoWaypoints (waypoints which can have information tagged against them) and an infoWPGroup capability which allows you to create named groups of waypoints for Patrol sets etc and assign any number of waypoints to these.

I have also implemented a FSM (Finite State Machine) system as an initial AI control mechanism which is also working well so far (but will see how I get on with this as behavior trees are a possibility too). This has been used to create a few states to control Patrol behavior. Basically a PatrolGroup (infoWPGroup) is assigned to an NPC along with a default starting waypoint. Under 'no threat' conditions the default behavior is to Patrol. The NPC can be spawned anywhere on the level in an Idle state and will walk to the Patrol start position and then walk the set of patrol waypoints. Full path finding is used for every move to produce realistic avoidance of level geometry. I have NPCs walking patrol paths that traverse the level, walk round buildings, climb stairs and walk round balconies etc).

I'm looking to expand on the current functionality by adding NPC groups next so that various factions of NPCs can be created and also tasks and behaviors be assigned to NPC Groups as well as individuals. This will eventually lead to factions capable of fighting each other.

Also expand on the infoWaypoint functionality by having NPCs react to embedded commands in waypoints (might be pause at this waypoint for 30 seconds and look in this direction for example) or use waypoints as indicators (cover points etc).

In addition I'm looking to expand the Patrol capability to include the ability for the AI Manager to dynamically re-assign patrolling NPCs as existing NPCs are killed to ensure patrol routes continue to be manned where numbers allow.

Then my intension is to work on forming some good defend and attack AI which will form the bulk of my new development over the next few months.

I'll post a video as soon as I have something worthwhile showing. I'm knee deep in ideas, design, implementation and testing at the moment.

Editor expansion

2010-03-06T12:36:00.002Z

Have been working on re-structuring and consolidating my path finding functionality within the editor to provide a better framework for being able to implement AI; such that the AI can be configured and tested in real time in the editor using loaded levels.

The saving and reloading of static path finding data to binary files is complete and working. The framework has also been updated to allow for work to be queued prior to execution and the work load shared across multiple game loop iterations , if needed, helping to reduce the impact of heavy loads on frame rate.

Work has now started on introducing real AI capability with lots of paper based design and illustration exercises taking place to identify key components and framework structures necessary to allow this to all come together and interact successfully. This is still ongoing but I'm starting to implement elements of it in the editor as and when I'm happy their design is unlikely to change.

The big decision on whether to use fsm (finite state machines), decision trees or both is yet to be made and will probably finally be decided by practical application of both methods and the feedback obtained.

Lots to do but getting very interesting! I shall of course put a video out when I've reached a point where I think I have something worth while showing (this won't be until I at least have some real combat up and running).

Small Update

2010-02-13T00:07:00.003Z

I've decided for just now to stick with my own path finding solution but have coded the high level path finding calls in my AI manager so that I can literally substitute any path finding solution in there without affecting my AI. This was done with the intension of swapping onto a navmesh solution later, probably recast.

I've not really done much coding since Christmas due to a diversion into rigging and animating models and other things which have eaten into my time. However, it's now headlong back into the coding to get the next phase of development done. I'm very happy with some of the changes Josh has been introducing into the engine recently and the progress others are making on their projects. Leadwerks has never looked so vibrant!

Into the unknown ... I may be gone awhile

2009-12-10T18:42:00.003Z

I'm now entering what has to be the most difficult and sustained period of programming and design I have undertaken so far. Game AI is not to be taken lightly and is the next phase of my game engine development. This is completely new to me, never having coded any AI before, but I have the path finding in place which is a good foundation and my editor to test it all in as it evolves. As a result this blog is likely to go fairly quiet for the next month or two before I hopefully emerge with some real game AI capability.

Chris is continuing to make good progress with his AI solutions and I now have a recent copy of his code. Part of the up and coming weeks will be spent looking at this and deciding if that's the route I want to go down or if I want to continue with my own path finding and develop my own AI with the option of integrating elements of the libraries/code Chris has been using that may be of benefit.

Some difficult decisions ahead but I'm looking forward to getting into the detail and a whole new learning curve, spurred on by the goal of being then able to build fully interactive worlds and NPCs.

I'm sure I will emerge from this journey a lot wiser and probably with a new respect for those guys who have written AI for other engines!

Latest video

2009-12-02T01:03:00.001Z

Sorry, no sound on this as yet but thought I'd put this out anyway.

Started documenting my navArea Editor

2009-11-30T22:59:00.003Z

In case I decide in the end to stick with my own pathfinding \ AI solutions I started documenting my navArea editor tonight. It's still not completely finished but all of the components are there and it does work rather well and it's a good foundation on which to expand on. I am really interested in exploring a true nav mesh solution but it's nice to have something to fall back on.

Moving along

2009-11-29T18:39:00.004Z

Leadwerks Engine 2.3 is here and things are moving along quite nicely. I'm now fairly happy with the scenes I'm creating. There is plenty of room for improvement but I am satified I can get the type of graphical quality I was aiming for.

On the programming front Chris and I are shortly to be exchanging code modules which will mean I get to inherit the nav mesh and AI stuff he has been working on and he gets to inherit my player\user input\ weapons control module and the destructible objects. It's an exciting time as the combination of these should mean we will shortly both be in a position to realy start building the foundations of games with interactive NPCs. It's going to take a little time yet but I feel like we are entering a new phase and will finally be in a position to start designing some effective combat based missions.

The trouble with birds .....

2009-11-16T18:33:00.003Z

is they have a tendency to fly away and that’s exactly what they have been doing. Had to plug a hole in my algorithm which resulted in the occasional bird flying off into the horizon until I had none left. Have been working on a scene to show these off but need to get a bit more work done on my navArea system and basic AI first before posting.

Have also been taking a good look at the Unreal Engine SDK with its impressive toolset and attempting to ascertain the pros and cons and the size of the learning curve required.

Bird flight

2009-11-05T18:08:00.002Z

Not managed to do much recently as we have been struck with a bought of winter illlness in the family. However, I have purchased a nice animated bird model and have subsequently created a flyingBird class to control it which simulates random flight patters over a given area. It's a bit of fun really but adds to the realism when playing levels.

I have to get down to finishing the destructibleObject class next by adding the flammable object support as previously described. That's next on the agenda with this weekend looking likely.

Breakable Objects Done

2009-10-24T20:30:00.002+01:00

I have successfully coded the breakable objects functionality today and now have breakable crates up and running. Tomorrows work is going to be fun as it's the coding of the flammable objects side.

This I suspect is going to take some doing as I have to figure out a way of making fire appear to spread realistically over objects and between objects. I will need a different system of propagation as the previously coded destructible objects are all activated by collision or impact force. That's clearly not a mechanism for propagating fire. Ah well ... another day another challenge!

Work Continues

2009-10-24T09:58:00.004+01:00

Not managed to get much programming done this week but am hoping to get the code in place for normal breakable items (creates etc) and flammable objects this weekend.

I'm also hoping to have a look at Chris's integration of the ReCast navigation mesh library and see how it handles my current test game level. He's kindly given me the code to play with. Although I have my own pathfinding system in place ReCast is far superior (it was written my the Technical AI Director for Crysis after all) and it would be foolish not to look at it.

On another note I was interested to see Matt's latest video showing off his latest level for his Horror genre game. He jumped to Unity a little while back. This is an engine I had not previously rated to highly mainly due to a failure on my part to be impressed with anything much I has seen made with it rather than the potential of the toolsets which had always looked impressive. However, I have to say Matt's video looks very impressive. It's in its early development yet but the lighting and atmoshere looked spot on and the overall feel was very polished. Great work Matt!

Exploding barrels

2009-10-18T10:21:00.004+01:00

Things are progressing nicely and I now have enough of the class structures in place to have created and tested the classic 'Exploding Barrels'; almost a pre-requisite in First Person Shooters ;-)

There is a lot to do yet in terms of putting the flesh on the bones but essentially the basics are all working. Hoping to make some considerable inroads today ... all being well.

This is fun code to write :D

Destructible objects

2009-10-10T09:41:00.004+01:00

Moving on again, I'm now working on a destructible object system. Based on a prefabricated approach it will allow items to be placed in the level and assigned a series of meshes representing the broken bits of the object, details on whether the object is flammable and whether it may explode along with details on what impacts are required to trigger any of these and the explosive force released so that cascaded events can take place.

Its early days yet but I have animated explosions in place and am working on producing the broken mesh parts for some simple objects (barrels and crates). A lot of coding and testing will then follow.

As soon as I have anything of significance I'll post an update.

New system has landed

2009-10-01T22:41:00.003+01:00

My new PC has arrived and I'm really pleased with it. Have been able to run the Leadwerks Island demo with the full waves for the first time ever. Crysis also runs with everything full on and is looking really nice.

Meanwhile, I have completed the code for aquiring weapons and ammo from the level and its all working really well. Have started work on the player HUD now.

Timings

2009-09-27T22:13:00.002+01:00

The timings I measured tonight have re-assured me.

Typically the time spend in the player class update is well under 1 ms with typical values ranging from 1.6 to 2.4 ms with the weapon animations running which seems not unreasonable especially given my current slow system.

Steady progress

2009-09-27T13:07:00.004+01:00

Development of the Player Class has continued to go well this weekend and I have now added ammo control and player health.

The configurable element of this class has made it so easy to add new weapons. The total time to add a new M4 Assault Rifle this weekend was 30 minutes:

27 minutes to go the conversion of the animated model and textures to gmf format with mat files

3 minutes to add it to my engine and have it up and fully running as weapon4 triggered by the number 4 key with select, deselect, fire, idle, reload animations, weapon assigned damage force and sound complete with full ammo control.

This self configuring OOP approach has paid big dividends and the editor is now starting to look like a playable game in its own right.

I'm looking to add some HUD elements next and then support for weapon acquisition and ammo loading from placed weapons and ammo stashes in the level.

I will run some accurate timing tests later today to get a feel for the efficiency of the system and post the results. I'm hoping despite its complexity that it's still reasonably efficient and doesn't eat to far into that valuable 'between frame' time

Latest Progress

2009-09-25T16:47:00.003+01:00

Sound, muzzle flash light and animation, and bullets now implemented and all working nicely. Need to add some nice physics objects to my test level now to allow me to play with it. I'm also going to add an RPG and a suitable animation for the grenade firing and subsequent explosions.

Hoping to leave this soon and get on to designing the AI proper; now that I have the where for all for testing it.

For those who might be interested

2009-09-18T22:28:00.005+01:00

User Input Class

Basic Description

Processes user input, both keyboard and mouse and provides an event notification registration process for other Classes using a callback system for the notification. Registered notification events can be of two types, single or continuous. Single will result in a single notification following the event, such as a press and release of a key, or the click of a button. Continuous will send repeated event notifications for the duration the key is depressed or mouse button is held down.

Detailed description

Object creation

A simple constructor using no parameters is used for object creation

e.g. userInput ui;

Registration of external requests for event notification

External classes can register for callback notification of user input events they are interested in. They call the following public function:

bool registerUICallback(void* pObj, void (*p2Function)(void* p2Function,std::string EventDecriptor), std::string uiEventDescriptors);

passing a pointer to themselves (their class instance)
the callback function they provide (see detail below for exactly what they need to provide)
a string containing sets of comma separated event descriptors and their type (single of continuous)

The calling classes are required to provide a static callback function for the User Input class; defined as follows:

static void uiCallback(void* p2Object, std::string keyEventDescriptor);

The function name is immaterial as it is passed to the registration function at run time and stored but the parameter types must be exactly as shown above. This callback function wll be called by the User Input module when ever a registered event occurs and will be passed a void pointer to the originating class instance along with the event descriptor as a string.

In order for a non static member function to be subsequently called the receiving class will also need to define a member function which is then called by the static function and passed the descriptor string. This ensures access from the function to all of the class objects members.

So an example of the above static function and the subsequent called member function might be:

void player::uiCallback(void* p2Object, std::string keyEventDescriptor)
{
// Explicitly cast to a pointer of the class type
player* mySelf = (player*) p2Object;

// call member
mySelf->uiEventReceived(keyEventDescriptor);
}

void player::uiEventReceived(std::string keyEventDescriptor)
{
// Do something with it
}

User Defined Keyboard and Mouse mappings

This is provided courtesy of a ascii text configuration file. It basically contains a series of eventDescriptors and the associated key/mouse event as comma separated pairs. This allows the use of descriptive names such as ‘fire’, ‘jump’ etc to be used and simply mapped to whatever keyboard/mouse action you desire.

They are loaded using the following private member function called from the constructor:

bool loadUIDescriptorMappings(void);

This loads the pairs into a map container for use later when doing event to descriptor mappings.

Registered Event Descriptor Data

When event notification items are registered by external classes details of the calling object, the callback function, the events and their associated event types are stored in structures which are in turn stored in a SubcriberEvents multimap container using the mapped event as the key. The mapped event is obtained by looking up the registered descriptor in the Descriptor map container to see if it has a mapping. If it does the mapped event is used. If not, the original registered event descriptor is used.

Update function

This is called once per iteration of the game loop and carries out the following functions:

Clears any previously stored keyboard/mouse events
Scans the keyboard for input events and stores them in a set container
Scans the mouse for input events and stores them in a set container
Generates subscriber callbacks

Generation of subscriber callbacks

This is achieved by iterating through the set containing the user input events and checking if we have matches in the SubcriberEvents map container. If so, the structure containing all the relevant data to make the callback is retrieved and the call made passing back the original event Descriptor as registered. Events of the type single generate just a single callback per keypress event whilst events of the type continuous generate a callback for every iteration of the game loop whilst the key/button is depressed.

Progressing nicely

2009-09-18T16:11:00.005+01:00

Everything is working beautifully in my Game Engine; I'm really pleased with the results. I am fine tuning the event notification system so that actions that only require a single notification of a key having been pressed do not get continuous notifications whilst the key is depressed; as is the case at the moment. This will cut down on the overhead of callback firing where it's not needed. I'll accomplish this by adding another configuration item for the notification Type 'single' or 'continuous' so this again is not hard coded in the engine and can be externally configured against any notification item. I hope to get some timings done this weekend to see how efficient the system is. The configurable speed settings for each of the animations (in FPS) is working very nicely as are the configurable keys and mouse events. Simply edit the key mapping file to change any of the weapon animation key or mouse assignments and the engine responds.

Then the intension is to add the muzzle flash and sound in along with the damage decals. Then onto coding the weapon projectile stuff and handling the collision and application of forces to the targets.

I lost a lot of time last weekend when my PC went into multi re-boot mode. Took me till the Sunday to find the culprit, as it was intermittent, but it proved to be my Anti Virus software which appeared to have corrupted itself. This was sufficient to panic me into buying a new system which has been long needed. It's being built at the moment and hopefully will be delivered and up and running in about a week’s time. Can't wait!

A slight hickup in the master plan

2009-09-15T19:28:00.003+01:00

It appears that when the leadwerks rendering window is running as a child of a parent window, as in my editor, the keyboard and mouse capture using the leadwerks functions is not 100% reliable. I'm getting issues with missed keyboard and mouse events when the focus is moved from the leadwerks window, which I guess is only to be expected. As a result I'm going to have to take all user input via windows api functions when running in this environment. In the meantime, I'm going to port what I have to my Leadwerks game engine and test it there where this won't be a problem. I can then at least test the full working functionality of the Player object and do some timings on the OOP stuff to see if it's efficient enough.

Event notification system up and running

2009-09-13T00:49:00.002+01:00

Well after many hours of pulling my hair out I now have a basic event notification system up and running and can register events on behalf of my Player object with my User Input object which will notify my Player object when those events occur by means of a callback. It all works dynamically at run time from values set in a config file with nothing hard coded in the engine itself; making it completely generic. That’s the major hurdle over and hopefully tomorrow I can complete the remaining code and test it all.

User Input module

2009-09-09T17:21:00.003+01:00

Have finally settled on writing a new User Input module (class) to handle all the keyboard and mouse input and support a system of callbacks where other modules register requests for notification of user input events and provide function pointers for callbacks. In this way the Player module can simply request a 'fire' event notification, for example, along with a callback function pointer and the User Input module can have this mapped to any key or mouse event giving complete freedom to configure the game controls. Whenever a registered input event occurs the User Input module will translate it to the mapped event and trigger the callback. I think this will give me the flexibility I need and keep the code as generic as possible allowing everything to be externally configured.

If it hadn't been for the need to use User Input in the editor I would just have coded the User Input handler directly in the Player Class. But for that reason it would be kind of nice to keep them apart, so long as the cost in performance is not too great.

I have added a little facility to aid with the placement of weapon animations in the editor. The animations can now be positioned in real time with the mouse. The position vector is displayed on screen. This allows optimal positions to be easy found for each of the animations and the vectors simply input into the config file for use from that point onwards.

Dynamic event notification system re-think

2009-09-08T18:05:00.003+01:00

Having pondered this requirement for a dynamic event notification system I have decided not to go down the road of using the Leadwerks callback system. Although I believe I could fashion a working system using this it would most likely be clumsy and not that efficient; as it’s based around Leadwerks entities and not my internal class objects.

So I am now going down the line of writing my own event notification system which will accept input triggers from any other modules, such as the User Input module, and marry those to requests for notification from other modules, such as the player module. The requests will need to be made at run time as I cannot know before hand what the contents of the config files are. The system will need to create the necessary hooks to accommodate these; probably using run time provided function pointers for the callbacks. All theory again at the moment, we will see how this eventually works out.

If anyone out there has experience of such things I would be very interested in hearing from you. Or any alternatives for that matter!

Player class config file and event handling

2009-09-07T20:36:00.003+01:00

I now have all the animations loading from an external config file which is really nice as I can define all of the properties of the various player animations in this and the code just loads and controls it all. This includes all of the start and end frames, associated sounds, trigger keys for animation segments, toggle keys for enabling/disabling weapons/animations etc. Default animations and animation segments can be flagged as well and will be the ones to initially load and render.

It has highlighted the need for a system of dynamically defining and triggering callbacks when trigger events occur, such as the trigger key presses for the animation segments. The file defines these in relation to the animations, the system will dynamically set these up and then the player class will be automatically updated with only the relevant key press/mouse click events it requires to action them following the update call.

Will take a long hard look initially at Leadwerks support for callbacks as I don't want to re-invent the wheel and if I can use that to accomplish what I need ... I will. That's the theory anyway; I have yet to implement it. If I can get this final part working then I think I will have an incredibly easy to use and setup player class!

Player class well under way

2009-09-05T18:39:00.004+01:00

In order to test AI in my editor it was obviously essential to have a player character and as such I started work last night on a Player Class. I have the basis of this up and running in the editor now with some initial weapons animation in place, but more to the point a design which accommodates any number of weapon/player animations to be loaded and implemented seamlessly. Apart from instantiating the player and overriding any default characteristics the only call required is a player.update() call per game loop. Weapons can be equiped/de-equiped using configurable keys and the animation elements triggered in the usual ways. Animation speed is also configurable on a per animation basis.

There is no associated sound or emitter support in there yet, I'll be starting work on that shortly, but the whole process has proved to be a lot easier that I had initially thought and I'm hoping to be able to move on from this fairly shortly and put the bullet support in place. It's been a productive weekend so far!

My latest train of thought on game objects and my editor

2009-08-26T19:15:00.003+01:00

Since designing a fire object which encapsulated three emitters for the fire, smoke and heat refraction and also a flickering light allowing these to be placed as one into my game level where ever fire was required I've been thinking about this type of encapsulation of game objects and how they might be used / manipulated in real time in an Editor.

It seems to me that it might be a good design strategy to have a base class that contains a standard parameter interface that all the game objects are derived from. Basically, the idea being that each object could define its own set of parameters which are exposed through the interface to an Editor. This would allow the objects to be dropped into the game world in the Editor, say with a default set of parameter settings, and then manipulated in real time in situ in the game level until the desired effect is achieved. The settings could then be simply saved to a level config file and loaded with the game level. Being able to drag and drop game objects into the world and then size their elements in real time say with mouse drags seems a pretty nice scenario which would really cut down the time taken to set up levels and special effects.

Just thinking aloud really at the moment but something I will give serious consideration to adding to my Editor.

No other news really at the moment. I have finished the few little excursions into other areas I was working on and will now be settling back down to writing the AI stuff at last. I may be gone some time!

The Work So Far

2009-08-20T19:00:00.007+01:00

A video of the test level I'm working on to prove my engine and level design:

A pic of the navArea Editor as it currently stands:

Ongoing work:

Currently the main thrust of my development is to build on the foundation I've created in the navArea Editor and start to add the AI capability and functionality. This is probably the hardest part of the coding and will involve the integration of configurable State Machines to control the game play and NPC decision making, an Animation Engine and a Time Division Pathfinding Execution System allowing pathfinding to be spread over many game cycles if need be to reduce the impact per frame and maintain good frame rates.

In parallel to this I will be gradually converting all of the models to Leadwerks gmf format and carrying out the texture conversions and generally maintaining the existing code in line with new releases of Leadwerks.

My Development Blog

2009-08-20T17:56:00.004+01:00

OK, so here it is, my development blog for my game STRANDED which I'm attempting to develop in my free time as a solo Indie developer using Leadwerks Engine 2.

The game:

Essentially a fps aiming to emulate the fun and excitement I experienced with the original Unreal single player game. Initially set on earth the opening level introduces the main character (you - the player) and provides an opportunity to enjoy some combat as the initial story line unfolds. The rest of the game will find you stranded on a distant planet and having to use every ounce of ingenuity and skill you can muster to survive and eventually escape.

The scope of the project:

To complete the first playable level to serve as a demo of the game's potential. A fully playable and interactive terrestrial based level leading to the first space based scene and eventual cut scene introducing the player to a beautiful alien environment that will become home for the rest of the game.

Where it goes from there:

As a solo developer working in my free time it is unfeasible to continue beyond the initial demo without some financial backing or offer of partnership with other artists/programmers etc. Should that be forthcoming then maybe the whole game will see the light of day. If not then should sufficient interest be shown in the engine\toolset then I might consider making that available and remain open to offers to deploy my talent on other projects. Only time will tell!

The background so far:

I've already spent some time with Leadwerks Engine 2 having licensed it back in it back in May 2008 and have seen it build in strength during that time. I am completely convinced that this engine is capable of producing games which could be competitive in the commercial marketplace. It remains just a question of time before this becomes apparent with the first release of a commercial Leadwerks based game. During this time I have gained a good foundation in programming using Leadwerks with C++ and have started to develop the first tools for my game, namely a Path finding and AI editor for setting up path finding in game levels and to act as a test bed for AI development for the game. I have also acquired\purchased most of the assets I require for the first level.