Maps and Terrain

[Christian Knudsen]

Choppinit's recent topic regarding DLC mentions focus on "playable map area".  This makes me wonder about the way in which units will interact with the map.  In the example pictures, the map appears essentially as a standard military map, implying that neither a hex nor "area" system will be used.  This has advantages and disadvantages.  Obviously the following questions imply that neither system will be present.  Also, I am limiting my queries to the "auto resolve" system - the issues involved in porting a map to another battle resolution method ie a miniatures wargame, or Combat Mission, will present other challenges.

There has been some discussion of unit footprint, and how that will vary based on unit size.  Will it also vary based on the type of terrain occupied?  How much ability will the player have to "force" a given unit to occupy a given terrain feature and not spill out of it?  Once in a given terrain "type", how will the unit's ability to spot and fire be affected?  How will intervisibility be handled?  This is critical, especially when considering artillery usage.  How will units "bump" up against one another, and how will the terrain affect this?  As importantly, how much "fidelity" ie effective terrain resolution will the map have?  How will this fidelity level affect movement and all the above issues? 

Now I am no programmer - I have no idea how easy it would be to create a system that "draws" LOS from every prospective map point to every other.  I know that such a system has been done before - Command Ops springs to mind immediately, although it could be argued that this system lacks the fidelity level that the map examples seem to imply.

All of these questions(and discussion of DLCs), make me wonder about community involvement in creation of maps/scenarios/campaigns.  Command Ops has a mod community that has done work in map design, but the way that Choppinit describes DLCs leads me to think that the ability to create maps (and therefore totally new campaigns) will be somewhat limited.  Or will we see more of the model that Panther games is now following, where a core game will include an editor, but the designer releases campaign packs (DLC in this case) that hopefully compliment and are a touch more polished that community efforts - not to put down the often awesome stuff that modding communities put out!

Anyways, just some stuff that I have been pondering...

[76mm]

There has been some discussion of unit footprint, and how that will vary based on unit size.  Will it also vary based on the type of terrain occupied?  How much ability will the player have to "force" a given unit to occupy a given terrain feature and not spill out of it?  Once in a given terrain "type", how will the unit's ability to spot and fire be affected?  How will intervisibility be handled?  This is critical, especially when considering artillery usage.  How will units "bump" up against one another, and how will the terrain affect this? 

These are all good points--for instance, will a unit in a city or forest have the same footprint as in open fields?  And how will stacking work?  And ZoCs?

From Matt's other posts, it sounds like the map will have "fidelity" of 200 meters.

[choppinlt]

Yes there will be blocks of territory used, and I am calling them "tiles". Most likely they will be hex shaped but do not have to be reflected on the map as such. For instance, CM is actually played on a hex map! Each tile will represent a 200mx200m area as 76mm states. The unit footprint represents the area occupied by most of the unit, particularly when it is deployed for combat.

The footprint only changes when they are moving, OR if a unit is "split" up. March moves will be in a single tile wide column, Approach moves will be the "normal" footprint of that type of unit, and Infiltrate will be a hard-to-describe combination of the previous 2. When a unit is stationary, it has the same footprint as an Approach move. For instance an infantry battalion has a footprint of 600m diameter. That does NOT automatically mean the entire battalion is in that area...If you wish to reduce a footprint, you can split up the unit. The advantage of deploying as a battalion is that it fights as an entire cohesive unit regardless of the circumstances. If you "split" a unit up, depending on how you deploy them and the distances between subordinate units, there are ways a unit could end up fighting piecemeal...

To answer your questions directly, yes the footprint remains the same based on terrain, and is more impacted by movement of the unit. And units will have the ability adjusted to a reasonable degree. For instance an armor battalion is spilling out of a 200m wide hamlet..., but will be contained in a 1km sized village. Even it there were a small unit section "exposed" that is more of a technicality... Perhaps the best way to describe the game is "effects" based vs a literal interpretation of what you see on the map. In other words the terrain in the footprint and all surrounding terrain will be analyzed to create an overall effect.

Terrain can greatly impact vision, and once I get to play test more, it will likely limit zone of control (ZOC). The basic concept of ZOC is that when a unit ZOC touches an enemy footprint, an engagement occurs....it becomes far more complex after that, but that is the basic concept.

Visibility will be part of the game as well. But a unit will be able to see beyond a mere footprint. 2 guys with a radio in a tree 1 km away from the main body can give reliable info to the unit...but it goes deeper than that. In short it is abstracted to account for lots of different circumstances.

Stacking can occur to a limited degree, but you are not going to see more than 2 infantry co's occupying the same tile.

Last thing, I am leaning towards fully capable scenario and map editors. I am wanting to make this a mod friendly game...I believe it only helps bring more of a feeling of ownership and loyalty to a game. besides, I am excited to see what ideas people come up with too!

Did I answer everything?

[Christian Knudsen]

Great response, Choppinit, thanks! 

As for answering everything, almost, although while I still have some questions, your answer shows me that you and your team have really thought about this.  Not that I doubted it, of course, but reassuring and invigorating still.

First question is what will the map look like?  A lot of my pondering was started by trying to think through systematic problems that would arise from the maps you have been using throughout the public process.  If the actual maps are going to be designed (in terms of a hex underlay, or whatever) significantly differently, then it would be nice to see that.  I'm sure it's coming, however, and am more than willing to wait.

ZOC is an enormously complicated concept that needs to be handled with some care, as you know.  Terrain, visibility, unit posture and especially quality, the air superiority situation, to name just a few off the top of my head, all have a massive impact.  And I get that it needs to be abstracted, or else you will end up with a rulebook the size of ASL.  But at a 200m scale, it is less easy to abstract than at a 10km hex scale.  I would guess the easiest way to do it might be to assign a ZOC range for each unit based on its type (weapons and mobility systems, organization) and quality, and then modify it by its posture (orders?), surrounding terrain and visibility, time of day, air situation, fatigue, casualty level, etc.

Which leads me to a whole other ball of wax, fog of war and intel gathering, which has the potential to add a whole new layer onto the ZOC issue.  But that can wait for another time.

PS - please excuse my meandering - when I'm excited I have a tendency to problem-solve by verbally throwing potential obstacles at the wall to see what sticks, and then dealing with those.  I know you are way ahead of me.

[choppinlt]

Thanks, and yes there has been lots of thought on all of this.

Maps: we will probably allow for the authentic map to view used, and an augmented map. Clearly there are going to be those areas that straddle tiles, and it will be adjusted to represent the computer map data. I want to try to keep it close to an authentic topo map appearance. Showing the tiles is something I anticipate being on a toggle.

I am sticking with a fairly standard set of different ZOC's based on movement rate and unit size. For instance a battalion will have an 800m ZOC. This will be something that will be analyzed further with playtesting, but that is where I am at right now.

Please, feel free to meander!

[A Canadian Cat]

Yes there will be blocks of territory used, and I am calling them "tiles". Most likely they will be hex shaped but do not have to be reflected on the map as such. For instance, CM is actually played on a hex map!

Please no! say it isn't so.  No hexes.

OK that is clearly a bit strong and the game will need to have something behind the scenes to allow things to work. 

First things first CM does not use hexes.  CM uses 8mx8m squares they call action squares. Squares!  And more importantly these are *not* used for calculating distance between units.

Hexes are from a day long gone.  Humans need hexes so they do not have to measure distances with a ruler on a cardboard game.  Computers do not need hexes to be able to measure.  Your system should be measuring distances between units on the map not between dots at the centre of some construct from a by gone era.  For example if you have a tile which is part forest and part field and there is an AT gun in the treeline that is actually towards the back of the tile that is firing on a platoon of tanks that is driving on a road that crests near the edge of a tile then the distance between the AT gun and the lead tank should be the distance it really is say 850m because there are three full tiles between them plus the AT gun is further away than the tile centre and the lead tank is just barely into the tile. If you do it the old way you would measure a distance of 600m because you measure from the hex center.

As I said before I know you need to have something underneath for the map and the game and if you are forced to use hexes please, please do not let that bleed into the UI.  This is a computer game and as a computer game it does not need to feel like a board game.  I know some people seem to think it is comforting but it feels wrong when you play.  I would argue that the best way to stop hex mania bleeding into the UI is to not use hexes for the underlying model.

Please no hexes.

[choppinlt]

He, he, he.... Well I would beg to differ, hexes are alive and well! Now I would not bet my paycheck on this, BUT I would argue that hexes are exactly what CM uses. Yes they talk about 8x8 squares, but if you offset every-other row by 1/2 the distance of the square side (do the offset horizonally or vertically, but NOT both) you have the exact equivalant of hexes. Draw it some time and see what I am talking about! Furthermore, check out the squares and how they are laid out on a CM map, and I think you see what I am saying...Again I won't bet my paycheck on it, but I think that is how they do it.

Furthermore every game has to have a defined unit of measure for maps, etc. It just becomes a matter of granularity for what you are trying to portray. The finer the unit of measure, the less you can detect what type of map outlay your object is moving on. Are you familiar with calculus theory? I will spare the explanation, but I will just say it applies here. And I am not 100% certain in which geometrical outlay we will create the map, but there are geometrical limitations that must be designed around however it is executed...It will most likely be hexes. If we need finer map granularity, we should be able to do it without changing the game algorithms dramatically.

[A Canadian Cat]

He, he, he.... Well I would beg to differ, hexes are alive and well! Now I would not bet my paycheck on this, BUT I would argue that hexes are exactly what CM uses.

Good thing you did not bet then because that would be a double pay check for me.   All you have to do is look at the map editor in CM to see what the actions squares are.  Steve has confirmed this there are not hexes in CM.  None. Never have been.  They did that specifically because they had no need for a simplified method of distance calculation because the computer does all the measuring between actual units. 

It will most likely be hexes.

Then I will be sad.  As long as we do not have a map grid system that exposes it or see the term bleed into the UI then I guess I will live.

All joking aside please do not make this look like a board game ported over to a computer.  Every time I see hexes in a computer game it just makes me sad.  All of your images so far have made me feel happy so I am hopeful.

[choppinlt]

Wow, I stand corrected! I went back and took a look at the game map and The Cat is correct. I know I have seen this recently, but clearly not CM...

The programming process will determine the best geometrical layout, and I am going to assume hexes... but there is going to be an in depth conversation about it at some point soon. Regardless, the point about choosing the right granularity is heart of the discussion. I don't want to feel like I am playing on a checkerboard, or a hexboard...

I anticipate having the hexes/grid on a toggle, because there are those that have no real issue with it...and some like yourself that do take issue. I chose the term "tile" because of NOT knowing for sure if there are going to be squares or hexes, and for the hexophobes! In terms of the game itself, I am hoping that distances will only be discussed in 200m increments instead of their geometrical shape!

[Asid]

I anticipate having the hexes/grid on a toggle, because there are those that have no real issue with it...and some like yourself that do take issue.

Definitely this should make the feature list.

Regards

[A Canadian Cat]

The programming process will determine the best geometrical layout, and I am going to assume hexes... but there is going to be an in depth conversation about it at some point soon. Regardless, the point about choosing the right granularity is heart of the discussion.

Sure.  That is fair.

I don't want to feel like I am playing on a checkerboard, or a hexboard...

OK to I am not a hex a phobe per-say - although it is true I see no place for them on a computer game because of what you said above.  This should feel immersive and right.  It should not feel like playing a board game or a checkers match.  I totally agree.

I anticipate having the hexes/grid on a toggle, because there are those that have no real issue with it...and some like yourself that do take issue.

And this right here is the kicker.  I agree that some kind of grid should be available but here is my argument for that being an actual grid - immersion.  Commanders today and going back before WW2 use a map that has a grid.  The use a map grid reference to coordinate everything.  There are no hexes in war.  You clearly care about immersion because you are talking about using actual topo maps.  I think this is brilliant actually.  Absolutely brilliant.  Nothing could make a command game more immersive than actual topographical maps.  A grid overlay will reinforce that.  A hex overlay will break it.

[choppinlt]

Asid, you really feel it is that important to mention the grid toggle on a features list? I have no issue with the suggestion, but I'll admit that sentiment surprises me a bit.

Cat, the heart of my concern comes from the geometrical differences between squares and hexes that can become significant when projecting footprints and ZOC. So all I am saying is there is going to be a certain sweet spot we need to hit regarding map creation, and map movement granularity with the resources we have available. I would love to have very fluid and smooth movement, so I think we are on the same page on what we want the game to play like. I just don't want to mislead what may be realistic to expect under the circumstances. My guess is that we will be able to have our cake and eat it too.

You clearly care about immersion because you are talking about using actual topo maps.  I think this is brilliant actually.  Absolutely brilliant.

Thank you, thank you very much (patting myself on the back)  So yes, I understand your concerns. Hopefully I can get some of the programming team on here at some point to discuss some of these things.

[A Canadian Cat]

Cool. 

ZOC is zone of control - correct?  All I will say is the computer can compute the ZOC based on the unit's location and the line of sight that terrain and forests allow.  I would imagine that squares hexes or overlapping circles will not really matter much when the computer needs to plot the ZOC along the top of a ridge line or the edge of a forest.

[choppinlt]

Before I forget to mention this again, this game was originally designed with 1km hexes. It was only within the last several months that we made the decision to create a more refined and fluid movement system. This has had a significant impact on what I have designed, and I have had to re-design a number of things to account for this (e.g. the combat resolution system). I am still trying to iron out things that pop up from time to time as a result of this change, BUT I think a more fluid movement system will be much more appealing. And this conversation is only reinforcing that thought! 

Correct, ZOC=Zone of Control. You are probably correct, it may not matter that much. As a result of what i mentioned above, this will need to be playtested A LOT to make sure we are getting good results. So I have no doubts all of this will change/evolve over the design process.

So this touches on some deeper design concepts, so I will warn you now before going further. Most of this stuff will be "behind the scenes" so you will not have to know this in order to play. It is important to know that all these things are considerations in this sim. The footprint designates the "center of gravity" of a unit's disposition. It shows where the main body is generally located. The footprint combined with the ZOC shows the area a unit can influence based on different factors such as outposts, patrols, and ranged weaponry, and it helps define a Main Line of Resistance. When any footprint encounters any enemy ZOC an engagement occurs. The battle area and all the units involved will be based on different circumstances such as unit movement vectors. Footprints can overlap to a very limited degree, but ZOC's have no limit on overlapping.

There will also the concept of Zone of Action (ZOA). The ZOA concept helps to delineate the area each unit is resposible for covering. So units that are in close proximity to each other will have a smaller area it is responsible for covering (think of an interior battalion of a regiment deployed abreast), and a battalion on an open flank is probably going to have a significant amount more area it is responsible for. This becomes important for a number of reasons, and one is for calling in artlliery on targets of opportunity.

Detection-there are 2 types of detection:operational, and contact. Operational is attained through various intelligence efforts such as aircrew debriefs, AAR analysis and unit reports, listening posts, radio intercepts, etc.
Contact-this occurs as units move in to closer proximity with each other and they will detect more enemy activity. Eventually a basic unit location can be determined, even without direct engagement. So a company can recon ahead without trying to get in combat and will eventually get a good idea what is in front of them.
Visual spotting is a major factor for contact detection. The visual spotting factor can be applied to a unit that has a height advantage anywhere in its ZOA. A height advantage can come from hilltop/ridgeline, church, etc. while considering intervening terrain, and current visibility conditions.

OK, you can't say I didn't warn ya!

[A Canadian Cat]

I think that sounds great.  Over lapping ZOC's - could even result in tactical scenarios with patrols clashing or recon scenarios (with successful recon giving you more intel).  Mind you that sounds like a wish list item