The Benefits and Challenges of Supporting Third-Party Developers in Eve Online

Uh, with that out of the way though, I think we'll get started. So, my name is Riner Block Anderson. I work at CCP Games right now, uh, primarily on Eve Online. I've been with CCP for about two and a half years now, since June of 2012. Uh, and I'm currently titled as a technical designer, uh, as that title tends to change from studio to studio. For us, it means uh I do a bit of game design and a bit of programming. Um whatever is sort of needed to get the job done within uh the team I'm on. Just briefly, uh I'm going to go over what Eve Online is for those of you that may not be aware. Uh so Eve Online is a sci-fi MMO sandbox. The sandbox is a really key thing for us. Um and by that I mean we stay very hands off of our game. We provide our players with tools. what they do with those tools is entirely up to them. If you scam someone uh and you're using the tools provided in game, we will not intervene in that. So it you can be scammed in that kind of

stuff. Building on that though, we are also a single sharded game. Uh we have one cluster in London which is where all of our players connect and play. Uh and this tends to amplify the sandbox nature of our game. If you pull off a great heist, everyone in our game tends to hear about it. And it's this big thing because it happened on one server in one universe. We're also coming up on our 12-year uh birthday. We came out in 2003. Uh and relevant to this presentation, uh we have generally an above average uh technical user base. Our users tend to be more technically inclined than most. Uh and then as this will come into play a little bit later, um these are some numbers uh averages from 2014 on the EVE uh sort of player base. Uh the key thing here that I'll come back to is the 420,000 unique users logged in per month. Before we really dive into what uh I or we at CCP believe are the

benefits and challenges of supporting third-party devs, I want to make sure we're all on the same page as to what um we define thirdparty devs to be. Anyways, so to us, a third party developer is someone outside of CCP who creates external content for our game generally in the form of desktop web or mobile application. It could also be spreadsheets or whatever. Uh these developers are not paid by CCP in any way. Uh and they don't receive any extra information that anyone else uh can't get. All of the resources we provide our thirdparty developers um whether it be our APIs or downloadable resources are available to anyone whether they classify themselves as a third party dev or not. But what do we offer these thirdparty devs in terms of resources to do cool things? Uh we offer them first uh our image export collection which is a we gather up all the static images for our game. things like icons, uh, re renders that are not going to change that are static renders between releases. Um, UI

elements, uh, as well all get packaged up and released. We also offer our static data export. So, this is a collection of static information, uh, for our game such as, uh, item attributes, item names, the way the market's laid out, the universe data, all of that stuff that will not change between releases, packaged up and released to our third party devs. We give them access to our ooth 2 login so they can uh add a login with Eve button to their application, web page, whatever. We also give them access to our image server. Uh this is something we use ourselves as well. And this is generally um basically a CDN. It hosts uh a lot of the same images that are in the image export but also dynamically generated uh images. So character portraits, that kind of stuff, corporation logos, whatever. We then give them access to two web APIs. The first is our XML API. It's our older API. It's been out, I think, since about 2004 or 2005. Uh, and our CEST API. Crest stands for carbon RESTful API. Uh, both these are HTTP

APIs. Um, the Crest one is a JSON restful API. Uh, the XML API, as I said, it's our older one. It gets about,00 requests a second these days. Uh, and Crest is approaching 500 or 600 requests a second, just to give you an idea of where our API sit. Um, the key difference between these two, aside from their age, the XML API sits outside of our game cluster. It has no access to the logic of the game or the runtime state. It only knows what's persisted to disk in the DB. So, it just has read access to the DB. Uh, Crest, it runs on the cluster. It's part of the game. It was built for our second game, Dust 514, so that it can read and write to our cluster. And we're working on opening that up to our third party devs now so they can both read and write to our game. Uh and then briefly uh what we uh feel internally are our guidelines to help us in develop uh developing resources for our thirdparty devs. First and foremost, our client is off limits.

There's no UI mods, no mods of any kind. Anything like that will get you banned permanently from our game. Uh we do this because we firmly believe uh as our game is a competitive game. When you get into a fight, it is up to your skill using our client. We don't want you to have to go and download something just to be competitive, which is kind of our second point. You should not have to download any application to be competitive at Eve. You can have an application that helps you find a fight, that kind of thing. But once you're in a fight, it's your skill at our game that is going to sort of determine who wins. So those two kind of play off each other. And the third one just builds on that which is um no information should be available to our thirdparty devs that you cannot get in the client. Uh this is again just to help support the the first two points there. So the first benefit I really want to talk to you guys about is how thirdparty developers can help you uh deal with the scope of features in your game. For us, we generally start when we're designing a new feature very blue sky, right? We design the feature to

cover as many use cases as possible. We're brainstorming the biggest greatest feature ever. We scope this down and prioritize it and start work on it. Right during development, sometimes things get cut. This is either because we've run out of time, the thing was too difficult to do was going to, you know, whatever problem came up, or we just felt it, this thing we were going to do, part of this feature wasn't going to fit our game, wasn't going to fit our client, so we cut it. For the most part, this is generally where, you know, things then get shipped. For us, what we try and do, however, is during that development expose it in one of our APIs, whether it's XML API or Crest or add it to the static data export. Um, and we have a very easy framework for doing that these days. So, uh, if a team would like to add something to the API, it doesn't take much effort, doesn't take much more, uh, than they've already put in to develop the feature to get it added and exposed to our third party developers. But I mean, okay, so that's what we do. But why expose the data and how does it

help us deal with the scope of feature? The best way to sort of go about this, I think, is with an example. This is a screenshot of the wallet in our game. Shows you all the money coming into you, your character, and the money that your character spending. It works pretty well for small groups, right? You can pageionate forward and backwards. You can put in a specific date and load the transactions from that date. You can filter by transaction type. If you only want transactions for market stuff or player trades and then you get a very quick rundown sort of summary of what uh the money coming in and out and how your total balance. So again, this works wonderful for small groups or an individual, right? Small groups, 10, 20, even maybe a hundred. But we tend to have groups in our game as we're a single sharded game uh that go up to 3,000 10,000. There's a coalition of 40,000 players in our game. this wallet tends to fall apart at that scale. So very early on before we even really realized how important thirdparty developers were to us, one of the things we added to the XML API was the wallet.

And this is exactly the same information you see in this screenshot here, right? It's the who uh who the trade was between or who the transaction was between, sorry, the transaction type, the time, how much it was for, all that kind of stuff just grabbed from our database, formatted for XML, and dumped out. What I'm about to show you is a an public financial release from one of our organizations. They're a 3,000 member organization known as Pandemic Legion and it covers 18 months of their alliance. So very simply, it shows sort of the income and expenditure of their alliance over time. Uh same sort of thing just broken down by subgroup or corporation in the alliance, how much they were spending uh by corporation over time. Pretty straightforward, right? Then they start breaking it down by uh category or I'm not sure how they define these but they're type of category I guess. Uh this is the fuel usage over 18

months by the corporations in this alliance and sort of who was spending the most fuel and then broken down by fuel type. So that was all really cool, right? Really nice and pretty graphs. It makes for great content, nice news articles written about this financial report and that kind of stuff. But if it's so cool, why do we not offer that in the client, right? Well, to be honest, we could add all of those features in the client and they'd be used by no one. And the reason I say that is Pandemic Legion or any other organization of that scale, they really only have one guy dealing with their finances, right? And that one guy probably wants Excel. But also, and this is sort of more important, uh not sure if you can read it, but there's a section there called espionage or special projects. Then there's another one called FanFest. Fanfest is our player gathering in Iceland that happens once a year. I have no idea how they're spending in-game money on that.

I don't know. Um special projects or espionage. Again, I have absolutely no idea what they define as that, right? Our game is a sandbox. We give them tools. what they do with those tools is up to them. So, a lot of this is emergent gameplay. They're infiltrating a corporation and I guess probably spending some money to pay for that alt or whatever. Um, but we have no way of tracking that in the game, right? So, we could spend a lot of time developing this feature trying to build a replica of Excel in our client, but then we're probably going to miss a lot of these special edge cases that our players want because we don't know what they are. This is a sandbox. It's emergent gameplay. Um, and just serve as a few other examples uh of areas that our third party developers have created tools or resources to help in areas that we didn't even know existed or needed features. Character trading. Uh, we offer uh an authorized way of transferring a character between two

accounts and players will uh bid ISK or our in-game currency to buy these other characters. Um, and they could take the word of someone that says, "Well, I'm selling this character and he has these stats and this much money, but then you're relying on that character or that person to be telling you the truth about that character via our API. There's a a person that set up a he's a trusted person, a trusted player, and he set up a website that'll pull all this information from the API and tell you it's API verify, and this what this guy is telling you is true, right?" So, that helps with character trading, which is, I don't think, anything we originally thought would exist. planetary income monitoring. You can own planets in our game and when players use those planets as the owner, you get a cut of that. You get to tax it, right? Uh and that'll show up in your wallet. And again, it works great for small groups. If you own a planet, half a dozen or a dozen planets, it works fine. But when you own 500 planets and you want to know which planets are generating all the in like the most income for you and you know 500 planets and 30 of them come under attack, which

one do you defend, right? You need to be able to track all this information. and you want to track things like which corporations are paying you the most. Maybe you make them a deal or trying to attract more people into using your planets, right? All this sort of stuff which applies to like three or four organizations in our game. So, we could again spend a bunch of time developing these features in our client, but the number of people they apply to is pretty limited. Starbase fuel management, same kind of thing as the planetary income monitoring. We show you in our calendar in the client when the star base you own is going to uh run out of fuel and we send you a mail in the game when it's running low. But if you own 3,000 or 2,000 star bases, trying to track that and trying to track where the fuel for specific ones are and who has access to all of this stuff is very tricky. And again, only a couple of organizations in our game need that. But then not just talking about these larger organizations, asset management and more specifically cross account asset management or cross account anything. We

focus our client on when you're logged in the character you're logged in as. I don't think that's going to change anytime soon. But a lot of our players have multiple accounts or multiple characters. They have assets split across all of them. They want to know how much total wealth they have. They want to know where I know I have this ship, but I can't remember what character had it or where it is. Load up a third party tool. do a search for that ship and it'll tell you where it is. But we're not really going to offer that because we are focused on the character you're logged in as at that time. This list goes on though. Shopping list, timer boards, hundreds of other things. Sorry. So again, these are all things we could add in. Uh but it's a question of really sort of I'm not sure if any of you guys have seen this uh chart or something like it before. You generally get to pick two things, right? It's going to take a lot of time or you'll have a lot of time uh and you'll get a great thing, but it's going to cost you a lot of money, right? Or you get a

great quality thing and it's not going to cost much money, but it's going to take a lot of time. So, by exposing this data to thirdparty developers, we're they're creating things first and foremost that we didn't even know existed or things that we didn't have time to do or that we didn't think fit our client, right? We we have uh we're pretty proud of the client we have and we're building it in a certain direction, but sometimes players want it to go in a bit of a different direction and and you know, we can't make this work for everybody. So, third party tools can help with that a lot. So my first uh recommendation to you or the first benefit that we see in thirdparty developers is letting them help us build a better game. They're very passionate about our game, right? These people put hundreds or thousands of hours into our game. A lot of them are very technically inclined. Some of them work for Google or Microsoft or whatever, right? They come home and they want to do a side project or something. Give them the

chance to do it for your game and they'll do amazing stuff. The next thing is uh quite literally sometimes they'll do things better than we do or than you can do. So this is uh a killmail uh in our game. When two people meet in our game and they kill each other, the person who died and the person who laid the final blow will get uh or used to get when Eve launched a mail in the client. It was literally a text mail that we sent you that contained this sort of information. And it would tell you who killed who, you know, who died and where you died and how the ship you were flying at the time you died was fit and the weapon that was used to kill you and that kind of stuff. And it'll list everyone that was involved, but it will only be sent to the person who did the laid the final blow in the person who died. Uh, at CCP, we viewed these as a form of an afteraction report, right? So after you died or after you killed someone, you could see, you know, what they lost or what they died if you killed them or, you know, if you died, who killed you

and what ship they were using. so you could look back at it and maybe learn from it. So yeah, we called it kill mills because it was text and it was sent as a mail and it was about a kill. Three or four years after the introduction of kill mills to our game, we went and updated it a little bit. We made it so it was no longer a mail sent to you, but you could go to your character sheet and you could look at all of your kills or all of your losses. It was still though when you clicked it and viewed the kill mill just a bunch of text. Not really that pretty, right? Around the same time we did this renovation though, we added the same information to our XML API. And this is when it really took off for our third-party developers and they really started doing some cool stuff with this. And the key thing with what our thirdparty developers did is they viewed kills as something very different than we did. Whereas we viewed them as as an afteraction report, they viewed them as something entirely different. And I'm going to get into that in a second. But first, the first big change they made was they made them look a lot prettier than we did. Right. They made

it really nice and graphical. Big image of the ship that died. You can see the ships that killed you. The portrait of your character was in there. Looks really good. And this uh this website hasn't changed a lot since it was first released many many years ago because it looks pretty good as it is. But as I said, the bigger change here was that these third party developers viewed the kills as something different. We viewed them as an afteraction report. They viewed them more as an intel tool. Right now that they were storing them all on a database on their server, they could let you click on a character and view all of that character's kills and losses where those kills and losses happened. So you could start tracking where a character was in our game based on their kills and losses. You could look at a specific system and see all the kills or losses in that system. Right? The front page of the website showed you the biggest losses in the last seven days. And there's a leaderboard. You got points for killing people and points for and you lost points for dying. All these kind of things built off of this idea

that kill mills were something more than just an afteraction report. Right on top of that, one of the cooler or to me one of the coolest things is they started building in these timelines. You can you can get fights in a game that involve three or four parties, different parties, right? They'll let you group the people into parties and then view a timeline. So, even if you're not in the game, you're at work or something and there's a big fight going on in our game, you can load a page like this up and just start hitting refresh and watch is like, "Oh no, my team's losing, losing. Oh no, sad." But you could participate in the game without actually being in the client. Over time, these killboards grew to be a very central part of uh our game's experience. If you participate in PvP, there's a very very good chance you care about killboards or you're viewing them at least. Maybe you don't care about your killboard stance, but you're using them as an intel tool to find fights and that kind of stuff. To give you a bit of to give you a bit of an

idea as to how central of an experience these killboards are to our players, there's two main killboards uh sort of out there right now. The first uh actually I guess it's the second the newer one is known as Zed Killboard. They get about the these stats are all taken from a one-mon period in 2014 and as I said earlier we get about 420 on average we had 420,000 unique people logged into our game uh per month in 2014. So these stats are again taken from one month in 2014. Zed Kword would get about 658,000 visits a month which translated to 3.1 million page views and about 200,000 unique viewers. That's not bad on its own right there. But then we look at Evekill, which is the older Killboard. It's been around a bit longer, right? In that same month, they got 1.6 million visits at 8.6 million page views and 401,000 unique viewers. Of course, some of these are the same people from work or home or their laptop or whatever, right? But that is a substantial portion of our player base. When we have 420,000 unique users

logging in every month and about 401,000 unique visitors on this website, it's a pretty good indication of how important these are. Uh but beyond just uh intel or you know uh bragging rights or whatever, these killboards turned into something else without I don't think we really realized it at the time. Um, so the important thing is to keep in mind is as I said, we're single shards. This game takes place, you know, at all times of the day while we're asleep or awake. And sometimes these big fights will happen while we are asleep in Iceland. So we'll wake up and there'll be articles on Kotaku or Joystick or Massively, sometimes the BBC or Times about these massive fights that have happened in our game. And we're waking up and being like, well, that's cool. They have all these numbers and whatnot. And these numbers are incredibly accurate. They're taking these numbers from killboards about how big these fights were and how much was lost in these fights and there's news articles being written about it. There's

Wikipedia articles being written about it. We wake up and all we do is say, "Yep, those numbers are accurate." Right? So these killboards have turned into a bit of a marketing thing for us. Not like us directly using them, but they can give us a bit of a marketing benefit. The other huge uh advantage and really cool thing about thirdparty devs making a killboard was that when we decided we wanted to go back and revisit kills, we had something to sort of look at. We could look at the what they' done as a prototype or as an experiment and sort of pick what we thought was the best from different things. So a few years ago, we went back and we redid kills in the client. No longer is it this blob of text, but we're actually formatting it, displaying it nice and pretty, right? We added the ability to look at specific wars, all the kills and losses in there. Again, taking some hints from the killboards and sort of mixing it in with what we thought worked best in our client. Sorry. Uh so again, the the main

point here I want to make is just that sometimes third party developers can do things better than we can and it's we should embrace this. We shouldn't be afraid of it. We shouldn't be worried about it. We should embrace it and support it. It's awesome. So, the third thing I want to talk to you about is mobile phones and what our third party developers have done for us in this sort of realm. Um, uh, Eve Online specifically, we have zero mobile resources. Our web team makes their web pages to look great on mobile. Yes. But we don't have a dedicated mobile app for Eve Online, not an official CCP one. We're focused on Eve itself and that that client. There's an Android application called Eve Droid. There's other ones for Android and there's some for iOS. But I just sort of want to quickly run you through uh what what our third party devs have done here. So this is as I said Eve Droid. First thing to me it looks fabulous. It looks like a professionally done application. Uh it

has a lot of great features. You can look at all your different characters from multiple accounts. You can look at a specific character's wallet transactions. That's what's going on on the left there. You can look at the entire item database of our game and then based on what character you have selected at the time, know if he can use those items or how long until he can use them. On the right there, uh this uh is a screenshot of the person uh playing around with a fitting for a ship and seeing how that all works. So, this is all really slick. It looks great. It's wonderful. And just to give you an idea, this is the top user agents on our XML API. The second, third, and fifth slot are all mobile Android mobile applications, right? As I said, we get about 1,00 to,200 requests a second on this API. So a substantial portion of them are coming from mobile. Now we we exposed this all this information that's being used by this uh this eve droid application was exposed either in the static data export or the

XML API years before Android was ever publicly even known about right um but without any extra effort on our part right we were just maintaining a set of APIs that already existed we had a substantial mobile presence something our players seem to really care about and our third party developers were eager to do something with. Uh so what I really want to the the while I was writing this, what I realized though is that it's not really about mobile phones, right? As I said, we didn't even know about mobile phones at the time, like Android. There wasn't really a thing, but we released this information. We got that. So yes, it's about mobile phones, but it's about smartwatches and Google Glass and robots and whatever comes next. I've seen a robot walking around that tells you when the server comes up or goes down and tells you when your character's done training things and that kind of stuff, right? I've seen it on Google. I've seen notifications on Google Glass and all these other things that again we don't even have access to. I don't have a

robot to try and play around with. I wish I did. Um I also don't have Google Glass, but I've seen Eve there, right? I've seen us have a presence there because our third party developers are doing awesome stuff for us. So, the real point I want to make here is that thirdparty developers will help you take your game to places you don't even know exist. Um, and then I guess on top of that, even if we do go back and create a mobile application ourselves, just like the killboards and the kill mills, we'll have great examples to look at and places to take pieces from. So, those are some of the benefits and they were quite wonderful. Um, but let's talk about some of the challenges and the problems that we've encountered. The first thing is uh the API key requirements. So with the XML with uh sorry with Crest the authentication on Crest is with the OOTH 2. The XML API though uh you log into our website you generate an API key and that just gets passed in as a parameter in the URL. Uh and that will determine whether you have access to certain resources based on the

character the API key belongs to. Um and as I said we have a bit of a above average technical user base and we're very hands-off in our sandbox. So, if someone steals from you, that's your fault for letting it happen. Because of that, though, we run into a situation where corporations, guilds in our game, um, are very eager to protect themselves. So, if you want to join a group, they generally want your API key up front so they can do a background check, right? If you think that's funny, so this is the I want to give you just sort of a an understanding as the lengths our players will go to to protect themselves. This is a screenshot of the Pandemic Legion forums. Everything looks great, right? It looks pretty normal. If you were to copy and paste that, actually, I think they've deactivated it now, but it used to be. If you copy and pasted that, posted it on Reddit, right? You're a spy. You have access to their forums. You copy and paste this bit of information to leak it on Reddit. Uh they've done Unicode uh watermarking on this, so they can copy and paste what you've just pasted into Reddit back into

their tool, and they'll know what character was logged in at the time this was copy and pasted. They took this further though when people started finding out about that and just started taking screenshots like this. They started doing some screenshot watermarking so they could adjust the levels in Photoshop on the screenshot and still know who took this screenshot. Right? So this is the lengths our players would go to to protect themselves. This counter inelligence espionage game they're playing out, you know, sort of outside the client. Um, and again that takes place outside the client, right? So, we don't really care except we kind of do when it comes to the API key. So, this is a comment from control delete. It's a few years old now. He starts with giving an example of joining a guild in most MMOs, right? Hey, I like this game. You like this game? Fantastic. Let's play together, right? Then there's Eve. To join a group in Eve, you need to go through this long interview process and give them your API key. It's that API key thing that we're worried about because they get the API key, you need to leave our client, go to

our web page, log in, generate an API key, and then go and give it to these this corporation that you want to join, and then they'll do a background check uh based on that API key. But if you check the wrong boxes when you generated the API key, you got to go and generate it again. It's a bit of a mess, right? And most importantly, excuse me, you're being forced to leave our client just to play our game with people. That's not so great. And on top of that, most people don't know what an API key is. I don't know of many other games that have that, right? So, you come to Eve and you're like, well, I don't really know what this is, but okay. And now you've just given these people access to everything about your character. You probably don't even know you can revoke that API key if you leave that organization and don't want them to have access anymore. So, this is uh an ongoing issue. And uh sorry, kind of meant to advance to that. Um, yeah, the this problem of leaving the client just to play our game, it it goes against one of our core guidelines for the API. We're not quite sure how to fix this ourselves

to tell you the truth. We we know it's an issue. We're aware of it and we're trying to make sure it's not becoming more of an issue as we continue expanding the resources for our third party developers, but we're not quite sure how to fix that. Uh, it's a bit of an issue specific to Eve, but it's a good example of where things can quickly spiral out of control. Um, what we try to do though to avoid more of this same problem coming up is we talk internally about what we're going to expose, right? We talk about how it could be used against players, how it could be used to do weird things, but then more importantly, we talk externally about what we want to do. We talk to our third party developers. There's a Slack channel that I sit in with a bunch of thirdparty devs, an IRC channel. I'm on Twitter. Most of them know my email address. I'm easy to get a hold of. tell them this is what we're thinking of doing and they're more than happy to give us feedback. These are some really smart people and they're also very devious uh and they're more than willing oftentimes to tell you what bad things

they'll do with your API if they got it. Um and this again this seems a bit obvious. Put it on the test server, right? And yes, please do. But tell your third party devs about it. We try and make sure we tell them in advance. This is what we're going to put up. It's up. please go try it, right? Not just uh yeah, it happened to be on the test server two weeks ago. Why didn't you try it? Right? We we encourage them to go and try it before we put it to production. Uh and then most importantly, watch its usage and be prepared to take action. Right? If you leave an API up and it's bad things are happening with it, but you leave that up for five years, players tend to get to the point where they they believe it's an ex a right that they have it. They they deserve that. it's part of their gameplay, right? If you take it away a month or two after release, at that point it's still kind of a a privilege to have. They're happy to have it. It's kind of cool, but it's not become ingrained in their daily life of the game. So, uh, when you put an API out,

watch it carefully. Watch what your third party devs are doing with it. Talk to them. See what they're doing. Ask them what they're doing with it. And then if it's starting to go the wrong way, be prepared to take that action. Maybe it's modifying the API resource or deleting it until you solve whatever problem there is. But this kind of that last point of um taking action uh leads me into sort of my next thing I want to talk about which is a bit more of an a specific example which is sort of what I guess I've called the forgotten data. So this is the star map in Eve. Uh I guess it's a little hard to see there but all the dots are solar systems in our game. uh this map and when Eve launched uh had about 5,200 star systems in it, all that you could visit, right? Uh the yellow and red that you're seeing is based uh as a filter you can apply to the map. So you can see the number of NPCs killed in every system over the last hour. When we uh when we added the XML API, this seemed like a great thing to add to it. So we did every solar you can

get publicly available every solar system in our game. The number of player kills in it, the number of NPCs killed, that kind of thing. It's exactly what you see in the client. Um, so that's fine. It's cached for the same amount of time. It's one hour. You only updates once an hour. Uh, importantly though, when we did this, there was only 5200 systems and they were all visible on the map. So we basically just did select all from map data, convert to XML, dump to the API, right? Very simple. Uh, and it worked fine. In 2009, we added a new area of space to our game called wormholes. These wormhole systems were very different than other solar systems in our game. Um, they were much harder to live in. They did not show up in the client. If you open the map in the client, you didn't see them, right? Um, and as I said, they're much harder to live in. And this didn't happen right away. Over time, as players started developing tools, I forgot to make that image bigger. Um, as our players started developing tools to help them better live in wormholes, uh, one of the things

that they started doing, and this is like three three or four years after the release of wormholes, what they started doing was tracking all of the NPCs killed every hour for every system. So, when you went into a new wormhole system, because it didn't show up on the map and you couldn't get this information, suddenly you had it outside the client. But more importantly, you knew sort of every time if their NPCs were killed between five and seven every day, you knew the people who lived there probably logged on at five between five and seven. So if you laid a trap, you had an advantage. And this was information that you couldn't get in the client. You could track this out outside the client, use that information to lay a trap, and present yourself with uh an advantage. When we learned about this, um, we knew we had to do something because it was breaking a core guideline, a core rule of ours for the API, which is that information in the sorry, information outside, you should not be able to get information outside the client, you can't get in the client. Wow. Um, so what were we going to do

though? Right, when we first talked about, well, since this is breaking the rule, we need to remove it. Our players got very angry. They got very upset that we were taking away something that they were using to get PvP, right? They were using this tool to get content in our game and we wanted to take it away. And they'd gotten so used to it that there were organizations that built themselves around this. There were organizations of several hundred people. Their only purpose was to use this information to get their kills. So, okay, we said we want to remove it. Our players got a bit upset. We went back and we talked about it a bit more and we just simply looked at our guidelines which were um you know you should not be able to get information outside the client that you can't get in the client. H and so we thought okay should we add this to the client if it's giving our players content should it be there? When we talked about it and thought about it some more we realized that it was not creating the style of game that we wanted in wormholes. So we stuck with

our decision. we remove this information from the API. So, whoops, again, little behind. Uh to to avoid this kind of thing though in the future, something we've tried very hard to do uh at CCP is make sure that the feature teams that are developing features are also the ones that are dealing with the API. when the API, the XML API was first released, there's one guy who sat over in a corner and and did this right um in his spare time, which is why when wormholes came out and one team was adding these wormholes and decided that they didn't want it on the in-game map. This other guy, he didn't really know that decision. He didn't so he didn't think about removing them from the API, right? There was this lack of communication. And so what we try and do now is make sure that feature teams are either doing the work in the API themselves or they are at least well informed of what the API is capable of and the people working on the API are there and ready to assist them either by showing them or doing the work that's required to make the

modifications um to the API. So yeah I the biggest thing there is just making sure that feature teams are aware of it and preferably doing it themselves. Uh, so that went a little bit quicker than usual, but that's fine. Um, some conclusions. Uh, again, third party developers can help you with use cases that you don't have time for or that you don't know exist, which to me is a really key thing, right? We're building a game with emergent gameplay. What we don't know all the things our players want to do and our thirdparty developers are there and they're more than happy to help us. Uh, so empower them to do so. If they're there, they're willing, they're smart people, right? They can do some really cool stuff. Give them the chance to do it. The number of times I've seen players go through and manually write down all the stats for items in a game because they can't scrape that information from the data files or it's not provided to them in in an easy to access way. So, they're going through and they're just looking at the game and writing down all the stats just so they

can build a mobile application that is an item database, right? It's not that hard for us with the framework we have in place to release this information. And you know, I I don't personally think it's I guess it depends on the use case, but if you put the effort in and you make that information available, you provide yourself with a framework to easily do that, they'll do a lot of cool stuff. Uh and then sort of I think this covers most of our our the uh issues I talked about. The biggest thing is really just discussing um what you want to do in your API, what your feature teams are doing, and preferably, as I said, bring that API development into the feature team. So, uh as I said, my name is Reiner L Anderson. It's my email address for my Twitter. Uh and if you guys have any questions, I'd be more than happy to answer them. There's microphones. [Applause] Great talk. Uh I love Eve. I don't play

it enough. Um I guess two questions. First is do you use this also in Dust 514 514 I guess. So the with the XML API, no. But with Crest, yes. Um so C Dust 514 for those that are unaware is a PlayStation 3 uh first-person shooter. It takes place though in the EVE universe on the same server as um Eve online. So we we use Crest for all the readr between the Dust client and the Eve server. And then so second question is do you use the API internally? So Crest is read write is it a benefit to your internal team to also utilize this to add features? Um we have used it in several cases and we are working more towards having it be something that uh we use more. Great. Thank you. Yep. Awesome. Thanks for the talk. Um, so I me you mentioned that uh as part of a feature development um teams have to add the API uh and you also mentioned that

developers uh internally will add API requests uh when they see the fit like when it be good for the API. Uh how do you uh from like a your community how do you understand like when you should remove add or prioritize different API features? Um, do you have like a request open? Do you have like a poll that Goonfleet can swarm or uh like how how do you the add these nonfeature specific like APIs into your system? Uh, so yeah, I guess the question is how do we add features uh to our API that are not uh requests from the feature team but requests from the community? Um, and honestly we we just sit down and talk with them on the forums or or whatever. Uh, and if if a player has a suggestion and um someone in the company's really interested in exposing it, then I it's just up to that person to go and expose it. Uh, we're um pretty open like that, right? So if yeah, if someone wants to do it, they just do it. Okay. Thank you. Yeah, not a problem.

Hi, great talk. Thank you. Sorry. Um uh oh for Pete's sake um usually when a when a a new a change comes out for a game uh that involves you know a new feature or uh maybe some some rebalancing um the the community's reaction to it is based on their exposure to those changes. Um this API seems to provide a lot of transparency. I was wondering if you get a more uh let's say profound reaction to to you know designers balancing things in Eve Online as a result of that. Sorry, I didn't quite understand. Um I'm saying um if if a game needs to be rebalanced after it's released, right, as they tend to be. Um, does your API expose those changes in a way that you know players can analyze those changes, see what you've

done, react to that more strongly? Um, in many cases, yes. Uh, and and we will often put out um the static data export that I was talking about, we'll put that out early. Um, there's tools that are uh generally called fitting tools. They let you practice fitting a ship without actually launching a client or owning the modules. we'll put out the information that's needed to update those tools before um the the actual release so that we can get better feedback. We we we find that's actually a very valuable and beneficial thing. Also, um how do you decide whether uh a feature in the client will actually be exposed through the a like is there is there a a general um guideline for whether or not to expose it? Uh so the uh question is how do we decide which features will be exposed in the API and which ones won't? Um again as I sort of uh suggested we sit down and we talk about it um and we we decide we want to expose everything possible at least I personally do right so really it just

comes down to discussing it and deciding if there's a reason not to expose it. Thank you. Yeah. Um, I was curious, uh, do you guys have information in the game that's only available to the individual users? And how do you feel about thirdparty developers aggregating data, um, that's meant to be private for individual users? Very, we we have a lot of sorry uh, the question was, do we have information uh, in the API that is private? Um, and how do we feel about thirdparty devs uh, correlating that information and stuff like that? Uh, very much a lot of our API is private information, especially the XML API. Um it there's a everything about it uh is built around the idea of giving people the control over what they expose. So you can create an API key that only gives access to your wallet or only gives access to your the skills you have or the items you have, right? Um and if a third party developer gains the trust of the community and the community gives them all the API keys required to to gather that information, then that's

kind of the choice of our community. Um, we do have a bit of a a thing that I don't think we've decided how we feel about it yet where part of that that counter intelligence and that espionage thing is specifically going out and harvesting API keys. Um, so that uh yeah, and I'm not sure how we feel about that yet to tell you the truth. You have a lot of botting traffic against the APIs and how do you evaluate and deal with that? And then correlary to that is there um aside from API key um how have you addressed any security concerns and um protecting you know the APIs and users in general. So I I sort of I missed the first part of your question. Can you repeat that botting traffic against the APIs? So users writing bots to just constantly hit them and yeah um I mean our API so I guess the question was um you know there's a lot of bots or or programmatically our API is accessed programmatically a lot uh and um we're totally fine with that

uh as I said um we we try and offer the best uh and the best security to uh our players in generating their API keys. They can revoke them uh and we give them a log of the API key access. So if they feel that their API key is being misused or abused or something as an individual you can revoke it. Other than that I'm happy to see the graph climb of the number of hits on our API. Uh so uh does that answer the first part of your question? Yeah. Um and then I guess the second part was about the user security of it. How do we secure the API? Sorry. I guess it's more platform security once you open up this functionality. Um there's potential abuse and potential you know. Yeah. I I mean um our our biggest concern is uh is people dodoing it kind of thing. Outside that it's it's secured with SSL3. We highly encourage everyone to use that. Um I'm very much of the opinion of revoking the non-HTTPS version of it. Uh so hope that and as I said we we we do a

lot for providing users information about how their API is being used. Sorry I didn't question. Um uh so uh one issue um uh that that I feel like has we've run into is um you talked about being users being able to select um what information they want visible. Um so there's like an instance where there's like a history of some sort like um like a battle history or like a match history of some sort. And um users may go in and select that um they don't mind if that's available through the API. And then if they go back later and say that they want that private, then um there's sites that had already scraped that information. Um how do you how do you feel about that sort of um is is that something that you well excuse me that you would ask sites to remove or is that something that's on the user's um um so the the question was sort of once a user is granted access to their API and certain information if that user revokes it, how do we feel about the information that's already been pulled from the API? Uh, and it's up to our users as to what

they expose. If they choose to expose it and share that information and once it's out there, that's sort of on them. Uh, is our general response. Hi. Uh, another question. um at at what point did your community grow large enough that I mean I'm not sure if uh maybe they were large enough when you released the API but um I'm I'm wondering if there's a critical mass of you know of members of of the player base that are necessary to utilize these APIs. Uh so the question was um sort of at what point did we hit critical mass where there was enough users to to utilize this API these APIs that we provide and to tell you the truth as I said at the beginning we have a an above average technical user base and the API was built in response to uh our we we used to offer a web page that would show you your character skills that web page was being scraped so the API was originally built in response to the tech the the needs of our community um and it just sort of continued to grow from there.

Um, this sounds like it might be against your guiding principles, but I was wondering if uh it seems currently like a very readonly API. Is there any plan to expand to any actions or rights? Yeah. So, the question is, are we ever going to open up right access to our API? Very much so. Hopefully this year. Um, as I and that'll be via Crest. Um, and yes, very much so. Crest, as I said, was built for Dust 5.4, which does read and write access. uh and yes we are very much moving towards releasing that to our community in which capacities which kind of vaccines for good question uh so in in what way are we going to release read and write or the right portions of the API anything that doesn't modify your wealth directly so no selling of things we don't want people making market bots no transfer we're going to start with no transferring of this our our gut feeling is we're going to start with things that don't modify your wealth so changing the your uh cue for skills that your training or modifying your uh contacts, sending uh mails in

the client, that kind of stuff. Hopefully chat at some point as well. We want to open up to our third party devs uh those things that don't modify your wealth. Cool. Thank you. Yeah, not a problem. Kind of as a follow-up to that, um what kind of philosophy do you have about what things experiences you want to players to have to have in game versus ones you want to allow outside of the game? because with some of these things you can get people mostly playing your game through the phone and not through your client. Uh so uh if I understand the question is sort of how do we feel about um and and where do we draw the line? Yeah, I guess. Yeah. Yeah. Where do you draw the line as to like you know this is something we really want you to log in to the client to do versus something we'll allow you to just do anytime anywhere. Um we're we're moving in the direction of uh we want you experiencing our game whether it's through our client or not. We're happy that you are experiencing our game and being involved in it. So, as it stands now, uh to do things, you have to be in the client. As we open up right access,

we're more than happy if you just send if you just experience chat through uh your phone, like that's that's fine. We're totally happy with that as long as you're part of the universe. Awesome. Uh you mentioned that you currently have like the XML API and you're opening up the the CEST API here soon. Uh is do you have a plan in mind of maybe migrating people from the XML one to the rest API and if so like what kind of strategies are you utilizing for that? Um so the question was uh are we going to deprecate the XML API uh sort of thing I guess really. Um, and yes, very much so. We're uh we've been focused on getting Crest to the point where we can release read and write access to our community. And once we get that, our one of our top priorities will be sort of migrating all the same information you get in the XML API over to Crest. And once we've done that, development of the XML API will stop. There's a ton of applications already built around it. So, we're just going to leave it running for kind of however

many years we feel is needed. Uh, and throughout that time, we'll just be encouraging development to happen on Crest. And then at some point, I assume we'll kill it. Cool. Thank you very much, guys. Appreciate it for coming out.