Alastair Callum Unity Developer

CREST API Regions & Solar Systems

Shoot for the moon!

Part of the goal for the EVE Online CREST API challenge was to visualse the chosen trade route. To do this I've made use of both the CREST API and Static Data Export (SDE) to populate a series of uGUI buttons for each region.


There's not a whole lot of reasons to use the CREST API to poll static data such as regions, but it shows that I know how to use it. The next task is to show the constellations - which are collections of solar systems.

This was a little harder to pin down on a usability level, as you cannot reasonably show all 8035 solar systems without hitting performance issues but what I came up with appears to work well. When a region is clicked, it will make a request to the CREST API for that region (giving us a list of constellation IDs), which is then used to poll all solar systems in each constellation. A random colour is added at each constellation iteration.

WWW _www = new WWW("" + _regionID + "/");

while (!_www.isDone) {
    yield return null;
Region _region = new Region();
_region = JsonUtility.FromJson<Region>(_www.text);


So there we have it. Visualisation of New Eden in Unity, making use of the CREST API and Static Data Export. The zoom was handled by simply scaling the ScrollView's content transform with the scroll wheel value, and inverting the scale on all child objects.

_obj.transform.localScale = ( / _zoomTarget.localScale.x);

Where the _zoomTarget is the transform scaled by the scroll wheel.

Links in this post



With an understanding of how to retrieve data from the public CREST API endpoints, I want to get down the autentication side of things before I get into the fun stuff.

Third party applications for EVE Online can now make use of the Single Sign On (SSO) userflow, allowing users to authenticate the application via the EVE login servers. This is great for web based applications but causes a bit of hassle for non-web applications. I'll try and explain, this is a succesful use case for a the third party web application:

  1. The user goes to a third party web application and clicks a "Sign in with EVE" button
  2. The user is directed to the EVE Login and logs in
  3. The user is shown what permissions the application requires and agrees
  4. The user is redirected back to the third party web application with an authorisation token in the URL
  5. The the third party web application grabs the token and exchanges it for an access token
  6. The the third party web application can now make authenticated requests on the users behalf

Now, most of these steps are similar for a non-web application except the nice bit at step 5. where the web application grabs the auth token discretely from the url. In order to get on with the challenge and not get bogged down in a nice solution for non-web, I've basically set up a php page that the SSO workflow uses as the redirect:

This just grabs the authorisation token (the property following ?code= in the URL) with the following php:

<?php echo $_GET['code']; ?>

The authorisation code can now be copy and pasted by the user into the application, which will then exchange it for an access token. This is done with a simple HTTP POST like so:

_www = new WWW("", _data, _headers);

The _data member represents the authorisation token received by the user, and the _headers member contains a 64bit encrypted application ID and secret key to validate the request for an access token.

Links in this post

EVE Single Sign On - The EVE Sign In user flow used for third party applications

Meta data

Let's have some fun!

With the data in and stored in sensible C# classes, we can start to have some fun - I've added in some meta data about the current search item. By checking the lastest history item with the latest but, comparisons can be made about their differences. in this case, the change in price and percentage change.

double _latest = hist.items[hist.items.Count - 1].avgPrice;
double _latestButOne = hist.items[hist.items.Count - 2].avgPrice;

double _change = (_latest - _latestButOne);
double _percentChange = (_change / _latestButOne);

DateTime _latestDate = DateTime.Parse(hist.items[hist.items.Count - 1].date);
TimeSpan _outofDate = (DateTime.Now - _latestDate);

The TimeSpan class is great for this as it can be calculated with a the DateTime class.

We can also display when the latest history was updated - this is where buy/sell order wil come into their own as it is updated much more often than market history.


Links in this post

Unity & Graph Maker

Make something already!

Ok, so we're gonna be pulling down loads of information from the CREST API so it's going to have to be displayed in a sensible way and there's nothing more sensible than graphs. Graph Maker is a fantastic plugin for Unity that allows the creation of fully dynamic 2D graphs and charts, honestly, the work put into this is just incredible - oh and it's fully supported by the new Unity UI framework.

The first thing to do is set up a graph ready for holding the information. In this case a line graph. The graph contains a whole load of configuration options for auto scaling axis, colour, grid display, labels, legends - anything you can think of. After the required series where added to the graph object (it's a good idea to break the prefab instance so you don't overwrite it!) you can start populating it with data!

From our previous progress, the history has been deserialised into the history object (RootObject). The following populates each series by firstly clearing any current values, and adding one for each history entry with the average, min/max price, and volume.


int _i = 0;
foreach (Item _item in hist.items) {
    series1.pointValues.Add(new Vector2(_i, (float)_item.avgPrice));
    series2.pointValues.Add(new Vector2(_i, (float)_item.highPrice));
    series3.pointValues.Add(new Vector2(_i, (float)_item.lowPrice));
    series4.pointValues.Add(new Vector2(_i, (float)_item.volume));

Frustratingly GraphMaker uses the Vector2 type to store it's point values - but this causes problems when casting the Double values from the history into floats; this could be a problem because of EVE's currency commonly enters into the billions. I may look at converting the Vector2 types to a custom container that supports Doubles.

Anyway - when the application runs the graph is populated with the desired data. Nice.


And with a little time configuring the various GraphMaker prameters, we have a pretty snazzy looking graph. The bar chart at the bottom is a second graph with one series and only 200px high. Both Y axis auto expand or shrink based on the data provided, maximising the real-estate of the graph area. The X axis, time/date, is currently fixed to the 12 month period, in time this will be configured dynamically based on the search period.

Links in this post

CREST API: Making the first request

Is anyone there?

The CREST API has a fistful of endpoints available to 3rd party developers. Interestingly, sending a request to the root endpoint returns a JSON string of all available endpoints; pretty handy.

Most browsers will return this object as a download as there is no filetype associated with the response. When sent through an application however, the string can be read as normal. This stuff is pretty straight forward as all that needs doing is identifying the desired endpoint, some examples are outlined below.

Will return the history of the item ID 34 (Tritanium) from a market region ID 10000002 (The Forge).

Will return all current sell orders of the item ID 34 (Tritanium) from a market region ID 10000002 (The Forge).

More information can be found on the EVE Online wiki.

Anything else?

The CREST API is still being implemented so a lot of the endpoints do not work, but in future it is planned to give access to any public game data from characters, industry, market, corporations and alliances. There are also plans for an authentication only (OAuth) API for account private account data.

Rate Limits

Rate Per Second: 150
Burst Size: 400
Maximum concurrent connections: 20

For your requests, this means you can send an occasional burst of 400 requests all at once. If you do, you'll hit the rate limit once you try to send your 401st request unless you wait.

Your bucket refills at a rate of 1 per 1/150th of a second. If you send 400 requests at once, you need to wait 2.67 seconds before you can send another 400 requests (1/150 * 400), if you only wait 1.33 seconds you can send another 200, and so on. Altrnatively, you can send a constant 150 requests every 1 second.


Developer or Gamer?

As a developer it becomes difficult to see games in the same way as gamers. The perfect example of this for me is EVE Online - the fantastically technical MMO. I've tried to play it many times - and like many others found it difficult to really get into; now this isn't a criticism of the game, I guess it's just not my play style. But what I do love is it's technical magnificence.

I've always been fascinated by the 3rd party applications people have made to monitor, estimate, and plan their entire progress in the game. The very fact there has been such a direct link between online and offline play goes to show how well structured (you'd hope) the game is.

I won't lie, I've been out of the loop for some time but recently saw a trailer for an expansion coming Spring 2016; EVE Citadel. So I found my account, logged in and flew around a bit (trying to remember where I left off) and then logged out again. It's just not me. So instead I started looking at the updates CCP have made to the game since I've been away and began reading about the new CREST API.

For most people it might not sound very exciting, but to me, this was my opportunity to get into (quite literally) EVE Online.


There's not a whole lot of information out there, but the CREST API is essentially a direct link to the game's server, Tranquility, allowing much more up to date information requests.

Most details come from the Third Party Developer Blog, and the EVE Wiki:

The Carbon RESTful (CREST) HTTP API is a read and write API to the EVE Universe game cluster. It gives the ability to interact with the cluster in a scalable way from clients/applications other than the EVE game.

The API returns JSON strings based on the requested endpoint. In the past 3rd party applications relied on 3rd party APIs to request data and these are often only updated at certain times of the day. With the ability to requst data directly from the game server, the CREST API offers new opportunities for 3rd party developers.