Progress

[Arjuna]

Hi all,

What an intense fortnight. Playtesting from the beta testers revealed some unwelcomed behaviour when multiple Move waypoints are issued to large forces. Sure enough on checking this out I discovered a series of bugs that accounted for this. I have fixed these and along the way wrotes code to better manage the maintenance of position in road column formation. What was happening was the mainGuard would end up pushing right up and into the advanceGuard position. This resulted in a bunching up of forces at the front, then a huge gap back to the formation hub. I had to write some pretty sophisticated code that manages the order of march for road columns. The result is that large forces now move over long routes with multiple waypoints, maintaining their spacing and without the stop starts we were experiencing. Check out this screendump. It shows the 116 Pz Div moving from east to west. The main guard units have been selected and are highlighted in yellow. There is a little overlap at the tail end of the advanceGuard but that's to be expected, otherwise you end up with grid lock.

[Arjuna]

Here's another shot with the 116th Pz Div moving from west to east. Note the individual Move task objectives for each of the units. For the advanceGuard and mainGuard units these are projected well past the next waypoint. For all but the final waypoint, hey use the missionRoute of the senior hubs plan to know where they should end up. On the final waypoint they will choose objectives based on a local defensive position around the final waypoint. This facilitates the smooth flow of the entire force through each of the waypoints, without the need to regroup or delay ( one of the causes for the original stop start behaviour ).

Note that this behaviour was introduced with the new complex Move code designed to handle automated bridge building. I'm mentioning this here to highlight the complexities involved and the often unforseen knock-on effects you get each time you introduce complex features into the system.

[Arjuna]

Now that we've fixed this issue, Richard and the West Front data design team are working on making the final adjustments to the scenarios. I have a just a few small AI issues to tidyup. [:)]

[WildCatNL]

ORIGINAL: Arjuna
Note that this behaviour was introduced with the new complex Move code designed to handle automated bridge building. I'm mentioning this here to highlight the complexities involved and the often unforseen knock-on effects you get each time you introduce complex features into the system.

Having a game AI background and some experience with hierarchical planners, what impresses me most is your ability to significantly extend the decision making without (presumably) increasing the CPU load much. Adding the options to temporarily split foot-mobile and motorized units and to build bridges should impact any long distance maneuver in this kind of terrain, theoretically multiplying by a large factor the number of plans to be considered. I'm assuming you've build up and refined a great number of heuristics to weed out bad alternative plans (wrt duration, risk, terrain) quickly and at a high level.
I wouldn't mind hearing more about it (once you're done with the game, obviously ).

The other thing that surprises me is the absence of "debug UI screen shots". Is this a design choice (the game should be able to show all relevant AI information, and the AI shouldn't be doing anything not visible in the game)? Or do you rely on alternative means (Gantt charts, for example) to inspect and debug AI plans?

William

[Arjuna]

ORIGINAL: W1ll14m
Having a game AI background and some experience with hierarchical planners, what impresses me most is your ability to significantly extend the decision making without (presumably) increasing the CPU load much. Adding the options to temporarily split foot-mobile and motorized units and to build bridges should impact any long distance maneuver in this kind of terrain, theoretically multiplying by a large factor the number of plans to be considered. I'm assuming you've build up and refined a great number of heuristics to weed out bad alternative plans (wrt duration, risk, terrain) quickly and at a high level.
I wouldn't mind hearing more about it (once you're done with the game, obviously ).

What's your AI background?

The other thing that surprises me is the absence of "debug UI screen shots". Is this a design choice (the game should be able to show all relevant AI information, and the AI shouldn't be doing anything not visible in the game)? Or do you rely on alternative means (Gantt charts, for example) to inspect and debug AI plans?

Not sure I follow you here. I don't understand what you mean by "debug UI screen shots".

In debug mode we can select a unit and dump its details, including plans, to a html file. I can open this file up in a browser on another screen and review them. Also in debug mode we produce a recording of the game that we can replay if need be. So say something doesn't behave right. We can select the unit in question, dump its details, find out the ID of the plan or task or subForce or whatever we're trying to investigate. Then put a break point at the appropriate line(s) of code, re-run the recording and find out why it happens the way it does.

[GoodGuy]

ORIGINAL: Arjuna

Here's another shot with the 116th Pz Div moving from west to east. Note the individual Move task objectives for each of the units. For the advanceGuard and mainGuard units these are projected well past the next waypoint. For all but the final waypoint, (t)hey use the missionRoute of the senior hubs plan to know where they should end up. On the final waypoint they will choose objectives based on a local defensive position around the final waypoint. This facilitates the smooth flow of the entire force through each of the waypoints, without the need to regroup or delay ( one of the causes for the original stop start behaviour ).

One of the paths determined/drawn by the AI looks like an alternative route (a shortcut?) that differs from the route set by the user, via Amonines - Dochamps. Is that route projected for the rear guard and will the rear guard use it? If so, why?

Another question:
Does the new ambush feature provide for limited (or even better "zero") intel? It's in the nature of ambushes that ambush parties hide and stay in concealed/camouflaged positions (undetected, if the ambush had been set up properly) until the entire enemy party is in range or even surrounded, before they start to fire. So, at least with formations of say up to 1 or 2 companies, such relatively small bodies should not show up on the screen until they open fire.

It would be realistic if this would also go for ambushing AT gun platoons, Hell's Highway was packed with camouflaged German AT guns when the British Armoured Division advanced along the highway, and US gun crews tried the same (in a more hasty setup [:D]) during the German advance in the Ardennes. Especially the low profiles of Pak 40 75mm and US M1 57mm guns allowed for proper concealment.

[Arjuna]

GoodGuy,

The alternate route you refer to was actually for the arty unit that was moving to its base. I have changes the LOS for AT, IG and Mortar units such that they are treated the same as infantry if deployed and not firing. So yes they will be a lot harder to detect than previously when they were treated simply as "Gun" units. We don't apply any special detection modifiers if "ambush" is set. That's perhaps one for the next edition.

[ETF]

Any updates on how MP testing is coming along......after all an AI is good for about the first few days only IMHO

[Arjuna]

ETF,

We hit an out of sync bug in multiplayer testing last Saturday morning. We're working to resolve it. It's in the UI, so that makes it difficult to track down. Don't know how long this will take at this stage.

[ETF]

Thx for the update. Good luck finding the little sucker. Hey any improvements since COTA re. MP games?

[Arjuna]

What were you hoping for?

[ETF]

hmm I take it then status quo?
Would have been interesting to see different command levels re. MP players. We are seeing more and more wargames coming out with multiple levels of command for multiple players. I take it is still 1vs1 etc.
Thx

[Arjuna]

Yes it's still 1 v 1. I'm attracted to the idea but it's a big job. It would require us implementing multiple commands per side. There are other advantages to doing this. Advice from Intel is that the speed of individual processors is not going to increase much in the near future. The approach to providing more power is to provide more cores ( CPUs ). To take advantage of this you need to support multiple threads. We do that at the moment, with one thread for the AI, another for the UI and four for sound. What i would like to do in the future is to have multiple AI threads, one for each command. That way we divide up the forces and spread the load across multiple cores. This should speed up the game and allow us to support bigger maps and more forces - ie bigger battles. Consequently we should then be able to support team play. It's on the wish list. [:)]

[Llyranor]

Just voicing my opinion once again that that would easily be my most wanted feature for the series by far! The implications re: team PvP and co-op are pretty awesome! It should be noted that co-op is very much in demand by gamers nowadays, regardless of genre.

[Arjuna]

What do you see as the difference between teram play and coop?

[ETF]

Well Coop would be possibly 2vs.AI rather than a "team vs team"....Also Coop allows all players on a side to move all units. Commands do not really exist. ie Player A handles the east side of the map and player B the west. However if all the action is on the east side player B would jump over and take comand of some of player A's units to help him out. Kinda mute for some new wargames like JUTLAND were players can assign units of there command to other MP's and vice versa. Keeps all in the action rather than getting stuck in the read with the gear

[ETF]

ORIGINAL: Llyranor

Just voicing my opinion once again that that would easily be my most wanted feature for the series by far! The implications re: team PvP and co-op are pretty awesome! It should be noted that co-op is very much in demand by gamers nowadays, regardless of genre.

Agreed..... the days of PBEM and Hot seating are pretty much over. It still amazing me the number of players to this day that still play AI exclusively. Even find it interesting after a few weeks [8|] Once you play MP IMHO there is no substitute.

[BigDuke66]

This team play is something I've been dreaming of for games on a more strategic level like a complete Barbarossa scenario.
I did something like this with TOAW and the "Drang nach Osten" scenario, one was the overall commander and each Heeresgruppe had one player commanding it, in a PBEM this of course slows the turn speed down a lot but it was fun.

I'm sure if the scenarios with the AA engine get big enough this would be wanted again, hopefully by then it is somehow possible.

[ETF]

TOAW was a great wargame in its day......

HISTWAR is about to be released and its MP options are second to none. Mind you it is still not released but the MP options are amazing.

[Arjuna]

Well allowing free form coop play where any player could issue orders to any force would detract from the realism aspects and also nullify the value of segregating into different comamnds so that each could be managed in its own thread. I would prefer to have a system where a player has control of one or more commands and can only issue orders to forces within those commands. We could allow for the transfer of units between commands, albeit with some orders delay built in. This would allow for load sharing if all the action is occuring in one sector but also allow us to speed the game up by isolating commands and threading them separately.