News:

One Minute Game Review by The Happy Friar: https://ugetube.com/@OneMinteGameReviews
Also on Rumble: https://rumble.com/c/c-1115371

idTech 4 (aka Doom 3 tech) Discord Server! https://discord.gg/9wtCGHa

Main Menu

Why are so many mods existing IP's?

Started by aphexjh, October 24, 2014, 01:05:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

motorsep

@BloodRayne: There is no trick to it. It's a learning process, just like when you have to learn anything new.

Unity doesn't have level editor per se out of the box. All levels have to be modeled. If you want something similar to Radiant (CSG geometry), you have to buy a module for Unity. Some people made .map file reader or converted, so you could map in Radiant derivatives and then import .map to Unity.

UE4 has CSG, but indeed, it's opposite to Radiant way of mapping. In Radiant/idtech4, the world is void, and you add geometry (brushes) to it. In UE, the world is solid (rock? :) ) and you carve (subtract) from it to make rooms. Nothing mind boggling, just a different concept to get used to. Plus, the amount of training materials for UE4 (even for UDK) is massive. There is no excuse not to learn it, if you have desire/time.

Good example is ahead. When I was 3DS MAX user (a way back in the days) and I wanted to switch to Blender, I found it to be ALIEN^1000000 to me. It took me a good month or two to wrap my head around it and become more or less proficient with Blender.

If you are really being honest, you should see why idtech 4 is hard to work with. There  is no conspiracy. The reasons are on the surface.

The Happy Friar

I used the forum "split topic" tool to make a new thread for the Unreal vs id mapping discussion.  Here: http://idtechforums.fuzzylogicinc.com/index.php?topic=157.0

Cool discussion btw.  :)

oneofthe8devilz

#32
I never considered content creation with unreal engine based editors to be my true problem... but what personally bothers me most about the UDK/UE4 engines, is the lack of proper AI navigation showcases/kits for indie developers...

I've seen proper AI Navigation done right in UE-games before (AAA games examples like Gears of War, Hunted:The Demons Forge, Spec Ops The Line to name just a few) but all those developers had source access to the engine and were probably re-writing the AI navigation from scratch...

When we look at the showcases that are being released with the UDK/UE4 (and community), they look nothing even remotely close to that...

You either have really dumb utbots that mostly move along static navigation routes being 100% of the time predictable (that is unless for some reason they get stuck and their navigation goes completely down the drain) or you end up with custom hacked AI showcases that desperately try to make use of the Navmesh feature and fail to do so... Either way you end up with an AI behavior that looks tediously generic, repetitive and amateurish...

I still have to see an indie UDK/UE4 video clip showcasing doing something useful regarding AI navigation sharing the method to implement it...

In short, IMO the default unreal engine "Nav-Point", "Pylons", "Navmesh" methods produce terribly awkward behaviors prone to bugs, are hard to implement and IMO produce intolerable results...

With idtech4 instead, I simply build my map and the system automatically compiles the AAS navigation file for me and unless I violate a few basic rules at the end of the day I always end up with AI  that perfectly navigates around that new environment...

In combination with proper AI doom-scripting, one fairly simple gets to achieve dynamic and unique group AI behavior that looks and behaves naturally to the eyes of the players and works great in a multiplayer/coop environment...

In case anyone here knows a clever way how to apply the same quality of AI behavior to unreal engine games with the same ease, I am all ears because the rest of the unreal engine/tools are pretty easy and comfortable to work with...


I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

Chosker

Quote from: oneofthe8devilz on November 14, 2014, 02:35:29 PM
When we look at the showcases that are being released with the UDK/UE4 (and community), they look nothing even remotely close to that...

You either have really dumb utbots that mostly move along static navigation routes being 100% of the time predictable (that is unless for some reason they get stuck and their navigation goes completely down the drain) or you end up with custom hacked AI showcases that desperately try to make use of the Navmesh feature and fail to do so... Either way you end up with an AI behavior that looks tediously generic, repetitive and amateurish...
I have to say I haven't really seen "showcases" released with the UDK/UE4 that feature AI navigation, but then again I haven't been looking too much :)

with that said let's explore the core of the problem a little.
when it comes to AI movement I'd say it can be reduced down to two elements: pathfinding and behavior.
- pathfinding is what allows the character to move from A to B without getting stuck
- behavior is what drives the character to what they do and for the reasons they do it

in UDK for pathfinding you could use Pathnodes (which required strategic placement and produced somewhat robotic pathfinding, the curves of movement were not smooth), and then Navmeshes (which required less human input for better results, and produced much smoother movement curves for movement). Pylons are the same as Navmeshes btw.
in UE4 pathnodes are gone for good but navmeshes are supposedly better (you can build them at runtime, but I doubt there's any other improvements that affect the visual quality of movement)

now let's assume you used navmeshes because they are more recent/better tech than pathnodes.
is the core of the problem about moving from A to B? do you experience characters getting stuck, moving in linear routes, move in jerky ways, losing their way?
or is the problem about the behavior?


in UDK behavior pretty much didn't exist in a usable way. there's no such thing as a "behavior coding tool" and this is understandable (writing AI is not trivial, much less for a multi-purpose game engine)
the only example that came with UDK was the UTGame AI. you could modify the UTBots which had some obscure and very UT-dependant ways of determining the behavior. back then when I did this I realized it was a pain to get them to do what I wanted them to do so I just wrote my AI class from scratch.
also most tutorials cover the basics of pathfinding and barely scratch the surface of behavioral AI. it's a complex matter that even AAA game titles have trouble with, so it's understandable that UDK AI behavior tutorials hardly ever went beyond a "Zombie AI" implementation.

UE4 now comes with the Behavior Trees feature. there's already at least a couple of tutorials around, and I heard that the ShooterGame sample project uses them for their AI (though I don't know if it's true and if so, how much developed it is)
I haven't tried it myself, but it's a recent feature so I don't think it's usable for production yet. but at least some effort is being made.


to sum it up I'd say there's more than enough information to get a pathfinding implementation up and running, but then I'd agree with you that there's hardly any behavioral AI showcases/kits for UDK.
however getting an AI to patrol, pursue an enemy in a non-kamikaze way, use the environment to his advantage, or have group behavior, are all non-trivial tasks that require some effort.

Quote from: oneofthe8devilz on November 14, 2014, 02:35:29 PMWith idtech4 instead, I simply build my map and the system automatically compiles the AAS navigation file for me and unless I violate a few basic rules at the end of the day I always end up with AI  that perfectly navigates around that new environment...
I've never done any maps for idtech4, so can you describe a little better what you mean with this? the AI perfectly navigates around that new environment, which means he can follow you on sight? patrol the area? strategically camp around powerups? have multiple enemies act as a group that can surround you or block the exits?
and how would it reflect to the AI if someone wanted to mod idtech4 into a tower defense game or a sniper vs. sniper hide n seek?
Developer of Elium - Prison Escape

The Happy Friar

Quote from: Chosker on November 23, 2014, 07:56:46 AM
I've never done any maps for idtech4, so can you describe a little better what you mean with this? the AI perfectly navigates around that new environment, which means he can follow you on sight? patrol the area? strategically camp around powerups? have multiple enemies act as a group that can surround you or block the exits?
and how would it reflect to the AI if someone wanted to mod idtech4 into a tower defense game or a sniper vs. sniper hide n seek?

The camping & group attacking would need to be built in to the AI's code (like the "smart" strogg troopers from Q4).  Q4 even had helper entities for stuff like what you described (ETQW has amazing AI that does near what you say).  What the D3 tech Area Awareness system does is different: it tells the AI where it can go.  It says "that area is to short, don't try to go down there."  It says "That drop is to tall, don't try to walk off."  It says "that area is to high, find another way around."  It says "those are steps, you can walk down/up them to go where you need to go."  It says "that's a ramp, you can go up/down it."  All this opposed to an AI that isn't aware of it's surroundings that trys to go up/down steps it can't navigate, then trys somewhere else.  Or walks off a cliff to go somewhere, or if not off the cliff, keeps trying to "walk" past the cliff but can't.  So in another system you might but an entity at a cliff saying "monster can jump off here" D3 doesn't need that, the compiling process already registered that information and the appropriate AI will jump if it can.  Or it will crawl, or walk up/down stairs, or run, etc. 

So when a monster sees the player & he's on a lower level & can't attack the player, it will find the proper way to get down and attack w/o any extra entity placement.  It won't walk to a staircase & not be able to go up because it's to steep and keep trying to "walk" up, it won't even try.   It won't fall off the edge of a cliff (unless it's allowed to) and die, it will go around.  However, most monsters in D3 are range monsters and have a "fire first" AI, so they do all this cool stuff very rarely.  Q4 greatly expanded on it & ETQW even further.

oneofthe8devilz

#35
I would say the major difference between modding AI behavior and navigation for Doom3 versus UDK/UE4 is that Doom3 was released as an AAA commercial game with an opensource text based file structure, whereas the UDK/UE4 devkits are more of a Sandbox "anything is possible" solution directly targeting indie and professional developers.

So while technically it certainly is possible to achieve AAA quality AI behavior and navigation with the UDK/UE4 kit, it will actually require top notch state of the art programming skills and/or significant resource-investments to realize it.

In contrast to that, while from a business point of view certainly not being the best idea, using Doom3 comes with a number of significant advantages over the UDK/UE4 regarding AI behaviour and navigation...

The open textbased file-system in combination with the various Monster enemy presets that can easily be extended (inherited) in combination with the quite flexible doomscript AI behaviour, make it very very easy even for beginners to generate new and complex AI entities that benefit from all the work that id software invested in the first place...

Here quite an old video from 2011 as an example where an AI entity has been re-programmed to act as a bodyguard to human players (human players have a green triangle "head icon" and friendly AIs have a rotating green dot "head icon), protecting the human players against the enemy AI monsters at all costs. And while the video might be nothing impressive visually, I am convinced that trying to re-create such an AI behavior and navigation in an environment of similar complexity with the UDK would technically almost be impossible for me to do due to the lack of technical ability on the one side and the lack of already implemented sub-behavior-routines (that come with the Doom3 game) on the other side...



btw... the youtube movie example I have posted here actually is a very bad one.. as this custom created map was still early wip in 2011 being converted into a playable coop-map and most ".ase" based models were not yet marked to be obstacles for the AI and so they keep constantly bumping into them not being aware of them... this has been fixed by now

Doom3's AAS (Area Awareness System) seems to be the equivalent of UDK's/UE4 navmesh system with the difference that it was developed in the early 2000's and released in 2004.

And it might be just my personal opinion here, but I find it way more simple to apply and work with the AAS system producing reliable AI navigation results with custom maps compared to the UDK's navmesh, where the AI still constantly either bumps into static/dynamic obstacles, looses complete track of the current tasks/enemies or simply denies to work at all...

Now I think the situation might be completely different if we had complete source and asset access to one of the major AAA unreal engine powered games like "Gears of War, Hunted: The Demon's Forge, Spec Ops: The Line" which we then could put into direct comparison with Doom3. But since this is VERY unlikely to happen I am judging from the current situation.

Doom3 was developed by id software, a company that significantly influenced the history of computer games (in pretty much every regard be it "3d rendering, networking or cooperative gameplay") and while most people might scream that the AI featured in Doom3 is one of the most primitive ones (attack the enemy at any cost ignoring cover or damage), thanks to the open text based way in which every asset, script and code is written in Doom3, it is predestined to serve as a perfect tutorial in itself giving the modder infinitive possibilities to modify the existing assets and codebase while at the same time having access and inheriting all the AAA assets and code (including the AI behaviour which in intself might skilled people take a very signifant amount of time to develop) to base his mod work on.

I am convinced one of the main reasons why idtech modders find it difficult to learn and work with UE devkits, is the fact that over the years working with Doom3, they got used to this very "open-source-ish" way of working with the assets and codebase...

Now I did not yet try out the UE4 kit but with the UDK, every tiny peace of asset, code and script gets instantly compiled/binarized on runtime which sometime makes understanding and quickly editing/experimenting with assets or code take longer than it really needs to...

Of course the UDK has a ton of features and tools that totally blow the Doom3 tools out of the water when it comes to efficiency and complexity, but I always felt that with the UDK, there is this extra layer of "binarization" which keeps me from working at the same "low-level" asset-access that I got used to while working with idtech4.
I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

Chosker

#36
Quote from: The Happy Friar on November 23, 2014, 08:40:54 AM
What the D3 tech Area Awareness system does is different: it tells the AI where it can go.  It says "that area is to short, don't try to go down there."  It says "That drop is to tall, don't try to walk off."  It says "that area is to high, find another way around."  It says "those are steps, you can walk down/up them to go where you need to go."  It says "that's a ramp, you can go up/down it."  All this opposed to an AI that isn't aware of it's surroundings that trys to go up/down steps it can't navigate, then trys somewhere else.  Or walks off a cliff to go somewhere, or if not off the cliff, keeps trying to "walk" past the cliff but can't.  So in another system you might but an entity at a cliff saying "monster can jump off here" D3 doesn't need that, the compiling process already registered that information and the appropriate AI will jump if it can.  Or it will crawl, or walk up/down stairs, or run, etc.
UE's navmesh system also accounts for this, but not in such a flexible way.
if you take a look at this very standard navmesh, you can see it already accounts for ramps (which really are the same as stairs), and areas that are too high to walk up to, or too low to jump down from.
there's a few limitations though. if you have an isolated area of the navmesh (like the top of the box in the screenshot) it will never be reachable by any means. some guy (Rama) made a system that allows jumping up/down such places but I believe it requires significant effort. I'd be suprised if Epic doesn't include such a thing in the future though, as I'm sure the new UT game will need it.
aditionally, the navmesh is the same for everyone. if a cliff is just too high to jump for character A, it doesn't matter if character B is twice as tall, he still won't be able to jump it.
also I haven't tested this, but I suspect that if you make a narrow passage that character A can fit through, character B who is twice as fat won't realize he can't fit and will keep trying. I hope I'm wrong on this one though :)

Quote from: The Happy Friar on November 23, 2014, 08:40:54 AMSo when a monster sees the player & he's on a lower level & can't attack the player, it will find the proper way to get down and attack w/o any extra entity placement.  It won't walk to a staircase & not be able to go up because it's to steep and keep trying to "walk" up, it won't even try.   It won't fall off the edge of a cliff (unless it's allowed to) and die, it will go around.  However, most monsters in D3 are range monsters and have a "fire first" AI, so they do all this cool stuff very rarely.  Q4 greatly expanded on it & ETQW even further.
this is still "getting from point A to point B" which is no different from any proper pathfinding system. in the case of navmeshes, the steep stairs won't even be computed as 'walkable' so no one will ever attempt to walk up them. but again this is only okay if all the characters have a similar size.




Quote from: oneofthe8devilz on November 23, 2014, 09:33:26 AMwhereas the UDK/UE4 devkits are more of a Sandbox "anything is possible" solution directly targeting indie and professional developers.

So while technically it certainly is possible to achieve AAA quality AI behavior and navigation with the UDK/UE4 kit, it will actually require top notch state of the art programming skills and/or significant resource-investments to realize it.
exactly my point

Quote from: oneofthe8devilz on November 23, 2014, 09:33:26 AMIn contrast to that, while from a business point of view certainly not being the best idea, using Doom3 comes with a number of significant advantages over the UDK/UE4 regarding AI behaviour and navigation...
sure, UDK's one is limited and also multi-purpose, while Doom3's is much more geared towards the FPS kind of monster AI so it's very natural that the behavior tools are easier to use in that context.
but like I said how would it hold up if you wanted to create a sniper vs. sniper hide and seek AI, or a tower defense AI? or what about someone makes a mod of doom3 to make a chess game, or an RTS?

Quote from: oneofthe8devilz on November 23, 2014, 09:33:26 AMAnd it might be just my personal opinion here, but I find it way more simple to apply and work with the AAS system producing reliable AI navigation results with custom maps compared to the UDK's navmesh, where the AI still constantly either bumps into static/dynamic obstacles, looses complete track of the current tasks/enemies or simply denies to work at all...
I never tried UDK's navmeshes (made my own pathfinding solution), but in my brief with UE4's pathfinding the navmeshes always felt reliable, even if modified dynamically. keeping track of the current tasks/enemies is a matter of the AI programmer's code, and "simply denies to work at all" is an unacceptable scenario that I never had.

Quote from: oneofthe8devilz on November 23, 2014, 09:33:26 AMNow I think the situation might be completely different if we had complete source and asset access to one of the major AAA unreal engine powered games like "Gears of War, Hunted: The Demon's Forge, Spec Ops: The Line" which we then could put into direct comparison with Doom3. But since this is VERY unlikely to happen I am judging from the current situation.
exactly. you're comparing the AI of a full and finished AAA game that is open to modding, with that of a multi-purpose engine (and an incomplete one, both UDK and UE4). it's only natural the one in Doom3 is better.

Quote from: oneofthe8devilz on November 23, 2014, 09:33:26 AMI am convinced one of the main reasons why idtech modders find it difficult to learn and work with UE devkits, is the fact that over the years working with Doom3, they got used to this very "open-source-ish" way of working with the assets and codebase...

Now I did not yet try out the UE4 kit but with the UDK, every tiny peace of asset, code and script gets instantly compiled/binarized on runtime which sometime makes understanding and quickly editing/experimenting with assets or code take longer than it really needs to...

Of course the UDK has a ton of features and tools that totally blow the Doom3 tools out of the water when it comes to efficiency and complexity, but I always felt that with the UDK, there is this extra layer of "binarization" which keeps me from working at the same "low-level" asset-access that I got used to while working with idtech4.
this also striked me as weird when I started working with UDK. they have this approach where you cannot create or modify any content without having the editor open.
in UE4 it's still the case but with two slight but powerful differences.
- first one is the assets no longer live in packages, but each is now their own (yes, binarized) file of its own. this makes it easier to deal and manage them, and have multiple people work together
- second one is that with the 'coding' being done primarly in the editor for many people (via blueprints), and the inclusion of hot reloading of the C++ code modules, iteration times are much faster because you don't really need to close the editor (or wait for longer game launch times) to test new stuff
Developer of Elium - Prison Escape

motorsep

#37
Doom 3 AAS system is much more prosaic than what TheHappyFriar wrote about it :) It simply defines areas (volumes) for AI to use and their reachability.

Doom 3 monsters don't jump, at all. MOVETYPE_WALK and related types of movement don't even account for verticality. MOVETYPE_FLY is the only one type of movement that does that. So all in all AAS system is the same thin as nav mesh, just in 3D (verticality, which isn't even utilized for the most part). Technically AAS could be used for 6D navigation, a la Descent, but it needs to be heavily revised/improved.

AAS also doesn't care for meshes. It only works with brush based world. So every model has to have brush hull inside or manually clipped. Dynamic obstacles avoidance is in primitive state.

AI itself is a simple FSM (leaning toward HFSM) and is animation dependent. If you don't have a frame of animation - you can't call event / script.

One could probably go a way beyond what Doom 3 and AI mods for Doom 3 offer, but it requires tons of animations per character and/or significant rewrites of the engine (and that's why ETQW's and idTech 5's AAS systems are quite different from what Doom 3 has).

So objectively speaking, if one has dedicated programmer and time, one should be going with Unity or UE4 (although it is still a quite raw engine for production). Doom 3 could be built on UE4 and it will be in all aspects better than Doom 3 on idTech 4 :P (except the modding part).

One thing that idTech4 GPL has that no other engine does is full game code, tested by time and modders. It's heavily underutilized in Doom 3, and there is so much more that can be done with the code out of the box (with some fixes and addition, but nothing too major). To create such code base in UE4 it will take a massive effort and time. So if we are talking about time savings, it could be easily half of the dev time saved using Doom 3.

As for non-binarized assets... Well, if ID Software cared about modders as much as Epic cares for devs, we would have massive amounts of documentations, which would negate necessity of having ascii format assets. Not to mention now much inefficient ascii assets are for RAM and loading times. That's why BFG engine converts it on the first run into binaries, so that it takes less RAM and level loading times are _much_ faster than with old Doom 3.

So to prospective indie devs - stay away from original idTech 4 as game dev platform (it's good to mod Doom 3 and get a feel what it offers as far as gameplay code and what can be done with it). Either use Doom 3 BFG engine (which will still require effort to bring it to production ready level) or go with Unity or UE4. Or wait until Storm Engine 2 is out to the public ;)

motorsep

Quote from: Chosker on November 23, 2014, 10:28:51 AM
Quote from: The Happy Friar on November 23, 2014, 08:40:54 AMSo when a monster sees the player & he's on a lower level & can't attack the player, it will find the proper way to get down and attack w/o any extra entity placement.  It won't walk to a staircase & not be able to go up because it's to steep and keep trying to "walk" up, it won't even try.   It won't fall off the edge of a cliff (unless it's allowed to) and die, it will go around.  However, most monsters in D3 are range monsters and have a "fire first" AI, so they do all this cool stuff very rarely.  Q4 greatly expanded on it & ETQW even further.
this is still "getting from point A to point B" which is no different from any proper pathfinding system.

Indeed. Even Quake 1 did that, and it has no actual navigation routine ;)

The Happy Friar

All my experience with Quake 1 & 2 stock AI methods (not new GPL versions or other games based on their code) shows the AI to be pretty dumb in surroundings.  Both will try to do things it can't do (like walk off a cliff or up a cliff).  Never encountered that with stock D3.  They just follow commands or go straight for the player w/o "knowing" what's around them.

But when comparing D3 to UE4, devils is correct: there's nothing to REALLY compare as D3 gives us a full game & UE4 gives us nothing.  We get less with UE4 really: with D3 you can load up the stock assets to see how you can improve things.  With UE4 there's nothing to test with or improve upon as the developers gave us nothing (they have stuff, they make games with it, they just didn't release it for us to see).  Everything being talked about here with UE4 is theory, with D3 it's fact.  I'll take fact over theory any day.  Maybe Epic should GPL their UDK code so people can get a better look at it.   O:-)

And motorsep, you should know that D3 monsters DO jump.  Imp (and those weaker Imp wanna-be's) and that baby thing do.  :)

motorsep

Quote from: The Happy Friar on November 23, 2014, 08:29:02 PM
All my experience with Quake 1 & 2 stock AI methods (not new GPL versions or other games based on their code) shows the AI to be pretty dumb in surroundings.  Both will try to do things it can't do (like walk off a cliff or up a cliff).  Never encountered that with stock D3.  They just follow commands or go straight for the player w/o "knowing" what's around them.

Quake 1 and 2 don't have navigation system. Quake 1 has findradius() function which tests in real-time available path. Doom 3 only has that precompiled, just like navmesh. So AI in Doom 3 doesn't need to test path, it only needs to follow it. Thus you don't see "dumb" behavior. But, get up on the table in Doom 3, and you will see AI running around it ;)
There is really nothing magical or awesome about Doom 3 AI. It was, like many other things, underdeveloped, and that's why it's almost all trigger based.

Quote from: The Happy Friar on November 23, 2014, 08:29:02 PMBut when comparing D3 to UE4, devils is correct: there's nothing to REALLY compare as D3 gives us a full game & UE4 gives us nothing.  We get less with UE4 really: with D3 you can load up the stock assets to see how you can improve things.  With UE4 there's nothing to test with or improve upon as the developers gave us nothing (they have stuff, they make games with it, they just didn't release it for us to see).  Everything being talked about here with UE4 is theory, with D3 it's fact.  I'll take fact over theory any day.  Maybe Epic should GPL their UDK code so people can get a better look at it.   O:-)

UDK has no gamecode either. They should really release one of the games they made. After all, UE4 is a development platform, not modding platform. It doesn't really help small indies to go after large games, but it does help developing small games quicker, more efficiently, and not get stuck in the engine fixing. They only need to worry about gameplay and art.

Quote from: The Happy Friar on November 23, 2014, 08:29:02 PM
And motorsep, you should know that D3 monsters DO jump.  Imp (and those weaker Imp wanna-be's) and that baby thing do.  :)

That's not jumping, that's leaping ;) By not jumping I mean not jumping off/up a ledge in pursuit of the player. They only perform melee attacks horizontally or with projectiles.

BloodRayne

Quote from: The Happy Friar on November 23, 2014, 08:29:02 PM

And motorsep, you should know that D3 monsters DO jump.  Imp (and those weaker Imp wanna-be's) and that baby thing do.  :)

Actually, Motorstep is technically correct. The 'jump' is nothing more than an animation that's alled on the monster, if available. The AI doesn't actually 'jump' anywhere. It tracks the origin, sees if a jump animation is possible (without the origin moving in height!) and then executes the animation after which the new origin point is read and the AI goes from there.

The AI doesn't know how to navigate heights like a player would be able to, jumping on obstacles and properly allowing for all (or even some) jump mechanics in navigating the map vertically.

But I believe it's actually not very hard at all to program such behaviour into the AI of Doom3. I mean all code is available. And you can quite quickly hack some stuff in there that will allow for greater and smarter movement. I've added coded in Grimm for example that allows creatures to recognise more of their surroundings, when they are surrounded by breakables they will attempt to break them, thus breaking free.

If you don't want to include horizontal pathing you'll have to trick monsters into using a ladder. You can do this by making the monsters aware of their relative height distance to the player. If for example it is 100 units below the player (and the player cannot be reached by normal travel) then it could try to find the nearest ladder and attempt to traverse it. A simple hack like that could actually work quite well without having to re-invent the AAS pathing system.

In fact, this sounds like a very fun challenge to work on because I've been thinking about creating a 3D Lode Runner mod for Doom3.

aphexjh

Quote from: BloodRayne on November 24, 2014, 09:24:57 AM
If you don't want to include horizontal pathing you'll have to trick monsters into using a ladder. You can do this by making the monsters aware of their relative height distance to the player. If for example it is 100 units below the player (and the player cannot be reached by normal travel) then it could try to find the nearest ladder and attempt to traverse it. A simple hack like that could actually work quite well without having to re-invent the AAS pathing system.

In fact, this sounds like a very fun challenge to work on because I've been thinking about creating a 3D Lode Runner mod for Doom3.

The method of having AI search for certain volumes, in this case the ladder volume, is similar to the way ai and players navigate "Mantle over" and "Mantle on" objects in the IW engines (CoD games). 



You just place these brushes in the map and the ai finds them and uses them when needed. If BR is correct, it shouldn't be hard to implement a similar technique in Tech 4.

Sir Blackington

This is more specific to the etqw bots, but aren't the strogg ai with the jetpack able to use that to navigate the map vertically in ways undoable without it?

motorsep

Quote from: Sir Blackington on November 25, 2014, 12:08:40 AM
This is more specific to the etqw bots, but aren't the strogg ai with the jetpack able to use that to navigate the map vertically in ways undoable without it?

Where did you see Stroggs in Doom 3 ? ;)