The state of Doom 3 modding is pretty sad (while people still play and buy Doom 3, there aren't any new mods coming out and many of the old mods are abandoned).
So I am wondering if there are any modders who dwell on this forum worked with Doom 3 AI.
The question is if AI seen in my previous game, Steel Storm (http://store.steampowered.com/app/96200/), doable in Doom 3 without messing with C++ code.
what features have the Steel Storm AI?
does it use objects or lists?
I wish I knew :)
What it does it generates navigation grid made of cells of a fixed site, before player and AI spawns. It's purely a 2D system. It doesn't account for ramps or lifts or ladders. If an entity other than player occupies cell(s) those are marked as unavailable. AI simply probes around for free cells and moves enemies into free cells. Some basic steering is in place to "turn" around occupied cells. As AI finds player, they attack and they always track player as they move around. Of course there is a factor that doesn't allow them predict where player will be, otherwise player will never win :)
That's the gist of it.
well there are multiple things here
- the AAS system should be more advanced that any grid out there ,and should take into account the reachabilities, therefore the ramps should also make into it, lift won't though, as well as ladders (although those could be added in)
- the AAS won't take into account the moving entities, that has to be worked out in real time
- is the turning on the centre of gravity of the enemy or the turn is done describing big circles with the centre out of the enemy?
- there is this concept of planning in AI that at the moment is quite impossible in AI scripting (as done in idTech X ) because the lack of lists, that should anticipate the player actions (F.E.A.R. had a system like this)
- the way you describe the AI seems to be pretty similar to what quake 1-2 monsters did, to always track the player position, with an added navigation scheme on top (that 2D grid you spoke about) tracking the player is what d3 monsters do all the time, so it should be totally doable in scripting (minus the 2D grid, but that's what the AAS is for which should be far more advanced)
- things that should require lists probably would be multi agent strategies, and multi target strategies per agent, the first should be interesting due you could find several enemies, and those could pin you while others flank you ( somewhat to what you're asked to do in the Brothers in Arms series ) but as I stated you might need lists for this
-also AAS makes enemies in reality blind because navigation is separated from decision making, only feeding it as input for decision making, therefore you don't know anything about your surroundings just how to navigate it, you don't know how tall is that wall, you just know how to navigate around, so tracing several lines should be the first steps towards a strategy, but without lists, this all goes quite forbidden quite quickly, another idea could be, adding a strategist scheme via c++ that could feed the scripting, but this is more laborious than having a simpler (much much much more simpler) AI scheme like the ones in D3.
- the AI schemes in D3 are FSM ( Finished State Machines ) which get bloated as you need more features from them, and doesn't facilitate the construction of different AI behaviour for different agent (all the enemies behave similarly or equally, and all agents never gain any capacity over time) there are other ways to produce AI scripting that discard the FSM scheme completely and get more real-time generated AI with far more advanced capabilities.
Quote from: BielBdeLuna on April 28, 2015, 04:15:05 AM
- the AAS won't take into account the moving entities, that has to be worked out in real time
It actually would. There is dynamic obstacles avoidance system in Doom 3.
Quote from: BielBdeLuna on April 28, 2015, 04:15:05 AM
- is the turning on the centre of gravity of the enemy or the turn is done describing big circles with the centre out of the enemy?
It's just moving and adjusting turn angle. It's already in Doom 3's code (maybe not exposed to script).
Quote from: BielBdeLuna on April 28, 2015, 04:15:05 AM- there is this concept of planning in AI that at the moment is quite impossible in AI scripting (as done in idTech X ) because the lack of lists, that should anticipate the player actions (F.E.A.R. had a system like this)
RAGE doesn't use planner either, but its AI is awesome :)
Quote from: BielBdeLuna on April 28, 2015, 04:15:05 AM- things that should require lists probably would be multi agent strategies, and multi target strategies per agent, the first should be interesting due you could find several enemies, and those could pin you while others flank you ( somewhat to what you're asked to do in the Brothers in Arms series ) but as I stated you might need lists for this
No need to get things overcomplicated. If you can play SS:BR demo, you can "feel" the AI. It's quite good without having any advanced AI methods.
Quote from: BielBdeLuna on April 28, 2015, 04:15:05 AM-also AAS makes enemies in reality blind because navigation is separated from decision making, only feeding it as input for decision making, therefore you don't know anything about your surroundings just how to navigate it, you don't know how tall is that wall, you just know how to navigate around, so tracing several lines should be the first steps towards a strategy, but without lists, this all goes quite forbidden quite quickly, another idea could be, adding a strategist scheme via c++ that could feed the scripting, but this is more laborious than having a simpler (much much much more simpler) AI scheme like the ones in D3.
That's no different than any other AI. There flying monsters, so there is a way to determine the height. Although I believe they just navigate until they reach the goal. But AAS has ledges and all that good stuff, so I am sure it's not a big deal to write a function that measures the height of the walls from the floor to the ledge. The question is how is it related to the AI in general and to the AI I need to make in particular ?
Note that somehow people think self-aware AI is awesome, but in reality it's faster and cheaper to have mix of prescripted events and hFSM to make fun and challenging AI than develop "correct" AI system that works as if it's a human/self-aware AI.
Quote from: BielBdeLuna on April 28, 2015, 04:15:05 AM- the AI schemes in D3 are FSM ( Finished State Machines ) which get bloated as you need more features from them, and doesn't facilitate the construction of different AI behaviour for different agent (all the enemies behave similarly or equally, and all agents never gain any capacity over time) there are other ways to produce AI scripting that discard the FSM scheme completely and get more real-time generated AI with far more advanced capabilities.
FSM is easily organized into hFSM. Lists and anything else beyond FSm / hFSM is absolutely unnecessary at this point.
As I mentioned, AI in SS:BR is well received by people (a lot of folks thought it was too smart and tough; but I say it's just where it should be; maybe need slight tweaks and improvements but overall it's a perfect fit for the game), so there is no need to go a way beyond that. The goal is to recreate AI as-is (the "feel", not the exact code).
Quote from: motorsep on April 28, 2015, 09:16:42 AM
It actually would. There is dynamic obstacles avoidance system in Doom 3.
is it robust enough?
Quote from: motorsep on April 28, 2015, 09:16:42 AM
It's just moving and adjusting turn angle. It's already in Doom 3's code (maybe not exposed to script).
turning is exposed and used in every character AI script
Quote from: motorsep on April 28, 2015, 09:16:42 AM
RAGE doesn't use planner either, but its AI is awesome :)
it is? what does Rage does diferent? how different it is from D3? there is a lot of animations in RAGE at there might be some cover, but there is also cover in d3
Quote from: motorsep on April 28, 2015, 09:16:42 AM
The question is how is it related to the AI in general and to the AI I need to make in particular ?
the idea was to comment on the limits of AAS, finding it useful it's up to you
Quote from: motorsep on April 28, 2015, 09:16:42 AM
FSM is easily organized into hFSM. Lists and anything else beyond FSm / hFSM is absolutely unnecessary at this point.
what do you refer as hFSM?
Quote from: motorsep on April 28, 2015, 09:16:42 AM
AI in SS:BR is well received by people
I don't see much of difference between the AI in your game and the one in d3 imps so I guess you could start there
I know what AAS can and can not do, and you could at least play the game before saying there is no difference between AI in SS:BR and Doom 3's imps :/
Imps don't move as dynamically as hovertanks in SS:BR, they don't dodge, they don't back away and then attack again. Imps are dumb as rocks. All they do is attack and jump occasionally to the side (so slow and without any timing that it's a useless evasive maneuver).
You can definitely prove me wrong on this one by setting camera to top down in Doom 3 and having several imps around you (with improved AI I suppose). :)
So meanwhile the original question stays open :/
I have played the game that's the reason I stated that, and it was not meant as an insult.
so the enemies back up and dodge, ok you could add those behaviours to the imp AI script, and you're set! But this shouldn't be that big of a deal, this is an added behaviour, the general system remains the same
the general question doesn't remain open because I answered it:
Quote
The question is if AI seen in my previous game, Steel Storm (http://store.steampowered.com/app/96200/), doable in Doom 3 without messing with C++ code.
the answer is yes, it can be done, just need to look at the imp for starters and add those "new" behaviours you need
Quote from: BielBdeLuna on April 28, 2015, 11:25:59 AM
so the enemies back up and dodge, ok you could add those behaviours to the imp AI script, and you're set!
But how? Isn't dodging a part of navigation, which is in C++?
What script event would I use to dodge and back away ? I know there is script even to look at player and I believe turn, but not dodge / move backward.
Hi
Dodging is driven from script.
There are several ways of doing it atucally. In simple terms:
You can have animation based dodge, or physics based force dodge for flying creatures.
Both in general simply use a timer and when next dodge time is up, the code says can i perform animation "left_dodge" without hitting an obstacle, if so play animation on channel legs.
Things like the lost soul don't play an animation but have a physics force applied to them to dive bomb or dive back. There is also a script event to move x units away from the player and move to entity.
So basically its a collection of hard coded behaviors and tricks.
Cheers
EDIT: solarplace answered in less words. :p
Quote from: BielBdeLuna on April 28, 2015, 11:25:59 AM
I have played the game that's the reason I stated that, and it was not meant as an insult.
You should, it's a fun game. Coop is a lot of fun and the DLC is pretty darn hard. I loved it!
Quote from: motorsep on April 28, 2015, 11:31:20 AMBut how? Isn't dodging a part of navigation, which is in C++?
What script event would I use to dodge and back away ? I know there is script even to look at player and I believe turn, but not dodge / move backward.
I could never get my head around AI scripts but I've modified them somewhat occasionally. From looking at the Imp script, if the imp can't melee then it checks to see if it's in pain. If it's in pain & the current time is greater or = the next dodge time, it tests the animation. "testAnimMove" (from what I understand) has the engine check the bounding box of the animation (the whole thing). If it's ok (ie no collisions in that space) then it randomly chooses a dodge animation (it tests both left & right). So dodging itsn't in the AI or a special part, it's just a if/then/else statement somewhere in the script.
What the AI in SS:BR does is it doges w/o checking the animation because it doesn't run a dodge animation, it moves via code. That's also what Quake 2 does (never looked at Quake 1 code). Q2 has the coder manually enter in the offset values for each animations movement. A complete PITA. :)
I took at a look at the caco AI & def & tested the model in game. The Caco pain animation does make it move forward, but I can't find anywhere in the script that tells which direction/how far to move to dodge the player (which it does after getting in pain sometimes), so it must be in the code somewhere for flying monsters (IE don't stop flying at all). The only thing that I can think of for flying is that the flying monsters have a pitch/roll/yaw value and when in pain the origin rotates up to this amount and keeps moving, and if you do a standard pain anim it runs the animation and rotates based on those values.
I would figure for a SS:BR type game in D3 you'd need to animate several different dodge distances and have it test those each time it calls for a dodge to get something similar.
Doom 3 has animation driven AI, so I guess either hovertanks have to be flying monsters (but their code has no dodge functionality and it's all in C++), or they have to be standard creatures with dodge anims.
Next question is why doesn't Imp dodges properly/timely ?
Quote from: motorsep on April 28, 2015, 12:20:20 PM
Doom 3 has animation driven AI, so I guess either hovertanks have to be flying monsters (but their code has no dodge functionality and it's all in C++), or they have to be standard creatures with dodge anims.
You can easily add dodge to flying creatures. All you need to do is give them a physics force "blast" in a left or right direction from script. You could do this on a timer, or you could react to pain or you could react to enemy projectiles. It will require AI scripting of course, but its not that hard to implement. You don't need to write new systems in C++ to do that.
In fact a little physics push would look quite realistic for a hover tank perhaps?
Quote from: motorsep on April 28, 2015, 12:20:20 PM
Next question is why doesn't Imp dodges properly/timely ?
Keh? - Not totally sure of the question?
The imp spends most of its time waiting to do a "leap" attack and I'm not really sure dodge was properly implemented or it might only dodge one way I think I remember.
Bear in mind that a lot of the Doom3 AI scripts are a little "funky" in places and there are bugs. But obviously at the time id thought the behavior was just fine.
Cheers
Quote from: solarsplace on April 28, 2015, 12:30:42 PM
Keh? - Not totally sure of the question?
The D3 id AI doesn't really dodge, it reacts to being damaged. I'm not at my machine ATM but maybe the zombie police guys actually dodge.
I'm guessing what motorsep means by "dodge" is that the know the projecticle is heading their way so they get OUT of the way. The imp doesn't know about the projecticle, he gets hit at least once & then decides if he should dodge (I want to say Q2 had some monsters that would detect if a projectile was heading their way and duck (stock Q2) or dodge (expansion pack) before they'd get hit). The flying ones are the same way.
Maybe a check for projectiles could be made every couple game frames and if one is heading towards the AI position over several checks then it runs a dodge anim before it gets hit vs waiting until it gets hit.
yeah, that's what I mean by dodging. In SS:BR if you use miniguns, AI would get hit and then dodge. However with projectiles, AI will dodge (I don't recall if it always dodges). I am not sure whether it detects projectiles, or detects what weapon player fired and the distance between player and AI and then it dodges (moves aside so it won't be hit).
Quote from: motorsep on April 28, 2015, 01:36:02 PM
yeah, that's what I mean by dodging. In SS:BR if you use miniguns, AI would get hit and then dodge. However with projectiles, AI will dodge (I don't recall if it always dodges).
That must be why I always used miniguns. :) They AI must of had a time limit between dodges or else they would of never been hit.
Quote from: motorsep on April 27, 2015, 12:35:26 PM
The state of Doom 3 modding is pretty sad (while people still play and buy Doom 3, there aren't any new mods coming out and many of the old mods are abandoned).
So I am wondering if there are any modders who dwell on this forum worked with Doom 3 AI.
The question is if AI seen in my previous game, Steel Storm (http://store.steampowered.com/app/96200/), doable in Doom 3 without messing with C++ code.
@motorsep
The way I see it is that you basically have 3 options here...
Either start seriously learning and understanding the Doom3 engine, game and script code, focusing on that task for the coming months/years until you reach the desired level of technical fidelity to implement all your desired features yourself...
...or...
Start saving up money until you have a big enough financial investment sum to hire talented people that will quickly adapt and understand the Doom3 codebase, implementing your desired features for you...
...or...
Giving up your project due to the current lack of resources and/or technical abilities...
Expecting from a forum that barely has 84 members after the d3w meltdown to fix/explain all technical obstacles that you might encounter during the work on your own project is pushing it beyond the capacities of what this forum can provide or what it may have been intended for...
In a way it fascinates me, how over all those years that I have had the "privilege" to observe your online behavior, you've remained absolutely resistant in learning how to adapt and properly behave in online conversations, especially in a cases like this one here where it is you basically asking for help while at same time you trying to piss everyone one off as hard as you can with your cocky and ignorant statements...
@devil: I think you are very off-topic here, but ...
99% talented programmers somehow despise idTech 4 and don't want to touch it with a long stick (several ex-ID software folks already suggested ditching the engine). Money have nothing, absolutely nothing to do with this. They won't do it even for money (they would be more happy charging me less if I go with Unity or UE4).
I already foresee shit storm of fanboyism coming, so please do that in another thread.
I disagree...
I wonder how hard and how many potential candidates you have interviewed and how many of them were qualified for the job at all...
A professional programmer gives a shit about which engine is currently trendy...
He will work for you because to him it is a contract and because he has the required skills to complete it...
Most professional programmers I have worked with in the past years are mainly interested in problem solving... They usually absolutely do not care about which engine renders the most beautiful scenery or with which one it is the easiest to generate content/gameplay...
Also I really question the financial offers you have made your potential candidates and am pretty sure that if you would be serious about your project and put 15K on the table for a month of intense and productive programming, no qualified programmer in his right mind would turn you down... If so he would've been the wrong candidate to begin with...
That's fine. Obviously when I step up and disagree with certain things, because I have some knowledge too, I am cocky and I have no online manners and so on and so forth. But you, and some other folks can freely do so, right?
You can disagree in your own thread, this thread is about AI in id Tech 4. Thank you.
P.S. I have professional programmers on my team, who obviously work day jobs too. 1 month of intense work requires full work day commitment and only a person who does that for a living will take on such assignment. And such person won't agree to $15k per month. They would agree for more like $100+k per year. Cos you know, they have bills to pay and families to feed. So steady paycheck is appreciated. 1 month is absolutely not enough when dealing with unknown engine. Most of that time a programmer, a professional programmer, will learn the engine first, and maybe by the end of the month he would begin producing something fruitful.
I think you have to forget about animations and focus on flying monsters.
Quote from: BielBdeLuna on April 28, 2015, 08:50:27 PM
I think you have to forget about animations and focus on flying monsters.
I figured I can play with fly_* defs to stabilize entity (so it wouldn't wobble like Cacodemon). I got test model/anims/def setup. Now I need to make rough scratch AI code to even test the model in-game :/
you can use testmodel
I actually saw the model when I was setting up AF for it. I totally don't understand AF related stuff. For example, model disappears before it's completely out of the view, because "body" AF-body (on the origin bone) is out of the view. So imagine I have an octopus, and the head contains one AF-body (on origin bone), but tentacles have other AF-bodies, as soon as the head's AF-body is out of the view - whole model will disappear. Any ideas about that?
yeah, the only solution that it comes to mind is radical, we should scrap the AF program and do it in Blender with full control of all as an extension of the exporter, stuff like this will come once I finish the damn python API for idTech X
Quote from: BielBdeLuna on April 29, 2015, 12:07:53 PM
yeah, the only solution that it comes to mind is radical, we should scrap the AF program and do it in Blender with full control of all as an extension of the exporter, stuff like this will come once I finish the damn python API for idTech X
It really has nothing to do with AF Editor. It's just we need to understand the setup and its limitations. I used AF Editor and Notepad ++ to set up my AF rig. It works for the most part, but the thing is that there are certain way for setting up constraints and bodies, masking content, and including/excluding bones. Maybe certain combination is broken or not support or unfinished. I am using setups Doom 3 never used, but it's available.
your setup you described is somewhat like the four claws crane that the player uses to clear off a room full of toxic waste barrels isn't it? the middle part of the octopus should have it's proper collision shell and then every tentacle could have a nocliping shell with some system c++ controlled for it's moving isn't it?
we might have to fight the existing programs unknown quirks or do our own program with our known quirks :D
the more we work with the engine the more useful will be creating our own tools because it will give use more knowledge on the system I guess.
Quote from: BielBdeLuna on April 29, 2015, 03:37:10 PM
your setup you described is somewhat like the four claws crane that the player uses to clear off a room full of toxic waste barrels isn't it? the middle part of the octopus should have it's proper collision shell and then every tentacle could have a nocliping shell with some system c++ controlled for it's moving isn't it?
we might have to fight the existing programs unknown quirks or do our own program with our known quirks :D
the more we work with the engine the more useful will be creating our own tools because it will give use more knowledge on the system I guess.
Didn't think of that example, but regular characters would work the same - limbs are like sort of tentacles.
It just dawned on me that I might be missing a bone at one extremity and that's why bbox is constrained to "body" only. Will check after work.
It's really easier to figure engine out than build own tools. We added a few minor improvements to the tools already, except the Radiant if virtually untouched. DarkRadiant is quite sweet, but it seems like development has been bumpy lately and almost dead. If you have a burning desire to have a better level editor, there is TrenchBroom 2.x https://github.com/kduske/TrenchBroom/tree/develop and the author made it in such a way that you could potentially plug in any idtech game into it. Just need to write extension. So I talked to him and he is open to adding Doom 3 support (but as always the case with such projects, he won't do it himself :/ )
I'd like to use Blender, but Blender can't do cubical lights, and whole a lot of other things :/ I talked to some folks from Blender Foundation and they said certain things that Radiant does are not possible due to limitations of Blender's API.
what can't be done in Blender? the cubicle lights could be replaced with blender lights at export time, there is many ways to replicate the way d3 does the lights, but what else, the nurb curbes? the way the texture is setup since brush creation? all those things can be generated via scripts
if you do the tools you get the knowledge of how it works (and if you are smart enough you distribute that knowledge) and with knowledge then you can expand on the original tools on your own environment adding new features.