Map to Engine Compatibility Problems
-
Thread to talk about some of the cases where the game engine and map versioning do not always play well together.
1) Game engine does not know when a map is newer than current.
- A map that uses the latest pre-release features often cannot be read by latest standard release. This is due to DTD and the game engine not knowing how to handle attachments it does not know about. Worse yet, the game engine does not even realize it is dealing with such a map and would go ahead and overwrite a version with a newer one that does not work with that game engine.
2) Cannot both finish out save games and start new game after a major map version update
- Players will delay updating maps to finish up save games. During this time you cannot play someone that has the latest version of that map.
-
@lafayette Thoughts:
-
Could be resolved by just expanding the use of the existing engine version functionality (would help to simplify the versioning system as well):
<triplea minimumVersion="1.9"/> -
Only major changes in the map such as changing the base map image cause save games not to work with the new map version. After a map has been out for a bit its pretty rare to have major changes that aren't compatible with save games. I'd be interested in knowing if there are a lot of players that have experienced this and for what maps.
-
-
@redrum said in Map to Engine Compatibility Problems:
After a map has been out for a bit its pretty rare to have major changes that aren't compatible with save games.
To some extent I agree, on the other hand I wonder how much map makers are being held back. For WaW, it seems for a very long time some renames and updates were desired.
I'm also not sure to what extent we can just accept this as a problem and not try to solve it.
-
@lafayette I'd be interested in others thoughts but IMO many of the times there is gonna be a major updates, map makers opt to create a new map at that point.
-
@redrum I think the major case is changing names in a map. If there is a name like "Scottland", that you want to change into "Scotland", that is going to break all savegames, and make people in lobby crash all the times they are on the different versions, and it is ridiculous to break all people games and piss everyone off because of that; so you never change names.
The real problem (I'm not personally involved) is if you are going the way of making ladders, or any kind of competition thing; in that case, you have to deal with damaging the whole ladder system of a map you are breaking compatibility of.
The only reason why this is almost never an actual problem, is that almost nobody ever update or take ownership of abandoned maps. This is understandable, because, if you want to make a map, and you are able to do the skin things, it is much more interesting to rather make your own map (or a variant of an existing one). So, yeah, practically it is not a problem at all, or almost never encountered anyways, unless you want to make a way for making people able to make little corrections, like changing a couple names in a map, without major consequences, which is not that necessary, either. -
An example I remember, is that @RoiEX wanted to change a single misspelled name in the World At War map. If you would do something like that right now, you would make a lot of people more and more unable to complete savegames and cause a lot of crashes in the lobby and confusion in the general PBEM and whatever community.
And if people complains and you would, then, say, there was a "f" we changed into a "v" in a name, they would be like what the actual...?
But it is really not a big deal abstaining from making any compatibility breaking changes on popular maps, I think. -
@cernel said in Map to Engine Compatibility Problems:
But it is really not a big deal abstaining from making any compatibility breaking changes on popular maps, I think.
I think this is where it dovetails with greater compatibility concerns. While I agree with this point, it does have an implications that we have a 'read-only' map that we are not changing as it's active and has saves. It makes sense to then create variants.
There is an implication here, the XML is controlled by a DTD file which constrains teh defintion of what can be in teh XML and the structure. We also have restrictions from the game engine of what it can read in XML. For me this is where the biggest problem comes in, we are left not changing maps (good), but still maintaining their XML anyways and occasionally breaking them due to game engine and DTD.
So if it were the case that the game engine could easily 'forever-read' immutable maps, then it would not be a problem at all. As is our maps are mutable, and the engine can't always read future and present maps.
-
@redrum said in another way, I think the problem is also that we don't have a
maxEngineversion tag : )
This is why I think so much of the trick is to make sure we don't lose compatibility to read existing maps. -
@lafayette Uh. How would you use a maxEngine version tag?
-
@LaFayette About the territory naming problem:
Wouldn't it make sense then to simply give territories unique ids and use that internally instead of names as identifiers and keep names a visual-only thing? -
@roiex
Great idea.I currently have a map which I intend to use for multiple different time periods, and might rename areas with era-appropriate names. If I could use the same name within the centers, place, and polygon files for all iterations, but just had an XML option that changed the display name, it would be incredibly convenient. It would be great just for updating names in general, rather than change a minimum of four files, you just update the XML.
-
@roiex Yeah, I tend to agree with something along those lines to at least resolve the renaming issue but that would potentially require a lot of changes I believe. It also would only really solve the territory renaming challenge not other major map changes (though I think that is probably the most common case).
-
@redrum Perhaps the best choice would be to completely redesign maps using another format like yaml (because of the built-in types like arrays and objects/prototypes/maps/tables/whateveryouwanttocallit with modularity and shared map resources in mind.
This would of course require a lot of work and in depth brainstorming first, but such a brand new system could be the solution for a lot of problems we currently have. -
@roiex So in an ideal world, I think that would probably be the right approach. The challenges that I see with doing that are:
- Would we convert ALL existing maps to use the new yaml standard? That would have to include official, unofficial, and in-progress ones as much as possible and would probably be pretty painful. Alternatively, if we don't do that then we essentially have to support both xml and yaml standards which would be more maintenance and hard to provide map makers guidance.
- Existing map makers would have to learn a completely new standard to utilize the new yaml system.
Given those 2 things, I lean towards trying to improve what we have over creating a new standard. I also think that while yaml would help in some places, I'm not convinced it would solve things like changing base map tiles. Some things like that would be hard to ever make compatible as you really have a different underlying map/territories at that point.
I think maybe we need an exercise in making the problems we want to consider a bit more concise. Do we really care about just renaming? Do we want to be able to change base map tiles? Change image names? To understand what are all the things that break map compatibility today and which items each potential solution would/could address.
-
@redrum If we actually manage to achieve such a new standard, I'd be happy to create a converter tool (perhaps javascript, on the website) that takes a map and converts it to the newer standard
I think having map makers to deal with change is a sacrifice we have to make ^^
Especially because the basic system of what a map needs to specify, turn oder, units, positions etc. will stay, just the way it's done will change. -
@roiex Yeah, some form of converter tool would probably be necessary. I definitely would want mapmakers to be part of the process if we went down the road of a new standard map format. The last thing we want is a great new standard and all our map makers leave cause they hate it
-
@roiex I feel scared by this proposal. Definitely would suggest supporting both standards indefinitely; if that is not feasible, maybe better not.
-
@Cernel Change is always scary, however there's no need to be worried.
Supporting both options defeats the purpose of redesigning the system IMO, so that's not an option.
However currently all of this is just some theoretical thinking.
There aren't any concrete plans yet, and even if there were, it would probably take months until everything works as expected. -
@Cernel Also using an older version of the engine will always be an option ^^
-
@roiex I'm mainly worried about everything in term of triggers changing raw elements of the game and any kind of advanced mapmaking stuff still working and the difficulty about doing such stuff if everything would become less intuitive?
Would a yaml standard allow faster loading and lower RAM requirement of heavy xml?
