navArea Editor Demo Videos

[Pixel Perfect]

I've posted a series of video demos showing some of the key functionality of my navArea Editor in my development blog and have included them below if anyone is interested.

 

The whole purpose of this is to allow me to develop and test AI using the navArea Editor as my test bed.

 

Select 480p to view at the higher resolution!

 

Seems I cannot embed more than two so the links to the first two are below:

 

navArea Editor Demo - Part 1a

 

navArea Editor Demo - Part 1b

 

http://www.youtube.com/watch?v=U-csE7nbVvg

 

Latest Video of the techniques applied to the whole test level (posted 19-07-2010)

http://www.youtube.com/watch?v=L8sn5kA7eKs

[TylerH]

This is wonderful. Quite an exquisite editor that I know took a lot of work which seems to have definitely paid off for you!

[Richard Simpson]

Agreed. This looks really nice Pixel. Thanks for posting!

[Pancakes]

wow I'm very impressed that is extremely well done. I like your system better than CryEngine's

[Jordan]

your hard work is paying off

[niv3k]

simple. love it man. nice work

[Sooshi]

this is genious Pixel. I cannot wait to see it all in action with your NPC's chasing you etc. Really awsome stuff man, if you need me to model something for you please dont hesitate to ask.

[AggrorJorn]

Awesome stuff Pixel. Can't wait to see a video where the NavArea editor calculates the entire island.

[Roland]

Pixel ... My hat of and great applauses

 

What a great thing. When can I buy

 

Edit:

Suggestion (if not planned already)

 

Now the path seems to be made as straight lines between the points

and thats great in a building.

 

Outdoors it can look a bit strange, specially when the NPC changes

direction. It looks a little bit robotic.

 

Could this maybe be solved with some kind of splines or other smoothing

mechanism so that the NPC don't makes a bit smoother change of direction.

[Guest Red Ocktober]

elegantly simple... you've made one of the most complex aspects of gamemaking accessible to even the most pathfindingly challenged developer hopefuls like myself...

 

this looks well thought out and meticuloulsy coded...

 

big time kudos Pix...

 

--Mike

[Pixel Perfect]

Thanks guys for all the supportive comments, I wasn't sure anyone would even make it through the first video

 

My main design strategy when doing all this was 'keep it simple' so I'm glad to see that this seems to have rung an accord with others. It's still very much a work in progress with some way to go but I'm getting a better feeling about it every day ... in as much that it feels like I am actually getting something right here!

 

 

Now the path seems to be made as straight lines between the points

and thats great in a building.

 

Outdoors it can look a bit strange, specially when the NPC changes

direction. It looks a little bit robotic.

 

Could this maybe be solved with some kind of splines or other smoothing

mechanism so that the NPC don't makes a bit smoother change of direction.

 

That's a fair and accurate statement Roland and one I've given some consideration to. To address this directly my intention is to either do something similar to what you describe whilst retaining the existing path finding system or eventually swap the hierarchical grid system out for a proper nav mesh system which would allow for a more sophisticated approach to this.

 

It's been a difficult balance to strike during the development process as I have never written a complete game engine, or graphical based editor for that matter, before. The temptation as a programmer is always to stick with each element until its perfected before moving on to the next but the problem with a development of this scale is ... unless I tackle all of the major areas/components comprising a game engine first, so be it just at a fundamental level, it's not possible to know if my ideas are feasible, will work well enough and whether my existing engine framework will support what needs to be done.

 

As it stands now, the framework has been re-written once already as the initial one proved too inflexible as I advanced the design. So the aim is to put in place all of the major elements essential for modern game play with a stable and flexible framework and then refine and fine tune those elements at that point. This is a long term development with the intention of providing a hard core of low level embedded functionality but combined with a simple but flexible interface and a scripting function using exposed high level commands to LUA.

 

The emphasis is basically on good flexible functionality and ease of use, because at the end of the day I want to be able to build games and have a tool/tools that really aid this process rather than hinder it.

 

The AI is barely started but I believe I now have a good enough code base and framework to really move that forward. Next to be tackeled are:

 

Dynamic (in real time) identification of cover points. Hopefully nothing will need to be pre determined or at least that's the aim.

 

A gradual build up of core AI functionality for defending and attacking including NPC grouping and factions.

 

Expansion of the info Waypoint system which already supports individual waypoints carrying key information/commands to allow the activation of these when reached. So for instance, a patrolling NPC may reach a waypoint that requests it to stop and face a certain direction and pause for a period before continuing on its way. These commands can be user defined and combined with scripts to control the action.

 

Exposure of low level C++ functionality through high level commands to a scripting language (almost undoubtedly LUA). NPCs will be autonomous as much as possible but capable of having their behaviour scripted too, especially for support of cut-scenes and scripted events within the game.

 

The ability to script the overall flow of the game, add triggers for level events and level loads etc.

 

A save and load facility where all dynamic object properties are saved to file along with pertinent game data.

 

Extention of the path finding to handle dynamic objects in the game (most of the underlying code has been written to support this) and tackle the more aesthetic elements such as the one raised by Roland.

 

Then the eye candy will follow with the introduction of day night cycles, weather systems etc and support for multiple water planes. I will also include a menu system at this stage too.

 

It's a big endeavour but one that I feel will be well worthwhile if I can pull it off. The main aim of this is to use the tool to initially produce my first playable game level and see if there is any interest. I would also considering making the tool/engine available at that point for other licensed Leadwerks users to develop with although there will probably be a small charge for this. I have had some commercial interest in what I'm doing for some time now but have made no firm commitments on timescales.

 

Sorry for babbling on so much but clearly you have shown interest and I thought you might appreciate a road map on this. Thanks again guys for the support!

 

I'll post a video of path finding in the full level this weekend, plus a few little extras!

[Sooshi]

Hey Pixel thought you might find this interesting lol...

 

http://aigamedev.com/open/articles/bugs-caught-on-tape/

 

 

Btw Pixel, as you place a new start and end goal to calculate Manhattan, how does this differ from dijkstra's algorithm, I dont see a difference.

 

I implemented a feature in "Whats Bugging You" which calculates an F score for my enemy AI. But I dont see the difference between A* and Dijkstra. Even though A* is supposedly more accurate.

[Pancakes]

Pixel Perfect if you made some more tools of this calibur I'd be interested in purchasing them.

 

For instance a cinematics editor with branching dialogue trees.

 

As well as some form of GUI editor. That would be GREAT!

 

btw I would also be interested in this pathfinding as well. B)

[Andr3wHur5t]

cool, very interested.

[Pixel Perfect]

Btw Pixel, as you place a new start and end goal to calculate Manhattan, how does this differ from dijkstra's algorithm, I dont see a difference.

 

I implemented a feature in "Whats Bugging You" which calculates an F score for my enemy AI. But I dont see the difference between A* and Dijkstra. Even though A* is supposedly more accurate.

Both will find the shortest path! A* only differs from Dijkstra in as much as it uses a heuristic which will reduce the number of nodes searched to find the shortest path. Dijkstra expands outwards in all directions and as such usually involves searching many more nodes to get the same result and as such is normally slower.

 

However, if the number of nodes is small then you are unlikely to see any practical difference.

 

There are some situations where Dijkstra may be preferable to A* There are plenty of articles on the net explaining the pros and cons if you search for them.

 

Some good stuff in that link too Kevin, thanks for that. Hopefully might enable me to avoid some of those pitfalls as my AI develops; although I'm sure I'll create plenty of my own B) No one ever said AI was easy!

 

 

Pixel Perfect if you made some more tools of this calibur I'd be interested in purchasing them.

 

For instance a cinematics editor with branching dialogue trees.

 

As well as some form of GUI editor. That would be GREAT!

Thanks Pancakes.

 

A cinematic editor is a distinct possibility at some point in the future and I keep hoping someone else will write a good GUI Editor so I don't have to do that myself lol

 

I'd love to tackle all these things but my free time is limited with having to hold down a full time job and have a family life too! We have another baby on the way (due around March) so I'm trying to cram as much as I can in before he/she arrives

[Mumbles]

Actually, this is very inspring stuff. I don't want to hi-jack your thread so I'll keep it quick.

 

But back in my DBP days I was building a dynamic waypoint generator. The whole pathfinding system was to be based on a system very similar to breadth-first search. But what I didn't want was to have to sit there placing large numbers of waypoints (especially if the levels became large), so I'd make a system to generate them for me.

 

You would provide it 3 integers to form a cuboid and all geometry inside this cuboid would be analysed (Probably either the same way, or a very similar way that your system does this). The cuboid would be split into 'cells', each with a size of 1x1x1. Once all the cells had been formed, any that were directly on top of geometry would have a waypoint on them. Then they were linked up. The only rule for linking was that the distance between two points must be less than sqrt(2) if they were on the same height level, or less than or equal to sqrt(2) if the height level was different. This disallowed diagonal movements on the same height level (to save memory), but allowed such movements as climbing stairs.

 

Unfortunately, this would generate sometimes as many as 8000 walkable tiles, and I decided that this was too many. Upon trying to build an algorithm to remove redundant (transitive relational) waypoints. But I couldn't figure out how to do this, so it eventually all fell to pieces - just over two years ago...

 

 

However, looking at your system, it seems that perhaps I was just being too conservative with memory. Not only does yours allow diagonal movements on the same level, but yours also doesn't attempt to optimise the navArea grid. The navArea grids look almost identical to my old waypoint generation outputs, because it wouldn't ever place a waypoint in the air, it had to be right on top of something.

 

 

So yeah, this looks great, and has actually inspired me to possibly think about pulling mine out of the bin and maybe even trying to bring it into Leadwerks. (I hope a kept a copy of it in a sensible place)

[Pixel Perfect]

Sounds great ... hope you do still have the code. No, you are right, I don't currently attempt to optimise the navArea nodes mainly because I found that in normal dynamic game play you don’t tend to need to plot paths that far ahead and by using multiple nav areas the connecting nodes represent a much smaller sub set and can be searched first leaving you to just plot the paths through the current child area as it may be redundant by the time you reach the next.

 

Nav meshes are by far the most efficient approach and if I was starting from scratch again would probably go down that route (and may yet!).

 

I'd love to see a demo of yours working if you manage to dust off the code

[wailingmonkey]

wow!...wow. huge respect, Pixel Perfect!

 

watched all 3 vids you've posted so far and I can say I'd love to have this capability

in editing and setting up AI. Can't wait to see how you implement NPC logic choices based

upon waypoints and/or player status (will you throw randomization control in there too?...

like 80% accurate to a certain choice/action, 20% accurate, etc.)

 

excellent, excellent work, my friend!

[Pancakes]

If you release this for public consumption will it be compatible with Lua and Rick's PiE?

 

Because that would be like, insanely wonderful.

 

I'm pretty sure you said that it was compat with lua. Oh I am looking forward to navArea and PiE. Will you also make available your weather system. Oh, I feel like I'm browsing at the icecream truck.

[Pixel Perfect]

Can't wait to see how you implement NPC logic choices based

upon waypoints and/or player status (will you throw randomization control in there too?...

like 80% accurate to a certain choice/action, 20% accurate, etc.)

Thanks again for your positive comments and yes, in response to your question these are very much elements which I'm looking to through into the overall AI equation. I welcome any input/suggestions on AI implementation as it’s all a brave new world for me. I'm certainly not short on my own ideas but always willing to listen to others experience and suggestions.

 

If you release this for public consumption will it be compatible with Lua and Rick's PiE?

 

Because that would be like, insanely wonderful.

Thanks too for your continued support and interest in this. I think a little clarification is probably required here in order to explain my answer to this. The simple answer is probably no and I'll try to explain why.

 

What I am really doing here is attempting to build a coherent and integrated game engine/tool designed from the ground up based on the Leadwerks API. The main reason is to leverage the power of C++ and my familiarity with it whilst exposing only high level functionality to LUA for the purposes of scripting game logic. At the same time my design emphasis is very much on making it as simple as possible for people to use whilst maintaining as much flexibility as I can.

 

This will inevitably not produce the same degree of flexibility that coding your game engine directly, be it with LUA or any of the other languages, but then ... how many people are capable of doing this? What it will hopefully bring is the benefit of fast, proven and tested underlying game engine functionality all working seamlessly and with highly configurable ways of setting it up and with a tool/tools that aid doing that. It's a more traditional approach as my belief is it’s the more direct route to achieving what the majority of Leadwerks users inevitably want. A powerful but relatively easy tool based around a pre-written game engine framework which simply allows them to design and implement games.

 

This is what has pretty much prevented anything but static scenes from appearing in Leadwerks so far; as beautiful as some of those are. The few real game demos produced so far have been from people with a coding background or capable of embracing programming and running with it.

 

So as much as I admire Rick's and others approach to independent game object design methodologies I find it still too radical, and little evidence that the same end goal is achievable by this approach, to invest what little free time I do have in. I started this don't forget to enable myself to make games and have taken what I perceive as the best route to bring this to fruition.

 

The lack of any visible support from Josh on what I'm doing is testament probably to him siding more on the game objects approach which is pretty much why he introduced LUA in the first place and that neither bothers or concerns me as I have a game to make and sufficient belief in my own direction to sustain that.

 

Competition is a great thing and I wish everyone involved in these endeavours success. The Leadwerks users themselves will decide in the end on what works for them and what doesn't and that's the way it should be.

[Guest Red Ocktober]

The few real game demos produced so far have been from people with a coding background or capable of embracing programming and running with it.

yup... unfortunately, this is a truth that many people refuse to believe... some sorta coding will be required to make any sorta game a 'real' game... while click together tools can be made to work, they usually result in the same basic type of games over and over again...

 

So as much as I admire Rick's and others approach to independent game object design methodologies I find it still too radical, and little evidence that the same end goal is achievable by this approach, to invest what little free time I do have in.

i understand your position here... i think i may surprise you though... the GameObject concept is to provide a canned template of(in this case) a playable NPC... intelligent hunter, avoider, whatever... and then allow the art-centered developer to customize it by adding their own models...

 

so... hopefully, the results of your editor will be usable to whatever GameObject NPC class i come up with... in short, the developer licenses the editor, make the paths, add it to their game... i give am a logic template in the form of a GameObject... ( though it looks as if i may have to license the ai code from you as well... hey, why not)...

 

anyways... this is a sidebar... don't let it interfere or influence or slow down whatever you're doing in any way... whatever you come up with, i'll try to adapt to...

 

 

--Mike

[Pixel Perfect]

some sorta coding will be required to make any sorta game a 'real' game... while click together tools can be made to work, they usually result in the same basic type of games over and over again...

 

Absolutely right, that’s certainly my experience of this type of approach so far. It's not to say that things can't be moved on and more flexibility built in but it will require an absolute standard interface for the components (which I know Rick is working towards) which all component manufacturers (for lack of a better expression) would need to adhere too. But much more than this, and this is where it gets tricky, an incredibly flexible framework designed to work with these in a way that allows users the freedom to wire these things up any way they want to. Whole teams of experienced programmers have worked on these kinds of systems in the past and I just fear that leaving this to a user base of part time programmers with little to no co-ordination is never likely to achieve what’s required, although the intention is good.

 

Your approach to the game object side Mike doesn't really sound too dissimilar to mine in as much as you are attempting to support embedded functionality of a wide variety of game components whilst allowing users to customise these and substitute their own models/artwork. The problem tends to arise when you no longer can rely on just autonomous functions but need to centrally co-ordinate these things, bringing us back to the framework issues I touched on above. It seems to me you can only go so far with this encapsulated functionality methodology where it's a self contained entity in its own right without it being able to somehow register with a framework its type and functionality so that a centralised AI framework and game logic module can interact with it too.

 

Again, I welcome all the different approaches that are being taking by the various people proposing these things (and I'm sure there are also others working in the background on systems we are yet to see anything of). It's all very healthy and ultimately encouraging for the Leadwerks community who will also be benefactors of anything that subsequently gets developed.

 

My current editor and proposed system is not designed to work with others as it is dependant on its own centralised AI framework that has knowledge and control of its component parts but is happy to allow autonomous behaviour when required.

 

However, if people can actively demonstrate real advantages to their systems then I'd be happy to work with them to integrate my tools with theirs. Most functionality can after all be packaged up and interfaced into other systems if the desire to do so is there!

[Porsche]

Holy...

 

 

Major Kudos Pixel Perfect.

 

 

So... How much?

[Pixel Perfect]

Cheers Porsche but I'm afraid it's still very much a 'work in progress' and not currently for sale. I posted the demos in response to requests from a few people to see what I was currently working on.

 

As previously stated I'm developing this comprehensive game engine and toolset for my own game but I hope to offer this for sale, should the interest still be there, for others to develop games with. I'm no longer certain that I'll use Leadwerks for the final game, as I've previously stated, but I have developed the editor to the point where it makes no sense to abandon it now as I can develop and test my AI using it. My current intention is to still use this to at least prototype an initial game level in Leadwerks. I want to finish what I've started as it's proving an invaluable learning curve.

 

There is however a lot of work still to do and a huge amount of functionality still to be added. I hope eventually this may offer people with minimal coding skills a working engine with the full functionality they need to make a game and tools to aid rapid game development. The ability to do simple scripting will still be required though!

 

I've not had a chance to put the video together of the whole test level yet as promised due to lack of available time but it's coming hopefully before the weekend.

[AggrorJorn]

Everyone on the forum thinks you have done a great job so far. Plus it is very cool to see the Nav Area editor working.