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 
|
|
 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 
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.
Report message to a moderator
|
Private 1st Class
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #317581]
|
Sat, 20 April 2013 07:11 
|
|
| Durak |
 |
Messages:57
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 Report message to a moderator
|
Corporal
|
|
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #317608]
|
Sun, 21 April 2013 11:42
|
|
| 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.
Report message to a moderator
|
Private 1st Class
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #317694]
|
Tue, 23 April 2013 19:43
|
|
| 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).
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #317745]
|
Wed, 24 April 2013 09:40
|
|
| Durak |
|
Messages:57
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 
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 Report message to a moderator
|
Corporal
|
|
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #317781]
|
Wed, 24 April 2013 18:34
|
|
| feynman |
|
Messages:38
Registered:October 2010 |
|
|
CapnJackSo 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.
DurakWhy 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.
DurakDo 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...
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #317798]
|
Wed, 24 April 2013 20:49
|
|
| 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.
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #318288]
|
Tue, 30 April 2013 22:14
|
|
| 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)?
Report message to a moderator
|
Private 1st Class
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #318289]
|
Tue, 30 April 2013 22:28
|
|
| Flugente |
 |
Messages:3509
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.
Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #318365]
|
Wed, 01 May 2013 17:40
|
|
| 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.
Report message to a moderator
|
Private 1st Class
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #318676]
|
Sat, 04 May 2013 21:05
|
|
| 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 Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Tactical AI - Functional Considerations[message #334448]
|
Tue, 22 July 2014 13:06
|
|
| Flugente |
|
Messages:3509
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.
Report message to a moderator
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 16 20:54:13 GMT+3 2024
Total time taken to generate the page: 0.02335 seconds
|
Blog
Search
Help
Members
Register
Login
Home
