Release 3

Release 3 is a significant improvement over Release 2. This is the first release that I would expect to be usable for anyone else to build a game with. It is still at least an Intermediate level of difficulty, as it requires some knowledge of database setup and web server configuration. Hypothesis will NOT have a corresponding release, since the GeoCache mode depends on a couple of features that aren't working in this release after all.

I might not have listed every change, but the biggest ones should be written below:

• Larry now has a -makeServerDb command, which takes your pbf files, processes them to the intermediate TSV files, and then uploads those to the database in a single command.
• Code cleanup done. Old tables and variable names should now match the concept they represent instead of a technical working name. Unused columns have been removed from the database. Close to 2,000 lines of code, comments, and whitespace have been taken out.
• Output files have now been standardized into a tab-separated values format. GeomData holds the Place entries, and tagsData holds the PlaceTags entries matching the DB tables. The TSV files are much more compact and take up significantly less space than JSON formattted data, and are faster to load into the DB at the cost of splitting data into 2 files. Coastline processing should be hard-coded to output appropriate style info.
• New Styles: A total of 4 default styles are included: mapTiles (roughly OSM defaults), outlines (everything gets a black outline), adminBounds(only draws cities, states, countries, etc), teamColor (A simple style for taggings areas by a team or faction), and paintTown(An example style for a client mode, that draws a color defined in the tag)
• Server's Performance Tracker class is now ASP middleware, so it logs all calls to all endpoints and their runtime. Can read a custom header (X-notes) to save additional data on a call.
• Performance boost: The functions for turning a PBF into intermediate files and loading those intermediate files into a DB are now dramatically faster. This is the biggest change, but most areas of the app have also seen small optimizations to keep the server performant.
• You can now run the core PraxisMapper executable to start up a working webserver without IIS/Apache/etc. This dramatically reduces how much effort is needed to go from nothing to a game server. You can still use a heavy duty webserver in front of the app as before.
• PraxisMapper now supports multiple drawing engines. Included in the project are 2: SkiaSharp (The Windows default) and ImageSharp. SkiaSharp is faster and handles anti-aliasing small details better, but ImageSharp doesn't require any external dependencies and works on Linux without jumping through any hoops. Each engine is handled in its own DLL project now, and which one is loaded at runtime as determined by the configuration setting.
• APIs have been renamed to be REST style, and are a good deal shorter and more obvious on their purpose.
• Clients can now ask for what version a maptile is on, and can track that to know when it needs to download a newer version of the time instead of redownloading every tile every time.
• Old code that was specific to a game mode or idea I was working on is removed from the server core.
• Performance Assumptions: A county sized game (500 mi^2) should run decently fine on an AWS Micro server (2 CPUs, 1 GB RAM) on Windows/Linux for some double-digit number of players. A State sized game (50.000 mi^2) will load on an AWS Micro server but takes dramatically longer to draw map tiles under any load. A Continent sized game will require a minimum of 48GB RAM on the database alone to handle indexes for Place data, and more for MapTiles as users start populating information. Actual results may vary with density of data.
• A bunch of bugs were fixed.