MAJOR EDIT: removed all the source code because it's useless, and this has now turned into a discussion about waypoints vs areas

Hi

I've been working with pathfinding algorithms for some time now, and to be honest, most of what I found either don't work in full 3D or rely on waypoints (which I can't stand). The only one that seems to suit what i need is the quake 3 aas. Not the actual implementation, just some of the ideas - basically, the idea of using volumes instead of waypoints. After many minutes (heh) of thinking, this is what I've come up with. It's not perfect, probably fatally flawed and stupidly ineffeciant, but hey, that's why I'm posting it here for you lot to poke holes into :). Right then...

The world is split into a set of axis-aligned bounding boxes (aabbs), called volumes. These make up the simplified representation used by the navigation system.

Hello Sami

In the beginning of your posting you say in the second paragraph:

> The world is split into a set of axis-aligned bounding boxes
> (aabbs), called volumes. These make up the simplified
> representation used by the navigation system.

You mean you interpret the world in this way so you can apply your tools. But of course the world isn't so. How good is that path finding then. You can't know it, I think. What do you think.

I will tell you my way. The environment is in your computer or somewhere else. You go there and what do you find - you recognize things, food, dangers and all kind of things. Recognizing is a kind of repetition, but with variations, noise and real change. It's identifying in maybe a chaos. The environment is also a neural net! Of course. Dynamic like nature.

You learn when you burn a bodypart, never again that. Think of storing the info and learning all the time and the environment is first simple. It grows when you visit it. You jump over a stone. The environment lives as well. It changes by you and also without you. I call this bottom-up thinking and it's certainly codable.

There are also rather complex mathematical solutions where you work with cameras and a database with the environment. With clever techniques a robot can navigate in a real environment. I've seen a demonstration. Yes it works. An expensive solution.

Ed van der meulen

... this is for a game, not the real world :)

Hello Sami

Sami Hamlaoui: ... this is for a game, not the real world :)

Ed: I know I thought also about a game. I like also to make a game, but more a player or a bot finds something, let's say in a file, and then he looks closer and sees more. When he later comes back this more info is still available for I store that.

So I stress the objects or more precise the meeting, certainly you can find them and use a grid, 2 dim or 3 dim.

I find or refind a path with preferences. Going on in the same way. Straight then straight, making a curve, continuing it. And the bot recognizes earlier met places and he can make mistakes then. You can use Fuzzy Logic for that. Not so difficult.

You can even extract tactics

And you can develop it further.

I wish you much success with your game Sami,

Ed van der Meulen

The major benefit of AAS was that the underlying engine was based on Binary Space Partitions, and thereby easy to create. I suggest such an approach is overly complex, and should only be attempted in these cases.

Waypoints are a pretty broad term (many different implementations), and it would be useful if you told us what in particular you don't like about them?

I'll be publishing part of my Masters thesis in the next few days, and that fixes my major gripes with waypoints: the topography is learnt automatically online. No hassle, simple, and works nicely. Keep an eye out for it!

The thing i dont like about waypoints is that it doesnt provide any information about the size of the dimentions of the environment. Two points connected together might provide a safe route from A to B, but what happens if the bot needs to strafe? how does it know that A-B wern't on a very find bridge and any movement from side to side would result in it falling off. With the aas, the bot would know that it could walk anywhere in the area and be safe.

that, and i've yet to find a decent automatic waypoint placing scheme (apart from Q1's reaper bot which places waypoints in locations the player has managed to reach) :).

You could do a couple of raycasts when the waypoints are placed to define a 'moveable' radius for each waypoint. The Bots would then just need to stay within the boundaries from one waypoint sphere to the other. For very narrow edges you could have an extra flag signaling a very strict movement.
Another alternative to waypoints would be using Navigation Meshes which to my understanding so far are a simple 2d surface representation of the 3d polygon mesh. I'm afraid there aren't many online resources (if there are please post them) but there was a good explanation in the book 'Game Programming Gems' and Paul Tozour described some improvements in the 'AI Wisdom' book.

About waypoint placement: you could do a hybrid version, automated placement first (either by monitoring players or floodfill) and have your game designers/mappers refine them. At least until Alex comes up with his thesis I guess :)
Btw. Alex, any approximations already when we can we take a look at it, I just can't wait to see it !

well, the system i posted above is actually working quite nicely at the moment (well, the theory. the original code has all but been replaced because it was horrible ;)). I might try and combine the two at a later date - use waypoints for specific navigation, but still use the underlying volume navigation thingy to actually navigate between them.

the advantage of waypoints is that you can specify EXACT locations, where as with the volumes you can only specify... well, a volume.

i dunno. after playing with the Q3 bots for a year or so with they expert knowledge of the area, i went back to the Q1 bots today and was horrified. waypoints, corner following, and... uuurrggghhh... random movement.

the hunt for the perfect nagivation system goes on.

Hello players, hi Sami hi

Yes there's a theory of waypoints. When you are yourself in a landscape where are the way points then? You see, meet with your eyes or in another way things, partners, dangers, happiness, but a waypoint as well?

Why do we need waypoints? Yes the military uses waypoints, but they have a concrete plan and they think they know the things beforehand. Is that in Quake 1 the same, a fixed plan?

It’s not difficult to work with waypoints I think also in 3dim bit know it’s a total other world as well.

So my questions why waypoints, while perhaps they aren’t necessary, and while they certainly a solution are as well.

Is it not nice we introduce the latin ablative in the language?

Maybe so:

Sami, I would copy what we ourselves as humans would do in that specific landscape. Also storing knowledge, far seeing and that kind of things and hardly a random search. Things we see strike, and you know your own and the other positions, isn't it. I see this as much more logical. You see edges and nice and bad things. When we wouldn’t have eyes or ears or nose we would stumble as well and maybe need waypoint to navigate. But we have eyes and ears. What do you smell now?

The oven!

You see something you recognize so you compare with your knowledge, you maybe store environment factors that help later recognizing. And so you can think further. What do you think?

Ed van der Meulen

"the advantage of waypoints is that you can specify EXACT locations, where as with the volumes you can only specify... well, a volume."

True. However you could introduce exact locations to those volumes as well by i.e. using the midpoint of the volume or using the points where adjacent edges are linked.

"i dunno. after playing with the Q3 bots for a year or so with they expert knowledge of the area, i went back to the Q1 bots today and was horrified. waypoints, corner following, and... uuurrggghhh... random movement."

Just don't do that :)
How old is Q1 and Bots using that game ? Imho way too old to compare them to newer AI (and weren't they written in QuakeC ?). I'd rather take a look at newer FPS games and analyze those instead of going back in time. If you've got Q2 you could get hold of the CGF Bots for Action Quake2 and see what they are achieving with waypoints. Almost all Bots for Half-Life and its MODs also use waypoints with varying success (but I'd guess a lot better than Q1 Bots). AFAIK there are 2 different navigation techniques used now:
Navmeshes or 3d Volumes in some form -> (C&C Renegade, Q3 engine games, Operation Flashpoint, some more escaped my memory)
Waypoints/Pathnodes -> (Half-Life,UT,UT2003,most if not all third party Bots)

If you've got UT2003 then type 'viewbot' and 'showai' into the console to see how they are navigating using waypoints. Actually I don't get why you're complaining about waypoint nav since it has been used quite often and if done right might have less flaws then what you've experienced with those Q1 Bots (cornering walls and more advanced navigation seems to be more attached to pathfinding). Take a look at what you can squeeze out of waypoints by reading this GDC presentation by William van der Sterren -> http://www.cgf-ai.com/docs/igda_may2001_slides.pdf

For a great (imho the best) Bot for Half-Life Deathmatch see here:
http://parabot.nuclearbox.com/

(the most interesting thing about this Bot is that it 'learns' the map while playing it, much like the Q1 Reaper Bot you've mentioned before but very advanced)

@ Ed:
I don't know if I'm alone here, I do have problems understanding you. If this guy has to write AI for a game then his Bots need to have exact knowledge of the game (and need to run fast since he usually only has about 15% CPU for them in the game). They need to have previous knowledge like goals/rules of the game and you can't just raise a baby Bot and tell him to use his sensors to explore the world. Speaking of sensors, hearing and seeing needs to be simulated and most often this is so costly in terms of execution speed that you often find yourself in the need to avoid it. For example 'seeing' is done by having the engine raycast lines through the level geometry (very slow!). Hearing often is done by cycling through important entities and assigning some kind of volume level to them, slow too. There's at least 1 Bot which tried to learn everything on its own using Neural Nets but it also gave a good example that this is something which doesn't work out well so far. Unfortunately it was hosted at the now diseased botepidemic site so I can't give you any links.

Hallo MarkusK

I know of waypoints. Please do it your way

I follow just how we do it in reality.

Ed

the reason i'm looking into areas is for a dynamic navigation system i'm churning out (albeit at a very slow pace), i.e. a navigation system that can handle both moving and static objects, regardless of their size. with the volumes, it's easy to split them into smaller volumes when an obstruction intersects it, something that's impossible with waypoints.

like i said in an earlier post i will be using waypoints, but i will be using them for stacking commands (go to this location, then that one, then this one, etc), not for actual navigation.

damnit i hate it when i get all inventive :)

If you're having trouble with waypoints because they specify exact locations, you're doing something wrong. Consider them as vague landmarks for movement, not precisely the start and end of the trajectory.

Using a robust lower-level of a navigation system (based on reactive behaviours) can really make the most of waypoints, and in my mind perform better than with any perfect 3D volume based approach. I'll even argue these reactive behaviours are key for dynamic navigation, one on the conclusions of my thesis.

My GDC talk is about all this, keep an eye out for the slides when they post them!

Hello Sami

I know waypoints are usable but I prefer the way I have told you. Then static and moving is no problem. Store also the speed maybe direction relative to the environment.

I know it's possible with waypoints as well. It's certainly not a bad way. My only point the technique of waypoints is not the only path-finding way.

We will also make games, but not with waypoints for they are not in reality present.

But who wants to use waypoints, please go on with it. Maybe we can learn from each other.

Ed

Hi game lovers,

Markusk: Is this guy making a game with an NN. Yes
He makes it a slow one. No.
The bot has to know goals and rules exact. No.

Suppose your name is Bot, why not?
Hi Bot, when you start to play that game. How precise do you know all?

I try somewhat, maybe to win or to survive, or to learn a tactic, but precise? Real Rules? I understand good behavior. Are you full of rules? Don't you understand me?

How can you know that you have to be precise?. Why are we in nature so fast? And why in a computer with so speedy electrons then so slow? What do you think about this difference?

The bot sees at a distance a figure it recognizes, so an array of numbers fits good enough, a matching case. What is striking then? How do we do that ourselves do you think.

Well, from rough to precise. Our eyes see maybe first a dark shadow in his view angle first in front and what preferences he has got, but nothing random. He sees a rough shadow at a rough place. That means the position has stages of precision like also the other bot of whatsoever. And also remembered in stages. Match rough with rough and so on, and you are very fast precise. For the extra storing only some extra memory, but slow? Fast the bot knows he can run in that direction and maybe he sees now more precise, maybe he can make a mistake. Suddenly disguise is an element

Well, extra features for free.

Sound is easier it has been sent, so present in a certain area. Well is that so difficult to code? Do you really think that will be slow?

No in this way nothing goes slow. But yes, you have to know how.

Ed van der Meulen

when did i say I was using neural nets?

No, you didn't.

Ed

"Markusk: Is this guy making a game with an NN. Yes"

Yes, Sami

Ed

Ed vd M: The bot sees at a distance a figure it recognizes, so an array of numbers fits good enough, a matching case. What is striking then? How do we do that ourselves do you think.

Not for a game environment - object recognition is for too complex and is not needed. The algorithm controlling the bot would simply be provided with the coordinates of its potential targets. It would know that they were things it could shoot at as it would have an abstract view of the action in a video game, just as a chess algorithm need not concern itself with recognising chess pieces.

Paul: Not for a game environment - object recognition is for too complex and is not needed. The algorithm controlling the bot would simply be provided with the coordinates of its potential targets. It would know that they were things it could shoot at as it would have an abstract view of the action in a video game, just as a chess algorithm need not concern itself with recognising chess pieces

Ed: Okay I give up. Please go your own way. You know it better Paul. Much success.

We will make first two demos more and then we'll start a branch NNW games. Very fast working bright games with a lot of features. But according my ideas. We go just two ways. Nothing bad is it?

Ed

right, this thread is disintergrating into chaos and flaming so i'm gonna leave it be. i'll post the results of my volume nav system when it's completed for anyone that's interested.

Alex: i would be insterested in having a good talk with you one day about the pros and cons of waypoints if you're up for it - i get the feeling i'm slightly biased due to my initial experiences with them :)

Sami: into chaos and flaming so i'm gonna leave it be.

It's not bad Sami, we just left each other and go all our own way. Nothing more has happened. Just some exchanging of ideas, that is not chaos or flaming.

I know something of waypoints. How can you know that other ways don't work? No, I don't see it as a bad discussion. We just didn't meet.

Ed

"i would be insterested in having a good talk with you one day about the pros and cons of waypoints"

Same here. I'm working on Bots as well and so far I had good results by using waypoints. After reading about NavMeshes I'm quite confused which one would work out better. My old Bot had the designer process involved where people had to drop waypoints to have the Bots roam a map. The new one has waypoint recording (should appeal to Ed since they don't have any knowledge about a map first) but also an alternative navigation using those navmeshes. I'll try to list the pros and cons I've got on my mind ->

Waypoints
---------

Pros:

- Long proven method, lots of articles about them
- Easily created/managed
- Usually easily integrated into a pathfinder
- Can be created 'on-the-fly'
- Don't use up much memory
- Fairly good level representation if dense enough
- Can easily be extended to contain abstract infos
- Not many problems with dynamic objects

Cons:

- Can lead to funny movement
- Lookup can be tricky and time consuming
- Doesn't necessarily represent the whole map
- Needs good low-level movement layer to avoid 'stuck' situations
- Might need additional human help to mark certain spots
- Not much help for certain terrain factors like 'openness'
- Needs costly 3d math operations and maybe additional raytracing

NavMesh
-------

Pros:

- In theory the whole map is checked for moveable areas
- old 2d theories apply and is pretty fast
- Simpler movement needed, flocking should be much simpler
- One run of the parser is enough to reviel the whole level
- Originally better looking movement

Cons:

- Dependant on the BSP Version, needs a different parser for each game
- Lot more difficult to do
- Very difficult to annotate special movements like water,ladders, elevators etc. (if you can't 'simulate' the game physics)
- Static models not in the world bsp need to be cut out of the polygon soup (this especially gives me headaches right now)
- Dynamic models much harder to avoid

So this is where I am. Now Alex tells us it's all about waypoints again ? D'OH! ;)

MarkusK: "i would be insterested in having a good talk with you one day about the pros and cons of waypoints"
...text is my text (ED) between yours.
Waypoints
---------
Pros:
- Long proven method, lots of articles about them
... yes certainly old, but why not a new method.

- Easily created/managed
... okay, but a method without them is still easier.

- Usually easily integrated into a pathfinder
... not present no need to integrate them

- Can be created 'on-the-fly'
... yes, fine for those waypoints, but...

- Don't use up much memory
... PC' have a lot of memory nowadays. Do you have an xt? Is it a nano bot?

- Fairly good level representation if dense enough
... also true, but so what?

- Can easily be extended to contain abstract infos
... is not very different to creating, but okay.

- Not many problems with dynamic objects
... no waypoints can move as well, waypoints sometimes tricky, isn't it

Cons:
- Can lead to funny movement
... not too bad. You are right here.

- Lookup can be tricky and time consuming
... define precise, a job yes.

- Doesn't necessarily represent the whole map
... No, you have to extend it automatically, isn' it.

- Needs good low-level movement layer to avoid 'stuck' situations
... certainly true, debugging not nice,

- Might need additional human help to mark certain spots
... yes and that's neither my goal, It's a job for the computer

- Not much help for certain terrain factors like 'openness'
... yes also very true.

- Needs costly 3d math operations and maybe additional raytracing
... a very bad thing. I would never do that.

Extra con:
... you have a connected extra layer like a kind of administration.
... life is powerful and a splendid example and in nature you
... have no waypoints, neither an administration

... you can't prove your source elements, and that's certainly
... possible, can't we proof in mathematics, can't we proof in Physics?
... this means there are different ways to proof something as well.

... conclusion: waypoints work, an old way and with disadvantages as well,
... but is there no better solution? Finding new ways, means trying other
... things, isn't it?

When did the waypoint technique arise. What were the PCs then and look how they have improved.

NavMesh
-------
... What is NavMesh

Later I can precise my way, okay.

Something to come in the mood...

Suppose we make a new bad game Star Wars, yes a new game. Will we use waypoints, to hit a missile in space? Would you do that really? Here a corner, there a corner? Maybe a first rendezvous point. But then no jokes anymore. It's real. Tension. Suspense, Show!

So TSS

--------------------

I do a lot of promoting for the active members

Ed

"- Don't use up much memory
... PC' have a lot of memory nowadays. Do you have an xt? Is it a nano bot?"

Yes computers have lots of memory now. But this is about games so it also includes consoles. While the average PC user has 256 MB and rising console platforms usually have less than that, 64 MB being a lot still. Besides, if your AI runs in a huge game environment like Half-Life, Q3 or Unreal you don't have much memory left for you and you don't want the game to constantly swap memory to the HD, do you ?
In my opinion less memory usage still is an important thing and most often it even speeds up execution.

"conclusion: waypoints work, an old way and with disadvantages as well, but is there no better solution? Finding new ways, means trying other things, isn't it?
When did the waypoint technique arise. What were the PCs then and look how they have improved."

Please don't get me wrong, I'm not a fanatic follower of waypoints I've explained that I'm also experimenting with navigation meshes. In fact I'm interested in alternative navigation hints a lot. Please tell me how you would annotate locations ? The example you brought up previously about humans seeing shapes (having a sort of LOD) just doesn't work in the realtime department where every frame counts. I'm sure it would work in some academic environments. I'm getting the impression some of your ideas have already been tried in the SOAR Bot -> http://ai.eecs.umich.edu/soar/main.html
However it has already been proven that some of their abstraction concepts don't work well in more difficult and never games (the original one was for Q2).

"Suppose we make a new bad game Star Wars, yes a new game. Will we use waypoints, to hit a missile in space? Would you do that really? Here a corner, there a corner?"

That's a different problem imho since this just involves a lifeless with the only goal to hit this missile. This is just about calculating the needed velocity to hit the target in a desired time window. Very different from having Bots fullfill their plans and have them do the desired action & navigation. Please tell me about your solutions.

Hello Markus.

Let’s play with our texts, like it is a game itself. Okay? It’s little bit funny way of discussing. Tell me please if I have to behave more, grin.

MarkusK: Yes computers have lots of memory now. But this is about games so it also includes consoles. While the average PC user has 256 MB and rising console platforms usually have less than that, 64 MB being a lot still.

Ed: My point is not that we can use a lot of memory, but that we don't think immediately the memory is too small. Everyone knows PCs will get larger memories as well. My main PC has now 512 Mb, which is also quite normal.

MarkusK: Besides, if your AI runs in a huge game environment like Half-Life, Q3 or Unreal you don't have much memory left for you and you don't want the game to constantly swap memory to the HD, do you ?

Ed: No. Yes, but, is that memory necessary. A normal mathematical NN is easy a few Mb, isn't it. My NN is few hundreds kb. Only the GUI and the graphical view on the net is relative large. They aren’t necessary. Programs are not necessary large. So the scenery may take memory.

MarkusK: In my opinion less memory usage still is an important thing and most often it even speeds up execution.

Ed: Okay. But let's look later how large the software will be. You code always for a next generation of computers.

Ed: "conclusion: waypoints work, an old way and with disadvantages as well, but is there no better solution? Finding new ways, means trying other things, isn't it?

When did the waypoint technique arise. What were the PCs then and look how they have improved."

MarkusK: Please don't get me wrong, I'm not a fanatic follower of waypoints I've explained that I'm also experimenting with navigation meshes. In fact I'm interested in alternative navigation hints a lot. Please tell me how you would annotate locations ?

Ed: The environment is for me a living one. All can change. It’s building up by visitors. Not the location contains things. But parts of the game reality have a position, that’s not the same. For me the bot doesn’t see the landscape and maybe another bot, but his eyes meet the landscape. Bots looks in that direction, the landscape enters him. And I haven’t talked now about computing, why should I compute then something. And the world consist then only out of numbers. They fit in margins change them or they don’t fit.

MarkusK: The example you brought up previously about humans seeing shapes (having a sort of LOD) just doesn't work in the real-time department where every frame counts.

Don’t mix the graphical work with the work of the central processor. It’s double power, the computing and the graphics. Do you know what cooling graphical cards have?

I'm sure it would work in some academic environments. I'm getting the impression some of your ideas have already been tried in the SOAR Bot -> http://ai.eecs.umich.edu/soar/main.html

How can you know that Markus.

Ed: tried, not found. So maybe. Maybe not. I know my way, not theirs.

MarkusK: However it has already been proven that some of their abstraction concepts don't work well in more difficult and never games (the original one was for Q2).

Ed: That's the first difference. I don't use abstraction concepts.
I use what I call factual thinking. Abstraction concepts come from top-down thinking. You can plan all but what will be the result? Never you know that it's possible.

"Suppose we make a new bad game Star Wars, yes a new game. Will we use waypoints, to hit a missile in space? Would you do that really? Here a corner, there a corner?"

MarkusK: That's a different problem imho since this just involves a lifeless with the only goal to hit this missile.

Ed: Are you sure? It's just one example. And such situations can be situated in a real game as well.

There are always moments no time to decide but to act and then the bot can misjudge in a natural way as well, without something of random.

What with waypoints when it storms an all the scenery changes, ways blockade and in natural looking way, so not everywhere repetition of rocks in a corridor, which is soon annoying. Draw the administration with you. The landscape lives as whole and not only the waypoints. You can see that immediately recognize a dead landscape. Never seen in games? Too quiet. In nature all moves, flurry when I don’t concentrate on it
Only sharp in the center. You haven’t often seen such a game.

Strange sharp in each corner?

MarkusK: This is just about calculating the needed velocity to hit the target in a desired time window. Very different from having Bots fullfill their plans and have them do the desired action & navigation. Please tell me about your solutions.

Ed: I think it's much more complex. When you have to do this with your body, can you fly? Then you would use each fiber of your body and all energy. And I calculate nothing for the neurons can’t calculate.

Now bots arise suddenly when you pass a point, very unnatural. They have other problems than the user. Do you think that is a good feature?

A stone flies to you, dive!... Did that stone compute? A stone?

You can describe boxing as simple as well, hitting in a window, only some other scale, will the boxers then say, my frames? Do you know when something moves fast, we see it as a smear, not at all high quality and with bad colors as well.

Why do you think the experiments with missiles failed so many times? Because it was only hitting a window? Was it not more reacting precisely, using all knowledge and memories as good as possible at this distance?

Ed: Conclusion. Speed, we’ll see. Maybe the speed on the screen as well? Important is I don’t use random and I don’t like computing so computing will hardly be necessary. And there are additional techniques to speed up a gaim.

Did you see in my texts already computing?

Ed van der Meulen

"Very difficult to annotate special movements like water,ladders, elevators etc. (if you can't 'simulate' the game physics)"

the way i'm dealing with this is to store the type of transition between each area. if the bot can walk it, set the flag to walk. if it involves a ladder, set a flag to ladder, etc. Then, when it actually comes to executing the actions the bot will already know how traverse the terrain. if it's an elevator, use the elevator flag and tell it the ID of the button that needs to be pressed to activate it (if any).

if you use "automatic ladders" (ladders that dont require any special commands by the player to climb them) then this can be simplified further still.

one thing i'm having trouble with navmeshes is providing an effective function to search for ideal cover spots. because i'm using 2D nav meshes for 3D (it's like doom. no 2 sections can be over each other) it's made it impossible to implement a good cover function. even in 3D i'm unsure as to how to pull it off :/

Hallo MarkusK.

Again texts starting with ... are form me (Ed)

NavMesh
-------
... no idea what Mesh is. Nav is navigation or something like that

Pros:

- In theory the whole map is checked for moveable areas
... not only a pro. With severe storms much can change and what
... about earthquakes, also a version of quake. All of the scenery
... can move I think. Do you it's difficult to code a so low quality
... picture where all is changing.

... Do you remember the web-GUIs of "der Bauer" A large wooden door
... in a stone wall and a deep thumping a stamping of giant feet that
... approach with deep noises from the hell. And the door and walls
... trembling in the dust. Beautifully made for a lousy internet
... connection for the noise and the image were very poor and still
... so fantastically made.

- old 2d theories apply and is pretty fast
- Simpler movement needed, flocking should be much simpler
- One run of the parser is enough to reviel the whole level
... why parsing the reality of the game scene is already loaded,
... isn't it. What has to be generated then? Are you building up an
... administration, am I a bookkeeper?

- Originally better looking movement
... I don't know enough of this way.

Cons:

- Dependant on the BSP Version, needs a different parser for each game
... Yes when parsing is necessary. Not nice, no.

- Lot more difficult to do
... I believe you

- Very difficult to annotate special movements like water, ladders, elevators etc. (if you can't 'simulate' the game physics)
... I think it's a lot of work, ladders are also different.
... I should think the bot comes with his abilities, mith margins
... of course and meets the ladder. He can fall down, maybe you can
... help him. That kind of games we will make, later... Did I
... tell here one mathematical word?

- Static models not in the world bsp need to be cut out of the polygon soup (this especially gives me headaches right now)
... the main objection is I can see in many games the static
... environments and that's not giving much joy. After so many
... years coding stil the same static backgrounds?

- Dynamic models much harder to avoid
... Yes, I agree with this, and why would this be more difficult and
... why would it take more memory in use. Provided we think very
... well how we can do this. Just trust your brains and use your
... fantasy.

Ed van der Meulen