EVE General Discussion

Maybe someone at CCP might be able to answer this one for me please?

The Achilles' heel of every expansion/patch so far was the inability to do swift and tiny adjustments to stats of ships/gear/etc. pp. which leads to unbalanced features that dominate the gameplay for extended periods of time. The so called FOTM-disease comes to mind.


Now with the massive changes to Supers, Hybrids and the new Tier3 BCs around the corner I'm in fear of a another sequel of the '3+ month post patch FOTM imbalance'.


Wouldn't it be cool if you had a tool that would allow tiny adjustment to whatever value you can come up with to the live server within 24 hours - especially after deploying new stuff?
This way you can make small and fast adjustments and get fast feedback on the changes, instead of the current situation where you adjust such values maybe once.. twice a year and then it's nearly always overshooting (nerf).

I don't think we will see such a thing in our lifetime. Perhaps our children one day will have the benefit of this new technology.

..and what has this to do with the current long turn around times for tweaks that lead to FOTM and unbalanced gameplay for months? Devs repeatedly said that it's not easy to get tweaks done (even if they would be needed swiftly) as there is no system for that and they have to wait for the 'larger cycles' to make it (if at all).

The testserver doesn't help with the core of the problem, and that is:
There is no way for CCP to.. let's say increase the tracking speed on a Small Blaster I within the next 24 hours without involving a horde of Devs + night-shift for all in QA + a patch for all of us.
Way to miss the point Andski.

Ok, I've seen some mods around the forums, so they're awake.. Spitfire, anything you could forward when Monday starts?

There is no Flavor of the Month in eve. Instead it is replaced by Flavor of 2+ years.

If i did not know better I would assume that a game like EVE-online would be extremely well balanced due to the amount of time and effort risked in pvp. Instead it's the exact opposite and we have large numbers of extremely broken ships essentially removing variation and content from the game. When not a single ship from an entire race is represented on top 20 kill listings there is something obviously very wrong. When more than 60% of ships flown in an AT are from a single faction something obviously is very wrong... When certain close range guns out dmg and track long range guns at 60+ km something obviously is very wrong...

Be professionals here CCP... Take some pride in how your game plays please.

You don't know how much work it is for them to change one value. Perhaps most of the work is done thinking about what to change how and not to do the actual changes.

Perhaps it realls is only changing one value in the database [im doubtful about that ^^] or a few and not rewriting alot of code ^^

*double post*

So I was going to say "no, not really", but then I remembered that we'd made some changes to the "Bulk Data" system recently, so I talked to CCP Explorer and I return with good news!

We now in fact have a system that lets us do pretty much what you're describing. In principle we ought to be able to get stat changes onto TQ with ~24h lead time. In practice, we've never used this system on TQ before. We've tested it extensively so there shouldn't be any technical surprises, but we've not tested the workflow process for using it in a live environment yet, so the first few times we need to make use of it may expose a few bumps and surprises.

Once we get those teething issues ironed out, though, and figure out how exactly we want to use the tool, how to decide when to use it, how to make sure stuff gets through testing etc, we're aiming at being able to get a 24-48h turnaround on urgent fixes, and on the normal weekly hotfix schedule for less urgent stuff.

I was expecting this thread to die of dev neglect. Instead we got a "your idea would work if it wasn't for bureaucracy" response.

There's two sides to that for us.

First is that we need to have most of that info stored on the client, so that we're not hitting the DB every time someone opens a showinfo window. In the past that's meant building a new client when we wanted to change a stat on something, which means going through the full deployment routine (not cheap). With the upgrades to bulk data, we can now make a change to a stat, deploy it to the server, and have the server tell every client that connects to download the latest changes. If you see "loading bulk data" when logging in, that's what this is.

The second thing is making sure stuff is actually correct. We don't as a rule change stuff directly on TQ except in the direst emergencies, because people are people and people will on occasion fat-finger their data input. The way we significantly reduce the incidence of this kind of bug on the live server is by having a clear process for deploying stuff - it gets created on the content creation server or in code, it gets ported through Chaos (internal testing) and Singularity (public testing), and then it gets deployed. Sometimes some things take shortcuts, but there's a minimum standard of "ticking boxes" that's in place to try and catch silly bugs before you see them.

The obvious reaction to this is "if you just edit things on the live server, then you can fix them really easily if you mess up so what's the problem?". The two problems are a) you're still getting buggy values on TQ for a while, and if for example I'm messing around and accidentally add a couple of zeroes to the damage multiplier on Mag Stabs, a lot of people are going to die before I fix it, and b) that's just a straight-up dangerous mindset to approach these things with, because it leads to a very lackadaisical mindset when dealing with the live server that can carry across into much more critical systems and consequently bigger mistakes. Most of us in development generally treat the live server with a reverence bordering on outright fear, and that's a good thing because it means we can't do anything really dumb. (I once offlined a player's starbase on TQ by accident while troubleshooting an issue, because I clicked the wrong button. That was a fun day.)

Also in our case, there's the more prosaic issue that our deployment workflow is very unidirectional - data changes can go from creation server to test server to live server, but not the other way around, so changing things directly on the live server introduces its own entire family of horrendous versioning issues that we just don't want to have to deal with.