Matrix Games Forums

And another thing...

Editable terrain would be really, really neat. Aside from being able to separate movement and defense modifiers, it would be good to be able to decide whether or not a given type of terrain can or cannot block supply lines.

...Yes, Curtis. I'm sure it's on the wish list.

ORIGINAL: ColinWright

And another thing...

Editable terrain would be really, really neat. Aside from being able to separate movement and defense modifiers, it would be good to be able to decide whether or not a given type of terrain can or cannot block supply lines.

...Yes, Curtis. I'm sure it's on the wish list.

..me too..

..some us do want to turn open/cropland into marsh every monsoon period..

ORIGINAL: a white rabbit

..me too..

..some us do want to turn open/cropland into marsh every monsoon period..

That also -- but it'd be more difficult to program than what I'm looking for. I just want to be able to program things like...

Woods that happen to have plenty of roads through them. One still should have the defensive bonus, but why a movement penalty?

Supply in cases like Operation Exporter. The Commonwealth forces, at least, had nil ability to supply troops in the hills of the Lebanon once they were off-road. The Australians were begging for mules -- and couldn't get them.

In larger-scale scenarios, I think of the terrain in places like Nevada. Very high, rugged ranges of mountains, wooded at the upper elevations -- all the defensive virtues one could ask for. But, generally, also dead-flat valleys of sage brush and grass. You could probably drive across them at 40 mph if you didn't mind a sore butt.

Jungle...it would be nice to be able to decide whether or not jungle blocked supply traces -- without tripling the movement cost by putting in badlands.

Polder. Sort of uber-cropland. It won't slow foot movement at all, but it'll stop mechanized movement cold.

Weakened bocage. Norm seems to have been very, very impressed by Norman bocage. First, I doubt that it's a major ordeal transiting the Norman countryside. I'd want to eliminate or greatly lessen the movement penalty. Second, hedges and stone walls can be found in lots of places. Leaving aside a debate about Normandy in particular, I can think of lots of places I'd want some defensive advantages -- but not the crushing ones the standard 'bocage' offers.

And no doubt other cases. Point is, editable terrain doesn't seem to me to like it would be all that hard to do, and the current values could be left as the default.

And while I'm thinking about it:

The hex conversion penalty needs to be adjustable. It's positively absurd in a lot of situations. Like what's 'enemy' desert and what's 'friendly' desert?

[Deleted by Admins]

My wishlist submission:
 
- increase the 2000-unit per side limit (doubling it would be a good start)
- ability to have a unit shift from one formation to another in-game
 

ORIGINAL: briantopp

My wishlist submission:

- increase the 2000-unit per side limit (doubling it would be a good start)
- ability to have a unit shift from one formation to another in-game

Actually, I'd rather have an increased map size.

We've got more events, which took some pressure off, and I have my reservations about the merits of what I would call the 'unplayable beast' scenarios -- but a bigger map would be useful. Some potential scenarios involve relatively small combats at widely scattered locations.

I had an idea that I included in the latest wishlist update to make further increases in editor parameters dynamic. So, instead of increasing array sizes, the array sizes would stay the same. But, if a designer wished to exceed any of them, the increase would be alotted dynamically (as a linked-list). That way, existing scenarios wouldn't have to carry the overhead of larger arrays, but the potential expansion ability would be almost unlimited.

The down-side would be that there might be some performance issues, since linked-lists take longer to access elements than arrays, but that cost would only be applied to those designs that went beyond the array limits. There would also be a risk that some really huge design would crash on some or most machines, but, again, that would be a cost that only the designer of such scenarios would have to be concerned with.

I haven't run this past Ralph, yet. He may say I'm nuts or that it's too difficult.

ORIGINAL: Curtis Lemay


I haven't run this past Ralph, yet. He may say I'm nuts...

Yeah. But the idea itself might be sound.

ORIGINAL: ColinWright

ORIGINAL: Curtis Lemay


I haven't run this past Ralph, yet. He may say I'm nuts...

Yeah. But the idea itself might be sound.

Yes, the idea's sound, although I can dynically allocate the array and avoid any performance hit. The big issues are that the UI isn't designed for large numbers of anything, and loading/saving would pretty much have to be all in XML for that to work.

Ralph

ORIGINAL: ralphtrick
Yes, the idea's sound, although I can dynically allocate the array and avoid any performance hit. The big issues are that the UI isn't designed for large numbers of anything, and loading/saving would pretty much have to be all in XML for that to work.

Thanks, Ralph. That's more positive than I expected. I don't see a problem if use of such expansion requires editing in XML. Isn't that just the facility that the new version of ODD is intended to provide?

Since "nuts" was mentioned a few posts above, I was reminded of the following thought that popped up while skimming the latest version of the wish list: With 100 km hexes and larger map sizes on the wish list, mapping of the entire globe would be within reach (the circumference would be approx. 400 hexes @ 100 km/hex). Not that I am eager to dive into it, or even find it very useful to do, there is always someone out there... [:)]. Now, for this to make sense, I guess we would need a spheroidal hex grid, as an alternative to the usual plane one. I am not suggesting that the developing affort should go in this direction, but it sure sounds like a challenge to get movement, supply trace, etc. to work seamlessly over the seam, so to speak...

ORIGINAL: MarGol

Since "nuts" was mentioned a few posts above, I was reminded of the following thought that popped up while skimming the latest version of the wish list: With 100 km hexes and larger map sizes on the wish list, mapping of the entire globe would be within reach (the circumference would be approx. 400 hexes @ 100 km/hex). Not that I am eager to dive into it, or even find it very useful to do, there is always someone out there... [:)]. Now, for this to make sense, I guess we would need a spheroidal hex grid, as an alternative to the usual plane one. I am not suggesting that the developing affort should go in this direction, but it sure sounds like a challenge to get movement, supply trace, etc. to work seamlessly over the seam, so to speak...

If nothing else, it would at least mark a natural limit.

...I suppose the aliens on the Moon can always be represented in some sort of off-map staging area.

..joining the edges is the problem, unless you use a North Pole centered projection, then your major headache is either sea-distances correct or land, but not both..

..oh and as a map-maker working upside down gets quite spacey, i dread to think how the playrs would feel..

ORIGINAL: ColinWright

ORIGINAL: MarGol

Since "nuts" was mentioned a few posts above, I was reminded of the following thought that popped up while skimming the latest version of the wish list: With 100 km hexes and larger map sizes on the wish list, mapping of the entire globe would be within reach (the circumference would be approx. 400 hexes @ 100 km/hex). Not that I am eager to dive into it, or even find it very useful to do, there is always someone out there... [:)]. Now, for this to make sense, I guess we would need a spheroidal hex grid, as an alternative to the usual plane one. I am not suggesting that the developing affort should go in this direction, but it sure sounds like a challenge to get movement, supply trace, etc. to work seamlessly over the seam, so to speak...

If nothing else, it would at least mark a natural limit.

...I suppose the aliens on the Moon can always be represented in some sort of off-map staging area.

..not really, no way to get them eqidistant, unless you stick them on the North Pole, anyway at anything like a reasonable scale the world takes up most of the map

ORIGINAL: a white rabbit

ORIGINAL: ColinWright

ORIGINAL: MarGol

Since "nuts" was mentioned a few posts above, I was reminded of the following thought that popped up while skimming the latest version of the wish list: With 100 km hexes and larger map sizes on the wish list, mapping of the entire globe would be within reach (the circumference would be approx. 400 hexes @ 100 km/hex). Not that I am eager to dive into it, or even find it very useful to do, there is always someone out there... [:)]. Now, for this to make sense, I guess we would need a spheroidal hex grid, as an alternative to the usual plane one. I am not suggesting that the developing affort should go in this direction, but it sure sounds like a challenge to get movement, supply trace, etc. to work seamlessly over the seam, so to speak...

If nothing else, it would at least mark a natural limit.

...I suppose the aliens on the Moon can always be represented in some sort of off-map staging area.

..not really, no way to get them eqidistant, unless you stick them on the North Pole, anyway at anything like a reasonable scale the world takes up most of the map

Distant hexes? +3840...if we plop the 'alien moon base' in the middle of something remote in should be reasonably equitable. I'd go for the North Pole. That way the aliens ravage Canada first whilst mankind gathers his forces for the great counterattack.

ORIGINAL: a white rabbit

..joining the edges is the problem, unless you use a North Pole centered projection, then your major headache is either sea-distances correct or land, but not both..

..oh and as a map-maker working upside down gets quite spacey, i dread to think how the playrs would feel..

I was merely thinking of an alternative to plane maps to be implemented in the game engine itself. By having a spheroid grid mapping the earth's surface, map projection will not be an issue. The hard bit is setting up the hex relations (which hexes are considered adjacent to a particular hex). This is non-trivial, but is done on a regular basis when generating grids e.g. for fluid-dynamical computations (I believe triangular grids are often used, which could be useful here since hex centres form a grid of equilateral triangles).

For example, if we arbitrarily choose the North Pole to be hex (0,0), it would be surrounded by hexes (0,1) through (5,1), and so on going southwards. Down at the equator, hex (0,100) would be adjacent to (399,100) or so @ 100 km/hex. Finally, the South Pole would be hex (0,200) or something, surrounded by (0,199) through (5,199). Scrolling around in your map window would be like Google Earth, but since you have such a small patch of the map visible, the curvature would not be a big issue (at the normal zoom level for game play, my [admittedly low] screen resolution usually lets me see 20 hexes width at a time, which would be 2000 km @ 100 km/hex). Hence, the map window could probably look and feel as usual (however, I guess the minimap would be something else!).

Off-map staging areas will be difficult, since there are no map edges. I suppose we would have to do without LGM[:D]

What would actually be involved in increasing the maximum map size to -- say -- 600x600?

"...More than 70 people have been killed by two bombs in Baghdad, attached to two mentally disabled women and detonated remotely, says a security official..." (Colin Wright)

Hey, Colin!

My mother-in-law has 'on-set' Dementia........

Can I have your street address? I wonder if this really works, eh? I could cure two problems at once! LOL!

[:D]

(just kidding, Colin, You know we all love yah!)

*shakes head*
That's so wrong on so many levels....[:-]
 
 
and yet still funny....[:D]