ORIGINAL: jmlima
ORIGINAL: ColinWright
...
Mind, if Matrix decides to go for it, it does open up some exciting possibilities. But I think there's a contradiction between demanding more programming resources and expecting a renewed emphasis on accurate simulation.
...
There might be a middle path, where the available resources get focused into significant features currently perceived as flaws.
For example, I would venture, that a middle way of having a 'super patch' for TOAW 3 that would be sold for a fee (less than a new game), would probably be more successful, time and cost effective, than heading towards an hypothetical TOAW 4.
Of course, there really is no substitute for investment. But the game is mature enough that we can do without a new version, only adding to the existing one. Matrix on the other hand, might very well say that commercially this is not viable, and that they prefer to spend 5 years developing TOAW 4 to sell it for $150 (assuming current increases in average prices continue).
My guess is that TOAW reached as far as it can go, and from now onwards it's minor tweaks, when and if Ralph has time and continues interested.
Well, presumably our presence and continued interest is valued. It seems to be...
To keep that, continued upgrades are going to be needed. On the other hand, if it would accelerate the process, I for one would be willing to pay money occasionally. When I consider what Talonsoft got away with with WGOTY/ACOW, paying for almost any substantial improvement seems reasonable.
However, and in the meantime, there are a number of improvements that don't
seem like they would involve extraordinary effort.
The return of sea roads.
The extension of variable supply points to the 'old' supply system.
A restoration of supply units so that they can work the way they used to. After all, apparently the programming has already been done so that Curtis can keep his new supply units. He can just call them something else. Or call the original supply units something else. I don't care.
The elimination of of the pre-1960 prohibition on helicopters. That's not really of immediate concern to me, but philosophically, it bugs me. If a designer finds 'helicopters' a useful way of representing something, he should have it.
The creation of a second category of rail movement -- except it would be road movement. Most armies did not have fully motorized troops. But they
did have trucks, and they did collect their trucks and bus infantry regiments here and there. I don't see why simulating this would pose horrific obstacles. You have a 'road movement' capacity, and you can embus units and 'drive' them along roads. You don't want this to happen, set the capacity to zero. It seems kinda cut and paste to me to create this option. Just copy the rail routines and tell the computer to look for roads.
A 'flak effect' that has a similar effect to that of clouds on air attack values. Sounds doable. Maybe not. I'd at least like to hear Ralph's reaction. After all, that's mainly what flak does. Render air attack less effective. The total flak value of a hex should correspondingly weaken air attack.
Designer enabled/disabled ability of formations/forces to use flak in ground combat. TOAW notwithstanding, a lot of armies at a lot of times just did not effectively use their flak in ground combat. Why is an interesting subject -- but an academic one. They just didn't. Your average 1942 British infantry brigade group may well have had 12 40mm AA attached. They rarely did anything at all for its AT or AP ability. An awful lot of scenarios I look at have an awful lot of flak that -- actually -- rarely or never participated in ground combat in that particular campaign.
Additional tiles for 'destroyable' roads/bridges. Is that really so hard to do? Doesn't
sound hard. All that's really needed is to unhook the 'bridge' from the presence of a 'river' -- and create a way of marking it as a 'destroyable road/rail.' Or 'bridge.' Call it what you like. As always, this should be designer-designated.
A designer option to permit airlifting of ordinary units. The non-airliftable equipment would get left behind, just like it does now, so this would stop
SS Leibstandarte from being airlifted into the Stalingrad pocket. Hopefully, it would be possible to restrict such units to landing on airfields. Perhaps -- like HQ's -- they could only land on friendly-controlled hexes. That's not
perfect, but it sounds simple, and if I can get it, I'll take it. Make it designer-enabled, and then if you don't want it, don't enable it.
As with trucks, armies used to airlift ordinary leg infantry about. The Germans were big on it. I know the British did it. This'd be a plus.
Stack movement for naval units. Why is this hard to do? Embarked land units can move as stacks. Point is that as things are right now, it'd be a convenience -- scenarios where one has a lot of naval units are
hell. More importantly, for most suggested improvements to the naval model, stack movement is a prerequisite.
There are other things, of course, and at some point I'll wander into stuff that'll require so much programming that a new release really is called for, but the point is that there are things out there that seem to me to be an inarguable good and that could happen fairly easily -- but don't.
