Home » MODDING HQ 1.13 » v1.13 Coding Talk » New Tactical AI - Functional Considerations
New Tactical AI - Functional Considerations[message #317576] Fri, 19 April 2013 22:52 Go to next message
feynman

 
Messages:38
Registered:October 2010
Greetings,

as you may have read in my other post, I am currently working on an AI overhaul. In this post, I want to discuss functional aspects. Or rather, I'd like you to discuss functional aspects. I'll try to keep the technical mumbo jumbo to a minimum, hoping that especially map artists can give some input.

What I'm currently working on is the NPC movement on green alert level. The militia movement, actually, but I do hope that things are intercangable for the most part. The map editor - and game engine - have several "orders" that dictate movement patterns:

    STATIONARY = 0,     // moves max 1 sq., no matter what's going on
    ONGUARD,                    // moves max 2 sqs. until alerted by something
    CLOSEPATROL,            // patrols within 5 spaces until alerted
    FARPATROL,              // patrols within 15 spaces
    POINTPATROL,            // patrols using patrolGrids
    ONCALL,                     // helps buddies anywhere within the sector
    SEEKENEMY,              // not tied down to any one particular spot
    RNDPTPATROL,            // patrols randomly using patrolGrids
    SNIPER,                 // snipes

You do likely know more about what that orders mean for gameplay than I do, but that may soon change, because I'm re-writing them Razz
Jokes aside, though. I have now... done stuff to the "POINTPATROL" thingy and noticed that two parameters cry out to be parameterized: how long to wait at each point, and at what energy level to take a break. Now it would be possible to make it further configurable, but: what options do you really need? Every configuration option also requires a map artist to generate the "right" configuration, i.e., translates to extra work. And we also don't need to make something changable just to fill in default values everywhere.

Currently every NPC has his own "patrol grid" (=waypoints); it would be possible to create a map of "general" waypoints that are shared between NPCs. That would however require someone to build that possibility into the map editor (don't look at me guys, I'm busy working on the AI). A workaround would be to combine all single NPC grids into one, but that would mean that the current cyclic patrols are no longer possible.

So, perhaps someone can shed some light on the topic for me: what AI options in general, and path finding options while undisturbed in particular do we need?

Thanks.
Re: New Tactical AI - Functional Considerations[message #317581] Sat, 20 April 2013 07:11 Go to previous messageGo to next message
Durak

 
Messages:58
Registered:April 2010
Hey feynman, good luck!
If I was a coder, I certainly would have tried out doing stuff with the AI by now.

I'm not, but I did a lot of maps in the past, and I remember one thing about enemy/npc placement that bugged me:
I would have been very very happy if there was an option which "binds" npcs, especially enemies, to the level - ground or roof - that they're placed on.

The way those patrol/stationary options work makes it very hard to set up small sniper nests/guard towers and the like, because even the "stationary" option allows npcs to move a bit (when they're fired at, I think), and most of the time they eventually jump down the roof during a battle, therby leaving their elevated vantage point and render the whole guard tower / sniper hideout thingy useless.

Especially if you want to create well guarded outposts, prisons, military bases, roadblocks and the like, or if you really want to set up patrol points on a roof's edge and make sure enemies will stay on it, no matter what, it would be really nice to have an option/flag "stay on roof" / "stay on ground" in addition to "stationary", "onguard", "patrol" or "sniper".


That's just something which first comes to my mind at this time of the day (and if I can get enough coffee, maybe more).

cheers


edit: And please, make retreating enemies go to another sector instead of hiding in a 2x1 tile toilet room somewhere on the map...

[Updated on: Sat, 20 April 2013 07:28] by Moderator

Re: New Tactical AI - Functional Considerations[message #317587] Sat, 20 April 2013 11:46 Go to previous messageGo to next message
pheloncab

 
Messages:270
Registered:August 2004
Location: So. Cal. or texas
Can I suggest that the length of patrols be kept as some kind of external file, maybe added to the constants so modders can change it.
When more of the game goes to big maps this will make a huge difference.
Re: New Tactical AI - Functional Considerations[message #317608] Sun, 21 April 2013 11:42 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
Thank you both for your replies. I'll check out the options for binding NPCs to a level (roof/ground), but am thinking that maybe that should be 'intrinsic' to snipers? I.e., snipers never change their level?

The "patrol routes in external files" is possible with my new system, as soon as someone finds the time to integrate it into the map editor, it will be ready. It might, however, be a better option to increase the number of way points to an arbitrary size? Currently, way point n is set via number key n; I'd propose a key to set a way point, and add this point at the end of the currently defined route.

Anyways, I've now moved on to the 'yellow' status (green is far from done, but I currently don't see the "right" pieces of the remainder - i.e., non-patrolling-code - to chop it into).

The yellow AI for militia (and, the most part, enemies, but I currently exclude that for the sake of simplicity) can do three things: (a) rest, because out of breath (b) radio a noise contact to friends, and (c) seek a noise. The first two are trivial and currently not worth a plan, but (c) is a candidate for encapsulation, so as to make it possible to further parameterize and improve it. This "seek noise" is currently implemented by what is at least labelled as "flanking", so the next plan I'll work on is a FlankPlan.

So again, my question: what are "good" parameters for flanking? How can we, in gameplay terms, define flanking? What is, in the JA2 gameplay environment, a good strategy to carry it out?

I would like to make the flanking as universal as possible (i.e., usable in all alert states; even if I see an enemy, I can try to circle around). I would also like to be able to use this flanking plan to emulate current behavior, while adding the necessary flexibility to improve the current AI easily. Given that, again, what would you, as "content provider", like to be able to parameterize or seen improved? My architecture allows (encurages, really) multi-turn plans (in contrast, these are a royal PITA in the current system, and implemented accordingly). I think we should exploit that.

Cheers.
Re: New Tactical AI - Functional Considerations[message #317694] Tue, 23 April 2013 19:43 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
Well, don't write down your ideas all at once, we wouldn't want the thread to get full too soon...

I think I'll implement two modes of 'flanking'. The first one is applicable if the target doesn't know our location and we want to keep it that way, while approaching the target. To this end, we estimate the target's position and hearing/visual range. We then use as trajectory the shortest path from where we are to where we want to be (i.e., behind the target and in firing range) while avoiding the circle defined by said position and range (which I've computed for Euclidean geometry disregarding obstacles; how well this works in practice I yet have to try out).

The second mode could be described as "action flanking". We know where the enemy is and in what direction it looks (and the enemy probably knows our position as well). We now exploit the fact that there are only 8 directions in which we can look. The area any single person can "cover" without turning around is one eighth of a circle. We go now outside this area (on a shortest route, i.e., orthogonal to its borders) and then towards the enemy. The goal is to reach firing range ASAP while forcing the enemy to spend APs on turning around instead of shooting us. Given enough coordinated enemies, approaching from different directions, this should be better than the current AI, especially against machine gunners and snipers, given that they are usually prone (=high turn cost), have high readying cost and, in the latter case, a high tunnel vision (thus might loose visual contact).
Re: New Tactical AI - Functional Considerations[message #317711] Tue, 23 April 2013 23:14 Go to previous messageGo to next message
CapnJack

 
Messages:58
Registered:June 2012
Sounds good so far. So if an enemy were to hear a sequence of sounds could they estimate a vector of motion and guess where the possible contact might be looking? This is a bit situational though as it would probably lead to confusing the ai with multiple sound sources since the source is not known before contact anyway. It could end up being a source of artificial stupidity if one were to be interested in programming the AI to be less than perfect all the time.

[Updated on: Tue, 23 April 2013 23:17] by Moderator

Re: New Tactical AI - Functional Considerations[message #317745] Wed, 24 April 2013 09:40 Go to previous messageGo to next message
Durak

 
Messages:58
Registered:April 2010
Am I the only one who thinks you should address the "enemies-are-completely-disoriented-when-fired-at-from-great-distances"-problem while you're at it?

I neither know how the game - in coding terms - currently handles (or does not handle) situations when your mercs remain hidden / out of the enemies' sight range while shooting at them, nor how or if this problem has been addressed in the past.
All I know is: If you're shooting a tree, they come running for you from the opposite edge of the map, so noise detection works at first.
They will try and flank you if at least one enemy spots one of your mercs, so these mechanics work as well.
But - if you hit one of them before they can spot you, they always seem to loose even the last bit of their initial battle enthusiasm.
When I'm playing the game and this happens I always wonder:
Why don't you spread out and try to proceed into the direction where the shooting comes from, as you did before? What's so tricky about that?


Do you think there's any possibility (or need, in the first place) to incorporate not only noise detection and plain view, but also projectile trajectories into those AI-mechanisms you're working at?

For example, if an enemy "sees" only a shot fired at him or his comrades, he can guesstimate (by the sound of the gun, the damage the bullet has done or the like) in which direction and how far the shooter is away, and apply attack/flanking behavior accordingly?
This would override plain noise detection as shooting is of course more dangerous than cracking twigs, and flanking a shooting, yet hidden, target has higher priority than chasing sounds, and it would allow the player to set up some nice traps and ambushes Smile

As you wrote in your other thread, it might be legit here to have the AI cheating a bit, for the greater good of making them dangerous again (even after the player has acquired his first rifle with a 7x scope).

That way the problem of multiple sound sources would possibly also be alleviated (at least in situations where there's not only noise but gunfire as well) as the AI would already know about those sources (by cheating a little) and would act based on priorities (for example: at first try to flank the most dangerous targets that have been shooting at us, snipers with antimaterial rifles and such, then machinegunners, then mortars and so forth...)


Just thoughts.
I'm no coder, and I can't even imagine the amount of work which one would have to put into something like this...


cheers

[Updated on: Wed, 24 April 2013 09:50] by Moderator

Re: New Tactical AI - Functional Considerations[message #317768] Wed, 24 April 2013 17:07 Go to previous messageGo to next message
Sam Hotte

 
Messages:2031
Registered:March 2009
Location: Middle of Germany
+1. I 2nd this thought. Smile
Re: New Tactical AI - Functional Considerations[message #317781] Wed, 24 April 2013 18:34 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
CapnJack
So if an enemy were to hear a sequence of sounds could they estimate a vector of motion and guess where the possible contact might be looking?

Theoretically, yes. Practically, I say we let the AI look at the player's real movement/direction, probably add some random error, and use that as input. I usually don't like cheating, but in this case, it simply is much easier to implement than using a svm, ann or whatever to do the guesswork. Furthermore, the player *was heared*, it is not like we would be using intel the AI *cannot* know - we just spice it up a little.
Durak
Why don't you spread out and try to proceed into the direction where the shooting comes from, as you did before? What's so tricky about that?

In the current implementation: the fact that the AI has no memory whatsoever. They hear something and think "oh hey, let's investigate". Then they find themselves in the enemy crossfire, which is - for the AI - a completely unrelated, new situation. Fortunately, this changes with my redesign. Unfortunately, that will likely break some legacy behavior. I hope I won't be crucified for that.
Durak
Do you think there's any possibility (or need, in the first place) to incorporate not only noise detection and plain view, but also projectile trajectories into those AI-mechanisms you're working at?
I've actually wondered that myself. AFAIK the game does not provide the means for the AI to access this data. Which doesn't mean we can't use it, of course. But it would be very hard to determine which NPC is eligible to what intel. Plus, it would have to be tied to some event - if we hear something, and it is a bullet impact or a gun fired, we could access the trajectory data (I think... haven't looked at it yet). If not, we can't. Bullets flying through our fov don't trigger these "events".


As should be clear by now, my initial plan to refactor the AI without improving/changing functionality didn't really work. The problem is that my design simply doesn't fit so good in the legacy code. The legacy AI functions operate on a global scope, while my design promotes encapsulation. When carrying out a plan, I don't care what an NPCs orders are - if it got the plan, I take it as a given that it fits its orders. Unfortunately, this is not how the old system works at all. If the plan "asks" every time it gets to the point where it "advances" if it should change, the decision making and -implementation level become so interweaved that the new system won't be an improvement (in terms of code maintainability) at all. But then we get another problem, because refactoring is something completely different than rewriting. The latter introduces new bugs, requires extensive testing, in short, is a fully-fledged programming project for a team of full-time developers. It'll be interesting to see how this ends...
Re: New Tactical AI - Functional Considerations[message #317784] Wed, 24 April 2013 19:11 Go to previous messageGo to next message
Sam Hotte

 
Messages:2031
Registered:March 2009
Location: Middle of Germany
Perhaps it would be possible to have the legacy global scope and orders as an auxiliary condition or constraint to your new plans?
Like "AI character heard something, executes plan 'go investigate'". But as his global function is 'camper; stay where you are and snipe.', investigation in this case results in "go to next cover in sound's direction, raise gun and look through scope" or so.

(I took this example out of the hat; it's unrelated to how current AI may work - because i have no clue - but i hope you get the idea)
Re: New Tactical AI - Functional Considerations[message #317798] Wed, 24 April 2013 20:49 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
Unfortunately, that's not the kind of "global scope" I meant. The problem is that low-level functions, like "find a free spot near " uses (among other things) the orders of the NPC for which the function is called to determine if the spot is not probably out of the "area" this NPC should, according to its orders, stay in (a behavior which is, of course, not documented, so to find out, you end up reading the whole code, which isn't as much fun as it might sound). If the orders don't allow the respective NPC to go there, the function returns "no spot found". Of course, how far a soldier with order "FARPATROL" may leave his post is some arbitrary decision not taking into account map size, environment or anything. Worse yet, many of these function have secondary effects, i.e., change global data. And finding out which pieces of data, making a "backup" before calling the function and then restoring it afterwards translates to "rewrite the whole thing". Heck, the "can we reach this spot" function overwrites the path currently stored in an NPC. Someone should have told the original implementors that even C has a const qualifier...

That means if I want to implement an "movement plan" which allows NPCs with any order (or other attributes for that matter) to go anywhere the plan specifies, I either must change the NPC attributes accordingly or modify the called functions to not check for these conditions. In either case, the legacy behavior gets broken. I could, of course, copy the legacy function, rename it, remove the unwanted behavior, and use the copied function for the new plans, what is kind of what I'm currently doing. But that leads to an even bigger pile of junk code, decreasing overall maintainability instead of increasing it, what was the whole idea of my endeavour. So, unless the legacy functions can eventually be removed from the code, this whole thing is pretty pointless.
Re: New Tactical AI - Functional Considerations[message #317803] Wed, 24 April 2013 21:13 Go to previous messageGo to next message
Flugente

 
Messages:3174
Registered:April 2009
Location: Germany
If this requires such an extensive rewriting of code, and especially when it breaks existing routines, you should develop in a branch. Otherwise we will have broken AI in all future releases.

And yes, quite a few functions, like the 'find free GridNo' have to be either cleaned, or propably rewritten. Good opportunity to clean up some oddities though Wink


Re: New Tactical AI - Functional Considerations[message #317985] Fri, 26 April 2013 14:47 Go to previous messageGo to next message
CapnJack

 
Messages:58
Registered:June 2012
This is probably a bit further along than current progress since no one has mentioned a ShootTarget plan as yet. One thing that always got me about the AI was its total willingness to shoot at a target despite friendlies rather obviously being in the way. I imagine this one could be sort of delicate to work around and maybe depending on the Flank plan the AI will tend to spread out more and this will be a more non-issue. It would be nice if we could have the enemy avoid shooting each other and the militia shooting our mercs and themselves. Of course it would probably still happen but that's part of the chaos of combat I guess.
Re: New Tactical AI - Functional Considerations[message #318270] Tue, 30 April 2013 18:33 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
I'll look into that once I'm there, and yes, I'm bugged by that behavior, too. But I currently don't know if the engine provides the required functionality to test this efficiently, so we'll have to wait and see Wink

As these computations have to be made in 3-space however, and the engine doesn't seem to be optimized for that (duh!), I'm not too optimistic.
Re: New Tactical AI - Functional Considerations[message #318272] Tue, 30 April 2013 19:06 Go to previous messageGo to next message
pheloncab

 
Messages:270
Registered:August 2004
Location: So. Cal. or texas
I think some of the blue on blue shootings is because distance scaling.
according to the original specs 1 tile =10 meters, so if someone was shooting through the tile your merc was in, the probability of hitting your merc was not supposed to be all that high..
I think the reality of the ballistics calculations tend to warp this so it happens more often than it should.
Perhaps once we get to the big maps platform, and adjusted CTH models, we will see this decrease a lot as troops are more spread out anyways so there is less shooting through them to cause this issue.
Re: New Tactical AI - Functional Considerations[message #318288] Tue, 30 April 2013 22:14 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
Another update...

What I describe here is the new "default behavior" for militiamen as long as no enemy is present; while it is theoretically possible to change that after my commit, I would like to get it done right the first time. This is your chance to make some input (remember: decisions are made by those who show up). To be clear: this is not some theoretic change that might probably happen in the far future, but planned to be released sometime next week; after the commit, it won't be possible to get the *exact* old behavior back (except using old revisions, that is...).

The "old" AI works like this: a chance is calculated to perform a certain action - visit a friend, look around, go someplace random, do nothing - and then the game tries to carry out this action. The chance is calculated by taking into account orders and "attitude" (cunning, loner, ... - whatever you can set in the map editor). This sounds nice enough, but doesn't work: the "...and tries to carry out this action"-part is *very* likely to fail, for any action other than "do nothing". I do have a sound education in statistics, so you may as well believe me when I say that it is next to impossible to determine the "real" chance of an action being carried out depending on the calculated chance to attempt it. An extreme example is the chance for militiamen to climb on roofs; according to the probabilities, this should happen all the time (70% chance every ~30 seconds for *each* militiaman). And how many do you see climbing on roofs? None, because the code was broken, so the probability of success was actually 0.

My implementation changes that. Due to my approach to make each "plan" re-usable, an effort can be made to produce higher-quality code - if the first attempt fails, try another. So if the decision to climb a building has been made, then either there is no building on the map, *all* the "climb points" is full, or the guy climbs the damn building. This *would* give us another chance to do something useful with the
probabilities, because now they actually have a meaning. I'm however not sure how wise that is.
Well, probabilities are good and needed, but I'd reduce their complexity. I would not at all look at the attitude of an NPC to decide the action (why would a cunning enemy be more likely to climb a roof, anyways? If anything, the arsenal at our disposal should determine that?!). I would instead like to generate one probability for *all* NPCs (...who belong to the militia). This way, we can look at *all* the actions, and distribute among them the number of NPCs that should, at any point in time, carry them out. So if we have 20 militiamen per sector, and the chance of climbing a roof is 1:20 = 5%, we know that, statistically speaking, at any time one guy climbs a roof (well, the probability that at least one NPC is climbing at an arbitrary moment actually is 64.1%, if we assume that the time to climb is 30s, but that's not really the point). Is this too much? Well, let's change it to 2.5%. Or if the chance to "visit a friend" is greater than the chance to walk someplace random, eventually all NPCs will clutter at one place. I believe that this kind of "group control" is more important than modelling "loner"-behavior etc. accurately. Then again, *I* think of "the enemy" (or, in this case, the militia) is one big entity. I don't look at one guy long enough to discern behavioral patterns that would lead to a greater immersion because I realize that he is different from the others. But in another thread, this behavior was on the wish list, so I hereby put it up to debate.


What do *you* think? How should these chances of certain actions be computed? Do we roll the same dice for every NPC to see if it gets to climb the roof, or does every NPC get its own set dice (i.e., a die for each NPC and each action)?
Re: New Tactical AI - Functional Considerations[message #318289] Tue, 30 April 2013 22:28 Go to previous messageGo to next message
Flugente

 
Messages:3174
Registered:April 2009
Location: Germany
I prefer a dice for each militia here, as otherwise the total number of teammembers would influence wether an action happens very much (though its green state anyway, not that important).

If I understood you correctly, you will change this in the trunk next week, correct? Why won't it be possible to test 'old' against 'new' AI? It'll be impossible to compare this way, especially if you introduce the new stuff gradually. And any error case breaking the new AI will thus break all AI we have, without any fallback solution...

Oh, and a small point of critique (that propably could be adressed to me as well, I know): Please don't change intending/tabbing on masse without any code reason. Overhead.cpp has ~10K lines, and you touched all of them. Not fun to merge.


Re: New Tactical AI - Functional Considerations[message #318290] Tue, 30 April 2013 22:38 Go to previous messageGo to next message
grim

 
Messages:300
Registered:July 2006
Location: France
Your global approach seems quite pertinent to me. With the militia treated as a group and each individual given a r
Re: New Tactical AI - Functional Considerations[message #318355] Wed, 01 May 2013 16:51 Go to previous messageGo to next message
Dansken

 
Messages:85
Registered:March 2007
Location: Norway
First off: Thank you very much for putting effort into the AI code -- that is brave!

However, I'm with Flugente on this one: The basic AI routine should have each soldier decide on a plan for himself.

My 2 cents:

(1) Maybe group-wide planning and assigning of plans could be added later as a Commander-AI that adds hints to soldiers under his command so a certain plan becomes more desirable, or simply assigns a plan to members of his unit.

(Bonus: If the Commander is taken out, AI becomes more disorganized until a new Commander is chosen)

(2) It seems attitude is assigned to soldiers in order to individualize them. Please don't remove this feature, even if it doesn't always work as intended. If you hate it because the wrong attitude sometimes influences the AI to make a bad decision: Could you make it optional or maybe externalize it?

Possibly, each plan could be marked as more or less desirable for certain attitudes in an external ini-file. Those wanting optimal decision making (not influenced by attitude), would remove attitude-based weightings from the ini-file ... and others might enjoy tweaking the weightings to their own liking.

Perhaps the weighting of AI plans could go beyond attitude: trait might be a good candidate.
Re: New Tactical AI - Functional Considerations[message #318365] Wed, 01 May 2013 17:40 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
OK, I didn't explain that very well... let me try again (it all seems so clear if you have have wrapped your head around this for two weeks)

(a) As Flugente pointed out, we would like to be able to test any new AI against the old AI.
(b) As I pointed out in the other thread, it isn't feasible to provide a behavior 100% equal to the old.
(c) However, it should be (and is) a goal to provide one AI implementation that behaves as similar as possible to the old, while employing the new AI system (and thus, allowing a major code clean-up)
Sidenote: To make multiple AI versions feasible at all, they may differ in only a small portion of the source code; otherwise, whenever something changes (e.g., holding a weapon costs breath now), large code changes have to be made in different places, once for each AI version, which is precisely why keeping the old AI is not feasible in the first place. My design approach, which should make different behavior possible with very little code change, is however not compatible with the current code, thus, we can't have a 100% recreation of current behavior.
(d) While AI changes/improvements should soon begin to emerge (one is running on my computer right now; the militia patrols the sector randomly in groups - IMHO, this creates a rather gloomy atmosphere, very martial-law-like), it is currently my top priority in this thread to figure out the AI behavior that will take the place of the old system.
(e) Most things are already in place, what is missing is the probability calculation of certain actions taking place. To explain properly, I'll have to go in some detail as to how the AI works:
In RT mode, every NPC gets to roll a die every ~30 seconds. Each NPC gets its own die, each with a different number of sides and each different labels on each side. On each side, a label describing an action is written. Whatever is rolled, the computer tries to carry out. If an action can't be carried out, the NPC does nothing until it is time again (i.e., another ~30s have passed).
The problem is: when I decide to do something, it *will* almost certainly work. And while I can figure out how the die for each NPC looks like, I have no clue regarding how probable it is that the rolled action "would have succeeded with the old system" (this depends, among other things, where exactly we are standing, in which sector we are and so on, and is, as a general rule, rather low). This means that knowing what the old dice looked like in the first place is meaningless, because we have to multiply the probabilities with the (unknown!) probabilities of success.
(f) So, I want you to help me design a new set of dice, which *must* differ from the old dice in order to make things as similar as possible to the old system - simply because my chances of succeeding with a plan are so much higher than they were before.

My intention is not - I didn't express myself here correctly in the previous post - to somehow distribute each available action to the NPCs; my idea would be that we use one die for each NPC, which is, of course, rolled anew for each NPC's decision making. This is different from the old system insofar as that the old system had, say, 3 sides more labelled with "climb roof" for "cunning" NPCs. Using such a system would make it very hard to foresee any changes to the individual dice, because at the time we write the AI code, we have no clue as to how many "cunning" NPCs are going to be in a certain sector. Plus, I very much question the effect the consideration has *on the current AI* - remember, we are trying to build a system that behaves as much as possible like the current AI.


@Flugente: Regarding my messing up Overhead.cpp... I hate myself. Should that ever happen again, please don't merge. Instead, commit your local changes, and tell me to clean up my mess. Sorry about that.
Re: New Tactical AI - Functional Considerations[message #318676] Sat, 04 May 2013 21:05 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
After spending most of my day with trying to get the "AI index" from the editor into the game, I've learned that there are two kinds of "placements", one basic and one detailed. The detailed placement is deleted on purpose once a sector is taken, so that "special" NPCs, that were explicitly created with, say, high marksmanship, don't resurrect.

Now the question arises: which structure should we put the AI index in? If it is put in the detailled structure it will be deleted once a sector is taken, so if we go there again, all AI guys belonging to the same group will have the same overall behavior (we still can use orders, but the whole benefit of different "AI Factories" is lost). If it is put in the basic structure, we might get strange resurrecting behavior. So, what's your opinion on this?

[Updated on: Sat, 04 May 2013 21:06] by Moderator

Re: New Tactical AI - Functional Considerations[message #318682] Sat, 04 May 2013 22:19 Go to previous messageGo to next message
pheloncab

 
Messages:270
Registered:August 2004
Location: So. Cal. or texas
I bet its lots more work.. but I would say, both need to happen.
a Enemy put in as say a sniper, or specific in the building guard could disappear, but the patrols should be the same since most the terrain hasn't changed, so the patrol plans should be the same no matter if its day 1 or day 50 or day 3000.

ok.. my 2 cents in.
Re: New Tactical AI - Functional Considerations[message #318707] Sun, 05 May 2013 13:46 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
OK, did something slightly different - I added a check box to be set if the detailed placement is to be erased once "used". If not, the "successor" inherits the detailed placement, and with it the AI index. I don't yet know how exactly this interacts with militia inheriting behavior and equipment, but it seems to be largely as one would expect. So to prevent a green militia from inheriting elite equipment, on maps where this could happen, it might be prudent to place the militia manually (or simply tell check the box to delete detailed placement for the elite soldier...).

That way, the sniper using the sniper plan factory also is guaranteed to keep his sniper rifle; I've always been annoyed when someone on a "guard tower" in smeagols WF maps was armed only with a shotgun.
Re: New Tactical AI - Functional Considerations[message #318768] Mon, 06 May 2013 03:18 Go to previous messageGo to next message
pheloncab

 
Messages:270
Registered:August 2004
Location: So. Cal. or texas
That sounds like a compromise worth trying.. It should give mod makers a lot of flexibility which in the big picture is what we want.
THX for listening and all the work
Re: New Tactical AI - Functional Considerations[message #332135] Sat, 03 May 2014 10:12 Go to previous messageGo to next message
M16AMachinegun

 
Messages:308
Registered:September 2013
I'm a little more interested in Militia AI during battles, specifically player-given orders to the militia. I understand that you're making attempts to add memory to AI decisions so that they 'remember' what orders they were given, be it from players or generated by code.

A recent example is in the middle of Mid-Drassen at night, I had several militiamen being shot at...so I used the command: "All: Come To Me" (or equivalent). On the Militia's next turn, however, they went off getting stuck in a "running towards the enemy/running out of light" loop like usual instead of completing my order of "Come to Me."

I assume your efforts will work both for real time as well as during skirmishes? I'd additionally love to give militia orders to "Climb onto Roof + stay on roof" without them climbing back down, ya know?

Best of luck with coding! As a Computer Science major I feel your pain in trying to get working code.
Re: New Tactical AI - Functional Considerations[message #334445] Tue, 22 July 2014 12:37 Go to previous messageGo to next message
buuface

 
Messages:101
Registered:October 2011
Has this project been abandoned?
Re: New Tactical AI - Functional Considerations[message #334448] Tue, 22 July 2014 13:06 Go to previous message
Flugente

 
Messages:3174
Registered:April 2009
Location: Germany
I haven't heard from feynman since over a year, and afaik nothing has happened in this regard since r6070... so yeah, seems pretty abandoned.


Previous Topic: A couple of ideas
Next Topic: Improving loading times
Goto Forum:
  


Current Time: Sat Jan 20 01:19:54 EET 2018

Total time taken to generate the page: 0.01000 seconds