Spring RTS Engine

Whenever i get to see the alps, i am thinking on: spring should have this!
The one thing that strikes me there is, that all of springs mountainous maps that i know of, have really small mountains. For example, using S44 as reference, it should take hours for an infantry unit to run over a mountain, but with the biggest mountians i know, it still takes seconds, or at best one or two minutes.
So the question is.. would there be any practical problems with a really big map (eg 64x64) that contains only one big mountain, or part of it?
i am thinking on too heavy height changes inside a map, or problems with the camera, or.. is there an upper limit for the heightmap values other then MAX_FLOAT?

in case it was possible, i am thinking on having some small flat stripes on two sides of the mountain, where you could build bases, and a few .. like smll valleys into the mountain, with small dirt roads, so you could get ground transports there, and most of the rest would be steep terrain, hardly or not at all accessible by vehicules, and infantry/kbots beeing slow there. lots of small and bigger valleys and stuff.

60x60 is the logical limit atm (rendering and mapconv taken into account). Tbh even 32x32 is really tough to pull off due to rendering time.

Nb4sm3

hoijui wrote:(eg 64x64)

Last I heard the max capable was 32x32 square.

ok, thanks. this does not matter much to me, smaller map would just mean a smaller part of the mountain. no other concerns?

Quite simply, gameplay, at a guess. Big maps are hard to make, hard to play, have poor gameplay, etc. As for localized parts of mountains: How do you know that DSD isnt on side of a mountain, and the stepped cliffs just keep going? If you focused on a localized region, its going to look flat no matter how high it is.

The only alternative would be a sort of 'concept map' where the whole thing was sloped to one side. It might be interesting as an experiment, but i sort of expect it to not play that great.

yeah, i expect the gameplay to be a problem, or at least be very different, basically vechs woulc only be used as transports, and then you'd have ot use kbots or even all terrain bots in *A mods, or infantry in S44, for example. It would also make air the ultimate thing, as bots and infantry would still be slow, but you can also disable air, in case you want.
The main thing i want to see is, a tank or unit beeing veery small compared to the mountian, eg have 1/1000 the heihgt of the full mountain. if that is not possible, then only show a part of the mountain, so it would still be true, if you extrapolated the mountain further out of the map. DSD is basicaly a flat map to what i want, biggest height difference is like 40m till 100m or so, if you take S44 units as a reference. i see it as a hilly map with steep cliffs. of course you could think of there beeing a mountain above.. but it does really not feel so, and no other map i know of does feel so.

some impressions:


i dont care if it is a valley, or a mountain top, or only one side of a mountain, or an edge.. whatever. it just should have the feel of a really big mountains, and units beeing very small, comparatively.

info about making heightmaps out of google earth:

http://www.tt-forums.net/viewtopic.php?f=29&t=27052

run it through SME or something and see what comes out. i'm not sure if it supports the scale you want (one heightmap square == 8 elmos == 2? 4? 5? meters)

Bad baczek bad!

Satellite maps look and play like shit. The scale is just too off. We dont need any more of them.

Many people new to mapping think they have this golden idea of making an uber map off a satellite image, because hey, it looks easy and its 'real'. Wrong. Its been done before and proven to be a waste of time.

I want to see mountains, Gandalf!

maps need to have flat surfaces to build on

Maps that are inspired by real terrain are fine, they can have a look and feel of real world locations while conforming to the limitations of the RTS genre in general and Springs various games, mods and packages in particular.

Beherith wrote:Many people new to mapping think they have this golden idea of making an uber map off a satellite image, because hey, it looks easy and its 'real'. Wrong. Its been done before and proven to be a waste of time.

Correct, I spent ages trying to get the heightmap to work in my EU1 map. Eventually I flattened out most of the height that was already there, save the few mountain ranges. I botched the height, texture and metalmap all in a big mash. I must admit though there were some fun epic 2v2v2 and 3v3v3 games on it, even if they were imbalanced. But I quit my silly attempts at mapping after that

Yep, others have explained it. Plus, 16-bit height levels are tricky to get working. Using 8-bit height channels, you have to be careful to avoid terracing, and the greater magnitude between the lowest and highest point on the map means it's harder to avoid terracing.

Plus, steep hills suck in BA, which is the only game for Spring.

Das Bruce wrote:

hoijui wrote:(eg 64x64)

Last I heard the max capable was 32x32 square.

nope, epic.smf for instance is 40*40
the limit I know of, is 64*64 for smf, but in order to make such map, you'd need plenty of memory

Or just make the units smaller like in s44 and NOTA.

Or like EE or Blood and Steel. But people generally haven't responded positively to the more realistic scale.

Hmm, I just saw there are no 64*64 maps, that sounds like a challenge to me!

Picasso made a few 64x64 maps. Or at least one 16x64 map.

The largest (by area) is 40*40.
There are quite a few 32*32 and 16*64 maps though.

Block wars. 64x64 SM3.

luckywaldo7 wrote:Or like EE or Blood and Steel. But people generally haven't responded positively to the more realistic scale.

One reason would be that the healthbars are always too big, spring maps look like ass when you zoom in that far, unit lighting is never bright enough so that you can actually distinguish them from one another.

PURE does epic scaling very well without using ubersmall units.

Edit: Peet, we're talking about smf here, sm3 has no point being discussed because while we can do nearly anything with it, it r broked.