Soon to Come - Not RHS

[JWE]

ORIGINAL: Monter_Trismegistos

Is submarine still able to manuver with such low speed? As I remember old Harpoon, subs always moved with speed at least 5 knots - speed arbitrary set to being lowest speed in which captain has still control over sub's position)

Speed, 'in the WiTP game', is just a number. It says how many hexes you can travel in a game pulse, and is used as a numeric variable in certain calculations. It really is as simple as that. There is no such thing in the game code as inability to maneuver. Speed really is just a simple, straight forward, ordinary, every day, number.

[JWE]

ORIGINAL: ny59giants

When does the sys damage from a hit or enough near misses figure into the calculation of further ASW attacks??
Example - If the first ship in an ASW TF of 6 ships (common number as many use that as a House Rule) gets a direct hit on the sub, do the rest of those ships in that TF have a higher chance of hitting that sub??

Often a sub will undergo an ASW attack earlier in the 12 hour phase and then again near the end. Does the change in sys damage come into effect for the last attack??

If not, what level of sys damage has to be achieved to increase the liklihood of further damage to a sub??

No increase of liklihood, due to prior damage. There is a liklihood that attacks will stop, however, if the sub is sunk by a previous ship.

[el cid again]

JWE seems to be wrong here. It appears that for some reason very low system damage values make a submarine much more effective. It may be difficult to see this looking at code - but it is easy to see it in testing. Just watch submarine attacks and take notes - the damaged subs are much more likely to take hits. It might be an indirect (or compound) effect: sys damage slows you down - slower means less likely to evade pattern.

[JWE]

No, not wrong. Damage is not an evaluated variable.

The way it effects things is in successive iterations of 'passes' and successive ship attacks, where the target evasion function is evaluated. Damage causes speed loss, and this is where a prior ship's attack "may" show up (speed is functionally evaluated, not evaluated as a stand alone integer). It all depends on where the 'increment' function resides in the routine flow.

[witpqs]

The original manual (IIRC) also stated that more damage made a ship more likely to be detected, and more likely to be successfully attacked. The context made it plain that applied to subs too.

[JWE]

Yep, and that's just what the reduced speed parameter does. Damage effects things. It's the things that damage effects that are evaluated as variables. And the really fun part is that they often pull in opposite and counter-intuitive directions. [:D] Oh, we definitely need a laughing pirate smiley face, maybe one with a a parrot too.

[el cid again]

ORIGINAL: JWE

No, not wrong. Damage is not an evaluated variable.

The way it effects things is in successive iterations of 'passes' and successive ship attacks, where the target evasion function is evaluated. Damage causes speed loss, and this is where a prior ship's attack "may" show up (speed is functionally evaluated, not evaluated as a stand alone integer). It all depends on where the 'increment' function resides in the routine flow.

This is not clearly expressed. You already understand what you are trying to say. Can you say it in a bit more complete form? Please.

[el cid again]

ORIGINAL: JWE

Yep, and that's just what the reduced speed parameter does. Damage effects things. It's the things that damage effects that are evaluated as variables. And the really fun part is that they often pull in opposite and counter-intuitive directions. [:D] Oh, we definitely need a laughing pirate smiley face, maybe one with a a parrot too.

Which speed perameter? And measured in what terms - knots - or hexes ?

[herwin]

ORIGINAL: el cid again

JWE seems to be wrong here. It appears that for some reason very low system damage values make a submarine much more effective. It may be difficult to see this looking at code - but it is easy to see it in testing. Just watch submarine attacks and take notes - the damaged subs are much more likely to take hits. It might be an indirect (or compound) effect: sys damage slows you down - slower means less likely to evade pattern.

So it comes in ahistorically.

I would assume damage would express itself in increased noise and detectability...

[JWE]

ORIGINAL: herwin
So it comes in ahistorically.

I would assume damage would express itself in increased noise and detectability...

Well of course it does. But, this is, after all, a computer game.

Since there is no such thing in the game as a 'noise' parameter, it makes the analysis pretty futile doesn't it?

[ChezDaJez]

ORIGINAL: herwin

ORIGINAL: el cid again

ORIGINAL: herwin

Why the big divisor for shallow water?

Subs were much less detectable in shallow water and littoral areas.

A couple of issues arise: if the bottom is shallow enough a sub can sit on it - and it "disappears" from active sonar echos most of the time. In some places - e.g. Formosa Straits - currents over the bottom cause a lot of noise - rendering passive detection less likely to work - and sometimes reducing active detection range as well.

But not all is roses for the submarine: it may not be able to submerge, it may run into things in shallow water a lot more often than not - doubly so with a strong current (see Formosa Straits) - and it may itself not be able to find targets - particularly by listening.

See Stefanick (1987) Strategic Antisubmarine Warfare and Naval Strategy, Lexington Books, for a discussion of the issues. In shallow water, you can only use the surface duct and there's a lot of acoustic clutter. My lab is studying this.

Incorrect. This is the difference between theorectical ASW knowledge and knowledge gained during real world operations. There are three basic sound transmission paths that are germane to ASW. These are direct path, bottom bounce and convergence zone. Now we can get into the various ducting rays such as surface (above the thermocline) or deep (below the thermocline) and split path but they are not germane to the game.

Confining our discussion to shallow water, there are two types of sound path: bottom bounse and direct path. Many call a direct path a surface duct but they would be incorrect. However a surface duct can be direct path. To explain in simple terms, direct path is the omnidirectional sound output from a target. That is, it radiates in all directions. The degree of temperature change (thermocline) will determine whether the sound becomes trapped (surface duct) for extended ranges. However, if there is little or no thermocline and the water is shallow, the sound will be radiated via dual channel. That is direct path and bottom bounce. The direction of bottom bounce is highly dependent upon the bottom type and the angle of incidence. A soft bottom (mud, loose sand) will attenuate the signal to a great deal. Under extremely rare circumstances, the sound can be trapped in the mud layer and emerge 1000's of yards away. If the bottom is hard, the sound will be reflected much like an echo in a cave. If an undersea precipace is present, it will be reflected back towards the originating source or scattered.

Chez

[herwin]

Why incorrect? We're talking about WWII--the standard sonar detector was a pair of ears, and array sonars were not yet in use--you had to steer the receiver. Active sonar was good for a nautical mile or so. Hard bottom areas on the shallow continental shelf and in littoral areas were small and isolated, so bottom bounce wasn't very useful in shallow water--especially as you had to disambiguate the signal with a pair of trained ears. You were basically restricted to direct path at shallow angles.

[el cid again]

ORIGINAL: herwin

ORIGINAL: el cid again

JWE seems to be wrong here. It appears that for some reason very low system damage values make a submarine much more effective. It may be difficult to see this looking at code - but it is easy to see it in testing. Just watch submarine attacks and take notes - the damaged subs are much more likely to take hits. It might be an indirect (or compound) effect: sys damage slows you down - slower means less likely to evade pattern.

So it comes in ahistorically.

I would assume damage would express itself in increased noise and detectability...

Me too - which means it comes in historically - they got it right - unless JWE is right - and lower system damage does not matter. This is a complex program - and just because something is not used in this routine here does not mean it is not used somewhere by something. So it is possible he is both right about one routine and not right totally because of somethign he is not looking at. That would be very SOP

[el cid again]

ORIGINAL: JWE

ORIGINAL: herwin
So it comes in ahistorically.

I would assume damage would express itself in increased noise and detectability...

Well of course it does. But, this is, after all, a computer game.

Since there is no such thing in the game as a 'noise' parameter, it makes the analysis pretty futile doesn't it?

Not if you think like GG does. He uses semi abstract modeling. It does not require we have a parameter called noise - or sonar - or anything like that. All it requires is that as damage goes up - the chances of a hit go up. Lots of ways to get there. But when someone on the board pointed out that subs do better at low system damage - I began to look at that: looks like he was right.

[herwin]

ORIGINAL: el cid again

ORIGINAL: JWE

ORIGINAL: herwin
So it comes in ahistorically.

I would assume damage would express itself in increased noise and detectability...

Well of course it does. But, this is, after all, a computer game.

Since there is no such thing in the game as a 'noise' parameter, it makes the analysis pretty futile doesn't it?

Not if you think like GG does. He uses semi abstract modeling. It does not require we have a parameter called noise - or sonar - or anything like that. All it requires is that as damage goes up - the chances of a hit go up. Lots of ways to get there. But when someone on the board pointed out that subs do better at low system damage - I began to look at that: looks like he was right.

You can model the process or you can model the outcomes. I prefer to model the process because if that produces the outcomes, I have a robust model, and if that doesn't produce the outcomes, I have an interesting research question. If you model the outcomes but not the process, your model isn't robust, and you can't adjust it later when you understand the requirements better or something else forces a change. Remember, requirements always change.

[JWE]

ORIGINAL: herwin
You can model the process or you can model the outcomes. I prefer to model the process because if that produces the outcomes, I have a robust model, and if that doesn't produce the outcomes, I have an interesting research question. If you model the outcomes but not the process, your model isn't robust, and you can't adjust it later when you understand the requirements better or something else forces a change. Remember, requirements always change.

Gosh Harry, I can hardly wait till your game comes out. Sounds like it will be a ton o’ fun.

We’re just being prosaic in the meantime, trying to understand the models we got. Heck, because of the way things work, we don’t even look for specific IRL outcomes, just those that fit within the model parameters and give the same ‘excitement’ level.

Sounds like you will have the definitive model for most of the various combat mode algorithms; sweet !! You got a possible intro date ?? I’ll use it.

Ciao. John

[herwin]

ORIGINAL: JWE

ORIGINAL: herwin
You can model the process or you can model the outcomes. I prefer to model the process because if that produces the outcomes, I have a robust model, and if that doesn't produce the outcomes, I have an interesting research question. If you model the outcomes but not the process, your model isn't robust, and you can't adjust it later when you understand the requirements better or something else forces a change. Remember, requirements always change.

Gosh Harry, I can hardly wait till your game comes out. Sounds like it will be a ton o’ fun.

We’re just being prosaic in the meantime, trying to understand the models we got. Heck, because of the way things work, we don’t even look for specific IRL outcomes, just those that fit within the model parameters and give the same ‘excitement’ level.

Sounds like you will have the definitive model for most of the various combat mode algorithms; sweet !! You got a possible intro date ?? I’ll use it.

Ciao. John

Done this and that over the years, almost entirely in professional and later academic contexts. Designed a ground combat CRT that got used in a couple of commercial games. Rules guru for an SPI game. I've been thinking about doing a computer game. What would you like to see?

[el cid again]

ORIGINAL: herwin

ORIGINAL: el cid again

ORIGINAL: JWE


Well of course it does. But, this is, after all, a computer game.

Since there is no such thing in the game as a 'noise' parameter, it makes the analysis pretty futile doesn't it?

Not if you think like GG does. He uses semi abstract modeling. It does not require we have a parameter called noise - or sonar - or anything like that. All it requires is that as damage goes up - the chances of a hit go up. Lots of ways to get there. But when someone on the board pointed out that subs do better at low system damage - I began to look at that: looks like he was right.

You can model the process or you can model the outcomes. I prefer to model the process because if that produces the outcomes, I have a robust model, and if that doesn't produce the outcomes, I have an interesting research question. If you model the outcomes but not the process, your model isn't robust, and you can't adjust it later when you understand the requirements better or something else forces a change. Remember, requirements always change.

The problem is money. A commercial company must control its cost - or it will not long exist. An earlier WITP - by Jim Dunnigan - was too ambitious - and never did work - the Mac version failed and the PC version was never released. GG used a simple concept - and we got something to work with.

The good news is this is the most successful product of its kind in history. The better news is that - in spite of a decision to discontinue WITP development as posted on this forum - Matrix has now decided to attempt an incrimental upgrade process - to generate revenue which will - if it works - permit a different platform for the second upgrade. We may have something better to work with in - wild guess - 3 or 4 years. But even so - I don't think we will see a total revision of everything - and I only think we can expect modest changes in the submarine/ASW model. It is indeed not very sophisticated - but a process treatment would require a sensor oriented design - and I don't think WITP II (or whatever it is called) will go that way.

For the record - I have such mechanisms - oriented for more modern conflicts - and they can be applied to WWII - and I am looking at implementing them in code with some new platforms that speed development. But anyone working on such things is welcome to ask for algorithms, principles, data, etc.

[herwin]

ORIGINAL: el cid again

ORIGINAL: herwin

ORIGINAL: el cid again




Not if you think like GG does. He uses semi abstract modeling. It does not require we have a parameter called noise - or sonar - or anything like that. All it requires is that as damage goes up - the chances of a hit go up. Lots of ways to get there. But when someone on the board pointed out that subs do better at low system damage - I began to look at that: looks like he was right.

You can model the process or you can model the outcomes. I prefer to model the process because if that produces the outcomes, I have a robust model, and if that doesn't produce the outcomes, I have an interesting research question. If you model the outcomes but not the process, your model isn't robust, and you can't adjust it later when you understand the requirements better or something else forces a change. Remember, requirements always change.

The problem is money. A commercial company must control its cost - or it will not long exist. An earlier WITP - by Jim Dunnigan - was too ambitious - and never did work - the Mac version failed and the PC version was never released. GG used a simple concept - and we got something to work with.

The good news is this is the most successful product of its kind in history. The better news is that - in spite of a decision to discontinue WITP development as posted on this forum - Matrix has now decided to attempt an incrimental upgrade process - to generate revenue which will - if it works - permit a different platform for the second upgrade. We may have something better to work with in - wild guess - 3 or 4 years. But even so - I don't think we will see a total revision of everything - and I only think we can expect modest changes in the submarine/ASW model. It is indeed not very sophisticated - but a process treatment would require a sensor oriented design - and I don't think WITP II (or whatever it is called) will go that way.

For the record - I have such mechanisms - oriented for more modern conflicts - and they can be applied to WWII - and I am looking at implementing them in code with some new platforms that speed development. But anyone working on such things is welcome to ask for algorithms, principles, data, etc.

I had some contact with Jim (still do from time to time) about Victory at Sea. There were two big problem areas--process models and AI. Jim gave them the data, but it turned out they didn't understand the mechanisms. A real pity.

I could probably write a spec for what is needed.

[witpqs]

ORIGINAL: JWE

ORIGINAL: herwin
So it comes in ahistorically.

I would assume damage would express itself in increased noise and detectability...

Well of course it does. But, this is, after all, a computer game.

Since there is no such thing in the game as a 'noise' parameter, it makes the analysis pretty futile doesn't it?

If the original manual is correct, it might have been included in the code that derives a ships detectability level (I might have misremembered the exact terminology the manual used). Supposedly, detection level is used by the code to modify how successful attacks will be (in addition to how hard/easy it is to detect a ship at all).