Ideas for Future of Map Making and Hosting

LaFayette

Today map making involves essentially stand-alone tools, manipulation of many files, heavy XML editting, and a file hosting and configuration process. While this is still more streamlined compared to where it has been, it's not ideal.

In progress, is work on an updated server technology that will make client-server interactions easier. From there I think there are some pretty nice improvements we could make.

In-Game Map Editting

The first update I've been thinking about is the stand-alone tools. It seems like it would be much easier to instead to start a game, do some edits, then have the game "save the map" as a complete map scenario. I'm suggesting that we bring all map tools into the game proper. In single player games, in addition to an 'edit mode', there would be a 'map making' mode that would expose all the needed map tools and we could re-use the same in-game UI for map creation. The existing tools we would re-incorporate into this mode, essentially a full 'map-making' menu.

Map Configuration Hosting

Editting a raw YAML file has its limits. With the new server, it has for some time seemed to make sense to host the map listing data on the server. Instead of the game client downloading a YAML file and then parsing it, the game client would instead send a request to the server to get a list of the games that are available for download. On the other side of this equation, we could enable the game to also send upload requests. This means essentially there would be an in-game UI sequence where maps, once created, could then be uploaded to the server and made available for download.

Decoupling Maps and Assets - Asset IDs

Last, it would be excellent to avoid redundant downloads of assets, facilitate uploading of individual assets, and allow for assets to always be made available. In part, it seems a win if we can simplify the map configuration and decouple the XML from asset data. Essentially have the maps be more or less just pure configuration data. Given all these details will be mostly hidden behind a UI, this should be mostly transparent to both map makers and players.

To this extent I've been thinking to have an 'asset' uploader as a new tool. It could be for stand-alone assets or would automatically grab all new assets from a new map and upload them with a new map. For example, from in-game, a person could upload flag images, or unit images, etc... On the server side these images would be tagged by an ID. On the map configuration side, the XML would declare its assets by ID and no longer have magic search paths to find the assets. For example:

<units>
   <player name="Americans">
      <unit name="infantry" assetId="5555" />
      <unit name="artillery" assetId="5252" />
      :
   </player>
</units>

When downloading maps, the game would scan for asset IDs and then ensure that it already has each one, any that are missing would then be downloaded.

I've been waiting some time before pitching these ideas as a lot of it is still pretty far off. Given the technology is now becoming feasible, it seem a good time to align the community to this vision and start the thought process of what this all would look like before we start building towards it.

ubernaut

@LaFayette love it!

redrum

@LaFayette Some quick thoughts:

In-game map editing - This generally is a good idea and actually most map makers do this when doing starting unit placements and a few other things already. I'm not sure if the base graphical utilities would fit well into this though as it might be hard to even launch a game without at least the centers, tiles, etc. I think the process today is mostly: run map maker utilities to create base map, copy files from existing map into the folder as a starting point, make some edits to the properties/XML/images, and load up the game in edit mode do things like unit placements.
Map configuration hosting - Sounds like a good idea to me.
Decoupling maps and assets - I like the theory here but the implementation would need some thoughts as to how to handle existing maps and how to avoid making the configuration overly technical as I think it could be difficult for non-technical folks to have lots of IDs over all the XML/properties files vs the names.

LaFayette

Thanks for the quick thoughts/feedback.

We'd have to work out some issues for the blank map. It could be that we start off with an empty map that can be loaded, or there is a quick wizard process that gets a map maker to that point. TBD exactly, main idea though is that the tools would be moved to in-game rather than be completely external.

Glad the idea of map configuration hosting sounds good. Implicit to that idea, is that the entire map would be stored on the server, in DB!! No more github manipulation or uploads. Hence the asset split is particularly useful. If the UI tools are good, then map makers will have a UI to select their assets by image and it will be written into the configuration properly without anyone dealing with IDs. Part of the goal would be to decrease the manual file editing. I suspect a fallback to file system will almost always be there to support offline map making.

I was thinking that the potential new map database could write out to a github repository and check in the contents, largely to serve as a backup. That's a detail for now that is less important compared to the other main ideas.