Civ3 Show-And-Tell

Yay! The terrain and bonus/luxury resource information is complete! There are definitely things to be done, but to me this is a very useful milestone.

Terrain-complete map

Web app

The south-corner rivers get overdrawn. I tried adding a circle there, but that doesn't quite get it done. Flood plains also need some extending for tile edges and both north and south corners. But I think I am done tweaking graphics for tonight. I think I'll take a nap or watch some TV.

Progress is a wonderful thing. Not sure where this is going to end, but I like watching it go.

One question, though. Is the black tile here just FOW?

wuhjah said:

One question, though. Is the black tile here just FOW?

Click to expand...

Yes. Here's a screenshot of that area in-game.

You've made some very nice progress. The combination of the progress here, as well as Antal1987's work, which I haven't had the time to keep up on, has inspired me to go back to my editor and add fog of war support. If you've managed to get fog, rivers, and resources in a few days, fog of war in scenario files can't be too bad! You've really been on a tear the past two weeks!

I did try out the ability to link to your own map, but couldn't get it working. It may be because I was trying to link to a Google Docs page that was HTTPS? It was publicly accessible, but I think Google Docs is all HTTPS now, and I'm nearly out of CFC attachment space.

Quintillus said:

You've made some very nice progress. The combination of the progress here, as well as Antal1987's work, which I haven't had the time to keep up on, has inspired me to go back to my editor and add fog of war support. If you've managed to get fog, rivers, and resources in a few days, fog of war in scenario files can't be too bad! You've really been on a tear the past two weeks!

Click to expand...

Thanks! Yeah, it's a mini-renaissance here. I hope it catches on and more people play and post.

I did try out the ability to link to your own map, but couldn't get it working. It may be because I was trying to link to a Google Docs page that was HTTPS? It was publicly accessible, but I think Google Docs is all HTTPS now, and I'm nearly out of CFC attachment space.

Click to expand...

I just tried it. The "share" link Google Docs gave me takes me to a "friendly" interface rather than directly to the file. My web app needs the link that returns the actual save; it can't deal with a user front-end. I have yet to figure out how to coax that from Google Drive, but I've only tried for about 30 seconds.

Edit: But DUH, this is how this project should work. I've had my own web server for over 10 years now, so I'm used to having my own place to offer files publicly. But nowadays anybody can share files on GD, One/SkyDrive, Dropbox, etc.. I definitely want to figure out how to make it work with cloud storage to read saves.

Edit 2: Updated so it's no longer spoiling BGs under forests, marshes and jungle (not sure you could see it past the jungle art) or drawing never-seen BGs under mountains and hills. (Yes, hills and mountains have grassland as base terrain, and some of them have the BG flag on. If you could "clear mountain" or "chop hill" you'd find BGs under some of them!)

I messed around with Google Docs share links some more. I was able to rearrange the URL to get to the file directly (well, with two auto redirects) in a browser, but for some reason my app still choked on it. I'll need to capture what's happening; I'm taking a wild guess that Google is disallowing scripted access to files. I'll have to see if there's an API...Google has an API for everything.

I think I improved floodplains since my last update, but nothing else of note.

I started this in Python on Linux for various reasons that make sense only to me. (Edit: I guess you can say that about this entire project.) And except for my brief port to C# (which I still haven't looked for, but it's probably around here somewhere) I've been banging on this in Python & Linux. Today I installed GitHub for Windows and IronPython which implements the Python language on the .NET framework. After cloning the repo to Windows I had to make a minor adjustment or two due to the way symlinks are handled, but for the actual code it just freakin' worked. So I think that means I should be able to make a Windows .exe that can turn an uncompressed save into an SVG. Maybe. I haven't tried it yet.

Puppeteer said:

So I think that means I should be able to make a Windows .exe that can turn an uncompressed save into an SVG. Maybe. I haven't tried it yet.

Click to expand...

Well that was more painful than I imagined, but I did it. If you want to make an SVG map of your uncompressed save file (autosaves are uncompressed, or you can find a utility somewhere to decompress it, but it's not common like Windows zip or 7-zip).

Download this huge honkin' zip file (5 MB, about 18 MB when you unzip it), then run makeSvgMap.exe <filename> or pipe it an uncompressed save.

Example:

makeSvgMap.exe "C:\Program Files (x86)\Steam\SteamApps\common\Sid Meier's Civilization III Complete\Conquests\Saves\Auto\Conquests Autosave 3350 BC.SAV"

Click to expand...

And it will make a civmap.svg in the current folder which you can view with any line art editor (Inkscape, Illustrator, etc.) or modern web browser either directly or with viewer.html .

One of the reasons the package is stupidly huge is that I had to compile and include the entire standard Python library else lose my mind and give up. This is closer to an Alpha than a Beta, and it is far from a finished product, but it's something many given Windows users might be able to try out if they were so inclined.

Nice! I tried it on an old, decompressed save game from my story-in-stasis, and it works! It's definitely the right map. I'll need to install Inkscape to zoom in, but Opera 11 and Firefox 24 ESR are displaying it well directly, if a bit small.

And it is better with viewer.html. Particularly in Firefox, as it gains in fidelity when zoomed in. Nice work!

For my Google Drive attempts, the main link is here. But I attempted it with the full link that I copied from Opera's download history. Although I notice that if I paste it in another browser where I'm not logged in to Google, it fails, even though it is supposedly shared to anyone with the link. Apparently that actually means "anyone signed into Google with the link" . However, if I upload it to Google Sites instead of Google Drive, the full link is here. And... uploading the same file that I tested with on Windows, it works! It takes 5-10 seconds to render, about the same as the Windows version on my computer, but then it's just as good as the Windows version.

I also realized that a compounding factor in it failing before was that I'd been trying with a compressed save. The Windows version complained with a "wah wah wah wahhhhhhh" error when I tried that, at which point I realized compressed files aren't supported yet. I'd thought they were for some reason. Even with Google Sites instead of Google Drive, the compressed one doesn't work.

Quintillus said:

I also realized that a compounding factor in it failing before was that I'd been trying with a compressed save. The Windows version complained with a "wah wah wah wahhhhhhh" error when I tried that, at which point I realized compressed files aren't supported yet. I'd thought they were for some reason. Even with Google Sites instead of Google Drive, the compressed one doesn't work.

Click to expand...

Sorry I was in a weird mood when I put in the "sad trombone" "wah wah wah wahhhhhh" in the compression detection and forgot about it. I was smart enough to leave out less appropriate responses that occurred to me at various times.

Automated compression detection has gone in and out a couple of times and currently relies on the linux "blast" command which isn't distributed with the project. Today I'm trying to compile blast for Windows and half-succeeded. It is bombing out in the middle of decompression but up to that point is producing appropriate output; I think the problem is Windows stdin/stdout and redirection, but I think I'm going to attempt to use blast as a dll and see if that works, bypassing cmd pipe handling. I expect the same technique would work for Mac, but I don't have a way to test it myself. On the other hand Macs include Python, so the rest of the code should work as-is.

Every browser should be sharp. If it isn't, try the "Webkit Redraw button. Webkit browsers (Safari, Chrome, Chromium etc.) seem to not always redraw after scaling.

I'm not on the same tear I was for two weeks, but this project is still in my mind. Visually I need to add graphics/icons for the remaining resources, improve the rivers similar to how I improved floodplains, and add some additional river/floodplain logic. (Currently with FP if there is e.g. a river along the SW edge and a corner of another river at the N corner, the corner does not draw.)

What I want next is not entirely clear to me. If I start adding more information such as city names, improvements or units I want to be able to switch layers on and off. I also find what *I* want to do with my new toy often is to look back at how the AI or the barbs progressed. I can manually change the fog of war to show any player's fog, so effectively I can see how the AI scouts and expands and where the barbs go when nobody's looking. I would also like to see an aggregate known world. It would also be cool to enable replay for any of the above. Since I run CAII and have it keep all my save files, I can do that. (Not trivially, though.)

Also, aside from worker improvements, any additional information will require reading other parts of the save file, and for some reason if I'm reading other parts of the save file I'd like to make a report out of it. That ultimately duplicates combined features of the game and CAII, but I find myself wanting to do it anyway.

Which means I'm also considering and redesigning in my head the structure of the data, the program and the output. My next structural decisions will affect a lot of other decisions going forward. And since I overthink things, anyway, I may be stuck in this phase a while.

For map visualizations, based on performance to date I think I'll have to have multiple SVG files overlaid. I would prefer to put all the SVG into the browser DOM and manipulate it there, but that gets much slower, especially in IE. Or perhaps some of the layers can be generated in-browser with javascript; mainly I'm thinking of territory shading and other ad-hoc highlighting for in-DOM operations.

I'm also trying to figure out the best way to allow spoiler use without making it too easy or tempting to spoil another's game for them. But maybe I should just put in warnings and rely on people not being dickish, because it would be really cool to use this on various save games to see how all players are progressing.

Edit: Which brings me to another thing to consider: UI. I am now envisioning where I want to say "view world as player 2", "view aggregate known world all players", etc. which requires UI of some sort or other and also makes me need to decide if I'm reparsing the save each time or if I will have my own data store and redraw from it.

I like whimsical error messages for what it's worth.

After realizing it was decompression that was needed last night, I went ahead and did a small utility that I've been thinking of doing for years - a decompression utility. If blast doesn't wind up working out, you'd be welcome to use the command-line version of it (link in sig) for decompression. Blast might be preferable if it does work and doesn't have external dependencies, as the decompression utility I uploaded requires Java (although the program using it can be in any language), but it's there if needed. The idea is that if someone's working on a utility, they can use it plug-and-play for compression, no matter what language their own project is in.

I think, to me, cities and territory borders would be a cool next direction to go, and really help with following along in games. And I suppose another thing that would help in that direction is some way to easily link to a game (without whoever wants to view it having to upload the map themselves, since most lurkers wouldn't already have the SAV).

I'm actually starting to look at changing some of the architecture of my editor. It's probably good you're looking at that now, before you have too much baked in. In my case I'd like to separate the logic from the UI, so I can upgrade the UI while still having a working version, updated, with the old UI, but after 5+ years of tying the UI to the logic, that's not nearly as easy as it would have been in 2009. But that was also one of the first larger projects I'd programmed on, and the first larger one with a UI, so there's a lot of design carryover where I probably wouldn't have made the same choice today.

I tried the WebKit Redraw button today, but it didn't help in Opera 11/12. I'm not too surprised it didn't, though, since the Presto engine isn't WebKit, and hasn't been updated other than security fixes since 2012. I don't think it's unreasonable to have to use a more-recently-updated Gecko engine instead. I already use it for certain sites such as Spotify and editing using Google Docs (though I don't actually edit in Google Docs very often). I don't have any WebKit browsers installed on my home computers, so someone else will have to be the test case for that.

I am way too busy to work on this or even play the game lately and for the near future, but my thoughts come back to it occasionally.

I wouldn't say I've worked with MongoDB, but I'm seeing how it's used several places, and I am thinking about using it as a back-end store for game data. In terms of mapping and C3SAT, I think I want to dump all known and pertinent data from the save file into MongoDB, and then pull from MongoDB to create the desired map(s). I've babbled and thought about what kind of data I want in the map, but if it's all in the DB I can pull it upon request instead of stuffing it all into HTML/SVG/JSON and throwing at the user.

But I'm also thinking bigger than one turn / one save at a time. The map--and much/most of the game data--doesn't change much from turn to turn. If I'm importing a new save game file and already have that world seed in the DB, only store the changes. I haven't worked out the "how" yet, and I haven't even installed MongoDB and played with it yet, but I think I can store only changed data but have keys or filters or somesuch so that I can pull any imported turn from the db without massively duplicating data on each import. Doing so would allow replays, even if I don't have every save game. Imagine if I import/upload turn 0, turn 100 and turn 300. I should be able to "replay" turn-by turn, showing new cities as they are founded and simply fading in the newly-revealed terrain.

As far as what to key on for games and turns, world seed and turn number are obvious, but what if I replay the same world save? What if I go back 20 turns and try to import different forks of the same game? If the app is running local to the game, it can key on game save file dates, and in some cases it may be able to get this from URIs. I may also be able to go by time spent in-game, which must be stored in there somewhere because it tells you when you end the game. Well, such thoughts are interesting, but it's not a problem that has to be solved early.

Edit: Ephiphany: was just rereading my last few posts, and re Google Drive problems, I said there were two redirects. The epiphany is that I probably need to ensure my call is following redirects a la "curl -L", but in urllib.

That sounds like an interesting idea for being able to re-play the game. I definitely think it should be doable and save space over storing each file - but indeed, the "how" is not easy. Does it make sense to pull the save apart and store changes in the database, and if so, how? I've never dealt with the code of programs that deal with this sort of problem, source control coming to mind, but there's surely a way that's better than storing every file.

For forks of the game, it may work as well as anything to work that into the UI for uploading. Let's say I upload a 4000 BC game, and then 2750 BC and 1600 BC games. In each upload, I could fill in a drop-down or something linking it as a continuation of a previous game. Then in 1575 BC, Montezuma invades me and I realize I'm hopelessly underprepared. But it's a sweet map, so I load up the 2750 BC save and play it awhile, saving and uploading again at 1250 BC. I could then choose it as a continuation of the 2750 BC save rather than the 1600 BC one. If the default were to have it continue from the previous one (1600 BC) is probably would be good to have some fail-safes, too - such as the program could check whether cities were built in the same places as the previous saves, and if not ask the user if this really should be a continuation.

Time spent in-game is a good idea, but I don't think it would always work. In the example above, the time played would probably be higher by the 1250 BC save than the 1600 BC one, so that alone wouldn't detect that it wasn't part of the same string of saves.

Redirects makes a lot of sense as to why Google Drive didn't work. I actually had a project at work myself that involved checking a bunch of URLs, and following redirects was one of the things that I had to turn on to do so properly on sites that redirect. Occasionally there'll be an infinite-redirect situation, so I did have to put an upper limit on it (curl might do that for you?), but if that does solve it it would be awesome.

In the short term, I think the #1 thing necessary to get Civ3 Show-And-Tell to where it can be widely used is the ability to easily upload a save, and get back an SVG. Redirecting might solve it well enough for external sites to work, although IMO it would be nice to also have a "Upload from my computer" button. If you add a "Save SVG" button that will let the user save the SVG file locally, then they can re-upload it and it shouldn't be necessary to keep them forever on your server (although what's a good hosting site for SVG files? I don't know yet. So if space isn't prohibitive, being able to keep them and using a link might make it more attractive to Civ3 players). But in the end, it ought to be able to post something like:

Future Civ3 Player said:

So, here's the latest on the state of the empire. It's really nice to not have to stitch together a giant world map like in the old days!

Spoiler Civ3 Show-And-Tell Map :

You can see the changes from the last 50 turns at the Civ3 SAT page.

Click to expand...

In this case I've just linked to your example SVG file, but I don't think it's far off from being able to do that easily with user-created files. And of course it somewhat is doable today - upload to a site without redirects, right-click download the SVG, find somewhere to host SVGs - but probably needs just a couple additions to reach a point of general adoption. Longer-term, it might be nice to be able to easily copy an SVG link that could be embedded in a post, as well as a link out to the Civ3 SAT page for anyone wishing to peruse (which I've simulated in the quote with a made-up URL). But I'd focus on improving the UI just a bit first so that, hopefully, these maps start showing up in other posts soon.

Regardless, I'm glad to see an update post, even if it's just thoughts on future direction. I still think this is one of the most promising utilities in development, particularly for the interactive, community-focused part of Civ3, and despite the disclaimer in the first post that you'd never follow through on it, I think you're very close to actually having followed through. I definitely understand the not having time to work on it part, though. I'm just glad that there probably is a future for it.

Quintillus said:

That sounds like an interesting idea for being able to re-play the game. I definitely think it should be doable and save space over storing each file - but indeed, the "how" is not easy. Does it make sense to pull the save apart and store changes in the database, and if so, how? I've never dealt with the code of programs that deal with this sort of problem, source control coming to mind, but there's surely a way that's better than storing every file.

Click to expand...

Oh heck yeah. I'm not using all the data from the file, so I'll only put what I might want in the DB. The easiest thing to do is probably to assume that files are imported in chronological order, and that a hash of world seed + game/world settings uniquely identifies a game, get that working and then deal with customized maps, replayed maps and edge cases. In that case, after I determine the map in the current save file matches seed & settings from one already imported, compare each tile and only store updated tiles. Then through some magic I haven't really figured out yet, have an index that can query the proper set of data upon demand.

I know existing analytics tools can have data tagged with from/to timestamps, so some permutation of that could work for slicing the 3D map (time/turn being the 3rd dimension) into a 2D map.

Once the basics work, dealing with edge cases might involve fingerprinting the base terrain at preset intervals, hashing some sort of table of civ IDs, names and start locations and other such things.

In the short term, I think the #1 thing necessary to get Civ3 Show-And-Tell to where it can be widely used is the ability to easily upload a save, and get back an SVG. Redirecting might solve it well enough for external sites to work, although IMO it would be nice to also have a "Upload from my computer" button. If you add a "Save SVG" button that will let the user save the SVG file locally, then they can re-upload it and it shouldn't be necessary to keep them forever on your server (although what's a good hosting site for SVG files? I don't know yet. So if space isn't prohibitive, being able to keep them and using a link might make it more attractive to Civ3 players).

Click to expand...

I tend to over-plan and over-think things. I can probably store and serve everything myself and not run out of space or bandwidth even if every actively-posting Civ3 user on this site used it weekly or maybe even daily.

After some more thought today, an architecture is emerging:

File provider --> validator/decompressor --> importer --> storage
Map/data UI pulls from storage

The file provider in the case of the web app is the upload or URI fetch UI. In the case of a local version of the app, this would be the part that watches the autosave folder for updated files.

The validator/decompressor will have whatever sanity/security checks I want and ensure a decompressed save file gets fed to the importer.

The importer will have any compression concerns removed and simply turn uncompressed save game data into stored data. Today the storage is an SVG file. In the future it may be a MongoDB data store. I will need to include some logic to the current version to store separate SVGs without overwriting old ones. And if I put in a DB backend the importer may be the place to put the deduplication logic. (Hmm, actually I don't think I want those in the importer...I might need another program in the data flow. Maybe the importer should be split in two: a converter that outputs structured data from the save file and the importer that worries about how it needs to be stored.)

The UI will be a web browser for the foreseeable future, and probably forever. This will work whether the app is local or hosted. Currently it's just viewer.html, but anything I can think of doing can be done with HTML and Javascript. The "storage" is currently an SVG file, but even if it goes to a DB backend I'll have an API the browser can call to get the map data.

Regardless, I'm glad to see an update post, even if it's just thoughts on future direction. I still think this is one of the most promising utilities in development, particularly for the interactive, community-focused part of Civ3, and despite the disclaimer in the first post that you'd never follow through on it, I think you're very close to actually having followed through. I definitely understand the not having time to work on it part, though. I'm just glad that there probably is a future for it.

Click to expand...

Thanks! It is close to being usable, isn't it? I want it to have some more visual polish and have the resource icon set complete, but it really doesn't need that to be usable, does it?

And given my architecture thoughts, I could make the "file provider" (uploader), figure out how to handle the multi-file SVG storage and retrieval URIs, get it working as-is and then I can go the MongoDB route without even changing the upload UI or map view URL. Come to think of it, there must be plenty of existing projects or code to handle uploads and downloads of user-submitted content. Hmm....

Puppeteer said:

Come to think of it, there must be plenty of existing projects or code to handle uploads and downloads of user-submitted content. Hmm....

Click to expand...

I've done some quick searching and am overwhelmed by projects that don't do what I want. I want server-side Linux-based free/open-source software that can have a user upload a file via web browser and internally give it a unique name/ID (to avoid filename collisions).

I can probably handle the logic from there, but I want to prevent it from being used as an unrestricted file share, so I will have it only accept .sav files, impose a file size limit, and prevent anyone from being able to download it until another process can validate it as a C3C save game file. I want to be able to retrieve the original filename and perhaps other metadata such as when it was uploaded.

Does anyone know of such a project?

Edit: Note to self. Fine-Uploader has server-side examples. Maybe I can cobble together from that.

I'm probably over-thinking it again. Uploading shouldn't be that hard, and I can easily upload to a folder that can't be accessed for downloads (to prevent becoming an anonymous file share service). Then another process can watch the upload folder and process new arrivals.

The trick will be handling duplicate filenames uploaded near-simultaneously and providing a URL back to the uploader to view the appropriate map. But those shouldn't be too hard.

Oh, apparently I can upload directly into MongoDB, and if I understand correctly I get the unique ID / anti-name-collision for free. That should make a lot of things easier, and I can store and serve the output SVGs from the current version in a similar manner. There is a 16MB limit for doing that without GridFS, but I want to cap file sizes anyway, and I'll check but I think 16MB is bigger than I need for an upper limit to a save game file. (I'll go find a late-game huge map SG save and see how big it is.)

As for minimizing duplication, I realized it doesn't matter if the data is uploaded in chronological order. Whatever fingerprinting / hashing / indexing method I choose, whichever key uploaded first stores everything, and then each same key can refer to the original and just store the differences. In the storage it doesn't matter what the game chronology is, just the reference data set and the changes.

Holy #%@. I just realized that MongoDB may be able to do some of the data extraction itself. That's kind of what it does, supposedly. Ok, I'm getting excited about the possibilities. Or it may just be that every problem is looking like a nail now that I'm getting a new hammer.

Okay, FineUploader was a bit weird. They claim open source & GPL3 but make it hard to use without paying them, and I gave up when I saw wording to the effect you could build it yourself if it wasn't for commercial use. WTF, that's not how open-source works. Not that this is commercial, but I didn't want to futz with them anymore.

So I tried https://github.com/blueimp/jQuery-File-Upload instead. It has a server handler in there, too, that I didn't see at first, so that's nice. I now have it uploading files, and it will rename them with a " (1)" etc. if filenames are duplicated, so that's nice. (This isn't public yet. I still have some dots to connect.)

Notes to self:
Had to not only enusre that php.ini post_max_size and upload_max_filesize were set large enough (12M for now), but the web server--in my case nginx--also needs to be set to allow client bodies larger than 1M with client_max_body_size.

After lunch I'll make sure I have it uploading the size limits I want and then see if I can get it to store in MongoDB instead of the filesystem.

Edit: More dev notes: Setting client_max_body_size in a location block didn't work for me, but putting in server worked. I'm guessing there's a hierarchy and I may need to set the server to the max I want, location / to 1m and then set again at my real location. I'll also probably need to update the nginx cache/distributor when I set that up to allow the larger uploads for certain locations.

OMG, I know MongoDB has GridFS. I'm finding it very hard to find info on storing a file without it even though I read I can store up to 16MB in a single document. Here is the most helpful thing I've found so far. Everything else either says "use GridFS" or "helpfully" explains how to upload a file to the FS and then insert it with another command. Another edit: although I may have to do this anyway. I am concerned a long-running upload direct to Mongo may cause a long-lived db lock that may cause me problems.

Yet another edit: Upon further thought, I don't gain much by putting it in the db. I can just assign a random or unique filename and keep the original filename in the db. I think that will be easier in the long run. Yeah, and I can treat the SVG output filename the same way; rather its ID prefix will match the originally uploaded file.

Ok, this is not pretty at the moment, but it seems to work.

http://civ3.bigmoneyjim.com/basic.html

Drag and drop a save file onto that web page or use the "select file" button to upload a save. Compressed or uncompresed. Any Conquests v1.22 save should work. In a few seconds the conversion will start and you can see the results here:

http://civ3.bigmoneyjim.com/maps-alpha/

Clearly a lot of UI work needs to be done, but now anyone can upload any C3C save file and get an SVG map.

The map generator itself has not changed (except I'm printing the svg code to stdout instead of a file name so the monitor script can pick the file name). What my server does is:

• Check the first 4 bytes of the file to decide if it's a compressed save, uncompressed save or not a save file at all
• If valid, pass the file through the map generator, decompressing first if necessary
• If successful, move the uploaded SAV file to the maps folder alongside the map
• If not successful, move the uploaded file outside of the web tree (so I can see why the map generator is failing and/or to prevent people from uploading/downloading non-save files)

Clearly some web UI work needs to be done, but it makes maps as-is. Currently you can view the svg file directly, but the pan/zoom map viewer isn't there yet. Also, currently valid save files uploaded with the same name will overwrite an older save/map with the same name.

Thank you for your work, Puppeteer

You're welcome, and thanks!

I've been working on this in my head as to how to make it more usable now, how I want things in the future, and how to make those two goals complement each other instead of compete with each other.

I think the UI needs to be visually one web page with various options and controls along the top and left sides, and eventually an optional info list on the right. (The right side being for lists of troops, cities/sizes/production, etc..) The middle is the map view. In the future, maybe the non-map parts can optionally hide or even pop out. The upload UI can be on this same page, too.

So I'll need the viewer html as a webapp that gets input via the URL as to which map to view. And then it will do an HTTP GET for the map SVG based on the input. But It also needs to know a list of available maps, and for each map it displays it should be able to provide the corresponding save file URL and an error log URL. Currently the available maps will be a modified and sorted file list; eventually it will be a page-able, searchable, sortable, tag-able map picker UI.

So the viewer is an API that loads the viewer page and optionally displays a map based on input from the GET parameters or the extended URL. Another API will return a list of available maps, preferably sortable by date uploaded or alphabetically. I think I need a third API to return metadata from a specific map, in today's case the original SAV file URL and a log file URL to see if there were errors.

Ok, I think I see what needs to be done next to both make it more usable now and pave the way to my future ideas.

Here are some random ideas that have recently gone through my head but aren't nearly ready to implement:

• A feature for COTM to limit map generation to starting landmass or other mappable area. I think this could be done by using an open player spot's visibility mask to mark the world mask, and/or a continent ID can be stuffed in there somewhere and the map can show just that continent or maybe that continent plus immediately-adjacent tiles (coast).
• Have the map canvas the size of the visible map.
• Have a minimap. This may be as simple as showing a small duplicate of the full map, possibly with some features omitted.
• Allow for PNG or JPG creation of map snapshots for hotlinking to discussion forums (e.g. this one). Perhaps include cut-and paste BBCode. I like this idea. At some point maybe the cut-and-paste code is a small bit of filled-in boilerplate info about a save.