October 2, 2015

More Fuel for the Eve Hype Train

CCP came back from summer vacations and opened up the throttle on the communication and the hype.  The real test, as always, will be the delivery but there are some obvious and not-so-obvious major news items in the latest flurry of communication.

Style
First off, big points to CCP Seagull for these video blog entries.  Close-up, looking straight into the camera, earnest and every bit the leader that I think many of us were so impressed with when she first hit the stage.

Secondly, the team is laying it all on the line with the Eve Updates page.  Not just items for next release, or even the release after that.  We have teasers to pique your interest clear out to Fanfest.  The risk here is that anything that is even mildly delayed will stir up every little rotten pit of negativity in the community.  This is a change from the previous approach of having rapid patches which can get announced mere weeks before the work hits the servers.

Is this a sign that CCP is being responsive, or that they're very deeply worried, or both?

Solid Responses
"We heard you" might be the theme from the capital rebalances to the careful steps around the use of Entosis links vis-a-vis citadels.  Right up front is the change to the Jump Fatigue limits.  We'll see if this means that big players will reach out farther, willing to make big strikes on the weekends knowing they can reset again by the next weekend.  Structure changes for nullsec includes the passive wind-down of attacked nodes if the attackers don't stick with it.  This seems like a good change to slow down trolling without inhibiting true attackers.

Teasers
Crimson Harvest?  The return of the Drifters is a fix for the briefly-implemented invasion of the Throne Worlds that I personally hope will have the potential to spread across New Eden if left unchecked.  But the Crimson Harvest - a new Blood Raider incursion?

Sneaky Fundamental Eve Changes
So kill marks on your ship for each final blow that this particular hull has scored - cool right?  But this feels like something far more fundamental has just slipped in.  In the past we've often talked about how each ship is very generic in being an entry in the database.  The only thing really different was the name that was assigned to it.  Now there is also an integer value which not only is driven by other game mechanics, but which feeds through and changes the behavior of the rendering of the skin.  Similarly we have reports of how dust and debris will accumulate on ships based on usages, or rust if they sit in hangar.  I think these are potentially signs of something deeper going on in the implementation of Eve, something which allows each database entry to be a bit more distinct.  We'll see - maybe this is just a bit extension of the uniqueness of the ship name or maybe it is something more.

I didn't even cover all of the things.  D-scan on the probe window?  Ice mining frigates?  Players who are of a positive mindset will climb on the hype train, and those who are deeply embittered will find a way for each new thing to represent disappointment to them.  Find what you love about the game and I think you'll find something to love in all of these announcements.

3 comments:

  1. I don't know if you program or work with databases or not but your "Sneaky Fundamental Eve Changes" aren't so fundamental. Most of it is just a simple variable stored with the ship database entry that the shader looks at to determine how to handle a range of values. It looks more magical than it is technically, but it'll still look awesome when they come out =)

    When they tell you that ships are generic items, they're only telling you a half truth. They're generic items until they've been assembled, then they become unique until repackaged. This saves you from having a ton of duplicate data entries all over the place that bloat your database. What they were really telling you was that they didn't want to deal with that spaghetti code at the moment.

    An example of what I mean is: I have a pile of potatoes. This potato has this color, size, weight, number of pits. This next potato has this color, size, weight, number of pits. This one has this color........for the whole pile. Instead you'd say, "I have a sack of potatoes and I'll figure out each potato's properties when I take it out of the sack". That way, when you look at the sack, all you really need to know is that they're potatoes and that there are a given number in the sack.

    -Baljos Arnjak

    ReplyDelete
    Replies
    1. Thanks for the database side insight. I have a decent programming background (now getting rusty) but no database design and optimization experience. I probably phrased that badly as well. Anyway, until now we haven't seen any real use being made of the unique values on the assembled ships (other than the ship name). I suppose the Brain In A Box aspect also comes along here, if ships can have properties that can be queried and modified effectively in the midst of combat.

      To bring it over the OOP side, if we're getting to each ship being an instance of a class that can have methods and properties that can be called (ship.incrementKills or ship.receiveReps) then that means that fancier logic can be done on the inside. Such as a stacking penalty on reps, for instance...

      Delete
    2. That's exactly what I mean =).

      We see OOP and the unique values on the assembled ships in action literally all the time, just never realize it. Spatial position, everything on the Show Info and some of the stuff on the fitting screen, ship name, current hull/armor/shield values, references to all the instances of modules, weapon groups, cargo, and probably a hundred other things that I'm missing are all likely members of the ship instance.

      You can't really have a game of any real complexity without OOP =)

      -Baljos Arnjak

      Delete