Tyrannis 1.1, fallout and why it's a good thing(tm)
So what is all this "UI Core" stuff about anyway?
You may have noticed that we released a patch a couple of weeks ago that, well, broke a lot of things in the UI that we've since been madly trying to fix. There's been a fairly common response to this, which is (paraphrased) "OH GOD CCP WHAT ARE YOU DOING AAARGH" - which in the absence of any proper explanation from us, honestly seems pretty reasonable. However, we don't like it when our players are upset, so we figured, hey, now that everything's settled down and we have time to breathe, we should probably explain what just happened.
tl;dr As unintuitive as it may seem, this is actually us fixing things.*
What's just happened
You may be aware that our UI is lagging somewhat behind the current state of the art for computer games, mainly due to the backend (in technical terms, the "UI framework") having been written by two guys in the late 90s. We're certainly aware that a lot of you feel we should probably be improving it in various ways, a position we wholeheartedly agree with. In fact, we've been working on this for quite some time.
We've talked in other blogs ([1]|[2]) about the process of corification - moving a lot of our EVE-agnostic code into a common place in our code structure, so that we can share a lot of work across multiple projects. This cuts both ways - not only do our other upcoming games benefit from EVE's battletested code, but EVE Online also benefits from improvements made by programmers on those other games. This ends up being a good thing for everyone involved.
We finished most of our corification last summer, but one of the big outstanding jobs was the UI code. As you may have guessed, EVE Online's UI code is rather idiosyncratic, and has thus far resisted corification (despite several valiant attempts). This is work that nobody really wanted to do - it's big and boring and difficult and requires a lot of concentration and late nights and being shouted at for breaking internal builds, and it doesn't even give you the satisfaction of having made something nice at the end, because the best-case scenario is that other departments ask what the hell you've been doing for six months because nothing's changed. However, it's work that's necessary in the long term if we want to make more interesting and visible improvements. Over the summer we bit the bullet, took our medicine, and made a big push on getting the work done. We finally got our known defect count down to zero a few weeks ago, and lined up all the resources and processes needed to release a patch.
As we've all since discovered with a project as large as this, even if we find the vast majority of defects prior to release, the remaining ones still end up being a rather large number of bugs. Most of these should now be fixed. Testing the whole UI is not as easy as it may sound; there are endless use cases and each person uses the UI in a different manner. Because of that, automated tests on the UI are of limited value, so even though we had our whole QA department run through this, defects still slipped through. Admittedly some of them were rather obvious, those are our bad and we should have caught them.
Why we did it
Once we get the last few kinks ironed out, we should have our UI fully corified. This is a good thing, for two reasons:
1. The first stage of corification was to consolidate and update our existing UI engine, to make it more consistent and easier to work with. The breakages we've encountered are pretty much always a result of trying to connect our old front-end to our new back-end, and discovering that a lot of the old front-end code does things in very odd ways, or is using features of the old back-end that we're deliberately deprecating. Make no mistake, our UI developers touched every single file in the UI prior to this release, and converted everything they could see to the new system. This was an absurdly large amount of work, and generated a massive number of defects. During the summer the UI was often quite badly broken in various ways and most of the problems were found and fixed at that stage. The ones we knew about were all fixed prior to the 1.1 patch, and what you've been experiencing on Tranquility in the last few weeks is the tiny part that slipped through the cracks. Yes, that's still a lot of bugs - but that should give you an idea of how big a change this is. End result: our UI code now makes more sense (and can do more things), which makes it easier for us to make better UIs.
2. Because the UI front-end now works pretty much seamlessly with a nice, consistent back-end, we now have the capability to drop an entirely new UI back-end into the codebase, and have a high degree of confidence that all the front-end code will play nicely with it, because there's now a very regularized way that the two parts of the code interact. This is what's technically known as awesome.
The process of releasing a change of this size onto Tranquility, giving the code a really thorough thrashing (assuming 10k players online in the first hour after the server opens, we get ~60 man-months of testing in that one-hour period), and fixing the problems that manifest, is obviously very painful.
However, this is the first step to really addressing the underlying problems with the UI. We went ahead with this because it's a necessary precondition of dragging our UI kicking and screaming into the 21st century. That's something we're pretty keen on.
More turbulence ahead
While we're being transparent about this stuff, we should mention that there's another big change coming up in the next few weeks: moving our inventory service to 64-bit identifiers. We'll have a blog out about that soonTM.
*Yes, obviously "Well, I'd hate to see what would happen if you guys actually tried to break things" - again, you should've seen the state of our internal servers over the summer.