God, the Borg and the art of relative spotting.

[Wartgamer]

If you had a medium sized map of 1000m by 1000m, thats 1 million square meters. Thats 1 million 1^m2 tiles. If you need to describe that with binary words, thats a 3 byte address. So just bare bones we are looking at 3 Megabyte to describe the map. A three byte address could describe a 4000m by 4000m map tops.

But even the simplest map info, elevation, terrain types, roads, buildings, etc all need to be in that map description. The three byte address just tells you where the 1m^2 tiles are.

So if each 1^m2 tile has a state AND a time since each state can change during the turn, we start to really CLOG things up.

Just an example but lets say we need another two bytes to describe the state of the tile and it is updated 1/10th sec (600 times in a minute).

Thats 3 Gigabyte. Thats the maps 'storey' during the turn. You do not want to pass that whole map back and forth during a game in email. Thats something you pump into a hard drive.

And there is much more to crunch and do and database and pass.

Just loading the scenario/map may be a waiting game. Creating a new large 4km by 4km map in an editor may be a 80 megabyte monster that needs to be served over to someone. Scenario design would take a hit.

A better goal is to have a non corruptible map on each end and just flow the state changes and times back and forth.

[ March 06, 2005, 05:59 AM: Message edited by: Wartgamer ]

[Wartgamer]

A mapping method may be to just use overlays. Just like real maps use.

So the base map is just non-dynamic information. Things like area, elevation, water, rocky terrain, rubble, roads are in this file and do not change state during the game. This resides on each computer initially. It does not need to be passed but once and does not change during the game.

Another file would be a building file. It contains info on all types of houses in the game. They do not change position with time but could change state. Collapse, degradation, etc. Each building has a database of its location, state, room layout perhaps. Collapse/degradation may only be updated every second. It does not need to be 1/10th second.

Things like a vehicle position when it is moving describe a database type that needs 1/10th sec update. A vehicle going 20 mph will cover almost a meter in 1/10th sec.

And so on for the entrenchments, vegetation, etc. There could be an obscurant file for smoke, dust, etc.

The basic thought is that we pass files instead of a very large database.

[ March 06, 2005, 06:43 AM: Message edited by: Wartgamer ]

[Andreas]

Originally posted by jim crowley:

Taken to its logical conclusion, though, down to what level would maps be available?

I'm guessing that Platoon HQ would probably be it, so perhaps their use of the LoS tool would include measurement.

The sections and teams would have to estimate ranges outside of what the LoS tool allowed them to see.

This would also add another layer of importance to HQs, which in itself is not a bad thing.

Not sure if platoon commanders in all armies would get have gotten 1:50k maps as a matter of course. Strikes me as unlikely, except when we are talking very specific operations (e.g. Overlord or Market Garden).

They may of course have rough sketch drawings, and may have walked the ground (if defending).

What would be interesting, but horrendously ugly I guess, would be to turn anything outside a friendly units direct LOS into a 1:50k map with terrain features (that may or may not be correct) and top-down view only.

[Michael Emrys]

Originally posted by jim crowley:

Taken to its logical conclusion, though, down to what level would maps be available?

I'm guessing that Platoon HQ would probably be it, so perhaps their use of the LoS tool would include measurement.

The sections and teams would have to estimate ranges outside of what the LoS tool allowed them to see.

This would also add another layer of importance to HQs, which in itself is not a bad thing.

Good catch!

Michael

[Michael Emrys]

Wartgamer:

Interesting analysis and suggested solution.

The use of overlays has been previously discussed in regard to planning and also scenario briefings. Seems to me that it could also be worked into making the Command & Control mechanics work as well. I.e., at the start of a game, the player draws on one of the overlays his intended plan. Orders given then during play that are consonant with this plan incur little or no delay in execution. This models units simply doing what they had been briefed on. Orders that diverge from "the plan" incur delays whose magnitude is related to how far they diverge and how complex they are.

In short, overlays offer solutions to many problems.

Michael

[Thomm]

I do not think that the user will ever get in touch with the 1m x 1m tiles that are mentioned here. These are apparently only for LOS crunching and (maybe) pathfinding.

The map design and storage will most likely be vector-based. For example, a 4-sided field is described as a polygon with 4 vertices. Should it come to that a flood-fill algorithm can fill all 1x1 m2 tiles within the vector-enclosed field with "field-type" tiles. So a minimum of map data has to be stored in the file.

I guess the same is true for the current CM1 engine. I remember an internal tile size of 2x2 meters, such that the 20m tiles are composed of 100 sub-tiles internally.

But, in the 20m tile scheme the 2x2 m2 grid does not have to be composed in its entirety, because all sub-tile operations can be performed within the individual sub-grids of the 20m tiles.

Best regards,

Thomm

[jim crowley]

Originally posted by Andreas:

What would be interesting, but horrendously ugly I guess, would be to turn anything outside a friendly units direct LOS into a 1:50k map with terrain features (that may or may not be correct) and top-down view only.

[John D Salt]

Originally posted by Rollstoy:

I do not think that the user will ever get in touch with the 1m x 1m tiles that are mentioned here. These are apparently only for LOS crunching and (maybe) pathfinding.

I'd just like to remind everyone that regular grids are not the only way of representing terrain, either; you can use triangulated irregular networks (TINs) too.

The good thing about such an approach is that you can use lots of data points in places where the terrain is especially wrinkly and interesting, and economise on them in the relatively featureless bits of the map.

If anyone happens to have a good LOS-finding algorithm for elevation maps based on Delaunay triangulations, please let me know.

All the best,

John.

[Andreas]

Originally posted by jim crowley:

PS Is it as cold in Paris as it is here, Andreas?

Colder, actually. But a bloody marvellous sunset.

In general, making the LOS tool less powerful is probably an easy way to introduce uncertainty, without giving up the squad-command level.

Of course, it will have a number of people howling, those who want it to be more powerful instead. I predict a debate on that issue which will at least be as intense as the PBEM debate, if not more so.

[Joachim]

Representing the map in 1m x1m tiles is less a problem with storage but a problem with LOS calcs.

I dunno the granularity of LOS checks in the current engine - maybe this is already down to 1m. But remember that calculating LOS has to do checks for every unit for every piece of terrain it can see.

More units and a higher granularity means longer CPU time.... which I fear as much as scenario size (30mins of calc time and up to 4.5MB per email in one of my last scens).

Gruß

Joachim

[Wartgamer]

Originally posted by Michael Emrys:

The use of overlays has been previously discussed in regard to planning and also scenario briefings. Seems to me that it could also be worked into making the Command & Control mechanics work as well. I.e., at the start of a game, the player draws on one of the overlays his intended plan. Orders given then during play that are consonant with this plan incur little or no delay in execution. This models units simply doing what they had been briefed on. Orders that diverge from "the plan" incur delays whose magnitude is related to how far they diverge and how complex they are.

In short, overlays offer solutions to many problems.

Michael

See? Now if Overlays were a Bone, then what Michael is suggesting would be a WishBone.

Excellent running with someone else's idea.

[Wartgamer]

Originally posted by Joachim:

Representing the map in 1m x1m tiles is less a problem with storage but a problem with LOS calcs.

I dunno the granularity of LOS checks in the current engine - maybe this is already down to 1m. But remember that calculating LOS has to do checks for every unit for every piece of terrain it can see.

More units and a higher granularity means longer CPU time.... which I fear as much as scenario size (30mins of calc time and up to 4.5MB per email in one of my last scens).

Gruß

Joachim

I don't believe that is true. LOS just checks if one unit can see another unit. It does not crunch the whole map. When you use the LOS tool, its doing an on the fly calc and representing it to you.

And relative spotting, which means that there ought to be a limit as to what each unit's database might hold, means that once a unit is full of spotted info, its done. It does not have to crank out LOS checks for enemy units anymore.

[Caesar]

Originally by Wartgamer

If you had a medium sized map of 1000m by 1000m, thats 1 million square meters. Thats 1 million 1^m2 tiles. If you need to describe that with binary words, thats a 3 byte address. So just bare bones we are looking at 3 Megabyte to describe the map. A three byte address could describe a 4000m by 4000m map tops.

But even the simplest map info, elevation, terrain types, roads, buildings, etc all need to be in that map description. The three byte address just tells you where the 1m^2 tiles are.

So if each 1^m2 tile has a state AND a time since each state can change during the turn, we start to really CLOG things up.

Just an example but lets say we need another two bytes to describe the state of the tile and it is updated 1/10th sec (600 times in a minute).

Thats 3 Gigabyte. Thats the maps 'storey' during the turn. You do not want to pass that whole map back and forth during a game in email. Thats something you pump into a hard drive.

And there is much more to crunch and do and database and pass.

Just loading the scenario/map may be a waiting game. Creating a new large 4km by 4km map in an editor may be a 80 megabyte monster that needs to be served over to someone. Scenario design would take a hit.

A better goal is to have a non corruptible map on each end and just flow the state changes and times back and forth.

This is not correct. Even if you were going to use a tile based system, you would not need a 3 byte address for each tile - you would simply have a contiguous block of memory. All you need to do then is decide how much memory needed to represent the height & terrain. Buildings may not even be part of the map, they may just be a list of 'objects' at location X, Y.

Why on earth would you send the state of each tile ten times a second, why not just send the changes with the times they happened?

You are grossly exagerating how much memory etc is involved. I'd suggest you leave this to Steve/Charles etc as this is way below the level of detail you should be concerning yourself with. Surely you don't think that Charles is so incompetant that he wouldn't have figured out this long ago.

[Wartgamer]

Any unit in the game needs a location no? Perhaps even 1:1 soldiers might need a location BTW?

How do you describe that soldiers location? He needs something to relate him to the map?

How do you use a contiguous block of memory to overlay him onto the map? The map needs some address lookup I hope.

The map tiles are going to have states. So how do you 'just' send changes (which I and other people have already suggested in the PBEM thread and I even mention it in the post above if you read it) when you need to have a map address to apply those states to?

[Wartgamer]

Lets say you wanted to just use a X Y coordinate to describe a soldiers location. Its a 4 km by 4 km map. Whats the resolution? 1/4 meter?

So I would still need a 2^14 to cover that for both the X and another for the Y coordinate. Know how many bytes that is?

But now you still need to relate that X Y to some 1 m^2 tile. Why bother, each tile will have its own address so that its state can be linked to that address.

[Wartgamer]

You are grossly exagerating how much memory etc is involved. I'd suggest you leave this to Steve/Charles etc as this is way below the level of detail you should be concerning yourself with. Surely you don't think that Charles is so incompetant that he wouldn't have figured out this long ago.

--------------------

Artificial intelligence is no match for natural stupidity

Steve has already said they may back away from the 1m^2 resoltion.

[Battlefront.com]

Geeze guys... what a silly conversation Leave the coding to Charles since he is the guy who will be doing the coding. He's well aware of these things since he's made games before and has already coded the CMx2 graphics engine. So for the most part it's already finished.

As for the resolution... remember that in CMx1 everything was measurable down to the partial meter. That's true for LOS checks, unit locations, etc. In that way CMx2 won't be any worse than CMx1 in some ways. What is different in CMx2 is that the terrain itself can be different every 1m instead of ever 20m. This has a profound and fundamental effect on the maps themselves, like being able to have more flexibility in placing buildings, being able to put down tiny objects like a telephone pole, etc.

The 1x1m system means, in theory, that there is now the need for 20x more map data to be stored because there are in theory 20x more tiles. In reality this won't be the case since not every tile will be unique terrain. For example, a flat spot for a 20x20m house would be treated as one type of terrain (house floor) in 20 pieces. Efficiency is gained from this, though of course it is not a 20 fold reduction. I'm sure Charles has other tricks he can use.

As for storage of the map data... the map is read into memory at the beginning of the turn. Changes made to the terrain during the turn, such as a new shell crater, are written to correct spots in memory. At the end of the turn the map in memory is written out to a file to be used for the next turn. In this way there is never more than one full copy of the map data on disk and never more than one in RAM per turn. The map data will grow over time, but only proportional to the involvement of new map elements (such as a crater hit). The data growth is also minimal in total since the additional data required to describe even massive alterations isn't all that great.

The game engine was also written to not care about the terrain resolution. With the change of one variable Charles could make the underlying tiles 100m x 100m or .0000025m x . 0000025m. The game system is looking at the partial meter and therefore can care less We're starting out with 1m x 1m and see how that works, but according to Charles he is pretty sure we'll be sticking to 1x1.

Steve

[Wartgamer]

Another interesting aspect of relative spotting is how the individual spotter's databse is going to be sized/filled.

A neat thing is that there must be an upperboundary to it. Even a large unit of 12 guys can only sense so many units with that much detail. Something like a small mortar crew in a trench might actually be modeling one guy 'filling' the database. The rest of the guys are under cover.

Each unit in the game must have some form of an ID number. Lets say that the game is a comapny based game and the upper boundary is 128 units. Even if every squad split up and all weapons detached as much as possible, they would still not number 128. Fine, so each side gets 128. But what about spooks? They come from nowhere. How do you fill up a spotter's database with spooks?

Think about the spotter's database as it changes with time. It will be updated according to some clock tick. 1/10th of a sec may be too quick but every sec might be too slow. What will be in the database once an enemy unit is spotted? The 'ID' number of that enemy unit? And the actual 'sensed' type of unit? Is it going to be a map address and a spotting type? I see a spook at coord XXX, YYY?

[Wartgamer]

The 1x1m system means, in theory, that there is now the need for 20x more map data to be stored because there are in theory 20x more tiles.

huh? you mean 400? 20m x 20m =400m^2?

[dalem]

Originally posted by Battlefront.com:

We're starting out with 1m x 1m and see how that works, but according to Charles he is pretty sure we'll be sticking to 1x1.

Steve

I'm pretty sure I want to have Charles' jarbrain-baby.

Question:

Will the map editor have access to the full resolution or will we use bigger chunks that are resolved at 1m? i.e. will I be drawing a "streambed" by drawing a winding Rough depression 1m deep myself, or will I be selecting a 10m x 10m "tile" piece that has a stream modeled at 1m deep on it?

-dale

[aka_tom_w]

"Will the map editor have access to the full resolution or will we use bigger chunks that are resolved at 1m? i.e. will I be drawing a "streambed" by drawing a winding Rough depression 1m deep myself, or will I be selecting a 10m x 10m "tile" piece that has a stream modeled at 1m deep on it?"

Maybe look at SimCity or Bryce

there are NO tiles

forget tiles

The thing could be a vector based wire frame map.

No tiles

but I am only guessing

-tom w

[Battlefront.com]

huh? you mean 400? 20m x 20m =400m^2?

Darnit... I'm always doing that! Yes, and that is also an illustration why I don't code. Tried it, thought it was OK, but hated the math aspect. I found that studying History was a lot easier on my noodle

Dale, in each 1x1 spot there can be a unique peice of terrain. Therefore, in theory, you can have a 1m wide stream. We might make certain tools, like a road tool, a set size (or sizes), but in general it's going to be a free-for-all when it comes to basic terrain. Stuff like houses, boulders, bunkers, etc. will be a lot less flexible for what should be obvious reasons (i.e. we have to make 3D models).

Steve

[aka_tom_w]

what do you mean?

"Stuff like houses, boulders, bunkers, etc. will bea lot less flexible for what should be obvious reasons (i.e. we have to make 3D models)."

what do you mean by the "less flexible" part

less flexible than what?

curious?

thanks

-tom w

[ March 06, 2005, 08:23 PM: Message edited by: aka_tom_w ]

[dalem]

Thanks Steve, that's what I'm hoping for. Hel-LO accurate bocage. For instance.

-dale

[Battlefront.com]

Less flexible in the sense that you can "paint" some features to be exactly the shape you want them to be, others are fixed in size. In all cases you'll be able to put things down pretty much where you want them to be.

For example, in CMx1 you would have a 20x20 tile with a house, in a fixed orientation, sitting on it and nothing else. In CMx2 you can choose to put the house anywhere on the map you like in any direction. The only restrictions are sensible ones, like you can't put a house hanging off a cliff or tipped at a 45deg angle to the ground. And unlike CMx1 the terrain immediately around it is fair game to any other terrain feature, such as trees, roads, hedges, fences, whatever you like. BUT... houses will come in a variety of sizes and shapes which you, the end user, will have no ability to manipulate.

And before I continue... the terrain itself doesn't have a concept of "tiles" like the CMx1 system did. However, there is an underlying mesh which is made up of 1m x 1m pieces which, for lack of a better term, I am calling "tiles". Not quite the same the term used to describe terrain in CMx1, but if it makes everything easier to explain you can think of them that way.

Steve