Concept: Evolving the "Ares" engine to a truly generic theater-AI (Full Version)

All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series >> Mods and Scenarios >> Lua Legion



Message


Dimitris -> Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/9/2018 2:16:57 PM)

Hi all,

This is something that I recently discussed with angster (creator of the awesome "Ares" theater-AI). He is very busy these days so he cannot contribute more actively ATM, but here is where we got so far.

My initial scribble of thoughts:
quote:


Okay, so the existing Ares is a very impressive AI effort, but has the limitation of pre-requiring knowledge of the general layout of a scenario and available assets. I have been thinking about a follow-on to this, an Ares Mk2 of sorts, that will be able to handle almost any Command scenario thrown at it. Such a component, if realized, would decisively address one of Command's current flaws: The static nature of its theater-level missions unless the scen author does a lot of custom Lua work.

As I envision it, the scenario author instructs Ares on the overall scenario goals of the side in question by creating "Theater Objectives". TOs can be thought of as higher-level mission-like constructs: They have a type (destruction / protection of a unit, surveillance of an area, ferry between points etc.), units or areas that apply to the TO type etc. What differentiates them from missions is first, that they are more declarative/generic in type (e.g. "The US carrier must be crippled or sank" rather than "Units X, Y and Z are assigned to attack the US carrier") and second and most important, that they are assigned relative weight values to indicate their priority.

So for example in a typical China-US scenario the following TOs may be defined for the Chinese side:
* US naval forces in area ABCD must be destroyed or reduced by at least 50% - Weight 80
* Air superiority over Taiwan must be achieved [define here the metrics for achieving that...] - Weight 120
* The Chinese heartland must be protected against strikes - Weight 200

Ares would then take those TOs, consider its available assets (both unassigned and those already assigned), create/manage the missions necessary to pursue these objectives and juggle its controlled assets between them to match the defined priorities.

The engine would need to periodically re-evaluate its decisions, as the objectives are met (or not), the priority weightings may be changed by the scenario author (shifting strategic, political or even inter/intra-service winds), and available assets are reinforced or (more likely) depleted.

The scenario author may also make "traditional" missions and mark them as "not under Ares control" so that the engine will know not to mess with them.



Angster took that concept and really ran with it. See the PDF inside the attached zip file.

So, what do you think? Is this something that can be done? Is it worth laying the groundwork for (ScenEdit constructs, Lua hooks etc.) and then building on top of them? How can this be improved, developed and realized?




SeaQueen -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/9/2018 3:07:00 PM)

I guess it depends on how it's used.

My observation has been that when a scenario gets too big, the limitation is less on the AI and more on the human player. Command requires very detailed planning. To really get it to perform well, you need to think about exactly how things are done, which is its strength over a lot of wargames, which are more abstracted. After a certain point though, people who are planning for a scenario of too broad a scope wouldn't be planning to that degree of detail and instead would be painting with a broader brush. Effectively, the player ends up wearing too many hats. This is where a less detailed game might actually be more realistic. Gen. Horner didn't build individual strike packages in Desert Storm, he set priorities and had his staff pick targets, then other people figured out how to do it. Command has always had you wear many hats, but at some point the work load gets to be so time consuming that you plan so much and never get to actually play the scenario. Either that, or you don't invest the time in planning and get unbelievable or weird results (e.g. "Why are my bombers turning around?").

Where the AI tends to stumble is re-allocating resources. For example, the AI's strike aircraft have flown out, some of them are lost, and some of them struck their targets. Now what? Does it reconfigure them for air to air and use them to defend friendly airspace or does it pick a new target and reconfigure for that? Does it re-strike the previous target? What does the new strike package look like? What supporting assets does it need? How do they need to be moved around and reconfigured?

Command really shines for scenarios which happen within a planning cycle (e.g. 12-24 hrs). It gets less believable for events which unfold over many planning cycles, unless the scenario is purely naval oriented. There it works well again, because the pace at which naval units move is so much slower. Even then, though, it's probably just less obvious because a ship might take a few days just to get to its first objective. Re-allocating submarines to different areas happens less frequently just because they move so slowly to begin with.




Whicker -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/9/2018 8:23:41 PM)

I like it, and I generally like large scenarios.

I am aware of the Ares thread, and like the idea, but am not aware of anyone using it, so I have not either. I worry about durability of things, and there are so many changes to the game that using a large script seems brittle. But if it is really a part of the game that is used in the scens the devs make and then others start using them I think it would be great.

On a separate note something I have thought of is the concept of missions being queues that can reenqueue to another mission after they are run. So say you have a mission to strike a base at the beginning of the scen, but once the strike is over you want those units to be assigned to another mission - maybe another strike but could be an aa patrol. If the missions were thought of as queues that could be run once and then change to another mission after all units have ran the first mission it would save the designer a lot of work. Part of the mission queue would have to be changing the loadout for the mission which seems complicated. Loadouts could be queued too? maybe the queue is at the unit level and you can have some units join a mission for one run of the queue and then reenqueue to something else, while other units stay in the same mission queue.

My biggest problem with large scens is how hard it is too test them - whether it is my design or someone else's, a LOT of effort can go in to it if it is a large scen, and then after 10 hours you figure out that a certain AI mission/event was incorrect, then you may have to start all over again (sure, hopefully you have reticent save so that is not needed but not always). It can be very discouraging if the event you are trying to test is hours into the scenario. If the AI was smart enough to handle what Ares is setting out to do I think it would be great. I could also see it causing unintended consequences though.

I agree with SQs 12-24 hours time frame, that seems to be a sweet spot of sorts, and part of that could be the AI not adapting to changes that far into the scen. I'm not sure I have played many 2 day + scenarios that stayed entertaining past the first day.




Gunner98 -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/10/2018 6:39:22 PM)

A system like this would make building larger scenarios quite a bit easier.

I might add a time factor to the TOs, this would help keep the player thinking. For instance if TO A was a priority for the first 24 hrs then that priority switches to TO B or whatever.

Whicker's point on mission queueing could be useful as well. Perhaps extrapolate that to TO queueing, but that is sort of in the notes already.

Perhaps an idea to address SeaQueen's point would be to build a UI function that would allow the player to assign objectives and resources to player assets. I.e. in a big scenario, perhaps the player wants the AI to take care of all the ASW or perhaps a certain area for MPA or even a strike. Might help the players work load and make larger scenarios more achievable.

A Theater AI pulse may be more manageable at 6hr hunks vice 1 hour. I worry that units might get re-tasked too quickly and wonky behavior is the result.

This looks very interesting.

B




SeaQueen -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/11/2018 12:44:45 PM)

I looked at the idea in more detail and thought about it. I think something like it might be useful for longer duration scenarios where there's a possibility of re-attacking targets (i.e. 24 hours long or more). It probably needs to be refined more. The cycle time is way too short for both the theater and TO AI's. If the goal is to simulate the behavior of a planning staff, they operate on a 12-24 hr cycle. How are the unit AIs distinct from what's already there? I'm also a little confused by his examples.

The theater objectives ought to be variable over time over either time, or on having achieved various conditions. I'd also argue that the overall AI probably shouldn't be allowed to automatically reapportion assets between subordinate AIs without some sort of more clear definitions of when they'd actually do that. The way it divides up objectives strikes me as a little bit off.

I'm unclear how it would handle the requirements of specific strikes. For example, suppose it was attacking a highly defended deeply buried bunker complex. To attack that target you would need some number either bombers or strike aircraft equipped with penetrating precision guided weapons. How does it choose the ordinance load? It only mentions picking aircraft. The real solution would have to pick a combination of aircraft and ordinance. There might be multiple solutions. For that package to have any chance of penetrating, you would need a fairly large number of supporting assets. Those would include SEAD, jamming (both escort and area jamming), offensive counter air, and defensive counter air assets. You'd also need support from some sort of AEW aircraft and ELINT aircraft. Timing is everything. How does it pick a time on target, and coordinate the various assets so that they arrive on schedule? How does it draw mission boxes? How does it choose WRA for each mission?

Any AI like that would have to be doctrine neutral, so it can't be designed around the behavior of any particular nation. Otherwise you end up with Chinese aircraft behaving like Western allied aircraft, which is totally different.

I also think that until it's really well developed it should be optional whether or not to use it.









Dimitris -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/20/2018 12:58:26 PM)

Some further notes from angster (see attachment).




Ancalagon451 -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/20/2018 3:13:56 PM)

So, are you gonna recruit angster and implement the Ares engine (in some adapted form) as part of Command AI?

Because that would be great.

Ancalagon




vOOdOO73 -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/20/2018 5:21:04 PM)

Amazing read and outstanding work Angster.




Dimitris -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/21/2018 4:22:34 AM)

quote:

ORIGINAL: Ancalagon451
So, are you gonna recruit angster and implement the Ares engine (in some adapted form) as part of Command AI?

Because that would be great.

Ancalagon


No, angster has fleshed out the original idea but is not able ATM to implement it.

Other Lua experts will have to take the torch, if they are interested.




SeaQueen -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/22/2018 1:56:29 PM)

I just downloaded this to study it. Will give my thoughts once I've contemplated it.




BeirutDude -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (12/22/2018 4:33:39 PM)

Being a person who tends to be a "Large" (dare I say "Monster") scenario designer this would be awesome! I think it might have saved me about a month in the development of my last submission as a lot of what I did was using Lua to tweak the mission AI!




serjames -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (3/16/2019 1:55:41 PM)

Just checking in... Major supporter of this effort as it addresses one of the core perceived weaknesses of the game in that the AI is not terribly responsive to smart strategies a play can adopt.

Just seeing if I can implement the original script into a new mission. I'm no coder though so will be a challenge in itself.

Happy to help test if anyone needs any done




Dimitris -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (3/27/2019 6:39:00 AM)

If anyone is interested in undertaking the Lua part, we can start adding the ScenEdit-side constructs (theater objectives etc.) in future updates.




Whicker -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (3/27/2019 4:47:49 PM)

why not add those in if you can and maybe people will find ways to add bits add pieces to get towards the goal. Then at least there is some foundation to work on.




rmunie0613 -> RE: Concept: Evolving the "Ares" engine to a truly generic theater-AI (4/2/2019 6:11:55 PM)

The idea seems awesome. The attached scearios- and attached LA scripts, are missing some key ingredients however...I was able to do one- the renaming reference points to AO-#...but still it was returning errors. However, it did generate some a lot of- missions in the scenario I plugged it in to.
One comment- the missions seem to suck out the memory, as I had multiple out of memory crashes... but I still love the idea, and would happily tinker with it.




Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
3.453125