RE: Comprehensive Wishlist (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III >> Scenario Design



Message

ColinWright -> RE: Comprehensive Wishlist (3/23/2011 6:00:28 AM)


quote:

ORIGINAL: Curtis Lemay
At this point, any solution that requires designer intervention is inferior to any solution that doesn't.


! As far as I'm concerned, the primary appeal of TOAW is the ability to design scenarios.

Given that, if I'm faced with a choice between having to specify parameters where I might be content with a built-in setting, and having a parameter set for me other than I would wish, I'll take the former.

Anyway, there are always default settings. For example, I simply haven't ever bothered to tamper with the attrition divider -- never seen a clear need. That doesn't 'require' my intervention, and I suspect you'd have to go out of your way to 'require' designer intervention in any respect.

We could create a thousand optional terrain types, and even allow the parameters for each to be altered by the designer. The defaults would still be there.



ColinWright -> RE: Comprehensive Wishlist (3/23/2011 6:01:37 AM)


quote:

ORIGINAL: sPzAbt653

quote:

... If it's a new map parameter (like "Distance Hex") then that will require the Map Format to be revised to incorporate that new parameter ...


I have no idea, I was just throwing in an observation, that the program, somehow, somewhere, knows that it is not to destroy bridges in some cases and to allow it in others. Give the designer a choice to intercede the programs choice right there in the editor, if desired. As I said, in my simple mind.

-----------------------
Destroy Bridges
No Bridge (or whatever term is best appropriate)
Repair Bridges
-----------------------


[image]local://upfiles/24850/501ADF50A579473EA48E8590C2966D1C.jpg[/image]



You definitely get a prize for clarity with this one.



sPzAbt653 -> RE: Comprehensive Wishlist (3/23/2011 6:46:27 AM)

Yeah, but I lost in the practicality department.

We did some terrain changes for D21 (changed dunes to look like spooky Finnish forests) but then had to include a separate .dll file. Don't know why, but again that goes to lack of knowledge in these matters.

quote:

... the primary appeal of TOAW is the ability to design scenarios.


I definately agree, but that's just me. I know some hate editing.



Curtis Lemay -> RE: Comprehensive Wishlist (3/24/2011 12:59:59 AM)


quote:

ORIGINAL: ColinWright

Now you seem to be equivocating. So you don't see any real problem with adding additional tiles?


There would be far more involved than just increasing the tile counter. For example, there's implementing the tiles' new features.



Curtis Lemay -> RE: Comprehensive Wishlist (3/24/2011 1:04:04 AM)


quote:

ORIGINAL: ColinWright

! As far as I'm concerned, the primary appeal of TOAW is the ability to design scenarios.

Given that, if I'm faced with a choice between having to specify parameters where I might be content with a built-in setting, and having a parameter set for me other than I would wish, I'll take the former.

Anyway, there are always default settings. For example, I simply haven't ever bothered to tamper with the attrition divider -- never seen a clear need. That doesn't 'require' my intervention, and I suspect you'd have to go out of your way to 'require' designer intervention in any respect.

We could create a thousand optional terrain types, and even allow the parameters for each to be altered by the designer. The defaults would still be there.


If the solution requires designer intervention then it only benefits those scenarios that will yet be edited by their designers. That's only a tiny fraction of the existing scenarios, and only a fraction of even future scenarios. If it doesn't, on the other hand, then it benefits all scenarios. All vs. a tiny fraction.



ColinWright -> RE: Comprehensive Wishlist (3/24/2011 10:18:39 PM)

quote:

ORIGINAL: Curtis Lemay


quote:

ORIGINAL: ColinWright

! As far as I'm concerned, the primary appeal of TOAW is the ability to design scenarios.

Given that, if I'm faced with a choice between having to specify parameters where I might be content with a built-in setting, and having a parameter set for me other than I would wish, I'll take the former.

Anyway, there are always default settings. For example, I simply haven't ever bothered to tamper with the attrition divider -- never seen a clear need. That doesn't 'require' my intervention, and I suspect you'd have to go out of your way to 'require' designer intervention in any respect.

We could create a thousand optional terrain types, and even allow the parameters for each to be altered by the designer. The defaults would still be there.


If the solution requires designer intervention then it only benefits those scenarios that will yet be edited by their designers. That's only a tiny fraction of the existing scenarios, and only a fraction of even future scenarios. If it doesn't, on the other hand, then it benefits all scenarios. All vs. a tiny fraction.


'A tiny fraction' implies that you see a short future for this game. If otherwise, then the 'tiny' fraction will keep growing. It's like buying a new truck. Makes sense if you're planning to stay in business.

Conversely, fixed 'improvements' depend on the programmers' ability to evaluate the impact on all scenarios -- including those yet to be created. As has already happened, such 'improvements' often have a regrettable impact on not merely scenarios yet to be written but those already created -- which generally, were designed to take advantage of/compensate for aspects of the program that have now been 'fixed.' Like, I was happy with the 'inaccurate' equation for flak that existed. That got 'fixed' and it knocked everything all to hell -- and presumably knocked things to hell in every scenario in which airpower played a major role.

As a general rule, given a choice between suffering through the often apparently whimsical notions the programmers have of what is or is not an improvement, and simply having defaults that stay the same while adding the ability to modify things if the designer sees fit, I'll go with the latter.

Take flak values, early turn ending, and the need to beat back graphics changes -- sometimes with only partial success. Whatever you might think of the various changes that have happened in these areas, as far as I've concerned they've been primarily an irritation that only forces me to go back and readjust things so my scenario still works.

On the other hand, innovations that work by leaving a default in place: supply squads, command squads, the attrition divider, etc -- well, these are great. Some I go to town with, others I ignore -- and no harm done.

Obviously, in not all cases is it possible to have a 'default' and equally obviously, in some cases, there has to be a default. Still, where a choice exists, and as far as the future direction of innovation goes, I'm all for defaults rather than hard-wired change.



ColinWright -> RE: Comprehensive Wishlist (3/24/2011 10:23:31 PM)


quote:

ORIGINAL: Curtis Lemay


quote:

ORIGINAL: ColinWright

Now you seem to be equivocating. So you don't see any real problem with adding additional tiles?


There would be far more involved than just increasing the tile counter. For example, there's implementing the tiles' new features.


So long as the 'features' are just variations on the existing suite of effects on combat, and on movement and supply, I don't see how this can be a case. So we make a 'many hot chicks' terrain type that costs 5 MP's for a unit to cross the hex but doesn't affect combat. So what? Where's the challenge?



Curtis Lemay -> RE: Comprehensive Wishlist (3/25/2011 1:57:38 AM)


quote:

ORIGINAL: ColinWright

'A tiny fraction' implies that you see a short future for this game. If otherwise, then the 'tiny' fraction will keep growing. It's like buying a new truck. Makes sense if you're planning to stay in business.


I see it lasting less than a century. Considering that there's probably 1,000 scenarios out there that will never be edited again, that's about what it would take for that fraction to even become "middling". And it will never be "All". "All" is always going to be better.

Some things need to be optional and some things don't. Take the Ant Unit fix. Making it optional would have been an unnecessary cost. TOAW is full of features that aren't optional and don't need to be. Limiting bridge-blowing to hexes that actually have bridges in them doesn't seem to me to need to be optional either. It's not like it's subjective. There is either a bridge in the hex or there isn't.

Now, if you want to simulate something else with the bridge-blowing feature, that's still possible - just put a bridge in the hex. But, I would think that needs to be handled via a separate feature. There are critical differences. First, since there was no actual bridge, then fixing it shouldn't require bridge repair ability. Maybe SeaBees, but not true engineers. Maybe not even SeaBees, if, for example, it was just felled trees or such. Second, ferry ability shouldn't be useful for overcoming it at all.

There are similar issues such as upgrading a road from normal to improved, or excessive tracked traffic degrading a road from improved to normal, etc. There are issues with bridge blowing, too - should engineers be required to blow bridges over major rivers?; should bridges over major rivers be harder to repair than normal bridges?

There could be more refinement of bridge-blowing using these matrices - we could blow a rail bridge while leaving the road intact if it lacked a bridge (or vice-versa). It would even be possible to address that other problem you listed: Unit's that enter river hexes by road could be so flagged - then they could only exit the river hex by road or to a hex "on the road-side of the river" unless it paid the river cost. Identifying the hexes that were "on the road-side of the river" would require another matrix that held that information.



Curtis Lemay -> RE: Comprehensive Wishlist (3/25/2011 2:01:35 AM)


quote:

ORIGINAL: ColinWright

So long as the 'features' are just variations on the existing suite of effects on combat, and on movement and supply, I don't see how this can be a case. So we make a 'many hot chicks' terrain type that costs 5 MP's for a unit to cross the hex but doesn't affect combat. So what? Where's the challenge?


I don't really know how difficult it would be. I do know that no new tiles have been added after years of programming.

And, the matrix idea really is trivial, as I explained before. Wouldn't even require a new line of code.



ColinWright -> RE: Comprehensive Wishlist (3/25/2011 7:38:28 PM)

quote:

ORIGINAL: Curtis Lemay


quote:

ORIGINAL: ColinWright

'A tiny fraction' implies that you see a short future for this game. If otherwise, then the 'tiny' fraction will keep growing. It's like buying a new truck. Makes sense if you're planning to stay in business.


I see it lasting less than a century. Considering that there's probably 1,000 scenarios out there that will never be edited again, that's about what it would take for that fraction to even become "middling". And it will never be "All". "All" is always going to be better.


It's beside the point to some extent, but many of these scenarios are garbage to begin with, and in any case, you yourself and your predecessors have cheerfully chewed them up with the various changes that have already been made.

Open up a scenario made under OPART I, and you can get helicopter noises (and movement rates) when you move what was intended to be World War One Turkish infantry. The flak values have gone all over the map. Early turn ending isn't what it used to be. Artillery now has an AT value.

This value attached to 'not wrecking existing scenarios' is only pulled out when it suits. When it's your idea (or that of your predecessors), the bulldozer goes right through the archeological dig without a care.

As things stand, any older scenario would need to be carefully vetted before play and probably reedited to work as intended. So it's the purest hypocrisy to argue for protecting these ancient treasures when really, it's a matter of the proposed change not being to your liking for some other reason entirely.

I'll grant we shouldn't make a change that renders the whole suite of earlier scenarios unplayable. But don't suddenly go over to 'the change in air temperature might wreck the frescos on the ceiling.' This obviously has never been a genuine concern.
quote:



quote:



Some things need to be optional and some things don't. Take the Ant Unit fix. Making it optional would have been an unnecessary cost.


Probably. But even there. Did you comb the existing bank of scenarios to see if there was one that made use of their previous ability to slow advances to produce a desired effect? Seems perfectly possible to me -- and yet somehow I doubt if you checked...
quote:



TOAW is full of features that aren't optional and don't need to be. Limiting bridge-blowing to hexes that actually have bridges in them doesn't seem to me to need to be optional either. It's not like it's subjective. There is either a bridge in the hex or there isn't.


One can just as easily redefine this as 'either the road can be temporarily rendered unusable or it can't.' Then suddenly there's no reason why the ability to destroy bridges should be confined to river crossings at all.
quote:



Now, if you want to simulate something else with the bridge-blowing feature, that's still possible - just put a bridge in the hex. But, I would think that needs to be handled via a separate feature. There are critical differences. First, since there was no actual bridge, then fixing it shouldn't require bridge repair ability. Maybe SeaBees, but not true engineers. Maybe not even SeaBees, if, for example, it was just felled trees or such. Second, ferry ability shouldn't be useful for overcoming it at all.


If you want to call them 'bridges without rivers' rather than 'destructible roads,' that's fine with me. Call them anything you like...

Otherwise, I think you're getting lost in distinctions that the game doesn't make in the first place -- and that don't even exist in reality. Engineers do fix things besides bridges. A lot of the various engineering forces that existed didn't have anything like the combat ability TOAW assigns them. Here, you're wandering into some completely imaginary terrain of a finely crafted weapon that isn't there and doesn't particularly accurately simulate anything that existed in fact.

Actually larger bridges were rebuilt by specialized bridge-building units -- and these would only have been used in combat in a pinch, and then would have been less than elite troops. A lot of ex-civil engineers and navvies stumbling about with the rifles they hadn't fired since basic training...

I already go through changes to get rail repair units that can fight (as some could), and 'engineers' that can't (as some couldn't). It's not like there's some well-thought out and detailed scheme for simulating all the possible variations in military construction units in place. There isn't.

So forget about this aspect of your argument. It has nothing to do with anything -- least of all TOAW. The game itself just says 'some kind of specialized combat/battlefield engineering ability? Engineers. They'll be who fixes your bridges.' It doesn't go into it deeply at all.





ColinWright -> RE: Comprehensive Wishlist (3/25/2011 7:44:03 PM)

quote:

ORIGINAL: Curtis Lemay


quote:

ORIGINAL: ColinWright

So long as the 'features' are just variations on the existing suite of effects on combat, and on movement and supply, I don't see how this can be a case. So we make a 'many hot chicks' terrain type that costs 5 MP's for a unit to cross the hex but doesn't affect combat. So what? Where's the challenge?


I don't really know how difficult it would be. I do know that no new tiles have been added after years of programming.


You really aren't doing very well here. If the suggestion is that tiles could be added, you claim that this would be hard. If the suggestion is that they could be modified instead, you say that that would be hard. When it's pointed out that it probably wouldn't be, you go back to claiming it would be hard to add tiles.

It would be good if tiles could be added or their attributes modified. Surely that much you will concede.

Now, how about actually ascertaining how difficult it would actually be to do either? When you or Ralph have time to consider the issue, of course.



ColinWright -> RE: Comprehensive Wishlist (3/25/2011 8:20:52 PM)

The ability to modify terrain/add tiles isn't really up there with supply or the suspension of the laws of time when it comes to encirclements, but it would improve the game a lot.

So often I see terrain that wouldn't slow movement but would offer major advantages to the defender. Anyone who has looked around as they drive across Nevada will see lots of perfectly flat open country that you could probably tear across at 30 mph if you didn't care about spilling your coffee. However, it's all in 2-3 km wide valleys overlooked by chains of rugged, often forested peaks. A defenders paradise...anyone trying to advance against opposition is going to get slaughtered unless they go into those mountains. One 75 with enough shells could control 10 km of front and stop a division.

Similarly with most Western European woodland. All the advantages of woods for the defender -- but usually plentifully roaded. Just so long as no enemy's about, you'll go right through without a hitch.

Conversely, there's Dutch Polder. My impression is that it offers no particular advantage to the defender at all...for the footbound, it's more or less just farmland.

But try to drive a truck across it. It's the reverse. Not much direct combat advantage -- definite obstacles to movement for any force with heavy equipment. Back to the American West, there is terrain there that wouldn't offer a whole lot in the way of defensive positions -- but that you're definitely not going to drive across.

The game would be better if we had either the ability to edit existing terrain types or had some open slots where we could do the same. No doubt. Ultimately, what we need is the ability to set -- completely separately -- the combat values, the movement values, and the ability to let supply through.



Curtis Lemay -> RE: Comprehensive Wishlist (3/26/2011 1:59:33 AM)


quote:

ORIGINAL: ColinWright

This value attached to 'not wrecking existing scenarios' is only pulled out when it suits. When it's your idea (or that of your predecessors), the bulldozer goes right through the archeological dig without a care.

As things stand, any older scenario would need to be carefully vetted before play and probably reedited to work as intended. So it's the purest hypocrisy to argue for protecting these ancient treasures when really, it's a matter of the proposed change not being to your liking for some other reason entirely.

I'll grant we shouldn't make a change that renders the whole suite of earlier scenarios unplayable. But don't suddenly go over to 'the change in air temperature might wreck the frescos on the ceiling.' This obviously has never been a genuine concern.


Who said anything about "not wrecking scenarios"? Pay attention. The matrix idea will benefit all scenarios. Regardless of how good or bad they may or may not be. New tiles won't. It will only help a small fraction of them.

quote:

One can just as easily redefine this as 'either the road can be temporarily rendered unusable or it can't.' Then suddenly there's no reason why the ability to destroy bridges should be confined to river crossings at all.


I just listed two reasons. I'll do it once more for your benefit: They require engineers to fix them, when in reality, they wouldn't. And they can be "bridged" by ferry teams, when in reality, that would be absurd.

quote:

Otherwise, I think you're getting lost in distinctions that the game doesn't make in the first place -- and that don't even exist in reality. Engineers do fix things besides bridges.


The point was, those things can be fixed by other than engineers. Felled trees could be cleared by any warm bodies, for example. But, if it is artificially treated as a bridge, then it must have an engineer to fix it. And, it will be absurdly spanned by a ferry team.

quote:

Engineers. They'll be who fixes your bridges.' It doesn't go into it deeply at all.


Right - bridges. Roads are another matter.

But, regardless, as I said, if you want to do this you still can - just put a bridge in the hex. To expect the game to officially treat road repair as if it were bridge repair is just wrong. That would need a separate treatment.



Curtis Lemay -> RE: Comprehensive Wishlist (3/26/2011 2:02:52 AM)


quote:

ORIGINAL: ColinWright

You really aren't doing very well here. If the suggestion is that tiles could be added, you claim that this would be hard. If the suggestion is that they could be modified instead, you say that that would be hard. When it's pointed out that it probably wouldn't be, you go back to claiming it would be hard to add tiles.


I never said hard. I really don't know. I said non-trivial.

And, once more, the matrix would be trivial. So, it's better and easier. QED.



ColinWright -> RE: Comprehensive Wishlist (3/26/2011 6:51:28 PM)

quote:

ORIGINAL: Curtis Lemay




The point was, those things can be fixed by other than engineers. Felled trees could be cleared by any warm bodies, for example. But, if it is artificially treated as a bridge, then it must have an engineer to fix it. And, it will be absurdly spanned by a ferry team.




Who -- exactly -- do you think would be charged with clearing a mined road?

And as a matter of fact, the engineers are usually the ones charged with clearing obstructions. They've got the tools, they've got the expertise...

Blown culverts...creating bypasses...filling in craters. OF COURSE it's engineering units.

quote:

quote:

Engineers. They'll be who fixes your bridges.' It doesn't go into it deeply at all.




Right - bridges. Roads are another matter.


To be precise, if you will look at a historical OOB, you will find many units charged with repairing roads. The roads are not simply repaired by any Tom, Dick, and Harry within arms reach. You might as well posit the artillery is manned by whoever's around. It is a skill, you know.

Now, if you want to create a further elaboration of the system to reflect the exact type of engineers who carry out these repairs, go to it. But in the meantime, 'engineers' are the best the system offers -- and in fact, if a stretch of road was out of commission, and a general found himself trapped in OPART-land, it would be his engineer battalion he would turn to. What would he use? His armored recon unit?







ColinWright -> RE: Comprehensive Wishlist (3/26/2011 7:13:50 PM)

quote:

ORIGINAL: Curtis Lemay


quote:

ORIGINAL: ColinWright

You really aren't doing very well here. If the suggestion is that tiles could be added, you claim that this would be hard. If the suggestion is that they could be modified instead, you say that that would be hard. When it's pointed out that it probably wouldn't be, you go back to claiming it would be hard to add tiles.


I never said hard. I really don't know. I said non-trivial.

And, once more, the matrix would be trivial. So, it's better and easier. QED.


There are two possibilities here.

The first is that TOAW perfectly simulates all the possible permutations of military reality over an entire planet for about a century, and that all designers will wish to treat everything in the same way.

For this, 'the matrix' sounds like a fine solution.

Alternatively, one might posit that in fact TOAW is a gross oversimplification that attempts to ram everything from Cossack Cavalry in southern Poland in 1914 to Airborne Rangers in Iraq in 2003 into the same box -- and that will be used by a hundred different designers with a hundred different approaches.

In that latter case, we'd want a toolbox that was as flexible as possible.

You are assuming -- in the face of all evidence to the contrary -- that a road can only be effectively wrecked where it crosses a river, and that all such crossings are identifiable on the TOAW map.

What about when the road simply crosses from one bank to another? What about the innumerable spans over militarily insignificant arroyos and tributaries? What about the effects of thorough mining? What indeed about felled trees? (Your blithe assertion to the contrary notwithstanding, it is exactly the engineers who are called up to clear that).

You can't reliably predict exactly where a road can or cannot be seriously disabled. If it passes through a narrow canyon, well-placed demolitions could make it unusable for months. Conversely, the 'river' might be easily forded in the dry season, and the absence of a bridge won't be much of an impediment at all.

Finally, neither you nor I can anticipate every situation that might come up, nor every need a designer might perceive. So 'the matrix' may be your idea, but it's a bad one.

Go with flexibility. Allow the designer of the particular scenario to determine what road hexes can or cannot be disabled. He'll know better than we ever can.



ColinWright -> RE: Comprehensive Wishlist (3/26/2011 7:55:15 PM)


quote:

ORIGINAL: Curtis Lemay

Who said anything about "not wrecking scenarios"? Pay attention. The matrix idea will benefit all scenarios. Regardless of how good or bad they may or may not be. New tiles won't. It will only help a small fraction of them.


I am paying attention. That's the problem. Actually, older scenarios were designed to fit the conditions that obtained at the time they were designed. One can assume that if roads could be blown anywhere along a river, the designer accepted that effect, or if he didn't want it, he laid the road one hex off the river.

Now you'd change how the scenario works. It's possible it'll be improved. Certainly not guaranteed, though. Maybe I only allowed that road to run along a river because I wanted it to be destructible.



Curtis Lemay -> RE: Comprehensive Wishlist (3/27/2011 2:27:06 AM)


quote:

ORIGINAL: ColinWright

Who -- exactly -- do you think would be charged with clearing a mined road?

And as a matter of fact, the engineers are usually the ones charged with clearing obstructions. They've got the tools, they've got the expertise...

Blown culverts...creating bypasses...filling in craters. OF COURSE it's engineering units.


You can't wiggle off no matter how hard you try. Fundamentally, repairing a bridge is just a different task than clearing a road. Can mines be cleared by infantry? Of course. Can obstructions? Of course. But even if it is being done by an engineer (again, a SeaBee is something else), the percentage chance of success will be totally unrelated to the chance of bridge repair. And, there's still those pesky ferry-bridging units you keep ignoring. They will absurdly span the mines, obstructions, etc.



Curtis Lemay -> RE: Comprehensive Wishlist (3/27/2011 2:43:23 AM)

quote:

ORIGINAL: ColinWright

You are assuming -- in the face of all evidence to the contrary -- that a road can only be effectively wrecked where it crosses a river, and that all such crossings are identifiable on the TOAW map.


No. I'm assuming a bridge only exists where a road crosses a river. And that that is what "blowing bridges" represents: "blowing bridges".

Again, if you want to adapt it for something else, you just have to put a bridge in that hex.

quote:

What about when the road simply crosses from one bank to another?


Wouldn't that be a "bridge"?

quote:

What about the innumerable spans over militarily insignificant arroyos and tributaries?


They can't be "militarily insignificant" if they require bridges - and their destruction would affect the hex. Just put in the tributary.

quote:

What about the effects of thorough mining? What indeed about felled trees?


Different from bridges. That would require a different feature. But you are free to use bridges if you want.

quote:

(Your blithe assertion to the contrary notwithstanding, it is exactly the engineers who are called up to clear that).


It would not be limited to engineers. Any warm bodies could remove trees from the road. And it would not be spanned by ferry units. And the chance of "repair" would be far different from building a bridge.

quote:

You can't reliably predict exactly where a road can or cannot be seriously disabled. If it passes through a narrow canyon, well-placed demolitions could make it unusable for months. Conversely, the 'river' might be easily forded in the dry season, and the absence of a bridge won't be much of an impediment at all.


I can reliably predict where a road crosses a river. That's a bridge. That's exactly what bridge destruction and repair is about. Nothing else.



Curtis Lemay -> RE: Comprehensive Wishlist (3/27/2011 2:51:21 AM)


quote:

ORIGINAL: ColinWright

I am paying attention. That's the problem. Actually, older scenarios were designed to fit the conditions that obtained at the time they were designed. One can assume that if roads could be blown anywhere along a river, the designer accepted that effect, or if he didn't want it, he laid the road one hex off the river.


That's an absurd assumption. No one wants the incredible mass bridge-blowing that entails. It ruins scenarios. It's safe to assume just the opposite. That the designer refused to accomodate his map design to TOAW's limitations. Curing that limitation is a good thing.

Had the designer truely intended a road running parallel to a river to be blown down its entire length he would have included the tributaries appropriate for such. In that case, it would still work in that manner.



Panama -> RE: Comprehensive Wishlist (3/27/2011 3:56:36 AM)

The real problem here is the way rivers are depicted. They should run along hex sides. Never could understand why Norm had them run through hexes. Even moving parallel along the same bank of the river becomes problematic. Of course if you changed that all scenarios would be history. No pun intended. [;)]



ColinWright -> RE: Comprehensive Wishlist (3/27/2011 5:33:44 PM)

quote:

ORIGINAL: Curtis Lemay


quote:

ORIGINAL: ColinWright

I am paying attention. That's the problem. Actually, older scenarios were designed to fit the conditions that obtained at the time they were designed. One can assume that if roads could be blown anywhere along a river, the designer accepted that effect, or if he didn't want it, he laid the road one hex off the river.


That's an absurd assumption. No one wants the incredible mass bridge-blowing that entails. It ruins scenarios. It's safe to assume just the opposite. That the designer refused to accomodate his map design to TOAW's limitations. Curing that limitation is a good thing.

Had the designer truely intended a road running parallel to a river to be blown down its entire length he would have included the tributaries appropriate for such. In that case, it would still work in that manner.


Now that last statement truly is absurd. WHY would anyone have put in 'tributaries' when as matters stand the mainstem alone will allow the bridges to be blown?

Curtis, you're just going where you always go, and the debate becomes utterly sterile.

I'll repeat two points. (1) You can't perfectly anticipate all situations and all design intentions, and so any hardwired 'solution' is bound to have pitfalls. (2) Therefore, it's best if there's a default that the designer has the ability to modify to meet his needs.

That's just the way it is. That you happen to have advocated a solution that falls into the former category rather than the latter shouldn't blind you to that fact.



ColinWright -> RE: Comprehensive Wishlist (3/27/2011 5:50:34 PM)

quote:

ORIGINAL: Panama

The real problem here is the way rivers are depicted. They should run along hex sides.


Yeah. That does usually become apparent at this point in the discussion. Aesthetically, I always objected -- but the argument is overwhelming. The change would also deal with the fact that if you're on a road running along the river, you can conveniently exit onto either bank.

Usually, the ever-convenient spectre of 'already existing scenarios' is raised. However, one could have tiles with 'new rivers' alongside the old tiles. That would scotch that.

They could work essentially as double-sided escarpments. There's even code that allows only certain units to cross major escarpments -- or major rivers. We'd just need (a) the cancellation of the artillery advantage for firing from the uphill side of an escarpment, and (b) the ability of those units which can cross eacily to help out those who have difficulty.

Then there's the question of bridge demolition. Happily, since we're also going to leave behind attempts to predetermine what roads and rails can be destroyed and let the designer decide, that problem's solved as well.



ColinWright -> RE: Comprehensive Wishlist (3/27/2011 6:09:56 PM)

I will not spend time addressing each of these points. I will not spend time addressing each of these points. I will not spend time addressing each of these points...sigh.

quote:

ORIGINAL: Curtis Lemay



No. I'm assuming a bridge only exists where a road crosses a river. And that that is what "blowing bridges" represents: "blowing bridges".

Again, if you want to adapt it for something else, you just have to put a bridge in that hex.


* Either (a) there will then have to be a river in the hex, or (b) you are essentially allowing for 'destructible' roads -- only you choose to call them 'bridges without rivers.'
quote:



quote:

What about when the road simply crosses from one bank to another?


Wouldn't that be a "bridge"?



Indeed. However, it wouldn't be represented on the TOAW map -- not unless you chose to have the road go 5 km or-whatever-the-scale-is away from the river and then come back again.

But here, you must understand the point. You're just obfuscating -- and that really isn't helpful.
quote:



quote:

What about the innumerable spans over militarily insignificant arroyos and tributaries?


They can't be "militarily insignificant" if they require bridges - and their destruction would affect the hex. Just put in the tributary.


In many areas, one would then have a 'river' in every hex. The fact of the matter is that there are many, many natural features that may not be militarily important enough to make it advisable to represent them as something that affects combat over the whole hex -- but that would certainly make it easy to thoroughly wreck the road.
quote:



quote:

What about the effects of thorough mining? What indeed about felled trees?


Different from bridges. That would require a different feature. But you are free to use bridges if you want.


See * above. Either (a) you are demanding that a river be put in the hex, or (b) you are conceding the principle while clinging to the name. The latter, you are welcome to do.
quote:



quote:

(Your blithe assertion to the contrary notwithstanding, it is exactly the engineers who are called up to clear that).


It would not be limited to engineers. Any warm bodies could remove trees from the road.


Here you simply repeat a point that has already been addressed.
quote:



And it would not be spanned by ferry units. And the chance of "repair" would be far different from building a bridge.


Ah. A real point. Hallelujah. Okay, obviously 'ferry' units should only work where the 'destructible' road coincides with an actual river. Come to think of it, they work on river hexes anyway -- whether or not there's a road there. Maybe this isn't a real point after all. Certainly movement is often still slowed -- even if there's a pontoon being towed back and forth across the river. Maybe what change there would be would be for the better.
quote:






I can reliably predict where a road crosses a river.


Ah. But such points cannot always be represented. Either (a) the 'road' never leaves the hex, or (b) the bridge is over a feature that it would be undesirable to represent otherwise. Plenty of features require bridges but shouldn't be on a TOAW map. Go ahead and count major bridges down Highway One from Newport, Oregon to San Francisco, California. You'll have to have a 'river' in each hex.
quote:



That's a bridge. That's exactly what bridge destruction and repair is about. Nothing else.


Indeed. And for reasons that have been made very clear, it would be a good thing if we changed that.



ColinWright -> RE: Comprehensive Wishlist (3/27/2011 6:24:00 PM)

...



Curtis Lemay -> RE: Comprehensive Wishlist (3/27/2011 11:05:13 PM)


quote:

ORIGINAL: ColinWright

Now that last statement truly is absurd. WHY would anyone have put in 'tributaries' when as matters stand the mainstem alone will allow the bridges to be blown?


To make it clear to players that such hexes should be treated as bridges - assuming there even are such scenarios.

quote:

I'll repeat two points. (1) You can't perfectly anticipate all situations and all design intentions, and so any hardwired 'solution' is bound to have pitfalls. (2) Therefore, it's best if there's a default that the designer has the ability to modify to meet his needs.


Any feature can be made optional. But, it comes with an expense in coding time, making the code unmanageble, and making players confused with all the rules options. So, cost/benefit desisions have to be made. Common sense should tell us that very few if any scenarios want roads running parallel to rivers to be blown. So, while the matrix idea could be made optional, I would advise against it. If some designer comes squawking afterwards about it, perhaps it could be made optional later.

Clearly, we can't make every feature of TOAW optional. And, just as clearly, we can't let minute risks of affecting previous scenarios shortcircuit every improvement. Now, if there were a known suite of scenarios that would be adversely affected, that's another thing. But this isn't one of those situations.



ColinWright -> RE: Comprehensive Wishlist (3/27/2011 11:41:38 PM)

quote:

ORIGINAL: Curtis Lemay


quote:

ORIGINAL: ColinWright

Now that last statement truly is absurd. WHY would anyone have put in 'tributaries' when as matters stand the mainstem alone will allow the bridges to be blown?


To make it clear to players that such hexes should be treated as bridges - assuming there even are such scenarios.

quote:

I'll repeat two points. (1) You can't perfectly anticipate all situations and all design intentions, and so any hardwired 'solution' is bound to have pitfalls. (2) Therefore, it's best if there's a default that the designer has the ability to modify to meet his needs.


Any feature can be made optional. But, it comes with an expense in coding time, making the code unmanageble, and making players confused with all the rules options. So, cost/benefit desisions have to be made. Common sense should tell us that very few if any scenarios want roads running parallel to rivers to be blown. So, while the matrix idea could be made optional, I would advise against it. If some designer comes squawking afterwards about it, perhaps it could be made optional later.


I'll grant the matrix idea won't wreck every scenario out there.

It would, however, pick a development choice that would further restrict designers over one that would allow them to model quite a bit that they can't model now.

Rommel did slow up Montgomery's pursuit by mining the roads behind him. And a completely unrestricted ability to create 'destructible' roads/rails would allow designers to not merely simulate bridge demolition, but also other effects.

Like when the road doesn't actually leave the river hex but crosses to the other bank, or spans a ravine feeding into the mainstem, or winds along a cliffside, or whatever. I can think of a lot of roads I've driven on that could be very thoroughly wrecked with very little energy -- and a river was nowhere in sight.

For example, what about rail tunnels? I've got a few in the scenario I'm working on -- and obviously dynamiting a tunnel is going to seriously hamper repair. So I have to stick in a 'river' hex just to make that particular rail hex susceptible to serious damage.

You can argue otherwise (and you have, and I'm sure you will) but I see it as preferable to go with unlimited (but designer controlled) destructibility as opposed to seeking to more sharply confine it, as you suggest. What's more, I don't see the added choice and variety as especially confusing or unduly complicated. The player reads the briefing/knows what hexes are likely to be susceptible to destruction. He can click to check if he's unsure. So? Pretty mild stuff.

If you wanted to do both and have your 'matrix' as the default and the possibility of the designer overriding that and simply setting a road/rail hex to 'destructible' or non-destructible' I could live with that. I wouldn't see your 'matrix' as an especially worthy expenditure of energy, but it wouldn't do a whole lot of harm...

So then things can be as you like them in your scenarios (and all others already created) and as I (and presumably others) would prefer them in ours. They'll even be your way unless somebody does something about it. Wouldn't that be nice?



Curtis Lemay -> RE: Comprehensive Wishlist (3/27/2011 11:41:51 PM)

quote:

ORIGINAL: ColinWright

quote:

ORIGINAL: Curtis Lemay

Again, if you want to adapt it for something else, you just have to put a bridge in that hex.


* Either (a) there will then have to be a river in the hex,


Correct.

quote:

Indeed. However, it wouldn't be represented on the TOAW map -- not unless you chose to have the road go 5 km or-whatever-the-scale-is away from the river and then come back again.


Which is exactly what you would do.

quote:

In many areas, one would then have a 'river' in every hex. The fact of the matter is that there are many, many natural features that may not be militarily important enough to make it advisable to represent them as something that affects combat over the whole hex -- but that would certainly make it easy to thoroughly wreck the road.


They are either bridges (as TOAW defines them) or they aren't. If they are, and can be blown/repaired in TOAW terms, then, obviously, a river is appropriate. If you're talking about culverts, that's a different animal, and requires a different treatment.

quote:

quote:

quote:

What about the effects of thorough mining? What indeed about felled trees?


Different from bridges. That would require a different feature. But you are free to use bridges if you want.


See * above. Either (a) you are demanding that a river be put in the hex, or (b) you are conceding the principle while clinging to the name. The latter, you are welcome to do.


I'm not demanding that a river be put in the hex unless you want to use bridge blowing to sort of model those effects. I don't recommend doing so, though, because bridge blowing is so different from either of those. They need to be handled via their own feature, separate from bridge blowing.

quote:

Here you simply repeat a point that has already been addressed.


Addressed wrongly. Certainly engineers could do the tasks, but clearly they are not the only ones that could. That is in contrast to bridge repair. That can only be done by engineers.

quote:

Ah. A real point. Hallelujah. Okay, obviously 'ferry' units should only work where the 'destructible' road coincides with an actual river. Come to think of it, they work on river hexes anyway -- whether or not there's a road there. Maybe this isn't a real point after all. Certainly movement is often still slowed -- even if there's a pontoon being towed back and forth across the river. Maybe what change there would be would be for the better.


This is exactly why we don't want to amalgamate bridge destruction and repair with road destruction and repair. They are fundamentally different. They need to be handled separately. Once you start making changes like the above, you've made the first step to separating them. That would have to be done, as well as other steps to completely separate them.

Let's just list the differences to be clear:

1. Bridges can only be repaired by engineers. Not so for roads.
2. Destroyed bridges can be spanned by ferry units. Not so for mines or trees or rockfalls, etc.
3. Bridge repair is a percentage chance based upon the assumption that it will be used for bridge repair. It certainly would be different for road repair - and probably different for each type of road damage.
3. Bridges can be destroyed by any unit. You have to be equipped with mines to lay them. Not all units would be.
4. Mines aren't limited to roads. Clearly, minefields need their own tile type.

It gets worse: suppose we wanted to refine bridge building/blowing like I suggested earlier. It would be harder to blow a bridge over a major river, and harder to repair it once blown. But, if you're just obstructing the road that runs along the river, why should it be harder to obstruct just because it is next to a major river instead of a minor one? So, incorporating road destruction into bridge destruction shortcircuits any further refinement to bridges.

quote:

Ah. But such points cannot always be represented.


Of course they can. You can put a bridge anywhere you want.

quote:

Go ahead and count major bridges down Highway One from Newport, Oregon to San Francisco, California. You'll have to have a 'river' in each hex.


Then it sounds appropriate. What's the issue?

quote:

Indeed. And for reasons that have been made very clear, it would be a good thing if we changed that.


It's very clear it would be a bad idea. But, if you desire bridge blowing in any hex, you can just put a bridge in that hex.



Curtis Lemay -> RE: Comprehensive Wishlist (3/27/2011 11:48:38 PM)


quote:

ORIGINAL: ColinWright

It would, however, pick a development choice that would further restrict designers...


What?? Now, today, if you want to use bridge blowing to represent road destruction you must put a river in the hex. This would not change that at all.



ColinWright -> RE: Comprehensive Wishlist (3/28/2011 12:01:24 AM)

quote:

ORIGINAL: Curtis Lemay



1. Bridges can only be repaired by engineers. Not so for roads.


Now (and for example, I simply to don't have the time to deal with each successive claim you make) this statement is simply and completely untrue. It is indeed engineer units that are called upon to deal with any serious obstruction.

You're trying to create a distinction between bridges blown over militarily significant rivers and other forms of obstruction that simply isn't there. If I use a few sticks of dynamite to bring down a landslide on your road winding down an escarpment, you've got an engineering problem fully as formidable as if I've blasted the bridge over the Eel River at Three Forks.

What's more, I just thought of something. You don't even know where there's a 'bridge.' What if we've got a north-south flowing river? The road comes in from the non-river hex to the southwest, runs north along the river for three hexes, and exits to the northeast.

Where's the bridge? Did the road come in, run along the west bank of the river for the first two hexes, and cross over in the third hex it shared with the river? Maybe it comes in, immediately crosses to the east bank on account of cliffs on the west bank, runs north for a bit, then crosses back over on account of cliffs on the east bank, and finally crosses back to the east bank again to make its exit.

Where's the bridge? In the first hex? The second? All three? You don't know. The 'matrix' is meaningless. The only case you can know with any certainty where the 'bridge' is or isn't is when the road shares the hex with the river for exactly one hex -- and the program already lets you blow it in that case.

Take I-70 running down the Colorado. All kinds of opportunities for demolition that have nothing to do with crossing the river, but never mind that. The river comes in from the north, so at some point, you are on the south bank. Then you're running down the north bank, so you must have crossed at least once. Then a while later you're on the south bank again. Finally, you come turn away from the river at Grand Junction -- but you've been on the north bank for some time again by that point. Certainly no crossing -- on the interstate -- at Grand Junction itself.

Where are the crossings? There are at least three of them -- but where? A TOAW map wouldn't tell you -- and your 'matrix' won't detect them either. It would put at least one where it's not -- at Grand Junction -- and miss at least two of the others.



Page: <<   < prev  46 47 [48] 49 50   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
3.3125