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 OSE 2.1 released

I have just uploaded the first release in the syslog-ng Open Source Edition 2.1 branch to our website. It is currently only available in source format at this location: http://www.balabit.com/downloads/files/syslog-ng/sources/2.1/src This release synchronizes the core of syslog-ng to the latest PE version and adds the SQL destination driver. This is an alpha release and thus might be rough around the edges, but it basically only contains code already tested in the context of the Premium Edition. The SQL functionality requires a patched libdbi package, which is available at the same link. We're going to work on integrating all our libdbi related patches to the upstream package. If you want to know how the SQL logging works, please see the Administrator's Guide or our latest white paper Collecting syslog messages into an SQL database with syslog-ng. The latter describes the Premium Edition, but it applies to the Open Source one equally well.

syslog-ng 3.2 changes

I've just pushed a round of updates to the syslog-ng 3.2 repository, featuring some interesting stuff, such as: SQL reorganization: Patrick Hemmer sent in a patch to implement explicit transaction support instead of the previous auto-commit mode used by syslog-ng. I threw in some fixes and refactored the code somewhat. Configuration parser changes: the syntax errors produced by syslog-ng became much more user-friendly: not only the column is displayed, but also the erroneous line is printed and the error location is also highlighted. Additional plugin modules were created: afsql for the SQL destination, and afstreams for Solaris STREAMS devices. Creating a new plugin from core code takes about 15 minutes. I'm quite satisfied. With the addition of these two modules, it is now possible to use syslog-ng without any kind of runtime dependency except libc. The already existing afsocket module (providing tcp/udp sources & destinations) is compiled twice: once with and once withou...