Jump to content
The Dark Mod Forums

Recommended Posts

How feasible is it to make a flying AI? Can they follow patrol waypoints like walking AI? Doom 3 had them, but their AI was much simpler to being with. Is it possible, for example, to put the cacodemon in the dark mod? Not that I want to, but I may want to use the cacodemon as a starting point for putting together a flying enemy. Or is the dark mod already so different than doom 3 that the cacodemon is no longer functional or relevant as an AI?

Link to post
Share on other sites

There really is no code for flying AI. Mostly missing is 3D path-planning (the engine is all about 2d-pathes that lie on surfaces), so the flying AI (we have a will-o-wisp) is not really flying, more like "sliding in variable heights over the ground".

 

That would need a lot of work (a bird behaves completely different from say a will-o-wisp, or a bee, or a dragonfly, or a butterfly, or a skull of hell).

 

We have the source, so everything is possible, but feasible it is only if you do it by yourself, or find a programmer who can do it for you. The TDM team does not have the capacities atm.

 

Edit: TDM has already been seperated from D3 so far that any D3 AI will not work - it will miss assets (models, textures, sounds) as well as the scripting side (which we ripped largely out). And since we are preparing to go fully stand-alone, this is a dead-end, anyway.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Thank you for a very informative answer. Actually, the flying AI I have in mind would work well as a variable-height, will-o-wisp variant. I'm a programmer who's worked in Java and AS3 (flash games), so this may be within my grasp. Am I to understand you've removed the AI scripting in favor of pure C++ AI baked into the engine? This would mean the only way to make (significantly different) custom enemies is to edit the mod source code.

Edited by eigenface
Link to post
Share on other sites

Edit: Interesting, I just got double ninja'd.

 

What you might do is start with something like the will-o-wisp and go from there.

It's not the best thing in the world, but it's something & it flies.

 

Edit: The core AI code is and always has been in the sourcecode, although a lot has been added by TDM as you could imagine. But all AI have associated game scripts that do other jobs for it too, and those are the ones Tels meant are missing. But even if you did have them (you stuffed them in your FM pk4), I don't know if the new AI code that's in the sourcecode is going to handle a Doom3 AI. I'm almost sure there's going to be conflicts all over the place.

 

But, that said, there's quite a bit you could do to make basically a new AI with the existing sourcecode, or even take an existing AI & replace the model & a few things in your FM package and make a new AI out of it. Since it's all open, just pay close attention to how the existing AI are made & try to copy it just like that, do some forum searches, and the errors will tell you when you need to do more. It's something you can do even without messing with the sourcecode I think.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to post
Share on other sites

Yeah, but I guess that would be a non-reactive ai, such as the pagan fen fires, not a reactive enemy, like the fire lementaries :o

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to post
Share on other sites

Thanks for the info, demagogue. To clarify, is the following correct: There were 2 kinds of AI code in doom 3, engine AI source code (C++) and AI scripts (a C++ based scripting language), and by contrast, there is only 1 kind of AI code in dark mod, engine AI source code (some of it was already present in doom 3, and more of it has been added by the dark mod team)?

 

I want to make a reactive enemy that has vision, alert states, and patrol routes (albeit hovering above them) the same as the existing dark mod AI, so it sounds like jury-rigging a will-o-wisp would not be enough. Does that sound right?

 

What would you recommend: should I use the scripting language, or would I be better off modifying the dark mod source code?

 

I have no problem modifying the source code, but then the flying enemy would not be available until the next dark mod release. The scripting language sounds like the better option to me, but then again I have no idea what would be entailed in getting it to work. Bikerdude, are you talking about a flying bird programmed with the scripting language?

 

Let me put the question this way: does it sound like a reasonable task to try to get a basic flying enemy working (vision, alerts, patrols, etc) by reworking the cacodemon script to function with dark mod? Or does that sound like a fool's errand?

Link to post
Share on other sites

The scripting doesn't do anything like reacting to the player or AI behavior. That all has to be done with sourcecode. So without sourcecode changes, you have to use what's already there, which leaves you possibilities like: (1) an AI just following a rail (a will-o-the-wisp IIRC; maybe it could still face & shoot at the player though, if you attach a normal Ai to it, but it wouldn't follow the player), (2) something technically on the ground but an invisible bottom so it looks like it's hovering, or (3) you use what's already in the sourcecode now for flying AI (what was used for that flying demon), the sourcecode from Doom3 is still there for it. You can download the sourcecode, so just do a search in the AI code for "flying" to find the relevant code (edit: well it's like what Tels was saying, not "real flying", but sliding on the ground up in the air with the ability to go up & down & bank and sort of look like it's flying, but that's what that demon was doing too). (4) Springheel made spiders hang from the ceiling IIRC, so there's code now for z-axis movement for AI that attack the player you could build off that spider code. Then just experiment with it and see what it can do. I don't know, maybe there are even other options.

 

The thing about modifying sourcecode is that there is no guarantee it actually gets into the game, and of course it doesn't work unless you get that. There'd have to be some discussion with the team & a decision, plus a lot of testing to make sure it's something good for the game, and that it works well, that it doesn't break existing AI or some other bug creeps in. Whereas building on existing sourcecode you don't have that issue; and you can do whatever you want by yourself.

 

But I believe the sourcecode for flying Ai wasn't just stripped out, because I remember it still there. So you have code to build off now that might be enough. Since I haven't played with it, I don't actually know how much it can do. But it's worth looking into what you can do with existing code first. Then you might get it to work just with that. But if you want to do more, and you have ideas how to modify the sourcecode after you've researched it for a while, then you ought to start talking with the team more formally in this thread how you want to do it, and get everybody's input.

 

That's not the worst thing either; I might have overstated it above. If you really wanted to spend time on working locally on some source code for bona fide flying Ai that search for the player, and you know what you're doing, and then you got a really good version of it working, I'm sure the team would be very excited to take a look at it and see if it works well & there aren't any game-killing bugs. It's just a bigger deal than just pk4 changes you pack in your own FM I mean.

 

So my recommendation is try to see if you can do it with only pk4 material (and existing sourcecode) first because that's the easier road to go, but report back if that's still not working and you want to go the sourcecode route. You might be surprised how much you can do right now.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to post
Share on other sites

Flying AI was always something I wanted to have in the game. I even had fire elementals working at one point (though they used the hovering hack) in the hopes that we would be able to use the same flying code D3 had. My limited understanding was that whatever D3 code we used as the base for our characters did not include the flying code from D3, and that it would have to be added in separately. It was a low-priority task that never got attended to.

Link to post
Share on other sites

I'm not so sure the default path-finding is 2D. AAS in Doom 3 was designed to cover 3d pathing issues of wall climbing AI.

In TDM the AI will watch you climb a building or even fly through the air with noclip and throw rocks at you or yell barks.

I think this is more of a locomotion issue (or "what do we do with non-planar pathing data?") than a path-finding issue...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites

flying AI in the source engine used for halflife 2 dont fly and they're not proper AI you have to bind a AI brain to them and they're basically a func_static hidden cube with a object bound to them following paths. Even the bird AI is an animated object that flaps wings and follows a path. (thats the bird object in source)

Edited by stumpy
Link to post
Share on other sites

I just took a rough look at the source on svn.thedarkmod.com and found this

 

 

 

/*
============
idAASLocal::FlyPathValid
 returns true if one can fly in a straight line between origin and goalOrigin
============
*/
bool idAASLocal::FlyPathValid( int areaNum, const idVec3 &origin, int goalAreaNum, const idVec3 &goalOrigin, int travelFlags, idVec3 &endPos, int &endAreaNum ) const {
aasTrace_t trace;
if ( file == NULL ) {
	endPos = goalOrigin;
	endAreaNum = 0;
	return true;
}
file->Trace( trace, origin, goalOrigin );
endPos = trace.endpos;
endAreaNum = trace.lastAreaNum;
if ( trace.fraction >= 1.0f ) {
	return true;
}
return false;
}
/*
============
idAASLocal::SubSampleFlyPath
============
*/
idVec3 idAASLocal::SubSampleFlyPath( int areaNum, const idVec3 &origin, const idVec3 &start, const idVec3 &end, int travelFlags, int &endAreaNum ) const {
int i, numSamples, curAreaNum;
idVec3 dir, point, nextPoint, endPos;
dir = end - start;
numSamples = (int) (dir.Length() / flyPathSampleDistance) + 1;
point = start;
for ( i = 1; i < numSamples; i++ ) {
	nextPoint = start + dir * ((float) i / numSamples);
	if ( (point - nextPoint).LengthSqr() > Square( maxFlyPathDistance ) ) {
		return point;
	}
	if ( !idAASLocal::FlyPathValid( areaNum, origin, 0, nextPoint, travelFlags, endPos, curAreaNum ) ) {
		return point;
	}
	point = nextPoint;
	endAreaNum = curAreaNum;
}
return point;
}
/*
============
idAASLocal::FlyPathToGoal
 FIXME: don't stop optimizing on first failure ?
============
*/
bool idAASLocal::FlyPathToGoal( aasPath_t &path, int areaNum, const idVec3 &origin, int goalAreaNum, const idVec3 &goalOrigin, int travelFlags ) const {
int i, travelTime, curAreaNum, lastAreas[4], lastAreaIndex, endAreaNum;
idReachability *reach(NULL);
idVec3 endPos;
path.type = PATHTYPE_WALK;
path.moveGoal = origin;
path.moveAreaNum = areaNum;
path.secondaryGoal = origin;
path.reachability = NULL;
path.elevatorRoute = eas::RouteInfoPtr();
path.firstDoor = NULL;
if ( file == NULL || areaNum == goalAreaNum ) {
	path.moveGoal = goalOrigin;
	return true;
}
lastAreas[0] = lastAreas[1] = lastAreas[2] = lastAreas[3] = areaNum;
lastAreaIndex = 0;
curAreaNum = areaNum;
for ( i = 0; i < maxFlyPathIterations; i++ ) {
	if ( !idAASLocal::RouteToGoalArea( curAreaNum, path.moveGoal, goalAreaNum, travelFlags, travelTime, &reach, &path.firstDoor, NULL ) ) {
		break;
	}
	if ( !reach ) {
		return false;
	}
	// no need to check through the first area
	if ( areaNum != curAreaNum ) {
		if ( (reach->start - origin).LengthSqr() > Square( maxFlyPathDistance ) ) {
#if SUBSAMPLE_FLY_PATH
			path.moveGoal = SubSampleFlyPath( areaNum, origin, path.moveGoal, reach->start, travelFlags, path.moveAreaNum );
#endif
			return true;
		}
		if ( !idAASLocal::FlyPathValid( areaNum, origin, 0, reach->start, travelFlags, endPos, endAreaNum ) ) {
#if SUBSAMPLE_FLY_PATH
			path.moveGoal = SubSampleFlyPath( areaNum, origin, path.moveGoal, reach->start, travelFlags, path.moveAreaNum );
#endif
			return true;
		}
	}
	path.moveGoal = reach->start;
	path.moveAreaNum = curAreaNum;
	if ( !idAASLocal::FlyPathValid( areaNum, origin, 0, reach->end, travelFlags, endPos, endAreaNum ) ) {
		return true;
	}
	path.moveGoal = reach->end;
	path.moveAreaNum = reach->toAreaNum;
	if ( reach->toAreaNum == goalAreaNum ) {
		if ( !idAASLocal::FlyPathValid( areaNum, origin, 0, goalOrigin, travelFlags, endPos, endAreaNum ) ) {
#if SUBSAMPLE_FLY_PATH
			path.moveGoal = SubSampleFlyPath( areaNum, origin, path.moveGoal, goalOrigin, travelFlags, path.moveAreaNum );
#endif
			return true;
		}
		path.moveGoal = goalOrigin;
		path.moveAreaNum = goalAreaNum;
		return true;
	}
	lastAreas[lastAreaIndex] = curAreaNum;
	lastAreaIndex = ( lastAreaIndex + 1 ) & 3;
	curAreaNum = reach->toAreaNum;
	if ( curAreaNum == lastAreas[0] || curAreaNum == lastAreas[1] ||
			curAreaNum == lastAreas[2] || curAreaNum == lastAreas[3] ) {
		common->Warning( "idAASLocal::FlyPathToGoal: local routing minimum going from area %d to area %d", areaNum, goalAreaNum );
		break;
	}
}
if ( !reach ) {
	return false;
}
return true;
}

 

 

 

 

in the game/ai/AAS_pathing.cpp

 

there is similar code for walking

don't know if the AI uses this, but if so, it should also be able to use the fly-code?!

 

you may wanna look ^_^

 

The heart of AAS is a special 3D representation of the game world.

http://test.modwiki.net/w/index.php/The_Doom_3_AAS_system

 

I don't know if the AAS system has been changed by the team

 

IMO the only thing that differs a "normal" AI from a flying oneis that the normal AI always fell to the ground, meaning it is capable of gravity

 

so beneath making use of the "fly"-methods you may also have to disable this

Edited by Obsttorte

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

OK, just checked the AI.cpp and corresponding header

 

the AI has a protected member variable idMoveState move (Class and name)

 

for evaluation of path / movement the code checks move.movetype

 

if move.movetype == MOVETYPE_FLY, the fly code is used

 

unfortunately it doesn't seems that this value can be manipulated by spawnargs, but may be overloaded when creating a new class for new AI like the fire elemental

 

what can be set is the spawnarg "animate_z" "1", what should disable gravity

 

will try it

 

used for something else

Edited by Obsttorte

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

eigenface, is you find a way to program/create AI for flying models to change from hoovering curves into intelligent AI with vision, alert states, and patrol routes would be terrific!!

That would add a new level of gameplay. Would definitly love that!! :wub:

"To rush is without doubt the most important enemy of joy" ~ Thieves Saying

Link to post
Share on other sites

eigenface, is you find a way to program/create AI for flying models to change from hoovering curves into intelligent AI with vision, alert states, and patrol routes would be terrific!!

That would add a new level of gameplay. Would definitly love that!! :wub:

flying guards ?

Proceed with caution!

Link to post
Share on other sites

I've seen that the AI has a movetype spawnarg, but it doesn't seem to affect how the AI is actually moving

 

does anybody know what this spawnarg is for?

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

angua - Sounds great!

 

ST - Not at all, just some pic on the net. ;) I wont be modelling new-gen character models anytime soon (if ever, and you would then need to animate them, and code them), but it would sure be cool if we could have an apparition like that flying around, and able to sense you and chase you. Would be a lot scarier than a zombie.

Link to post
Share on other sites

Hovering creatures like fire elementals or ghosts would actually be much easier than walking ones, as they would need a lot fewer bones and animations.

Link to post
Share on other sites

I don't see why an apparation like this one has to fly around.. Why just let out the walking animation and instead use a hover animation? Done. Or am I missing something? :mellow:

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to post
Share on other sites

as far as I understood it the difference is:

 

- a hovering creature would basically be a walking one, just placed far enough over the ground so it seems it is flying

this means it uses the walk-pathfinding and therefore only could reach areas, "normal" AI can reach

 

- a flying AI would really fly, meaning it could move in all three directions in space

therefore it would use a different kind of pathfinding

 

latter would add a much more challenging aspect to the darkmod gameplay, as it woul be much harder for the player to escape/hide from such

imagine a inventors guild bicopter steambeast

 

something like that :D

post-11230-0-26356300-1353002116_thumb.jpg

Edited by Obsttorte

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

The hovering hack would mean that "flying" AI would have to go around beds or tables, and they would fall down holes. I tried it with early versions of fire elementals and it didn't look very good.

Link to post
Share on other sites

There is a "good" way to do flying AI within the limits of doom 3, floor-based pathfinding, because the cacodemon did it. The situation is more complicated now, because the dark mod AI is more complicated (vision, patrols, alerts, etc), but that shouldn't make a difference as far as using the doom 3, floor-based pathfinding is concerned. Our flying AI *should* be able to do something very similar to what the cacodemon did, that is, create a convincing illusion of true 3D flight, using the doom3, floor-based pathfinding plus dynamic changes in hover height. Does this sound right?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...