the main issue in here is that the project still alive!!!

thanks GOD!

:)

my mapping is still alive!

slow but alive! 

What was your solution for the AI following the player?

I remember the F corridor description in the dev doc - the shambler ignoring the first branch because the player used the far one. But it didn't explain how exactly.

We've been thinking of the player leaving a trail of 'smell' behind them - dropping a finite number of entities basically, the oldest getting removed first. 

the monsters can follow that is, with some having a longer smell range than others. 

... mapped for neharah. Should try it one of these days. 

JPL if you make .qrk file sent me please! 

telnet 194.65.24.228:6969 

Email :) 

ijed: If I'm not mistaken, the monster records the vector location of its client enemy about every frame *if* the client is visible. If the client is not visible, it will try an alternate move routine to seek out that vector (the last place the monster saw the client)... before it defaults to the standard movetogoal hunting. 

That sounds cheaper, depending on how many players there are. 

I suggested to Elek an architectural transition (simplistic to more complex) from the regular Quake maps to the newer maps. There was a philosophy behind it, but now in retrospect, errm, it may not have had the intended effect.

i would actually have made that same suggestion. the first two maps were a pretty ideal introduction stylewise; perhaps 3 could have been a little more impressive to bridge the gulf a little more, but starting off small & basic before progressing upwards is always a good technique. it was only the tough gameplay i had issues with; it's always been my view that introduction maps should generally have relatively low-key easy gameplay, letting the player soak up the atmosphere and get a general feel for the game before laying the smack down later on 8) 

We've been thinking of the player leaving a trail of 'smell' behind them - dropping a finite number of entities basically, the oldest getting removed first.

That seems like a good system. It breaks when the player does something the monster can't (like drop off a ledge, or walk over a gap in the floor) but even then the monster will be no more broken than he currently is. Except it the player circles around, the current AI would start moving towards the player while this new AI would continue to try to get to this old breadcrumb... but then, if you limit the number of crumbs they will eventually de-spawn and the monster will start seeking either A. the player or B. the more recent breadcrumbs, which are closer to the player. 

Yeah. How many breadcrumbs and the frequency of drop (time or distance?) will have to be experimented with.

My coding's not so great though (too inefficient and takes me ages to write) so it'll take some time to get in - if it seems a good idea to the real coders on the team that is. 

Vertical movement -/+ 256 units could actually break the trail - removing previous entities left behind... 

Or mark it as leapable... 

another cool thing you could do with the breadcrumb idea is if you wanted to make more "realistic" monsters, the breadcrumb idea could be used to make a monster seek to the last place it saw its enemy, rather than magically seeing the current enemy position through walls. 

The Nehahra method Mindcrime mentioned above. Using multiple points for that'd probably be too much since the monster has already seen the position.

I was wondering about disabling a monster's AI if it can see its target but not attack it. It would then follow smell - hopefully leading it on whatever route the player took to get where they are.

So around the corner, up the stairs and then AbleToAttack = true so return to Quake AI. 

how much of all this will actually be noticeable to the player? Because if its not, does it really matter? 

But, imagine you've just ran away from a fiend, riding up a lift and going around two corners - but it finds you anyway.

Or how many times have you had a pack of knights underneith you, roaming back and forth and making angry noises? 

Call me old-fashioned, but I like that kind of predictability and dumbness of monsters. Works well with Quake's arcade-ish gameplay. 

"how much of all this will actually be noticeable to the player? Because if its not, does it really matter?"

That's the thing with AI. In a game like Quake where monsters die in seconds, it's hard to make anything look intelligent.

"But, imagine you've just ran away from a fiend, riding up a lift and going around two corners - but it finds you anyway. "

In theory, neat. In reality, how many times do you run away from monsters? :) 

where I would run away is because of low health/ammo and it would usually be backtracking rather than seeking alternative route forward (unless I have to).

I guess if monsters can track me as I backtrack looking for health/ammo, thats kind of neat but they do that already to an extent. A lift is one scenario where they wouldnt I guess but most the time they follow you somewhat. 

How about a map where you're unarmed?

Part of what we're doing is making the game robust enough to deal with most of what the mapper can throw at it.

The reason not to do the above with some sort of node or dynamic path system (without ruling those out) is for ease of use on the mapper and backwards compatibility.

The ideal from this point of view is to replay the original maps and be surprised by playing them - the monsters reacting less like robots. 

 

No more "trapping" monsters behind walls :)

I can think of numerous situations where this enhancement would make the game more challenging.

Like the Shambler in Starkmon in the lower area. Easy to kill that one by dodging behind the wall and just hammering him with the SSG. This new idea he would be able to walk round the corner and attack the player! 

low level enemies could benefit from this. Say if the player has low ammo or health, one grunt could prove to be quite scary of following the player around the map.