Spring RTS Engine

In the next major version (0.6)we plan to introduce a new map format. It will look and work much like the current one and be creatable with the mapconv utility in the same way, so keep the source pictures for your maps.

Improvements planned is

-New header format that will make adding new stuff easier and thus avoid more version changes.
-Possibility to read texture tiles from other files.
-Save height as shortints instead of floats to cut heightmap size in half.
-Possibilty to create a hardness map for varying map hardness across the map

Any comments/ideas ?

That you work with buggi in the dev process, so when 0.6 is released we ahve th necessary map tools to convert our existing maps to the new format.

Sounds like a good idea to me - presumably you're talking about how much terrain deforms on impact?

How about this idea:
instead of just having a "hardness" grid, which gives the hardness of each terrain point, how about having terrain classes such as rock, sand, mud, marsh, grassland etc.

The .sm2 map data would just indicate the terrain class number of every point on the map. The .smd file would then map terrain class onto terrain type* e.g. you could do something like this:
Then the engine would know how hard each of the terrain types was, since it knows what hardnesses to use for each terrain type. This should hopefully be easy for the map maker - who could still define "custom" hardnesses if they wanted. In future you could even go beyond just a simple "hardness" model...

What I'm thinking is we could ultimately (not right away!) have maps with little or no texture info in them, because the whole map is covered in terrain types, which (like grass at the moment), the engine knows how to draw real time. One problem with textures is that they don't behave in a very realistic way when they get craters blasted in them, but you could code up the way craters get formed for each terrain type, so that e.g. if you get craters in grass you get to see soil underneath, but if you get craters in sand you just get more sand... and when you get craters in rock, you get a dent in the rock and big pile of rubble round it, but the terrain doesn't just deform in such a simple way.

Obviously most of this is future expandability, but I figured if we start from a "terrain class" point of view, we can go there if we want, but don't have to.

On final point. I'd be tempted to put the "hardness" data, however it is coded, in with the rest of the data for each point, so that you have a height/hardness tuple, in good Object Oriented style. However, this will of course compress very badly. Far better to put all the hardness data in a section on its own. That way, large sections of map which have the same hardness will be compressed very efficiently. For maps with the same hardness everywhere (e.g. metal maps) the hardness map should then compress down to just a few bytes.

I hope these thoughts a useful.

Regards

Munch

* The idea of not coding "grass" or "sand" directly into the .sm2, but putting it instead into the .smd file is that you can specify a low number of bits in the main file e.g. 4, to allow each map to have a variety of terrain, without limiting the future expandability of the number of terrain types map makers can use.

But please SJ allow us to define and add arbitrary features to maps like we could in OTA.

Then all I'd say was left would be a GAIA player but that isnt exactly high priority

It's an honor to be mentioned ^_^;;

I'm curious, are you changing the tile size? I would imagine not as it would hinder the cross-use of other files.

I'd like to be in the loop, but it's up to you.

I know so much about the file format now it's crazy...

My main email is nhundley@k2is.net

-Buggi

Not to mention really do a number on our AI plans.

Hm defining hardbess via terrain types sounds like a good idea. I will add a second parameter to the terrain type directy, HaveGrass and remove the current grass as features.

Guess it would look more like this in the smd Arbitary features are already supported, they just have to be in the same format as wreckages.

Only one size of tiles will be supported to begin with although there will be values that can be changed later. The map creator will just have to make sure that the tile files used have the same resolution.

I guess everyone posting in this thread will be in the loop, I will tell you when I have something to check into the cvs.

Do please add a watermap, like a height map only that it defines where water is and on what level according to brightness.

A water map??!?! That makes no sence! Water is a plane... theyd have to redo a lot of the engin... basicly make a whole new landscape that intersected to be the water... and it would look funny going up hills and stuff...

Water should be on one level for now.

In saying this... Insted of giveing a min and max height, it would would be nice to just give the max, take the min as zero and then set water height by a num between 0 and 255, for the shades of grey on the height map. It would save a whole lot of guessing!!

aGorm

wha?! How on earth do I place them in maps then?!

As for the water map, it'd be useful to ahve pools or lakes above ground level however they'd have to be used in conjunction with hardness maps so that aGorms predictions dont come true. As for redoing a laoda th engine, I think that they simply add to the engine extra water planes for the associated points and the transparent water bit. Albeit it might give a resource hit........

SJ wrote:-Possibility to read texture tiles from other files.

YAY!

Now we can just make a few high quality tile packages, distribute them, and have future maps reference them so people don't have to download all of that redundant data again! Of course, there could still be unique style maps, but the fact that we can now have tile packages for moon maps, mars maps, metal maps, etc is great :D

SJ - Did I comprehend that part about tiles correctly? Are there going to be tilesets that can be used for several maps?

map tiles do NOT EQUAL tilesets.

A tile on the map is a 32pixel x 32pixel "bitmap". That's it. No orientation, no nothing. The conversion, when compressing and processing tiles looks at like borders, hue, satuation and brightness, if all are within threshholdes (as defined by compression level) the tile is reused, if no, a new tile is spawned.

Now, TA "tiles" were huge if I recall. Some were 512x512 for urban areas and such to define a block, or other oddity. The system is completely different in Spring.

Although the idea of a hardness map is intreging!!

Halfing the size of the heightmap array is a great start

I sense a Sharp Map Beta4 in my future :-D

-Buggi

I was thinking more along the lines of texture packages like you see with most modern games... UT2004, Half life 2, etc...

So instead of downloading the same files with every map, we get them one time, and cut our down loads into really small pieces? Like tilesets in OTA?

You shuld be able to set a level for 100% hardness (indestructible) to stop water forming in craters (moon maps etc).

LOL!!

We're getting illustrated descriptions now :D

wohoo!!

Although I'd like to be able to go below the waterline, create your own bay.

-Buggi

I like to draw
that shuld be for the mapmaker to decide, If he doenst whant any water on his map, (no water on the moon!) he shuld be able to set something like this.

Can you give support for two textures? As in, the color map + a color map at about 1/4 the resolution in each dimension? It would REALLY add to the deformations. When you shoot grass, it should become brown, like dirt. Sand should become slightly darker and increase in saturation (if it's near the water, because wet sand looks different to dry.)
Etc.

Lord -_-

Raise your e-hand if you want to exponentially increase filesize...

Anyone?

Half the people are struggling with maps as they are, lag, sync, download size... I don't think the point is to make matters worse.

-Buggi