What's next for Walkabout?

#1 Welcome back! :)

My vote would go on;

1, 3, 4, 5 and 6 (couldn't decide - they are all good options!)

With the use of Walkabout I've added the ability for AI to collision detect what object they walk into and perform an animation such as a hurdle over an object. Far from perfect at the moment - decided on collision detection instead of a raycast for now - not sure on the cost implication this may have in the game with lots of AI. So if you can come up with something better - this has my main vote.

A while back we discussed in the forums; the ability to link two or more nav meshes together with maybe a link. This could be ideal for two terrains on a map, with a bridge and a big fall down into a river. Maybe a solution, if larger Navmeshes are a problem.

I've found changing the tile size on the walkabout settings, it helps when dealing with larger navmeshes.

#2 Tbh Walkabout is already actually something am interested in but so far when lookin on a couple of addons for T3d
it is that they all focus mainly on 1 single thing
and that just prevents me personally from pickin it up.

now that single thing way might come in handy but
lets say you would expand Walkabout to be something more then just a navigation toolkit
along with your possible new features
-add controlable items
-doors
-elevators
and combine those with walkabout - expand it together
add extra behaviour types

i do hope that u get the bigger picture here, so far when i tried to express myself or make suggestions in this community it usually ended up with "This doesn`t fit in it" now is that really true

think twice
as later on the whole thing could be expanded even more
This is not about a make my game button.

#3 Daniel... before I forget.. I couldn't find these scripts in R1 or R1P1...

walkaboutSpawn.cs
walkaboutDynamic.cs

Could you include them in the zip and I'll download it again when you get back to me. Thanks!

#4 Cool stuff, Mr Buckmaster.

Maybe some sort of linking that works a bit like jump but has a dynamic bool for enabling/disabling - eg: locked doors, blocked pathway, etc.

Swimable water shouldn't be too difficult should it? Have the player settings float on the surface and have the navmesh find the water as a mask during navmesh generation?

#5 Oh, and getting cover to work on terrain occlusion might be neat ... if awkward to develop.

I like scones too.

#6 I currently very much like TAIK, if it was able to work with that?

Number 2, sounds like a killer feature to me!

Number 5, cover points auto gen is really a cool feature too.

And as Steve mentioned cover from the terrain :-D!

Doors and lifts are in most games, so knowing how these things work could really be important to AI.

#7 I just want ai vehicles. Well, I want everything, but if I'm being forced to choose I'm going with vehicles.

#8 2, 4, and 5 sound like great additions to this pack Daniel.

I'm looking forward to what you have in store for this pack and I will probably be grabbing a copy at some point once I get back into the game development mood.

#9 Actually, after some thought I'm leaning towards cover generation. Cover points are a must have these days imo. Give me some cover!

#10 I would second Dan....cover AND ADD IN concealment.... Cover provides safety from incoming rounds, concealment provides a hiding place, not always safe from bullets.... Think brick walls versus bushes.....

Ron

#11

Quote:
Tbh Walkabout is already actually something am interested in but so far when lookin on a couple of addons for T3d
it is that they all focus mainly on 1 single thing
and that just prevents me personally from pickin it up.

Ah, but what if you get an all-in-one pack that has all of the features you mentioned, but doors don't work the way you like and the elevators are difficult to configure? Then you have a pack that you have to modify (as you may anyway) but you have many systems that may be interdependent. Individual feature packs are better because you can test them separately, tweak them to your liking, then add the next pack.

Walkabout and Sahara, for instance. Both make engine-side changes and if there's a bug it might be hard to tell which pack is causing it. So I can make a new project and add one or the other to readily debug which is causing the issue. In a big, monolithic pack the up-front debugging task is huge.

Personally, I prefer one feature set per pack for this precise reason - I can test and study each in isolation, and when there is a problem I know which feature is causing it.

#12 Jules: adding custom animations to links could be helpful, for example, if you want characters to play a specific animation when they jump down a ledge. It also allows characters to traverse routes that are only allowed by a link, like windows (since the navmesh will not provide a path through a window without a link).

In terms of linking navmeshes, I'm very tempted to continue some old experiments I was doing in having a 'terrain nav' mesh which was very large and low-resolution, just enough to capture the detail of the terrain. When characters aren't in any other navmesh, they use the terrain mesh. This means they won't fall into canyons or try to walk over mountains that are too steep.

The .cs files you mention were in an early version, and I removed them but I think I forgot to update all the documentation. I was fairly sure I fixed that in R1P1, replacing those files with a tutorial on the relevant features. They didn't really have anything helpful in them. If you can download R1P1 you should have a tutorial that takes you through using the dynamic mesh updating script API.

J0linar: I hear what you say, and stuff like elevators and doors could be a great addition. However, with more and more features it becomes difficult to support the product, and to design it in a very modular way so that people can only use the parts of it that they want. I'll give this some serious thought, but for the moment I do still want to focus all my effort on making the navigation experience as good as possible.

Steve: being able to dynamically enable/disable links is on my internal list. I've yet to decide on a workflow for opening/closing doors and so on, especially since Torque doesn't actually have any support for doors in some standard way. I think dynamic links will be a good first step in that direction.

Terrain cover occlusion is an interesting ides. To be honest, I've never thought about it, but I'll see if I can find some way to fit it into the pipeline. You're thinking of taking cover behind the lip of a hill from people on the other side?

Edward: TAIK support is on my list. It will probably come in the form of a tutorial on how to modify the TAIK files to use Walkabout for navigation, the same as I did with the UAISK.

Dan: to some extent, the AI can already drive vehicles if they're slowish and not too different from how AI characters themselves should move. For example, a large mech/walker would work fine. Dealing with fast vehicles with a turning radius is a bit more difficult, and on second thoughts I might be a bit over my head with that ;P.

Ron: The problem is 'concealment' is a very tricky concept to deduce automatically. Individual games will handle these things very differently. Though I'll look at starting to support that, maybe by making a class for 'concealment points' or adding some meta data to cover points.


I'm surprised there weren't more votes for 3! It's something I've been wanting to do for a long time, but it's difficult (editor code blows my mind), so I might leave it on hold for a while longer.


In other news, I've been playing with NearlyFreeSpeech for webhosting, and I'm thinking of moving my site over there, which will hopefully alleviate those mailing issues!

#13 Daniel: Thanks - I was more interested in the following;

// Spawn a wanderer who stays within 10 metres of his spawn!
WalkaboutSpawnWanderer(DefaultPlayerData, "0 20 1", 10);

But couldnt see the files in R1, it was in the docs.

#14 Yep, I never finished implementing that function, and by the time I needed to release I decided it was too much to finish those example scripts! If you're interested I may finish them up and add them back in, or at least release them separately.

#15 Daniel - that would be most welcome! I'm just composing you an email, as I did come up with my own solution for this, but needed help with getting the xyz working with setPathDestination but had issues passing the position from a variable into a string with inverted commas. (tagged string)

Edit: may have resolved it with single quotes.

#16 @Daniel Buckmaster, thx for considering the door/ lift/ enviroment part
However like some others asked for a TAIK integration howto would be nice and mostly welcome.

#17 Having used it extensively, my biggest issue is getting it to generate meshes on large terrain [#4].

On the subject of #1, swimming would be the next I'd ask for and along with it, flying [yeah I know, that's a toughie].

#5 - goes without saying...

@Dan Webb: I've had it working with land-based vehicles for months - Walkabout isn't the issue as much as writing the vehicle-specific code and scripts to make it work. I have Cheetahs and hovertanks delightfully hunting down my player and fragging them with heat-seeking missiles... Sean Rice and I were just about to try adapting Drive to work with it, but we've held off because we're trying out different engines. There's quite an uphill struggle to get vehicles working well in Torque, and given the time we don't have, we're considering other options... We'll likely release some or all of our aiVehicle code, we're working out how to do that and how much time to put into it...

#18 I think my biggest issue right now is also generating meshes on large terrain (#4). Currently it likes to run out of memory and crash when it gets too large. While it's possible to get large terrains to work with it, the project gets a lot more complex, so my votes definitely for #4.

#19 Gibby: yeah, flying is interesting because it's completely off the navmesh. You can do limited flying with off-mesh links that represent 'you can fly from here to here', but actual aerial navigation would need an entirely new method of representing space. I've often thought about it, but I think it's beyond Walkabout's scope for now.

Patrick and everyone: sounds like my first order of business is to get large navmeshes working! Let's see what I can cook up this week...

#20 Patrick / Daniel @ might be crashing when it exceeds the max number of tiles it can store in memory - ran into issues with that, but didnt crash in debug mode.