Plan for Phil Carlisle
by Phil Carlisle · 06/12/2004 (12:40 am) · 6 comments
Well, I said I'd post some screenies. Of course, you wont appreciate the full majesty of what you are about to see. But its good for me to get it out so here goes..
These images show a "patrol" sequence being updated. Now there's nothing special about that, other than the actual interface to do it. Whats in play here is a FSM that transitions from an idle state to a patrol state (and back once youve run the route).
Now thats not especially funky, but what IS a teeny bit funky, is that the FSM is script defined and controlled. Whats also kinda funky is that the FSM is also attachable to ANYTHING in the scene. What that means is that its easy to have a stateful trigger (so for instance, you'll be able to have something in the world that can be switched between different states, like an "open/close" state or on/off or red/green/blue or whatever. Once Ive finished extending the FSM a bit, its onto Nic for some interface coolness. I'm going to implement Heirarchical FSM's for this too, because I need to address some of the obvious shortcomings of the traditional FSM (which this current code has).
Whats also on display here is the wigglyness I managed to induce in the smoothed paths (basically the spline we're using for the paths gets a bit unhappy when I use nodes that close together I think).
On with the images..

Onto next waypoint

Back again

And home..

Enough for now.. more next time :)
These images show a "patrol" sequence being updated. Now there's nothing special about that, other than the actual interface to do it. Whats in play here is a FSM that transitions from an idle state to a patrol state (and back once youve run the route).
Now thats not especially funky, but what IS a teeny bit funky, is that the FSM is script defined and controlled. Whats also kinda funky is that the FSM is also attachable to ANYTHING in the scene. What that means is that its easy to have a stateful trigger (so for instance, you'll be able to have something in the world that can be switched between different states, like an "open/close" state or on/off or red/green/blue or whatever. Once Ive finished extending the FSM a bit, its onto Nic for some interface coolness. I'm going to implement Heirarchical FSM's for this too, because I need to address some of the obvious shortcomings of the traditional FSM (which this current code has).
Whats also on display here is the wigglyness I managed to induce in the smoothed paths (basically the spline we're using for the paths gets a bit unhappy when I use nodes that close together I think).
On with the images..

Onto next waypoint

Back again

And home..

Enough for now.. more next time :)
About the author
#2
;-)
Fantastic stuff
06/12/2004 (3:34 am)
Ahhh - implementing the entire game programming gem series, are you?;-)
Fantastic stuff
#3
Glad this is in now, can't wait to update my CVS :) (You did check that in, didn't ya? ;))
Time I get back home and back to coding... :/
06/12/2004 (6:37 am)
Whee, way to go Phil! :) Looks great!Glad this is in now, can't wait to update my CVS :) (You did check that in, didn't ya? ;))
Time I get back home and back to coding... :/
#4
I really didn't see that yet in any other map...
are you sure you have $pref::NavPath::straighten = 1; set?
cause this looks like no straightening with a very dense grid...
EDIT: indeed looks like there is LOS between start and end node, so the whole path should be cut down to the two nodes with the straightening... and then the catmul-rom interpolation shouldn't even jump in... one thing that bugs me though is that the last regular path node may be behind the actual target which makes the paths look really stupid in those cases... so we should find a way to discard nodes that are behind the target somehow so that the bots dont have to move around their target before they arrive there :P
06/12/2004 (2:39 pm)
zoom: concerning the wigglyness: what is your terrainFrequency on that map?I really didn't see that yet in any other map...
are you sure you have $pref::NavPath::straighten = 1; set?
cause this looks like no straightening with a very dense grid...
EDIT: indeed looks like there is LOS between start and end node, so the whole path should be cut down to the two nodes with the straightening... and then the catmul-rom interpolation shouldn't even jump in... one thing that bugs me though is that the last regular path node may be behind the actual target which makes the paths look really stupid in those cases... so we should find a way to discard nodes that are behind the target somehow so that the bots dont have to move around their target before they arrive there :P
#5
Does look like a dense grid here though doesnt it. Which isnt what I'd expect to see, given the map itself is basically a single flat plain with 1 house on :)
06/12/2004 (4:42 pm)
Good call there stefan. I'll try out those settings tommorow and let you know how it works :)Does look like a dense grid here though doesnt it. Which isnt what I'd expect to see, given the map itself is basically a single flat plain with 1 house on :)
#6
06/15/2004 (10:01 am)
Very cool stuff. Keep up the good work... 
Torque Owner Dylan Sale