RFC: merging skins with maps
-
As an idea, what if we were to merge skins into maps. Map skins are alternative relief tile variants of existing maps. In this proposal instead of having skins as a second download, it would be merged into a map. Map skins today, because they are so stand-alone, have strong dependencies and considerable duplication to the base-map.
Here is the pro/con list as I see it:
Pros:
- simpler handling of skins
- reduce duplication in skins compared to the 'main map'
- would be easier to create skins
- far simpler code
- remove a whole download category for a simpler download UI (if we then also merged the 'tools' into the main download category, we'd remove a whole row of tabs in the download window)
- it would be easier to be aware of which skins exist for which maps by looking at the map alone
- it would be easier to not break a map skin when updating a map
- easier download process, no need for 'n+1' downloads to get map and skins, all would come as bundled.
Con:
- larger map download size
- skin makers would need to discuss building skins with a map owner first (though I suspect the two would often be the same person, but this is a potential con as communication overhead would be higher)
The con list is not that weighty, am I missing much to add to either of these lists?
-
@LaFayette would that make map creation more difficult?
-
@ubernaut I don't see how it would as a map skin is purely additional item.
There are only a few maps with skins. NWO, Napoleonic Wars, and Diplomacy are the notable examples. Looking at Napoleonic wars:
- map: https://github.com/triplea-maps/napoleonic_empires
- skin: https://github.com/triplea-maps/napoleonic_empires-topographical_map_skin
Notice that in the skin, most files are duplicated from the map, the files that are different are the relief tiles.
To combine, presumably we'd create a folder somewhere in the main map and place the skin relief tiles into that folder. Perhaps we'd create an index file to give the skin a name, or create a magic file called "skin-name.txt", and then done. If a map has no extra skins, then there would be no change to it.
-
This would make creating map skins easier.
-
@LaFayette cool
-
Interestingly, our Over the Top map was originally called "Great War Revised". @GenerationKILL wanted to do a "skin" of Great War, but quickly we realized there were other mechanics we wanted to change/add, inspired by other maps we had played (so it was no longer just a skin project). I think that's why there are so few skins- it's common to change the game itself as you "re skin". So I'm 100% in favor of simplifying this and benefiting the needs of the many over the needs of the few.
-
Map skins should be definitely merged with the maps if skins are made by the creator of map or created with the approval of map creator unless the map creator wants to keep it separate.
-
There would no longer be an option to release map-skins independently of the map. The map could be forked perhaps and then re-skinned.. This is where a 'con' comes in, there is overhead for that communication. I would expect for any reasonable skin to be welcomed.
-
Please no: leave them separate.
Especially with more than two players, when someone doesn't have the map, I would hate to have to wait more because of bundled additional skins.
Moreover, stand-alone map-skins are (to me, at least) very useful for skin-only development of available maps, as you keep the skin version, you have under development, as a map-skin (and then, when you believe it is ready, you reconfigure it as the new map), this way also avoiding the risk of accidentally overwriting your work-in-progress by downloading the available map, especially if the dichotomy between zipped and non-zipped folders would be phased out (currently, you can be safe from accidental overwriting by simply keeping your work non-zipped).
If I'm not hijacking the thread to much, a thing I wanted to request since a long time is having everything within a map-skin optional. Meaning that, every time you have a map-skin selected, the program should search within the original skin (the "map" folder where the game or the games are) every element missing in the map-skin, this way avoiding forcing duplication. This would be a huge help for map-making too, especially when modifying maps having one or more map-skins, the only downside being increasing the dependency of the map-skin on the original skin (which I see a minor matter since it would modestly increase an already huge dependency, in my opinion).
EDIT (This is an edit because I believe it adds nothing to the substance of what I already said at this post.): What I said at this post covers everything I want and it simply means that the "larger map download size" item vastly offsets all the mentioned advantages (over each of which I don't have a strong feeling, so didn't comment) if they are actual ones. An example could have been that you are about to start a 5 players FFA game in the lobby, and one player crashes because he doesn't have the map, so you have to wait for him, but you have to wait far more because this map happens to have 10 map-skins inside (Obviously, I realize that currently there is not a map having 10 map-skins.).
-
@Cernel I'd like for you to respond more directly to the pro/con list. Also keep in mind there are only 5 map skins AFAIK total, and all have been developed over 10 (?) years ago.
TBH it's almost tempting to remove the map skin feature altogether.
One really salient point is the extreme dependency between map skin and the original map. Having separated the two there is no way to be sure that any core map changes will not break a skin.
The two, skin and map, are very deeply linked together, so it makes a lot of sense to merge them. The maps that have skins are not common, the extra download weight is a one-time problem.
If a skin were bundled, it would be easier to do skin only development as you would not have to duplicate as many files or deal with magic folder naming. You'd only need to create a 'skins' folder and then put your content there, and you're off to the races.
-
I would like to see better sharing/reuse among game files via something like
<xi:include href="units.xml" />for different games/scenarios to avoid duplication for things that are constant among scenarios (e.g. Age of Tribes with different starting years). That seems way more useful and pressing than reuse of skins and graphical assets. As I said before, I don't think we see skins b/c a reskin inevitably involves a change to the game file itself.I'm also not sure what you mean about zip vs. not with helping to lose work or not. I 100% recommend version controlling each map in Git from day 1.
-
@LaFayette said in RFC: merging skins with maps:
Map skins are alternative relief tile variants of existing maps.
Not sure what you mean by this (since I'm sure you know this is not the case because map skins change whatever skin element), but I would also be against reducing this feature to the "reliefTiles" folder only. Of course, if a map-skin is duplicating everything but the "reliefTiles" folder, it would be better, for that skin, to have only that, as a particular case of what I was saying at my previous post.
If the matter is that optional skins should better be in the directory of their maps instead of in the same directory as their maps, I would say that map-skins should be optional elements that you can download within the map folder they are optional for (after having downloaded the map).
-
Interesting suggestion to make the new target of a skin download be the installed map folder. My inclination is to first keep it simple, it's already very cumbersome how skins are done and getting it to keep working at all will be challenge.
One problem we would need to solve is how the game engine would know which skins are installed for which maps. Once you download it, it is perhaps a good time to journal that the skin is downloaded, but how could we handle manually installed skins?
I've been thinking that the path to skins can be handled by an entry in a
map.ymlfile. That is centralized and is part of the map. If the download were separate, that would not work. Maybe we could do askin.ymlfile, though it doesn't seem that great to be scanning the file system to arbitrary depths for such a file as well and usually not finding it.The pro list has a number of really good items on it. A larger download size so far is not going to much of a problem. We are talking roughly an extra 5-10 seconds to download (for just a couple maps). IMO the dependency of a skin on a map makes it particularly useful to be together (the two are tightly coupled and have lots of duplication between the map and skin). Without that bundling, there is no way to know which skins exist and to avoid breaking them.
Re: relief tiles, AFAIK all existing skins have only differences in relief tile and there is yet to be one that has any other differences. For it to work, the skin is essentially a full copy of everything except the XML, which is also not ideal either.
This makes me really wonder, if TBH, if skins are really and truly used enough to justify even having. I do wish we had some numbers around how many people actually use skins (my impression is the total number of users is likely single digits).
-
@LaFayette I completely agree. I would imagine though that unit images might be another thing in a skin?
-
@djabwana said in RFC: merging skins with maps:
@LaFayette I completely agree. I would imagine though that unit images might be another thing in a skin?
That is likely the second thing (after the map's details) you may want an other skin for, but really everything may be. The point is letting the map-makers free to change what they want without obliging them to duplicate the rest.
-
I want to caution here us imagining useful features for a feature that AFAIK is not used.
-
@LaFayette The alternative skin for 270BC is an example of changing also the units. There may be others.
Here you can find a map-skin for RSoC that is actually about making the map bigger:
https://github.com/Cernelius/red_sun_over_china-big_skinThe current map-skin feature allows changing everything in the skin, and that is good. What is not very good is that it obliges you changing everything, so forcing duplication if you don't actually want to change everything. It is true that most map-skins are only about changing the map details, but I think this is beside the point (Of course, some things are more used or useful than others.).
