Sunday, July 5, 2015

100 Billion: June Income and Balance Sheet, and Reflections at the Mid-Year Point

June was back in the green and would have been better save for a completely random gank.  So goes life in EVE.  I also eliminated at least one item out of our tech II production chain.  I don't have a systematic way of doing that yet, but significant work on EveKit is nearing a close so I should be able to divert efforts to building those types of tools.  Finally, as we're six months into the year, now is a good time to reflect back on how the 100 billion experiment is going so far.

June By The Numbers


Here's where we were at the end of May:


and here's where we stand after June:



The balance sheet is up about ISK 1B although equity is still down due to the drag from PLEX cost.  About half of the increase came from income from tech II sales, and the other half came from asset appreciation.  PLEX prices are still on the rise.  So we're still waiting for the predicted bottom cycle of PLEX pricing which usually occurs late in the summer.  There was a PLEX sale this last month which would normally cause prices to drop, but that didn't happen.  Also, many EVE bloggers have been talking about the recent low active logons count.  That would favor higher PLEX prices instead of lower (not enough liquidity on the buy side).

Here's the top 20 assets from end of May:


and here's the top 20 at the end of June:



There are three main things to note from the asset list for June:

  1. Toxic metal prices continue to be volatile, at least on a month to month basis.  I have no idea what's going on there.
  2. Ship skins have now made their appearance in the top 20 with the Dominix skin being very popular.  It's a limited issue skin and likely something to be re-issued for major EVE events (think: EVE Vegas or FanFest).  That suggests we should consider dumping it soon.
  3. The special issue clothing is still on the list but, unlike ship skins, are particular to FanFest 2015.  That suggests they won't be re-released any time soon (perhaps ever again), so I think we're a hold for now.

On the income side, we were nicely into the green although as usual not near enough to cover PLEX cost.  Here's where we stood for May:


and here's where we are at the end of June:



We had the strong sales we expect for being well into the regular production cycle of our tech II items.  We should have been about ISK 200M higher but for a random gank which you can see in the transaction list.  We sold our kill rights for the gank, and they were used.  That's the ISK 2 we made :)  Here are the top 20 transactions for May:


and for June:



The company Crane (blockade runner) was randomly ganked on the way to a pickup all in high sec space.  We got podded as well.  There was no cargo loss as we were empty at the time, but as blockade runners can't be scanned, our gankers had no way to know they wasted their time (and ships).  So this was mostly an annoyance that cost us about ISK 200M in replacement costs.

The other item of note is that I've decided to drop Adaptive Nano Plating out of tech II production.  The market for this item is flooded at the moment and the price has dropped out of the bottom.  I'll leave a sell order on the market to get through current stock, but I'll be excluding this item from the tech II blueprint copy list until prices improve.  As I mentioned above, I don't have great tools for doing this systematically yet, but I expect to have time to work on that soon.

That's it for the 100 Billion corp financial update, now let's reflect on the year so far.

Reflections at Mid Year


We're half way through the year and it's probably fair to say that we're just treading water with the 100 billion experiment so far.  From an equity perspective, we're actually losing money.  But let's gather all the numbers so far, then draw conclusions:



I've colored coded the months to show where we had positive income versus negative income.  This leaves out the change in asset valuation, which is also a potential source of income.  But the main take away is that we're almost dead even with where we were at the start of the year.  That's a lot of work for no real gain.  In fact, we're actually losing money if you throw in the cost of PLEX (not shown in table).

I'm dedicated to this experiment for at least a year.  So despite the lack of any real progress, I'm staying positive.  Which means it's time to look forward and think about what needs to change to show real progress.  Here's what I've got so far in no particular order:
  • The Market?  Being in the finance industry, I feel like I'm missing a huge opportunity here to do some station trading and make some income that way.  I haven't gone down this road yet because I want to do it systematically and don't yet have the tools to get that done.  That will definitely be a focus for the second half of the year.
  • Drop the losers already.  The call to remove Adaptive Nano Plating from production was a gut call based on prices I'm seeing and my rough accounting of production cost.  This needs to be done more systematically for all the production we're engaging in.  Two updates ago I presented a simple spreadsheet analyzing drone production.  I need to do the same thing for all tech II production to see where we're just not making the grade.  I suspect I'm missing a few more items I need to cut based on cost.
  • Blitz more missions.  This is more time consuming than other endeavors but it's a money maker both in terms of cash (usually at least ISM 100M a month) as well as loot and salvage (particularly on missions which return officer insignia).  The real cost in missions is time, which of course doesn't show up on the balance sheet at all.
  • Is Tech I Profitable?  This should come from better market analysis, but it would seem to reason that given the amount of PVP, there should be a decent market for Tech I ships.  Of course, the market may be heavily flooded here.

Getting a handle on losing tech II production is probably the highest priority, followed by more regular mission running.  There are regular stories of players making billions from dedicated mission running.  I doubt I can put that much time into it, but I can probably do more than I'm doing now.

In other news, the EveKit Wayback Machine is about to become reality which will free up some time as well.  I'm really excited about that change as it will make it much easier to analyze how the 100 billion corp is burning through assets used for production.

That's the update for this month.  See you after the Aegis update!

Saturday, July 4, 2015

The EveKit Wayback Machine

We've posted in a few places that we're changing EveKit to implement something called the "Wayback Machine".  That work is finally happening on the Beta site starting tonight.  This post is a more detailed description of what these changes are and how they work.  This post assumes you know what EveKit is, why you might use it, etc.  If you're unfamiliar, you can visit the front page which has a decent summary of the main features.

What is the Wayback Machine?


Simply put, in Wayback Machine mode, EveKit will now retain a history of all changes to any XML API data we're downloading for you.  Previously, the only data which really had a history were things like industry jobs, market orders and the wallet.  Now, every time some piece of data changes we'll version it and save the old version for later reference.  We're also changing the API so that you can view the data at any time in the past.

The main reason we implemented this mode is to get better tracking of account assets over time.  When you're trying to manage a modest sized EVE corporation, it's useful to track how fast you're burning through key resources needed for production.  Likewise, there are several other interesting use cases.  For example, you can view corporation member tracking information over time to track movements, recruitment, etc.  If the feature catches on, I'm sure several more clever people in the community will come up with their own interesting use cases.

How It Works (Technical Details)


The main change to support versioned data is to assign every object a "lifeline".  A lifeline is a series of time stamps which indicate intervals at which an object was live in the system.  To simplify the implementation, we make copies of objects as they change, so a single logical object is actually represented as a sequence of physical objects reflecting the logical object's state as it changed over time.  We implement lifelines by assigning two values to each object in the sequence:

  • lifeStart: the time stamp (inclusive) at which the object first became live; and
  • lifeEnd: the time stamp (exclusive) at which the object was deleted or replaced.
The time at which a given object is live is therefore represented by the interval [lifeStart, lifeEnd).  The latest live version of an object will have lifeEnd set to +infinity.

There are two ways in which a (logical) object can change, each of which modifies its lifeline:
  • Delete: if an object is deleted, then we "end of life" the last object in the sequence, which means we set lifeEnd to the delete time;
  • Update: if an object is updated, then we "end of life" the last object in the sequence and create a new object with lifeStart set to the update time, and lifeEnd set to +infinity. 
We've changed the EveKit API (see below) to make it possible to query the version of a logical object at any given time.  If the query time is t, then this query is just a scan through the object sequence for an object with lifeStart <= t and t < lifeEnd.

Versioning everything raises some efficiency concerns so we've made two main changes to try to keep things performing well:
  1. Queries are optimized for returning the latest live data.  We're assuming the vast majority of API calls will be for current live data, so we've optimized our queries to work best for that case.
  2. We've internally refactored data which changes frequently. For example, most of a Character Sheet is relatively static except for things like "balance".  So we version balance data separately from the rest of the character sheet. This change minimizes the amount of data we have to copy when versioning.

What Happens to Meta Data? 


EveKit allows user defined meta data to be assigned to any object we sync through the XML API.  Meta data is just a set of key/value pairs made up of bounded length strings.  We've chosen to not version meta data, which means the following:
  • Meta data is associated individually with the physical objects which make up the lifeline of a logical object.  That is, meta data is a non-versioned property of each physical object;
  • Meta data may be copied forward depending on how the lifeline changes.  Specifically:
    • If an object is updated, then the meta data for the old object is copied and becomes the meta data for the new object.  This copy is completely independent of the meta data for the old object.
    • If an object is deleted, then later re-added, then the new object will have empty meta data (meta data is not copied from the last live version of the object).
  • Meta data changes independently for all physical objects in the lifeline for a given logical object.  This means you can modify the meta data for a given object without affecting the meta data for any other object currently in the same lifeline. 


API Changes


There are two basic changes to the EveKit client APIs:

  1. Every API call for synced data now includes an optional "at" parameter.  If you specify this parameter, it should contain the time stamp (in milliseconds UTC since the epoch) at which you want to view your data.
  2. Every API result now includes two new fields:
    • lifeStart: the time stamp (in milliseconds UTC since the epoch) at which the returned data became live, or 0 if this data was live when the site was switched over (see below).
    • lifeEnd: the time stamp (in milliseconds UTC since the epoch) at which the returned data was deleted or replaced by a more recent version, or -1 if this data represents the latest live version.
If you omit the "at" parameter, then EveKit will return the latest live version of the requested data.  An API call will either return valid data, or throw an error code if no data was live at the specified time.

For API calls which return a single data item (e.g. a single asset), lifeStart and lifeEnd are a direct view of the current life line for the given object.  For API calls which return multiple data items (e.g. a list of all assets), lifeStart and lifeEnd are bounds:
  • lifeStart = max(lifeStart) for all items returned by the call
  • lifeEnd = min(lifeEnd) for all items returned by the call
The individual items within a returned list may have different individual life lines, but the result is guaranteed to be live in the bound represented by lifeStart and lifeEnd.

A Special Note About Meta Data


As described in the technical details above, EveKit meta data is not actually versioned.  So there are no API changes for meta data and there is no "at" parameter required for meta data calls.  The lifeStart and lifeEnd values in a meta data response can be safely ignored.


How the Roll Out Will Work


The roll out is a multi-step process all occurring during down time:

  1. The data sync scheduler is disabled.  No new API data will be synchronized during downtime.  You can continue to make API calls against EveKit, but the results will be unpredictable.
  2. All current sync data is backed up.
  3. All current sync data is converted to Wayback Machine mode.  Each current data time will be assigned a lifeStart of 0 and a lifeEnd of +infinity.
  4. After a few basic tests, the data sync scheduler will be re-enabled and down time will end.
All current data is therefore considered live at the time of conversion.  The conversion time also places a natural lower bound on the "at" parameter: a query before the time of conversion will always return all the data which was live at conversion time.  As new data is downloaded from the XML API, current data will be versioned as described above.

Final Thoughts


We're very excited about this change, but we're also a bit nervous about any change that touches everyone's data.  So we'll be watching the Beta site pretty carefully over the next week before we decide to make the change to the main site.  We'll continue to post updates to the forums, this blog and the EveKit main site as we get closer to releasing on the main site.