Map and mod interoperability standardization

[Caydr]

Hello, I would like to discuss the ongoing issue of maps which are made without a baseline of "normal". Back with TA, we used to have a baseline, OTA maps. Mods were balanced around OTA maps, and custom maps were also balanced this way. A "high metal map" was a high metal map for every mod.

Because we have many new players, we also have many new mappers and even some new modders. Many of these individuals never played TA, so they are not familiar with the same baseline that many of us use.

The result is suboptimal gameplay. Maps with lots of metal or crazy tide values have become the norm - and while there is a place for these types of maps, they should not be considered "normal".

Furthermore, as the Spring engine has more content developed for it, maps will inevitably become mod-specific, fracturing the community. Maps made for S44 for instance, may not work for PURE or Gundam.

I would like to discuss with the mod makers what should be "normal" values. Maximum height, maximum depth, and everything in-between. This includes slope angles for different classes of unit. While not every mod will have "kbots" and "tanks", many will have "infantry" and "vehicles", or some variation of this.

It is necessary to define what "impassible" really means to each type of unit, or else maps can't be designed around these values.

An example proposal would be something like this:

Code: Select all

//Slope Value:  10  ::  20  ::  30  ::  40  ::  50  ::  56
// Real Angle:  15  ::  30  ::  45  ::  60  ::  75  ::  84
//                     TANK    KBOT     AMPH  ALL-T    SPID(?)

This provides for areas which are passable by all units, and areas which are passable by no units whatsoever. Bear in mind that if too many slope categories are defined, it will become increasingly difficult to design compatible maps.

Also important is water depth. How deep should "regular" units be able to cross? How deep must water be in order for ships to pass through it? What about different classes of ship, should scout ships and battleships require different amounts of depth? And submarines?

10 minimum depth for boats, 25 minimum depth for submarines is something I've been thinking about. This allows for areas to be made (with some difficulty) which can be crossed by both water and land units, but not submarines.

Maximum depth is another issue. There are surely situations where a map maker might want it to be altogether impossible for even amphibious units to cross water. How deep should amphibious units be able to go? For the purposes of my experimentation, I've found that 500 seems to be a reasonable value on the handful of maps I've tried. It's not hard to make areas that are less than 500 deep.

You may notice in my example above that I've given amphibious units greater slope tolerance. This gives ampibious units, which are typically more expensive, a good reason to be built even on maps which have no water. It also makes it easier for mappers to make shorelines that units can climb.

The values I've defined above are similar to OTA standards, and they seem to work on the handful of maps I've tried.

Earlier I mentioned maximum height - and why should this be an issue? Because there are only 256 shades we can use to represent height, AFAIK. Even if there are more, finding a monitor that can display them will be difficult for the next few years, let alone eyes that can discern them. If we say that there's no limit on height, you could conceivably have a situation where you need to have water that's 500 deep, and a mountain that is also tall enough to block heavy artillery fire, or (if this is possible) a mountain which prevents planes from flying across it. This means that there will be a total of 1000 height, and every shade of luminance will create a 4 elmo difference in height. It will be extremely difficult to create interesting-looking terrain that doesn't also block or slow movement of some unit classes unintentionally.

Speed modifiers for water depth and slope are another issue, but thankfully I think it's not something mappers will need to worry about too much as long as modders use some caution when setting high values.

Crush strength may be another issue, but not such a serious one since using crazy values tends to screw up things beyond maps. But it might be worth discussing what a normal range of values would be, to make fleas not crush a massive tree or something.

Resources are another issue, and probably a topic for another thread since this one might get a bit far off-topic if too many things are discussed at once.

I had wanted to have this conversation on Google Wave since it has built-in support for these very types of conversation, but not everyone is interested in trying it.

[zwzsg]

The OTA standard were thrown out the window since day one, as Spring gave a different meaning to maxslope than TA.

I foresee people disagreeing about your 256 shades of grey for heighmap. Not that it is relevant anyway.

Otherwise, it would have been a much needed thread, but I'm afraid it's coming a little late now.

[AF]

16 bit raw heightmaps?

The problem with these discussions in the past was that they were framed within AA, and breaking AA was heresy, yet working within those constraints meant problems for other games, as well as horribly flat maps, even though the benefits meant hugely more aesthetically appealing maps.

[smoth]

Furthermore, as the Spring engine has more content developed for it, maps will inevitably become mod-specific, fracturing the community. Maps made for S44 for instance, may not work for PURE or Gundam.

Gundam maps have gundam specific features that are only loaded if you play gundam. I am going to have a map feature over ride in the future that will take s44 maps and gundam-ify them .

I would like to discuss with the mod makers what should be "normal" values. Maximum height, maximum depth, and everything in-between.

Gundam utilizes extremes that would make ta units cry.

It is necessary to define what "impassible" really means to each type of unit, or else maps can't be designed around these values.

next version of gundam has jumpjets on almost all units.

Earlier I mentioned maximum height - and why should this be an issue? Because there are only 256 shades we can use to represent height, AFAIK.

as this is your lynchpin I suggest rewriting the argument. I use 16 bit heightfields.

[Tribulex]

oh so 16 bit does work? awesome. Anything higher?

[smoth]

oh so 16 bit does work? awesome. Anything higher?

I am going to assume you are this daft. 16 bit does not mean higher, it means precision as it is the range of numbers available to the greyscale value in the heightfield. Please use google.

[Caydr]

I tried using 16-bit, but at the time Photoshop didn't support using interesting filters and such that way, and besides which virtually everyone here is editing these maps on 6-bit displays anyway. At least, that's my understanding - most everyone here is a gamer, so the bad lag of VA is out, but few of us are rich enough to afford a decent IPS display. I'm already saving up for the first 20+" OLED for under $1500.

Also I think I had some problems properly outputting a 16-bit image and having Mapconv use it properly. I compared 8-bit output to 8-bit converted to 16-bit with a mild gaussian blur, and the result looked identical.

In any case, the limitations of 8 bit or 16 bit aren't really the most serious thing, what I'm more concerned about are terrain slopes. I thought something I might do, if a standard was agreed upon, would be to make a mini-mod which just has a few hacky units that simply have different slope tolerance, it would be useful to modders checking their maps prior to release.

Ages ago I changed AA units' slope tolerance slightly to the values BA uses today and I unintentionally broke an asston of maps. That's all history now, but I would very much prefer to avoid doing that again.

If we can agree on standards for slope tolerance, maps would be much more likely to work across a larger variety of mods. What we have now as standards are just values I came up with because they seemed better than the horrible values that were used previously.

There wasn't really any thought given at the time to the future repercussions, and I think this would be a great time to come to a community consensus about what some better standards would be going forward.

Also, with the untold marvels of Lua on our side, I bet it would be possible to have a map compatibility detector in the game launcher. Maps made to take advantage of a new standard that emerged could have their identifier files contain a "newstandard=1" line which would automatically tell the lobby to switch to an alternate moveinfo file. Thus no compatibility would be broken, but starting from the time mods adopt the new standard, maps could be designed better - and probably more easily.

The only problem would be trying to play an old mod on a new map, but that will be an issue for all of a week or so.

[Caydr]

The benefits to non-TA mods should be clear. If a unified standard could be agreed on, it would be one less barrier to people wanting to try other mods.

My understanding is that, if need be, it is possible for a mod to overrule a map's feature types. So, things like geothermal vents in TA mods could transform into... I don't know, oil wells or nano factories or whatever resource name you want for your mod. Same goes for trees.

A postapocolyptic-themed mod could have all the trees be burnt to a crisp and the geothermal vents be replaced with "auto factories" or something. And since terrain is standardized, your "supply crawlers" or whatever would be able to climb all the hills they're supposed to.

All of this is possible NOW, but the numbers are based on arbitrary values that I came up with, having no regard to the long-term impact they would have.

[Argh]

Caydr, I'm not even talking to you further until you go get and install the P.U.R.E. Demo and play at least the first mission... which you obviously have not even tried yet.

[Neddie]

This would require both maps and games become increasingly generic by limiting the use of the options before developers. If you generalize the argument you promote the same scaling, the same use of different dynamics, perhaps even the same weapon types and standardized impulse values?

I know it is hard, but a game team should deliver enough maps to play with, whether directly or through the use of informed mapper contributors. Any particular project can publish guidelines to help particular mappers as well.

[Argh]

Or they can live with OTA maps designed with BA in mind.

Or the Devs could let Lua write the metalmap state, and then games are in complete control of how the gameplay works on a given map, and this conversation's entirely moot, instead of 99% moot, tbh.

If you want maps to stay within a certain slope range, for example, write your own blurring routine and apply it to the heightmap where it exceeds those values at runtime, for example.



@d_b: you can't use 32-bit grays... not that you'd want to, or that it would be noticeable. Remember, no how finely graded the height is:

1. The xz resolution remains the same.
2. Players are generally using the default mesh resolution, or lower. Smoth's side-long shots look fantastic, I could shoot pretty cool shots of P.U.R.E. maps using 16-bit... but my experience with 16-bit raw is that it mainly just avoids some of the stepping of 8-bit. It's not that much more exciting from overhead, tbh, because then it's the xz resolution that's the main factor. The only way that's going to change, realistically, is for somebody to write a Lua-based map format, since there appears to be zero interest in doing anything about how dated SMF is atm.

[Gota]

-

[Beherith]

Not all maps will work with all mods. This is not a bad thing. We have over 1k quite good maps. You will find that a large amount will still work with whatever mod you want.
We need variation way more than we need standardized maps.

Modders shouldnt interfere with mappers business. If you dont like it, dont play it.

Ive been using 16bit extensively lately. Just take a look at Apophis or TMA-0.
http://springrts.com/phpbb/viewtopic.php?f=13&t=20684

Argh, your maps have hardly any height variation, 8 bits+lowpass (which lowpass filters to 32bit float btw) is enought for you. My heightmaps often feature details only possible through 16bits. And since spring stores the heightmap in 32 bit floats anyway, its easy to edit mapconv to read 32bit floats as well..

[KDR_11k]

I'll interfere with maps if necessary. What you intended for the map isn't what my mod will do with it anyway so altering the map data won't change much.

[smoth]

caydr, just because you cannot see the full range of 16 bit colors does not mean the data is not there. Most of us do not edit our heightfields in photoshop we use tools meant for the generation of heightfields.

I IMPLORE you download gundam rts and try the maps.

[Argh]

I'm not trying in any way to imply that 16-bit's irrelevant or useless. I found that without it, even on my flat maps, you tended to get obvious flaws with certain things when the engine builds the geometry. It's useful to use 16-bit no matter whether you're trying for a conventional feel or not, frankly. All I'm saying is that it doesn't make up for the lack of normalmaps at the diffuse-map level. Of all the things in P.U.R.E. after I upgraded a lot of things with shaders and other OpenGL stuff, the maps are looking the worst, frankly.

And yeah, I'm kinda with KDR on this, no offense meant, Behirith. The map designer doesn't have a clue what game's going to be played, and is probably designing for BA. Is it better for Spring, if we game designers are put in the position where we're like, "sorry, those maps are beautiful, but they screw up our game designs", or we just fix it at runtime?

I mean... if game designers want to deface the map's ART side... meh, we have a bazillion ways to do that, and nobody really wants to. It's one of those things where most of the worries have never actually happened. And there are a lot of possibilities for OTA games if we can alter the metalmap at runtime, come to think. We could see maps that were random each game, for example- static heightmap, but resources / typemaps would be different. Could be a very cool idea, tbh.

[Saktoth]

Its a very good idea to discuss what standards mappers and mods seem to be using, and try to encourage everyone to use similar conventions for slope tolerance and metal values if there is no good reason not to (PURE used to, possibly still does, use metal values 1/10th of that of regular maps- there is no discernible reason to do that, and it made the maps totally incompatible). Most maps and mods use the values you set in AA, and if we are talking standards, thats the most ubiquitous one.

Setting new standards though, is a waste of time. Nobody will adopt them and they wont be backwards compatible. Setting amph tolerance higher than bot tolerance in OTA mods will lead to vehicles being the more all terrain factory- which from a design perspective i would say is weird to say the least. In fact, CA has a policy of making Amphibious units bots, rather than vehicles, so that the slope tolerance can remain consistent with chassis type.

We did briefly try amphibious spiders in CA (with a similiar logic to yours, actually, that it gave them a purpose on both hilly and watery maps). It was felt, however, that mappers designed sea cliffs specifically to be impassable. In fact, one could say steep slopes against water is almost mapper code for 'impassable'.

Another one of the things i've tried to do in CA, standards wise, is have land viable hovercraft with slope tolerances lower than vehicle slope tolerance, to add more variation to slope ranges (CA also uses a lot more, stronger All-terrain units, so there is more up the other end too). This didnt work. Even on Scorpio, a map i designed and specifically noted the hovercraft slope issue, there were islands they couldnt access- the mapper tested with BA. We reverted to BA values.

Luckily, and here ill echo the sentiment of the other posters, CA has such extensive terraforming that we can probably revise this policy. An island with metal on it being inaccessible to hovercraft is no problem when they can just make themselves a ramp.

[smoth]

argh what does the heightfield have to do with the lack of shaders on the texture? The reason you would use 16bit is so that the terrain has no "stepping"

I don't follow your post.

[Argh]

I am saying, basically, that while 16-bit presents some novel ways to give us detail in the Y, there is no comparable way to achieve that in XZ without shaders or another rendering approach, is all. Meh, if I'm tired enough I didn't present that well, I apologize- it is well-past bedtime and I need to be up in the AM for Turkey Day.

[smoth]

it's cool man, I am half awake also. I was like wtf am I just out of it or something.