Ruminations on WitP-AE II (Full Version)

All Forums >> [New Releases from Matrix Games] >> War in the Pacific: Admiral's Edition >> Scenario Design and Modding



Message


herwin -> Ruminations on WitP-AE II (12/1/2011 10:21:29 AM)

fcharton might find this idea interesting. In neural modelling, we have to cope with stiff differential equations, so a trick we use in detailed models is to use a different time scale for intra-cellular compartmental modelling from the time scale for inter-cellular modelling. I will model on a microsecond or even nanosecond time scale for the compartmental models and a millisecond time scale at the inter-cellular level. Bats are known to be able to perceive changes to sensory stimuli at the 10-100 nanosecond scale, so we need to get down to the nanosecond scale in the hair cells.

At this point, some people might say their head hurts, but we have a similar problem in WitP-AE working with multiple scales and a single hex size. What about using multiple hex scales in WitP-AE II? That is, use 40 nm hexes for the naval scale, 4 or 13 nm hexes for the ground scale, and 120 nm hexes for the air scale (the scale on which air to air actions take place). To avoid confusion, refer to the ground hexes as grid points, and air hexes as air zones. To minimize the size of the map, grid points would inherit from the characteristics of the naval hex, with bases and population centres located at the centre of the hex, and ground unit positions being at a specific grid point relative to the centre. (An empty grid point would take up no memory, except when a naval hex is expanded during the ground operations phase.) Japanese units could specialise in infiltration--moving more rapidly point to point, while Western Allied units would be more road-bound and focus more on head-to-head combat. Chinese units would tend to prefer infiltration. Supply would move hex centre to hex centre, and be distributed to units from the hex centres. Major transportation routes (rail lines or roads) would be hex centre to hex centre, so that a garrison might be located on hex centres, transportation grid points, or individual grid points in the back country. Garrison requirements might be for the total in the naval hex or only units in the hex centre.

To plan ground movements, the player would use the standard hex grid (hex centre to hex centre) for operational or strategic movement or for tactical movements the magnified hex grid for a hex and its neighbors. Island sizes would be from a single hex centre point up to every grid point in the hex. A grid point would represent the area over which a unit can affect action. On a 13 nm scale, there would be no ZoCs, while on a 4 nm scale, some larger units would have a ZoC, perhaps only when deployed.

Since maps of grid points are generated temporarily and only when needed, the 4 nm scale seems to be possible. The 13 nm scale is definitely feasible.




elcid -> RE: Ruminations on WitP-AE II (12/5/2011 10:49:15 PM)

I once talked to the President of Matrix - before WITP was released - about scale. Scale is the most important choice in game design. He explained there are technical limits to possible scale - and he knew perfectly well 60 nm per hex was not ideal. Just as certainly, he knew 40 is not perfect either. For reasons of geography and sensors, the natural scale for naval air modeling in the period is 20 nm per hex. Land is different - and a good land model probably requires entirely new code. But even so, it is far better at 20 miles per hex than at 40 or 60.

I once experimented with breaking a hex into seven segments - considering each hex to be a circle of six hexes around a central hex. You can represent each sub area or zone as a point - as you propose. Thus, if the location of an asset matters - one can specifiy it as hex ABCD followed by a code for which point: Center, NE, SE, E, W, SE, SW or something like that. You can ignore the segments for some purposes, and only address them on others. Thus - for example - if a land unit enters a hex from the hex to the NE - it is in the NE segment of the new hex. In such a case, knowing what is defending the NE segment might matter. And knowing what is in the Center - not yet affected by the invader - might also matter. But it is a complex solution, and requires coding. In the end, it is probably easier to simply reduce the scale until you have the "right" one. What is "right" for land is not exactly the same as for naval-air - but since 20 is ideal for the latter and better for the former - it is probably the scale of choice for a combined arms game.

Note in all cases I use nautical miles. It is for good reason this is the standard for navigation (a nm is 1 minute of latitude, and 1 minute of longitude at the Equator). For non sailors, 20 nautical miles is the visual (and radar) horizon (which is not to say you cannot see a tall mountian or masthead at greater distances) for an observer on a surface ship. If you are right at the surface - the horizon is only 8 miles away. But on most ships you can get up about 20 or 30 feet - and most ships you want to see are not small craft - while aircraft fly at least a little above the surface. I have seen surface radar display something big at 60 or 70 nautical miles, but it is most unusual (and large, as a mountain). For practial purposes, at greater than 20 miles, it is not detected by a surface observer or radar.

quote:

ORIGINAL: herwin

fcharton might find this idea interesting. In neural modelling, we have to cope with stiff differential equations, so a trick we use in detailed models is to use a different time scale for intra-cellular compartmental modelling from the time scale for inter-cellular modelling. I will model on a microsecond or even nanosecond time scale for the compartmental models and a millisecond time scale at the inter-cellular level. Bats are known to be able to perceive changes to sensory stimuli at the 10-100 nanosecond scale, so we need to get down to the nanosecond scale in the hair cells.

At this point, some people might say their head hurts, but we have a similar problem in WitP-AE working with multiple scales and a single hex size. What about using multiple hex scales in WitP-AE II? That is, use 40 nm hexes for the naval scale, 4 or 13 nm hexes for the ground scale, and 120 nm hexes for the air scale (the scale on which air to air actions take place). To avoid confusion, refer to the ground hexes as grid points, and air hexes as air zones. To minimize the size of the map, grid points would inherit from the characteristics of the naval hex, with bases and population centres located at the centre of the hex, and ground unit positions being at a specific grid point relative to the centre. (An empty grid point would take up no memory, except when a naval hex is expanded during the ground operations phase.) Japanese units could specialise in infiltration--moving more rapidly point to point, while Western Allied units would be more road-bound and focus more on head-to-head combat. Chinese units would tend to prefer infiltration. Supply would move hex centre to hex centre, and be distributed to units from the hex centres. Major transportation routes (rail lines or roads) would be hex centre to hex centre, so that a garrison might be located on hex centres, transportation grid points, or individual grid points in the back country. Garrison requirements might be for the total in the naval hex or only units in the hex centre.

To plan ground movements, the player would use the standard hex grid (hex centre to hex centre) for operational or strategic movement or for tactical movements the magnified hex grid for a hex and its neighbors. Island sizes would be from a single hex centre point up to every grid point in the hex. A grid point would represent the area over which a unit can affect action. On a 13 nm scale, there would be no ZoCs, while on a 4 nm scale, some larger units would have a ZoC, perhaps only when deployed.

Since maps of grid points are generated temporarily and only when needed, the 4 nm scale seems to be possible. The 13 nm scale is definitely feasible.





Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.367188E-02