Announcing EU4 Stats

Let me prefix this by apologizing because this post will be a mix of content for technical people as well as content for those that just want to see statistics for their save game!

Introduction

As briefly alluded to – EU4 Stats is a web application that when given a save game, will generate a series of statistics that you can share with friends.

Everything is open sourced, so if you’d like to contribute to the project (in terms of code or ideas) you are more than free to! This is a pet project of mine, so hopefully someone finds this useful/interesting besides myself!

Limitations

• The application is designed to generate statistics on a given save game and then throw the save game away, the reason being that save games take up several megabytes each and the server only has a couple gigabytes to work with. So if new features are added to the application, the save game has to re-uploaded.
• Only tested with the latest EU4 game (as of right now it is 1.9.2, but obviously subject to change)
• Expect backups at high load. The application is hosted on a cheap server
• I give no guarantees, but accept all bug reports

Behind the Scenes

In lieu of a fancy diagram detailing how the application works, I’m providing a bulleted list of chronological systems that makes everything tick.

• Selected save game is compressed if not already (JSZip used for compression)
• Save game hits an nginx server on a DigitalOcean box, which saves the file to a temporary location
• Reverse proxies the temporary location to a Nancy server
• Parse the file into an in-memory representation of the game (language used: C#)
• Generate a series of statistics based on the game (language used: F#)
• Pass statistics to a Razor template, which creates a static html page
• Returns the url for the client to navigate to for the rendered statistics
• Nginx forwards the request while deleting the temporary location
• Client navigates to page and uses Datatables to render the tables with a little help of styling from Pure.

What’s Next?

This release tests the water for an application such as this. If there is overwhelming positive feedback and suggestions for improvement, I’ll continue working on this in parallel to the next version of this project. I say “next version”, but it is little more than a fanciful thought in my head. I do believe there needs to be next version due to the limitations listed above.

Being tested on only a single version of the game is a serious downfall, but this is due to the parsing of the save game. Between expansions and patches, Paradox will change the save game (add/remove/change fields), which breaks compatibility with the parser. A better approach would be store save games whole, and then pick attributes out when a client asks for it. This would also allow for statistics for a particular game to improve as the features are released. How this should be accomplished is an interesting question. Save games could be stored in S3 as is, and ran through something akin to XQuery for Paradox files on retrieval, and pushed to the client. Alternatively, save games could be converted into JSON and possibly squirreled away in a document store such MongoDb. As you can see, there are a ton of options and this will require a lot of mulling over.

Since more information will be available to the client I’m been thinking of managing it with something like Ember.js. This would make it easier to add features such as user accounts (so one could keep track of all the save games they have uploaded) and create cross savegame analysis.

I think I’m getting too excited now. We’ll see how things pan out, but of course first things first, try out the first version and let me know what you think.