General guidelines for adding new game-only modifications of existent maps

[DanVanAtta]

Originally posted by @Cernelius in https://github.com/triplea-game/triplea/issues/7563#issuecomment-689672196

So, general guidelines for adding new game-only modifications of existent maps is not making or using "variants" like maps, in the sense of up to one such map per every original map, inside which to add all such modifications for the map, but, instead, making a new skin-cloned map every time one or more such games are being added? For example, in this case, instead of adding this new game inside the "games" folders of the "world_war_ii_v3" or the "ww2v3_variants" existent maps, I'm understanding that the suggestion is making yet another skin clone of a map (substantially a second "ww2v3_variants" map) for this game only modification?

I see only 4 ways of handling game-only modifications of existent maps:

1. The new game file is added inside the "games" folder of the original map (this is what I'm seeing happening in the last years, especially with reference to the "Global" "mods").
2. A skin-less variant folder, containing only a "games" folder and no skin elements is made, and the new game file is added inside this "games" folder, but coded to refer to the original map (this is the usual way game-only modifications were handled in the past).
3. A new folder is made that is the clone of the original map except having no files inside the "games" folder, and the new game file is added inside the "games" folder of this new map, coded to refer to this map. Any more such game files (no matter if from different unrelated persons) are added within this "games" folder (so, you have two skin-identical maps, one to collect all basic games and one to collect all modifications of them).
4. A new folder is made that is the clone of the original map except having no files inside the "games" folder, and the new game file is added inside the "games" folder of this new map, coded to refer to this map (this process is repeated every time one or more such games are made, giving a potentially infinite number of skin-identical maps, each of them offering one or more game-only modifications of the same original map).

I would suggest the developers choosing a process and documenting it (if not already made). Practically some documentation telling makers what they are expected to do if they have made a game-only modification of a map (like a new map in which everything but the game (XML) files is the same as an existent map) and want to make it available to others through TripleA (just a suggestion so possibly not to go through this learning process every time, but before opening the issue).

[DanVanAtta]

@panther2 said:

1. The new game file is added inside the "games" folder of the original map (this is what I'm seeing happening in the last years, especially with reference to the "Global" "mods").

The process behind those additions to "Global" has never been discussed. It has simply been done, creating facts. Having writing access allows for doing so without any discussion with the developers or anyone.

Thinking about Global: There are so many user created variants out there. If every variant would be included into the "main" repo, it will be harder to distinguish different games, you will have more games in your game list than you ever wanted. I am for example happy that "Path To Victory" has been published in a separate repo - other than "Balanced Mod" that had been included into the main repo (both created by the same user by the way).

Today, when I reinstall the Global map file, I have to manually delete all the game.xml files that are redundant (to me) in order to keep my game list clean and practicable - containing only the games I want and need.

[DanVanAtta]

@Cernelius I don't think it scales very well to have all variants always be exactly in one 'variants' version of a given map. Perhaps radical changes are needed, there could be cases where there are many new images used by just one the XMLs and not the others (which would degrade download speed and map performance for all of the XMLs unnecessarily). There also arises the same original ownership questions, who owns the variants? If we are concerned about the original map being a grab-bag of new variants that we put them all in a 'variants', what's to prevent the same concerns about the 'variants' folder.

My 2 cents on this, there is a judgment call of where a new XML should land. Sometimes a 'variant' would be a good location, others perhaps a whole new map with its own files independent of any other maps.

@panther2 I agree that there is a scaling problem for selecting maps. After a map is downloaded, it's transparent if you get one or many and if those live in different folders or the same. How maps are organized on disk I would decouple from that conversation, how does one organize the selection of dozens if not hundreds of available Map XMLs to choose from?

[panther2]

@DanVanAtta Let us stick to the example "Global 1940" and take a look what you get when downloading "world_war_ii_global-master.zip".

You will get all of this:

What I would expect when downloading "world_war_ii_global-master.zip" is exclusively what I have marked yellow. As these are the games that IMHO belong there. Those are the official games (Global 1st and 2nd Edition as well as an official variant (1942-setup)).

Everything else, not marked yellow, IMHO does not belong there and has been included maybe because of particular interests or maybe because of a lack of knowledge of where to place it alternatively.

I am not accusing anyone here for having done this, I am just pointing out exemplarily the organisational deficits that become obvious with this map-repo.

While "Balanced mod" is popular enough to deserve its own repository, the other "variants" might be well placed in one or more "Variants" repository/repositories. That would keep game-files and repos clean and sorted.

It was actually this what I wanted to point out with my above statement. I am not concerned about individual disk management.

Me deleting the xml-files I don't need, is my individual way of cleaning up and removing the overload that is caused by merging "too much" into one and the same repository.

Now it is not only "world_war_ii_global-master.zip" that I download but many other game files, too. If I would not delete all the unwanted and unused xml-files my TripleA-Select Map-List would be spammed with useless (to me) maps/games/variants that I never intended to download and install and never play.

[Cernelius]

In my opinion, of the 4 points I made, best to worst is "2" (best), "1", "3", "4" (worst). Obviously, since "2" is what the developers unmade, I make no illusions it may be chosen. Mostly I'm saying that maybe you want to stardardize only to one of those process, documenting the matter for any future "modder".

Currently, there are examples of "1" (the "Global", mods, amongst others, like the "WAW 1940" game I remade), "3" (the v3 variants, to which I've added two games of mine some time ago) and "4" (the map at https://github.com/triplea-game/triplea/issues/7563).

[DanVanAtta]

Why is (4) bad @Cernelius ?

It has advantages:

• you're not coupled to any other maps. You don't have to worry about modifying existing maps or breaking them in unexpected ways.
• You can test changes easily, since you are aware of all map dependencies
• It avoids any of the ownership problems. Even with a "variants" map, someone still owns that, it's just the same as adding to any pre-existing map and it can be difficult to track that person down, get permission, particularly when only about a dozen of the 100+ maps have an active owner to them

[DanVanAtta]

(2) Had a number of drawbacks, I'm curious why it is the best in your opinion @Cernelius

• Complex
  • resource loading was complicated, buggy
  • map dependency was not always clear and enforced, complicated to tell a user "oh hey, this map XML, does not work unless you have X installed." Which map contains "X?", the game engine had no idea as it only knew about Map names and not the Game XML names.
• Easily broken, modifications to any map could seem self contained but instead can break any number of unknown dependencies.
• Was not common, we only had a few examples so it was easy not too difficult to "unwind" these.

[DanVanAtta]

(1) and (3) both suffer from ownership problem. AFAIK only about 5-15 maps have any kind of active owner, the rest are orphaned and maintained by the admins. Nobody wants to spend that much time and effort tracking down someone to likely never get a response to get "permission' to add a Map XML to an existing repository. I see a lot of friction and delay in that kind of process.

Ultimately whether someone goes with 1, 3, or 4, I don't know if it matters too much as long as it's easy and does not waste time in unnecessary gatekeeping and coordination with others. If a person spends time building a map, assuming they are free and clear on copyrights, it should be added, expediently with a minimum of effort for everyone involved.

My vision is that long term map files will be broken up. Instead of bundling all artwork for example, the unit images would be given identifiers and there would just be a big pool of unit images. As a map-maker you could then just pick and choose which ones you want by saying "this unit will use image ID: 1234", and the engine will automatically take care making sure you have it downloaded. In this way the artwork, XML files, and map bundles all become independent.

Medium term the plan is to allow map zips to be uploaded from in-game. It is likely then that every version of a map will become available and that any changes are observed as a new version. Something like (4) is attractive there as any changes to a map would be significant and observable with each version (rather than some random variant bundled with the map changed and so now we have a whole new version where nothing actually changed). Towards this, having maps and map XMLs be one-for-one has some strong advantages.

[DanVanAtta]

Beyond the previous discussion, I think the biggest problem we have is knowing "Which map X provides game Y?" For example, which download provides WW II V3 1941?? It turns out ht answer is WW II V3. Which map provides WW II V3 1942, oh, also WW II V3. The relationship of a map containing many 'games' is a problem in of itself.

This goes to @panther2 's point where when you download you get unexpected and perhaps undesired map XMLs. So at the end of the day the relationship of "map" vs "game" being done for the convenience of the coding and kinda being hidden from players but not really is the core problem. FWIW - making maps and games 1:1 would readily solve this.

[Cernelius]

Games supposed to use the same map should never require different maps (original skins).

Think about, for example, if the "Global" map would have a skin issue (like a territory wrongly drawn that shows a connection that doesn't exist). You would need to fix it for all the maps, at the risk of involuntarily breaking them from being identical.

Duplicating the same thing is never a good idea, unless it is the first step for an (intentional) map modification (which would be just a different map, like "ww2_path_to_victory", so irrelevant to this discussion).

If you make a "v3" board-game that has a 1941 and 1942 setup, you don't sell two boardgames with two identical maps and pieces. That would be absurd. You sell a single boardgame with the minimum required to allow the player to play either setup.

[panther2]

@Cernelius

Duplicating the same thing is never a good idea, unless it is the first step for an (intentional) map modification (which would be just a different map, like "ww2_path_to_victory", so irrelevant to this discussion).

Balance Mod is a different game, too. Path to Victory is a further development of Balance Mod. So this is far from being irrelevant to this discussion.

If you make a "v3" board-game that has a 1941 and 1942 setup, you don't sell two boardgames with two identical maps and pieces. That would be absurd. You sell a single boardgame with the minimum required to allow the player to play either setup.

Correct. But if I started to add XMLs with a "Combat Move First Variant" and a "Tanks cost 6 instead of 5 Variant" and a "Add XYZ as playable nation Variant" and a "Whatever Variant" to this repository, too. this would be another pure overkill.

@DanVanAtta

This goes to @panther2 's point where when you download you get unexpected and perhaps undesired map XMLs. So at the end of the day the relationship of "map" vs "game" being done for the convenience of the coding and kinda being hidden from players but not really is the core problem. FWIW - making maps and games 1:1 would readily solve this.

Maybe it is "only" a question of carefully sorting out and deciding what is accepted within the same repository and what not.

So maybe it is a good idea to have "core" repositories for the core games as well as for popular user created games. Here any addition to these repositories should be monitored and limited, somehow approved. And aside a variant repository where everyone can add his particular interests.

[DanVanAtta]

@Cernelius

You would need to fix it for all the maps, at the risk of involuntarily breaking them from being identical.

The involuntary break is much more limiting. For example, let's say you do need to fix something, but can't because you don't know how many maps depend on what you are modifying.

If you make a "v3" board-game that has a 1941 and 1942 setup, you don't sell two boardgames with two identical maps and pieces. That would be absurd. You sell a single boardgame with the minimum required to allow the player to play either setup.

Sure, but this is a computer game. You're ignoring most of the problems I noted above. When you're looking for a specific game name, it's difficult to find because we only show map names for download, not game names. It's then a surprise when you get many games (perhaps an analogy, you buy one board game and you get rules for 20 with the accompanying pieces that you never use).

We need to be considering maintenance costs and usability here. When we get to a place where you can upload maps without mucking around with manual file system management, it'll be an interesting question of how to update existing maps. I think the answer is you won't. Instead a new version is created. In such a case, a map containing many XMLs could then have many different versions even though a given XML might not be changing. This means if you play one XML, if that is popular, and a few others are being modified but not played often, then the popular XML will look to have many different versions requiring players to constantly re-download the latest version for the benefit of no changes.

@panther2 hence my thought it's a judgement call what is included with what. Though, a 1:1 of map and game solves that. We also have issues where scoring of maps can be burdensome and raises questions:

• does a map XML get kicked out if it is not popular anymore?
• what happens to all of those save games if XMLs are merged or removed? How difficult is it for the game engine to keep these working (likely extremely and most likely they would crash).
• how do we score popularity of a map or a map XML? Like, how do we keep track of it?
• Who decides exactly that a map XML should be included or excluded? what if they are AFK for an extended period of time. What if the map maker then does not have free time that lines up (EG: I've got one week, I make my map, then I go back to my life and the fact that my schedule does not line up with someone else should not be my problem).
• What happens when the original owner is not available? (as is really the case with 90%+ of maps, there's over 100, only a dozen have an owner on them, if that. Most maps are fire-and-forget, and the popular ones will get a lot of voices around them but rarely an owner)
• If the popular maps are promoted (IE: placed in a prominent place for download), is that not a self-fulfilling prophecy for popularity? How is a weakly promoted map to become popular if it is weakly promoted?

[Cernelius]

@Cernelius

Duplicating the same thing is never a good idea, unless it is the first step for an (intentional) map modification (which would be just a different map, like "ww2_path_to_victory", so irrelevant to this discussion).

Balance Mod is a different game, too. Path to Victory is a further development of Balance Mod. So this is far from being irrelevant to this discussion.

It has absolutely nothing to do with this discussion. "Path to Victory" and "Balance Mod" are obviously different games (by definition), but "Path to Victory" is a game of a different map. Such map being a modification of another map is completely irrelevant to anything at this issue (it's doesn't matter if you change one thing or if you make a new map from nothing, as you still end up with a new map in both cases).

Look. If I take "Global" and split a sea zone into two, adding 1 zone non-existent in the original map, all the rest being exactly the same, that's a new map. It doesn't matter how similar it is to any other map. It is just as much of a new map as a completely original map that I make from nothing, as far as this issue is concerned.

This issue is only about different games sharing the same or compatible skin elements (eminently maps being clones of other maps outside their "games" folder), thus currently or potentially being part of the same map.

The involuntary break is much more limiting. For example, let's say you do need to fix something, but can't because you don't know how many maps depend on what you are modifying.

If you make skin-only changes, not touching any game files, all game files of the map are supposed to be fine with the change. If they are properly made, they'll receive the fix too (for example, a connection correctly present in the game file, but badly or not shown by the map). If they are not, that's their problem, anyways.

If you are actually changing the map (like done with "World At War" going to version 2), you should take care to remove from download list all the variants you don't intend to upgrade. That's a reason why it is good to have easily recognizable names for such folders (like calling them with the original maps' names followed by "variants").

[DanVanAtta]

If you make skin-only changes, not touching any game files, all game files of the map are supposed to be fine with the change. If they are properly made, they'll receive the fix too (for example, a connection correctly present in the game file, but badly or not shown by the map). If they are not, that's their problem, anyways.

@Cernelius I think it's more likely to be the other way round, where a change is breaking existing maps rather than fixing. Maps that have issues will tend to be quite solid.

If you are actually changing the map (like done with "World At War" going to version 2), you should take care to remove from download list all the variants you don't intend to upgrade.

That is asking for a lot. It really is.

• you have to contact all the owners of all of those variants and get them to make changes
• you're removing many variants from the download list, that is huge
• you have to find all such variants, which then raises questions of how to do so. While certain conventions make it easier, it's not going to be guaranteed that everyone follows such conventions or everything gets backported.
• it assumes that all variants are known and in the official repository

I can't emphasize how prohibitive that is, I don't think anyone would ever say "yeah, let me spend the next month following up on this and breaking all of these variants" compared to "copy-paste, new map".

Having maps be independent from one another is extremely valuable, isolation of change makes modifications to maps magnitudes simpler. I'd venture to say as soon as a map has a variant, that base map is not going to change, and arguably should not change. That locks out options of improving unit artwork, and many other cosmetic improvements. Having to coordinate amongst the community is a good thing, but it's time consuming and personally I wouldn't want to be the one that says, "yeah, you 5 people that made variants, I'm changing the nit artwork and you're either going to have to do work to create other copies and or create a whole clone of the variant so it doesn't change, or just simply accept these upstream changes." That coordination process alone is time that most are not going to have or want to spend.

[Cernelius]

@DanVanAtta Let us stick to the example "Global 1940" and take a look what you get when downloading "world_war_ii_global-master.zip".

You will get all of this:

What I would expect when downloading "world_war_ii_global-master.zip" is exclusively what I have marked yellow. As these are the games that IMHO belong there. Those are the official games (Global 1st and 2nd Edition as well as an official variant (1942-setup)).

Everything else, not marked yellow, IMHO does not belong there and has been included maybe because of particular interests or maybe because of a lack of knowledge of where to place it alternatively.

I am not accusing anyone here for having done this, I am just pointing out exemplarily the organisational deficits that become obvious with this map-repo.

While "Balanced mod" is popular enough to deserve its own repository, the other "variants" might be well placed in one or more "Variants" repository/repositories. That would keep game-files and repos clean and sorted.

It was actually this what I wanted to point out with my above statement. I am not concerned about individual disk management.

Me deleting the xml-files I don't need, is my individual way of cleaning up and removing the overload that is caused by merging "too much" into one and the same repository.

Now it is not only "world_war_ii_global-master.zip" that I download but many other game files, too. If I would not delete all the unwanted and unused xml-files my TripleA-Select Map-List would be spammed with useless (to me) maps/games/variants that I never intended to download and install and never play.

Had it depended from me, I tend to think that now Global would have even more games referring to the same map.

Beside retaining all the various Alpha versions, I would have made Europe 1940 and Pacific 1940 as variants of Global 1940, using the Global map, since they indeed use that map (just part of it, so you would need something to make and show both land and sea zones as impassable).

You can see an example of the problems (or, rather, multiplication of problems) I pointed out if you load whatever game of the world_war_ii_global and whatever game of the world_war_ii_europe map.

@panther2 You probably remember that (under my guidance) you fixed the graphic of the world_war_ii_global map as showing Central America and Venezuela not connected. However, nobody ever fixed the world_war_ii_europe, that is still showing Central America and Venezuela as connected.

This is an example of why it is harmful to multiply a same map. You'll just multiply the chance of problems not being fixed.

And, as I said, imagine if you would have a map for every Global game. Then you would have to multiply everything you even do on the skin by that number. This is honestly silly, and will probably result in fixes likely getting applied only to one at a time, with a random divergent evolutionary patter for supposedly identical maps overtime.

On the other hand, imagine a perfect world in which all mapmakers are never wrong, and all maps are absolutely perfect, needing no changes nor fixes. In this case, duplicating maps would be absolutely baseless, as there can be no problem about not doing it, so you are just creating useless redundant weight.

So the system, at its perfect state, is actually perfect by not needlessly duplicating what are the same assets over and over again (quite obviously), and, when you start considering problems, sharing the same assets amongst multiple games has the beneficial effect of multiplying the fixes made at the risk that it might multiply problems if something is or was badly made, while needlessly multiplying the same map certainly multiplies the effort needed to fix the map if need be. Moreover, that is merely the best case, as chances is that only one or some of the identical maps get the change, which in turn causes maps that are meant to be identical going astray.

The case of actually changing the map is very rare (if only because maps are usually abandoned, not rarely before being even fine tuned), and should rather normally result in creating a new map (keeping the old one). It's like when you go from Classic to Revised. Revised is like if you take Classic and make changes on the map: You keep both. If you don't, you are substantially removing an existent map (in favour of a new one, as we did when we changed "World At War"), not just updating it.

So both in principle and in practice having one map is better than having two or more identical maps.

So, once we agree that we don't want to multiply the same set of assets over and over again, the only solutions to not have ours "Select Game" lists flooded with games we don't want (and, of course, you cannot oblige a mapmaker to accept within its own map games made by someone else) is having some form of map-external handling of games, in which each map comes with its basic games, while more games, using that same map, are additionally downloadable somehow. TripleA should either offer the option to download such games only if you already have the map or make you download the map upon downloading any external games you don't have the map for. Maybe a "downloadedGames" folder beside or inside the "downloadedMaps" folder, but probably better some standard format by which additional game are packaged in a folder that starts with the same name as the map they are using plus something (similar to how mapskins are recognized).

[DanVanAtta]

@Cernelius :

1. When uploading maps from in-game, a future featre, updating an existing map is going to be difficult if not possible. Instead new versions are going to be added instead.
2. Also in the future, when map assets are decoupled and referenced by ID, they would not be multiplied
3. Having to contact other 'map owners' is prohibitive, it doesn't happen. IMO it's a perfect world where in zero time you can find and contact all needed parties and have them update their variants such that they keep working, in practice though this does not happen. Instead the main map is updated and the variants have whatever happen. The Europe map not being updated I think is even an example of that, did someone know and were they able to tell the europe map owner (who does not exist) that their variant needed to be updated? Grant it, we're talking a map update here, but it's the same analogy for any other breaking update, people are not going to, even if able find and coordinate changes across so many people. It also breaks game-saves and is just generally impactful.
4. We're very likely moving to immutable maps. Once uploaded, it never changes. instead updates are a new version, this way if a map has an ID, and we push that to a game save, every player can always (automatically) find and download the exact right map version
5. It's a judgement call for right now where to bundle a map XML. We probably don't want 50 global variant XMLs in the main repository, we probably don't even want that in the global_variants repository either
6. An ongoing problem, finding a 'game' is very difficult. A person totally has a situation where they know which game they need/want, but not which map contains it. Even if we listed which games were in which maps on the download screen, clicking through one-by-one is still a PITA (but at least a person has a better chance). A good example are the big world variants that are really difficult to find and download successfully. When playing others, this can lead to pretty big delays of trail and error downloading and looking for the right map.

[DanVanAtta]

Another point to consider @Cernelius : 7) duplicating a map that has changed into "n" repositories is not that difficult either. So why is the duplication even a problem beyond an aesthetic consideration? Let's say we have bundled variants, are those owners always going to be happy just accepting whatever updates? This converts a map from a single owner to a shared owner, that makes changes pretty much infeasible. We're loosely distributed, have our own lives, anything that requires coodintation at arbitrary times between arbitrary people is going to move a process that takes minutes to weeks. Instead if you update a map image you can readily submit PRs into the downstream or duplicated maps and the owners can accept/reject them as they wish. We should also consider that most maps rarely change, the majority are on V1, most are not owned, and even popular maps rarely change.

[DanVanAtta]

Yet some more points to consider @Cernelius : 8) Independence of change makes change feasibe, it's a great thing. I'm emphasizing that any coordination will generally kill change or changes will just happen whether you want it to or not. But to the point, knowing that the map you are changing is the only thing you need to change is very powerful. For example, the canadian units in the main repo, there being unknown dependencies made that change very difficult and of course unknown maps have come forward and are broken because of it. Its the same thing with multi-repo variants 9) In the future unit stats and most stats would be modifiable on the fly, this should reduce a large number of variants that are produced where there are only differences in key stats.

[Cernelius]

I assumed it was obvious (but now I see it would be very good to document it) that all game variants would be subordinate to their maps, while sharing nothing in the ownerships of the same. Obviously, someone making a variant using my map cannot oblige me to care for it. Meaning that you don't have to care about any variant upon modifying a map (it would be nice, but not required, if you check and have them removed from download list, if they are not any longer working, but this can be done anytime someone reports them). This means that variants will automatically benefit from any skin improvements and fixes made on the original map, but have no guarantees otherwise. This can be documented. If someone making a variant doesn't have a good feeling about this, he can opt to have a standalone map, though I would prefer this being discouraged as much as possible (nobody is going to watch over him to see if its original skin is a duplicate of another map, anyways, and this will be always the first step when you want to make a map modification that also touches the skin (of course, here we could start with copyright considerations, unless we are sure all is public domains, but this is off topic)). Basically, the variant maker should stay around itself, and its game being readily removed from download list if it stops working because of changes to the original.

For the remaining part, I stand on what I said, but I also want to point out again that I make no illusion about things here going the way I think they would be best. I mostly just explained because of being asked why my preferences. My main suggestion was simply that the developers somehow pick a solution and document it, as currently I believe there is no standard process at all for game-only modifications (it can span from the extremes of adding your game file to the original map to cloning the original map, and renaming it, but with only your game files in it as the only difference, and it doesn't seem there is anything determining what's going to be).

I'll also add that duplicating maps is bad because it also makes hard or impossible actually to know what's the original and what's the clone (imagine in 10 or more years from now someone has to wonder about it, maybe after migrating the map somewhere else). For example, I want to make a game-only modification of @Heppisorus "Total World War", so I just clone its map and, on the clone, delete all its games and put in it my variant. Then, in the future, someone finds these two maps that are skin-identical and wonder which one is the original one. If, instead, I make a skin-less variant that uses the original "Total World War", all is clear.

Finally, while the process should be proof for all cases, I'm assuming that variants will be made on the basic maps only. Experience shows this being the case (I've never seen a "TWW" variant). The most non-basic game, I remember variants for, is "Ultimate World", and that's very basic too (and abandoned since a long time, thus stable, which is what eventually happens to maps).

I think this pretty much wraps up everything I said, and I think my participation in this discussion may end here, as my initial suggestion was really merely an advice about documenting "something" that a new mapmaker making one or more game-only modifications of a map may read, to know what they are supposed to do.

[beelee1]

How difficult would it be to make the "Remove" in installed maps uninstall only the map/xml/game you don't want ?

While 1:1 xml game to repo would prevent unwanted games showing up, it'd be a lot more repos and yamls to deal with. Also some people will become aware of these other games because they are included when they otherwise might not be. I know I did anyway.

I can see Panther's point as well, as where you don't need too many in one map dl. All the BM's should be in a different one and I can move the Oztea to a separate one if given permission. Think simon is in charge.

At any rate, it's not that big a deal to me if extra games show up. They can only be put in by whoever controls the repo anyway. If there's a quicker way to 86 them that might be the way to go.

[DanVanAtta]

@Cernelius some responses, thanks for talking this one through:

Obviously, someone making a variant using my map cannot oblige me to care for it. Meaning that you don't have to care about any variant upon modifying a map

I don't think that is acceptable. A working map should remain working. We do not want suddenly broken maps in the repository nor peoples work invalidated.

This means that variants will automatically benefit from any skin improvements and fixes made on the original map,

While perhaps desirable, again, maybe not.

. I mostly just explained because of being asked why my preferences.

thanks for going through this exercise. The points I listed above I think have some really compelling items. Going back to variants structure works against some of those goals and is not desirable from a code perspctive:

• the resource loading code is already a mess, making that have more features is going to make it worse, possibly put it into a state where the required test permutations for any future changes woudl be intractable making that code brittle and too dangerous to change to make it not be brittle. So it'll be crap code that we can't un-crap because it is too crappy to change it safely (which describes a lot of TripleA code; I've respect for what the code base does, but we've a lot of problems to solve..)
• again, the complexity of test increases substantially, if not otherwise by an order of magnitude.

My main suggestion was simply that the developers somehow pick a solution and document it,

Understood, there is no solution being chosen as its a judgement call and most options do not really fit into future direction. The best fit for future direction is actually option (4) that has been discussed. Until then it does not matter too much (and option (2) has been off the table for some time).

I believe there is no standard process at all for game-only modifications

Hopefully in the near future there will be less need for this as game-only options will be configurable at game-start. Ignoring that, the de-facto standard is not to touch popular and well known maps, essentially anything in the 'good' or 'best' categories. The only exception is if you are one of the half-dozen active map-owners and it's your map that you're modifying.

Then, in the future, someone finds these two maps that are skin-identical and wonder which one is the original one. If, instead, I make a skin-less variant that uses the original "Total World War", all is clear.

Why is that important to know? We will know if someone has game notes that claims original authorship, it's a nice thing to give that attribution but not required. To another extent, the maps are provided to the community so anyone can clone a map as they please (without attribution).

[DanVanAtta]

@beelee1 thanks for the comments, some responses:

How difficult would it be to make the "Remove" in installed maps uninstall only the map/xml/game you don't want ?

It's possible, but would be a bit of a PITA to unzip and re-zip the map folder up programmatically. A 'hide' option could be done, but then we'd want an 'un-hide' option too. Perhaps this speaks to the desire/need for a "favoriting" feature.

While 1:1 xml game to repo would prevent unwanted games showing up, it'd be a lot more repos and yamls to deal with.

That's a problem for the database to deal with. We would not go to 1:1 until such time that maps are in DB and uploaded from in-game.

[DanVanAtta]

@Cernelius, I'd agree a lot of duplication is not good. (2) is a problematic approach. I think the best is for XMLs to land in the original maps so that they stay self contained. Failing that, creating a clone. Eventually maps and the game XMLs will be decoupled, hopefully, at which point duplication would be solved. Notably, maps would be independently distributed and XMLs would reference the map ID that it needs. This solves the bundling problem and the duplication issue.

Meanwhile, it's a question of how to get that stage, and in what increments to move the system to get there. Hopefully that has cleared up some questions for you @Cernelius ; IN general the problems you have raised are just problems with the design and reality of the structure of maps and the lack of map owners.