Small Market & Roads

With more work happening on the actual business units and gameplay it became apparent quite quickly that the previous ‘market’ (which was a huge building with huge maintenance cost primarily due to its number of employees) was in no way able to generate a positive ROI. Sure, if cities were bigger and there were more products to sell to the consumer, things would look differently. But not the way the game operates right now. So let me introduce you to the new ‘General Store’:

Since it is much smaller it is also much cheaper to operate. Still not cheap enough to turn a profit, but at least it keeps certain bankruptcy many years away.

As you can see on the screenshot, I have also added roads. Those are cosmetic only! Margin Magnate is not about sending trucks from A to B or building a vast logistics network. There are other games specializing on things like that: OpenTTD, Factorio, &c. But they really help to hold all the different buildings together, like concrete glue. The world looks much better with them.

GDPR

With the 25th of May 2018 not being far off, I finally took a closer look at making sure Margin Magnate is GDPR compliant. And while Margin Magnate is an offline game only, there are 3 functions in the game which collect data and send them off over the intertubes.

Benchmarks

Benchmark data contains no personal data. It is only some hardware information (CPU make, speed, RAM, GPU type, driver version, &c.) and the actual timing information. The web-server receiving the data does not save any metadata that is considered personal data (which would be the IP address) with the data either, nor does it keep logfiles. Thus the benchmarking functionality is free of any sensitive data and is not covered by the GDPR. But I have updated the layout shown before running the benchmark to include information on: which data is collected and a note that no personal data is included, for the sake of transparency.

Crash Reports

When Margin Magnate crashed, it transmitted the logfile together with a Minidump file (Windows) or a macOS internal Crash Report to a server; after asking the user for permission, of course. It was neither transparent what Microsoft puts into a Minidump file, nor if Apple might change the format and content of those internal Crash Reports. Thus they were very much unsuitable from a GDPR standpoint, since it was impossible for me to know what data was stored in those files. And without knowing myself what data got included I could never comply with the GDPR. The only useful data in macOS Crash Reports was the stack-trace, while Minidumps contained a stack-trace and some data used in the current execution context. This data is enormously helpful to figure out why a crash happened, while a stack-trace alone only tells me where a crash happened. However, this tiny bit of data could be a user-defined string which may very well contain personal data, like the username or home-directory.

Storing only the stack-trace during a crash was the only way to make sure no personal data is included. While this makes debugging much harder, I see one big advantage: It allows me to make crash-reports opt-out (options menu) since there is no sensitive data included. And I would rather know about every crash there is, instead of only a few people consenting to transmitting helpful data. This is a huge win!

So all that was left was to implement ways to generate stack-traces under Windows and macOS as well as making sure the rest of the logfile does not contain personal data.

Feedback

Now this is the difficult one. And it saddens me that the only solution I could figure out is to disable this functionality for EU-citizens completely. Again, there is no personal data included when sending feedback from within the game. However, since a savegame, two screenshots of the game (with and without the UI) and the actual feedback-message are transmitted it may contain personal data: The name of the CEO may be the player’s real name; same thing for company and brand names. What if the player decides to enter any personal data into the feedback message? (“something constructive, and thanks - RealName“ or ”.. you can contact me at mail-address@real.name“)

I am not sure on how to handle those situations under the GDPR. I do not want your personal data! Even if I anonymize the savegame and screenshots by replacing all user-customizable strings by generic ones I am still left with the actual feedback message. Do I have to assume the worst case: that any field that allows players (or users on webpages for that matter) to enter any text freely contains personal data? Even more so: sensitive personal data (which is another class of personal data under the GDPR, resulting in stricter rules)?

Assuming I have to handle every feedback message like sensitive personal data, I am considered a Data Controller under the GDPR. Since my server, where all the data is uploaded to, is hosted by another company (considered a Data Processor) I need a contract with them to make sure how the processing and exchange of data works. One part of that contract is to list all classes of data I hand over to them for processing. But since I have no clue what data someone might send as feedback, I cannot answer that question. The same applies to my general obligation as Data Controller to have an answer to that very question for the actual players: what data will be stored, where, how long and why. Oh, and what happens when a non-EU-citizen uses the feedback functionality to enter personal data about an EU-citizen?

I guess it is probably best to disable the feedback functionality completely (and not only for EU-citizens) for the moment, until the dust settles and it becomes clear how the GDPR and user-generated-content interact.

But this saddens me deeply, since generating feedback directly from within the game and making it available to testers via Discord for immediate discussion is such a great thing to have during development.