Matrix Games

• Sequential Tasking - ie the ability to order multiple tasks in a sequence
  
• Planning Graphics - so we can impose realitic controls such as boundaries
  
• Triggers - so we can set conditions for tasks to start and end that are related to some condition other than time - eg enemy control town X. Note that Sequential Tasking, Planning Graphics and Triggers are a prerequisite for Planning Mode.
  
• Planning Mode - so we can create, analyse and commit contingency plans - ie plans that are not the current plan but can be committed to become the current plan. That way you can be creating future plans while the current plan is being implemented.
  
• Multiple Commands - each with a portion of the total force and each with their own AI processing thread. This would distribute processing and allow us to take better advantage of four and eight core processors, thus improving performance and enabling bigger battles or more detailed simulation. It and Planning Mode are prerequisites for Team Play.
  
• Team Play - where multiple players can play online on the same or opposing team. This woul be terrific IMO.
  
• Staff Roles - where different players can take on the roles of the different staff functions that a normal HQ would have. So you could have your 3 shop fighting the current battle while your 5 shop plans the future op. You could have a fires officer managing the allocation of fire support etc.
  
• Campaign Mode - so you can fihgt a series or network of scenarios where the outcome of the previous scenarios affects the current and future scenarios.
  
• UI Overhaul - to include ditching support for XP so we can take advatange of the new MFC graphics, including transparency effects, and so we can show info overlays like map control, movement maps, firepower maps etc. But also I would like to provide an enhanced sidebar which can be resized and with options to expand and collapse data views so people on larger monitors can take advantage of it. This would also include providing scalable text so older eyes can see the text more easily.
  
• Data Logging - with options to specify what data is logged to file as the game runs. This would allow those with such a bent to analyse events to their hearts content.
  
• Enhanced AAR - with more details on unit performance.
  
• Game Recording - that could be replayed and edited to provide a dynamic AAR.
  

quote:

ORIGINAL: danlongman

One thing we as wargamers expect too much is for our plans to work out perfectly.
Many are guilty of planning just to beat the known AI limits. I have a son who does that.
"Son you gotta keep your sense of immersion, be in the moment!"
"dad, shut up. I am winning the game." I think a few are old enough to remember the
old SPI monster HTTR where if you made a mistake in moving your pieces on the map and
busted stacking limits the whole formation was disrupted. It was a rule that said
your mistake was part of the game. The wailing and gnashing of teeth! The torn hair
and dogs and cats savagely beaten! Nobody went for a smoke or a pee during the other
guys turn in order that his move be policed - real interactive turns. I remember a multiplayer
game where XXX Corps commander's face went white as he accidentally overstacked a road
junction and the Guards Armoured Div went into a traffic jam. Those were the days.
I know this is a bug but in warfare at this level things always go wrong and the winners
are those who plan for misfortune (and it helps to make the least mistakes).
I was part of a military exercise once in a well known training area where an officer thought
he would be really smart and make blown up copies of the standard maps at a very large scale
so he could more intricately place and direct his units. He had these blow ups encased in plastic
laminate on 8x11" sheets (so he could do it at home). Unfortunately he mounted them upside
down because he had blown them up so the numbers were not visible on most copies. Plan for that.

quote:

ORIGINAL: Lieste

I think the impact of 'halting' is overemphasised. I have seen it once or twice, but it can be worked around, and is a prevalent problem in the real world. (That it isn't intentional makes it a bug ~ but I would welcome a managed 'retention' as a feature).

If the issue were severe then the tutorial 'game' I play ~ the elimination of 12th VGD(-) and KG Peiper before scenario end ~ would be less achievable, noticeably the race for St Vith - where the goal is to beat the German 'north edge' reinforcements into the objective.

quote:

ORIGINAL: Arjuna

From: Halting!!!!!!!! ARGH!!!!!!!

I found a bug in the code that tries to initiate attacks. There is a spot where it modifies down the initation probability if the subject has to cross a river to get to the objective. Trouble was that I had made a change to the default value that says whether you are across the river or not but had failed to change the actual test code to accomoate this change. As a result whenever you tried to initiate an attack it would say you are across the river and drastically reduce the prob of launching the attack. My bad. I have fixed this and will test to see if there is anything else amiss.

quote:

ORIGINAL: Arjuna

From: Play balancing

I have been running through a saved game Richard Simonitch sent me on RDOA. In particular he drew my attention to an attack he had ordered the KOSB to undertake and that had stalled. I have been paying close atention to the units as they attempted this attack and have discovered a few anomolies. First off the lead assault company changed facing as soon as it halted. It shouldn't do this in an assault as this decreases its cohesion and wastes valuable time. Next thing I noticed was that the KOSB mortars were firing at targets away from the objective. Upon investigation these mortars were supporting an adjacent formation because the ArtDirectFireOnly option had not been checked in the attack order. I have since made it default to be checked for attacks and probes. So this got the mortars now firing at those pesky German light flak units that were suppressing the assault companies.

However, the mortars were lucky to put in one minute of fire before they lifted. So I stepped through the code and found that it was because the vast majority of the five mintes of bombardment time alloted was being used to register the target. I have now ensured that the fire time is increased by the remaining registration time. So now the mortars get to pound the German lt flak and forced them to retreat thus enabling the assault companies to continue their assault. Yee ha!

But then I noticed that the mortars ran out of ammo just as the assault units got to the objective. This was very unfortunate. Now the code called for a standard bombardment time of five minutes per oncall shoot. Most arty has an allotment of 45 minutes of fire per day. So this would see around nine shoots, which should be enough for an attack. But the glider units don't land with a full load.

So what needs to be done is to reduce the bombardment time by the ratio of available arty ammo to estab arty ammo. I started to do so on Friday but ran out of time as this solution necissitates adding data to several classes ( ie we need to store the estab arty ammo for a unit ). Hopefyully I will complete this on Monday and then we should see the KOSB attack succeed.

Here is a list of the fixes I have done so far:

• Prevent face changing for assaulting units and those moving in road column
• Default the task settings for ArtyDirectFireOnly to true for attacks and probes
• Added the registrationTime to remainingDuration in bombardment events. This ensures that the arty unit fires for at least the specified number of minutes.
• Now cap maxSuppression to 75% for direct fire and to 85% for indirect fire when the target is in covered terrain.
• Reduced max registration times from 15 to 5 minutes and increased the range denominator from 200 to 500. Rego time = min( 5, range / 500 ). The overall effect is to reduce registration times for arty fire. Fatigue and training can increase time by up to 56% to a max of 8 minutes.


I will also take a look at the initial orders delay imposed upon the Germans at scenario start.

Oh and one other thing I forgot to mention above was that I have placed a cap on the amount a unit can be supressed if they are in covered terrain. this ensures that if they do Halt they can still return some fire.