Eve Needs a Tock, Not a Tick

The Clock Keeps on Ticking

The computer industry uses a term called “tick-tock” to describe progress in the CPU-release cycle.  A tock represents a major breakthrough or a radical change in architecture while a tick refers to an incremental upgrade that while noteworthy, is nothing to rave about.

Intel’s new processor increased in Base Frequency from 3.4 GHz to 3.5 GHZ? That’s a minor enhancement when compared to changing architecture of Intel’s Sandy Bridge series processors.

I thought that the CSM7 cycle would have been a period of major change but rather we saw a laundry list of items receive work. The Crucible, Pre-Inferno, and Inferno cycles got developer time assigned to work on a backlog of ticks.

Granted Retribution contained a lot of ticks, but I wouldn’t call them a tock when looking at the scope of changes that came when Tech 2, Capital Ships, and Wormhole space were introduced.

My current sentiment are mirrored in Marc’s recent post:

 …There are murals that could be painted to guide the way for EVE’s development for the next ten years, rather than looking at the last ten years and trying to fix all the mistakes. Not to say that mistakes can’t be addressed, but instead let’s try addressing them in new and inventive ways. Let’s kill two birds with one stone – set past wrongs right while also providing new and exciting content, or the frameworks for content generation, to attract a whole new generation of EVE players.
CSM Season Opens with Two Declarations and a Drama at Malefactor

Code Life Cycle

Working daily with a team that uses the same Agile software development methodology as CCP, I understand their struggle because we have many of the same challenges in our environment.

From what I have gathered from reading over CSM minutes, staff interviews, and perusing the Developer comments on the forums, a major hindrance to the advancement of the Eve world was in their inability to decouple their code.

If you made a small change to one section, it will affect thirteen other places that rely on it — oh, and all of the code is undocumented and the developer that wrote it no longer works here. As developers have changed seats and coding methods have advanced, I’m sure the style and quality of the current code is far more elegant and efficient. It can be easily tested and regression tested (something I think they have a problem with in previous years).

In the past few years CCP would develop, deploy, and then fix-on-failure. Compare the amount of patches and bugs in the 2009/2010 releases to the recent Retribution deployment. I haven’t worked out the numbers, but I feel it is significantly less.

The decoupling steps have been happening are ticks that will (hopefully) lead us up to a major tock.  Two major examples of steps to decouple sections of code can be seen with changes that came in the Crimewatch redesign and the rework of Hangars.

CCP has stated repeatedly that the Crimewatch system was old, clunky, and filled with a ton of fringe cases that they had to handle with bulky nested code. With the re-write of the system, they have reduced the amount of arcane scenarios into a more manageable rule system that they can support.

The recent changes to Hangars took a section of code that treated Hangars in POS’es, Ships, and Stations as the same entity and made them separate. Now making a change to the branch that handles a Carrier will not longer need to be tested against POS’es or Hangars.

I see this Hangar change as a necessary step to enable the development of an entire new section of code that will handle POS’es. There was no way to use the existing branches to handle all the design requirement that we are requesting in the new POS system. Now that POS Hangars have been decoupled, they can truly start working on the new POS design.

Tick, Tock, Tick, Tock

Time moves on and more cycles pass as we march through time. Hopefully we can have some major tocks coming up rather than ticks now that a lot of smaller, necessary work has been done to set us up for a major architecture change.

Just as Marc stated in his post that I quoted from, demand more of the next CSM and yourself. We have the power to put people in place that will help us drive the changes we want.

[Jan 07 update]

Comments from CSM7 Member Hans Jagerblitzen:

hans_jagerblitzen_twitter


13 Comments on “Eve Needs a Tock, Not a Tick”

  1. Tom Hoffman says:

    DUST would be a pretty big tock. And of course, Walking In Stations was supposed to be too…

  2. I agree EVE needs a very big Tock! CCP seems to be so busy constantly fixing broken stuff in the sandbox they dint really seem to have time to really look ahead to where they really want EVE to go and make changes to guide it there with a clear vision. Seems to me they will be stuck overhauling ships, fixing broken stuff and more for some time. It would be good if they were looking ahead and adding new stuff. But with so much broken can they ever catch up and get ahead of themselves and set a real vision to guide EVE there with new stuff.

  3. Orakkus says:

    I’m hoping that the “tock” will be some iteration on Walking In Stations, but I still think CCP is a bit gunshy right now.. even though I think they have the understanding and capability to put out a decent (though incomplete) product for it.

  4. I think they’re in a bit of a bind, because if you have a whole pile of undocumented and poorly-factored (or unfactored!) code with a lot of dependencies, you’re more or less obliged to do a lot of ticking before you even have a chance to tock. In a way, Incarna was good for CCP, because it revealed that their approach to development–from blue-sky to implementation–was unsustainable.

    To put it bluntly, we will not walk in stations while the station code is a horrible mess. CCP’s challenge is to find major features that they can safely build on top of code that they’re confident of, so that it doesn’t become yet another albatross around their collective neck, because on a strategic level, you’re right: customers expect tocks.

    • NeVrain says:

      I’m with you 100% on this Dersen. DUST is a tock, yes, but the brilliance of it is that it all happens through an API-on-steroids(CREST). It may have actually been easier to develop from scratch on another platform that decouple legacy code in EVE. In fact, I’m sure it was.

      Two majore tocks need to happen in EVE.

      Most fundamental is the physics/celestial engine. Apparently tied in at a genetic level to just about everything, and very limited as a physics engine. In terms of difficulty, that project makes Trinity look like a cakewalk, i’m guessing.

      A close second is a gameplay tock: moongoo redistribution. There need to be mutiple channels for the aquisition and processing of moongoo, focused on widely varying playstyles. And I feel it would be a missed opportunity if part of the aquisition/refining/manufacturing process for goo were not tied in to DUST in a fundamental way.

  5. modex says:

    Couldn’t agree with you more. The ticks were important, and they need to keep doing that, but in order to continue to grow the game CCP needs to do more. As complicated and big as the game is, its also a bit hollow. What’s there to do in any given system? (missions don’t count) Why do I care if I travel from one constellation/region to another? Where are the warzones/borderlands? Can’t play other factions? Can’t smuggle contraband?

    There’s plenty of room to add gameplay, while also improving on existing aspects of the game. Many of the existing aspects of the game feel like the fake building fronts of a hollywood film set. Once you open the door, there’s nothing there. CCP needs to add more structure behind those facades.

  6. oli says:

    There’ll always be something for CCP to add. And no doubt they feel the need to issue a tock just as much as we hanker for it – because they care about the game and its’ players. Nobody should take away from the ticks in Retribution though. They were an accumulated massive improvement in they way most of us play the game, and I think most agree. When was the last time you saw 57k logged in on Tranquility?

  7. Tk says:

    Whoa whoa whoa… Everybody wants to see some big new shiny thing, but for pete’s sake, don’t knock a company that’s willing to plow through a bazillion lines of code fixing bugs for months… omg, can’t even tell you how many other games I’ve played that would’ve been damn near *perfect* if the devs had taken five seconds to quit throwing new crap into the mix long enough to iron out the game-breaking flaws.

    I love to see new additions to any game that add depth and purpose to gameplay, all I’m saying is please, please don’t take those ticks for granted. 🙂

  8. I agree the latest releases have been ticks that polished the game play.
    But, the biggest distinction of EVE to other games is the sandbox character of game play.
    I’m really hoping CCP puts more emphasis on that in the future. Games with shiny units and fun explosions are a dime a dozen whereas the game style is what makes games unique and keeps people hooked. and when was the last tick or tock that affected EVE’s sandbox game style?

  9. Sestos says:

    I have to say I disagree. It took CCP almost 5 years to revisit and fix features that were never finished during their “1000 papercut” fixes. I think Dust is the tock, I would love to see CCP continue to finish content that was half completed 3+ years ago before they add even more new features.

  10. Bede says:

    Sometimes the customer is his own worst enemy….

    The game does need a tock, but there’s so many low hanging ticks that could be done that would massively increase the amount of things you could do in-game.

    A tock for me would be something that’s been on the cards since forever, Pos Updates…
    and maybe even destructible outposts.

    Improvements to industry queues and screens even if it means an increase in the cost for build slots,

  11. synth says:

    Not a very accurate metaphor at all. It’s not “the computer industry” that uses a tick-tock release schedule, it’s Intel. Just Intel. And a tick is a die shrink, where a tock is a new microarchitecture. They’re both necessary improvements, not a “major breakthrough” compared to “nothing to rave about”.


Leave a reply to Tk Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.