Skip to main content

From admiration to contempt - Frontier Development plc & Elite Dangerous

This post is somewhat unusual to this blog, this time it is not about syslog-ng, home automation or electronics: I would like to share an experience I had recently with a Frontier Developments plc, a Video Game company, a quite respectable one at that.

The story starts ~30 years ago, when I was a boy in early teenage years, saw a game called "Elite" on a friend's computer, running on a C64. The friend also had a floppy drive for his C64, which cost a fortune (roughly the same price as the main computer, as it was using the same CPU). I didn't have a floppy drive, so the only times I could peek at the "game" in admiration when I was my friend's place. I only remember that the game itself was not much more than a 3D wireframe. You had to dock by spinning at the same speed as a square in front of you, that represented the docking bay. We, my friend and I, were not really successful in playing the game, but nevertheless I still remember it, even though I am not a gaming person myself. (well, if you discount electronics and DIY stuff :)).

Fast forward 30 years, my son is roughly the same age, 12 years old. He started playing Elite Dangerous by a recommendation of my - not the same - friend. I felt nostalgic and remembered my earlier encounter of the predecessor. 

He was immediately hooked up: he immersed in it and started playing: exploring the galaxy, trading goods, fighting pirates, etc. And the best thing is that although it was just a game, it is so realistic and the background story is so detailed that there's a lot to learn. Astronomy, various - imaginary - space ship propulsion systems (super cruise and frameshift), how to trade, exploring uncharted star systems, etc.

My kid is pretty smart: he researches the games he is playing and tries to understand it to the tiniest details. This was the same with Minecraft, where he was able to use command blocks and redstones (quite akin to a simple electronics element) and came up with his own resource packs and maps.

In Elite Dangerous, following his tracks in Minecraft, he quickly delved into details and acquired an understanding of the game at a level I had a challenge to understand.

Then, one evening, my kid came to me crying, saying that he is unable to play and that his account was banned permanently. The notification was mentioning an earlier warning, which we found at this point in Gmail's spam folder.

The email itself was very official and claimed my kid has performed "client manipulation" and quoted the relevant parts of the EULA, stating that he didn't change his behavior since the warning, so the ban is permanent. We were given the option to open a support ticket as described here, but at the same time it was indicated that we shouldn't hope too much.

The email had no information whatsoever about the kind of client manipulation he actually performed, claiming that telling us would potentially give us sensitive information about trade secrets and their security processes.

We were puzzled. 

Imagine how devastated my kid was at this point: he spent a lot of time and energy into building his account, and the company is taking it away without a valid explanation.

As a father, I consider it an important part of my job to highlight rights and wrongs to my kids, as life happens. For instance, I always buy legitimate software (games included), and I always tell him not to cheat, highlighting the reasons why these things are not good things. 

This time, I was unable to come forward with an explanation on my own, so I was trying to get as much information about the ban as possible: opening support tickets, posting on Twitter, writing this blog post. All aimed at getting more information in which Frontier Development plc was not very forthcoming: the same message repeated every time.

As a manager in my past, I've learned that conflicts are always resolved by communication and by digging for information. So this is what I've learned when I confronted my boy about the question that the email claimed:

  • He found an article on the internet that describes how to change the colours in the game. He followed that article and changed the colour of the HUD.
  • He was recommended to use inara.cz, a site that helps with planning trade routes by showing how much anything costs in the game. The status of Inara seems pretty legit, a number of people discuss its use even in Frontier's forums and is available for all. Here's a reddit thread where players discuss its use and that it is a great tool.
  • Inara.cz is only a webpage, it is not installed on the client and is not touching the game at all, it simply collects information uploaded by Elite gamers all around the world. Players can even "connect" to one's Frontier account via public API. 
  • There are tools that build on top of Inara and the Inara API. I don't understand these in details, but the use of these tools is discussed by players, like in this Reddit post. These seem to sync data from the game to Inara. Again, Inara is pretty up-to-date, so a lot of folks do this. Most of these are not shady programs, they are open source and available on github (e.g. https://github.com/EDCD/EDDI), EDDI is even crediting the game itself as something that makes its development possible.
  • He installed some of these addons and then forgot about them. Again, the use of some of these is actually "best practice" in Elite gamers.

All in all, he was playing as a smart 12 year old kid, trying out things as he found them. In any case, the email that claimed that he was doing "client manipulation" completely puzzled him, and said he would never cheat in the game.

There's no official statement or any kind of response from Frontier whether Inara, the Inara API and these addons are considered cheating or not. Some say they should be part of the game and Frontier is leveraging these community efforts for free.

The definition of cheating is an entire topic in their forum, but Inara does not seem to be on this list. Inara is now collecting information directly from Frontier's servers. Which should be an indication of acknowledgement.

Here comes my biggest issue: I understand that my boy may have done something they consider "cheating" (no clear rules though), but in my opinion it is by far not something that (quote):

... where a player is having a detrimental effect on a large number of other players or our community. ...

And even though I am a customer, the vendor one-sidedly decides about the above and does not listen to queries of information, doesn't try to understand the situation in detail and does not give our money back and what's more it does not consider the time and energy that went into a game anything worth.  Frontier staff is blindly following a process and does not care about the consequences. I guess because the consequences don't fall on Frontier: the victim is the 12 year old who was hoping to have some fun. They run their process  against a 12 year boy, with carefully worded legalese, who does not get any feedback to learn from and who does not get a second chance.

I understand that the size of the crowd around these games is huge, and that processes and automation helps managing this crowd. But I exchanged emails/tweets with a number of individuals, who all work for this company, and not one, NOT A SINGLE ONE had the authority (or willingness) to escalate from the process, consider the bigger picture and give an account back to a 12 year old boy.

And this is a company which says on its career page:

At Frontier we believe your work should be rewarding in every way.

I hope that handling our case was indeed very rewarding.


Comments

Anonymous said…
I'm curious to know what Frontier's explanation for this is, please post a follow up if you do get more information.
Bazsi said…
I did not get any response and honestly at the end I gave up. Probably as expected by them.

Popular posts from this blog

syslog-ng fun with performance

I like christmas for a number of reasons: in addition to the traditional "meet and have fun with your family", eat lots of delicious food and so on, I like it because this is the season of the year when I have some time to do whatever I feel like. This year I felt like doing some syslog-ng performance analysis. After reading Ulrich Deppert's series about stuff "What every programmer should know about memory" on LWN, I thought I'm more than prepared to improve syslog-ng performance. Before going any further, I'd recommend this reading to any programmer, it's a bit long but every second reading it is worth it. As you need to measure performance in order to improve it, I wrote a tool called "loggen". This program generates messages messages at a user-specifyable rate. Apart from the git repository you can get this tool from the latest syslog-ng snapshots. Loggen supports TCP, UDP and UNIX domain sockets, so really almost everything can be me

syslog-ng roadmap 2.1 & 2.2

We had a meeting on the syslog-ng roadmap today where we decided some important things, and I thought I'd use this channel to tell you about it. The Open Source Edition will see a 2.1 release incorporating all core changes currently in the Premium Edition and additionally the SQL destination driver. We are going to start development on the 2.2 PE features, but some of those will also be incorporated in the open source version: support for the latest work of IETF syslog protocols unique sequence numbering for messages support for parsing message contents Previously syslog-ng followed the odd/even version numbering to denote development/stable releases. I'm going to abandon this numbering now: the next syslog-ng OSE release is going to have a 2.1 version number and will basically come out with tested code changes only. The current feature set in PE were developed in a closed manner and I don't want to repeat this mistake. The features that were decided to be part of the Open

syslog-ng 3.0 and SNMP traps

Last time I've written about how syslog-ng is able to change message contents. I thought it'd be useful to give you a more practical example, instead of a generic description. It is quite common to convert SNMP traps to syslog messages. The easiest implementation is to run snmptrapd and have it create a log message based on the trap. There's a small issue though: snmptrapd uses the UNIX syslog() API, and as such it is not able to propagate the originating host of the SNMP trap to the hostname portion of the syslog message. This means that all traps are logged as messages coming from the host running snmptrapd, and the hostname information is part of the message payload. Of course it'd be much easier to process syslog messages, if this were not the case. A solution would be to patch snmptrapd to send complete syslog frames, but that would require changing snmptrapd source. The alternative is to use the new parse and rewrite features of syslog-ng 3.0. First, you need to f