These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
12Next page
 

@CCP Spitfire: any DEV working on a realtime stats adjustment tool?

First post
Author
Tres Farmer
Gallente Federation Intelligence Service
#1 - 2011-10-22 02:56:36 UTC  |  Edited by: Tres Farmer
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).
Andski
Science and Trade Institute
Caldari State
#2 - 2011-10-22 02:58:47 UTC
if only they had a separate server that allowed subscribed players to test stuff before it goes live

Twitter: @EVEAndski

"It's easy to speak for the silent majority. They rarely object to what you put into their mouths."    - Abrazzar

Kumq uat
Aliastra
Gallente Federation
#3 - 2011-10-22 03:03:43 UTC
Andski wrote:
if only they had a separate server that allowed subscribed players to test stuff before it goes live



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.
T' Elk
Strategically Bad
Goonswarm Federation
#4 - 2011-10-22 03:06:50 UTC
Andski wrote:
if only they had a separate server that allowed subscribed players to test stuff before it goes live

Keep dreaming, kid.

~Badposter since FOOOOREEEEEVAAAAAR~ I come back after 2 years to THIS? ~Now 4 years apparently

Tres Farmer
Gallente Federation Intelligence Service
#5 - 2011-10-22 03:51:16 UTC  |  Edited by: Tres Farmer
Andski wrote:
if only they had a separate server that allowed subscribed players to test stuff before it goes live

..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.
Tres Farmer
Gallente Federation Intelligence Service
#6 - 2011-10-22 07:21:36 UTC
..anyone at CCP awake yet?
Tres Farmer
Gallente Federation Intelligence Service
#7 - 2011-10-22 14:34:30 UTC
Ok, I've seen some mods around the forums, so they're awake.. Spitfire, anything you could forward when Monday starts?
CCP Spitfire
C C P
C C P Alliance
#8 - 2011-10-22 14:49:50 UTC
Tres Farmer wrote:
Ok, I've seen some mods around the forums, so they're awake.. Spitfire, anything you could forward when Monday starts?


Yes, absolutely, I'll ask. I honestly don't know how easy/hard/appropriate/risky/etc. would it be to implement such a process, but I will try to get an answer for you.

CCP Spitfire | Marketing & Sales Team @ccp_spitfire

Jerick Ludhowe
Internet Tuff Guys
#9 - 2011-10-22 15:27:00 UTC
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.
Slade Trillgon
Brutor Force Federated
#10 - 2011-10-22 15:44:36 UTC
You could not cut the sarcasm in this thread with a laser Twisted


Slade
Orion Guardian
#11 - 2011-10-22 15:46:52 UTC
Tres Farmer wrote:
Andski wrote:
if only they had a separate server that allowed subscribed players to test stuff before it goes live

..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.


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 ^^
Slade Trillgon
Brutor Force Federated
#12 - 2011-10-22 15:55:09 UTC
Tres Farmer wrote:
Andski wrote:
if only they had a separate server that allowed subscribed players to test stuff before it goes live

..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.


Let us ignore the fact that, usually, new content is on the test server for more then just a few days before the patch day.


Slade

Tres Farmer
Gallente Federation Intelligence Service
#13 - 2011-10-23 03:12:42 UTC  |  Edited by: Tres Farmer
*double post*
Tres Farmer
Gallente Federation Intelligence Service
#14 - 2011-10-23 03:12:54 UTC
@Spitfire - thanks!

@Orion - perhaps, probably, maybe.. you don't know, I don't know - that's why I asked.

@Slade - you don't find slight imbalances on the testserver and CCPs current process to adjust those are improper and take too damn long to roll out (if they ever get addressed that is). Also, if code in hindsight would be written in such a way that more stuff after roll-out is adjustable - this wouldn't be such a bad thing, would it?
I wouldn't advocate such a system to be able to change slot counts of ships, but more subtile stuff like powergrid or resists.

For example.. CCP releases the new Tier3 BCs and after roll-out it's found that the Caldari version could use a tad bit more shield regen to be competitive with the other 3.. how long SHOULD it take to adjust that and how long WILL it take and when do we reach the sweet spot and how close can we get to it?

It SHOULD take 1 Dev 15 minutes to adjust the value a tiny bit and the change should be on TQ within 24 hours and might be a tad too much or to less, no problem - tomorrow is another day and we just push another tiny change to TQ till we're happy

It WILL take 30+ Devs 1 week to adjust the value by a big step and the change will come after 1 month and probably not hit the nail on the head.
CCP Greyscale
C C P
C C P Alliance
#15 - 2011-10-24 17:46:28 UTC
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.
Palovana
Inner Fire Inc.
#16 - 2011-10-24 17:57:25 UTC
CCP Greyscale wrote:
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.

Wasn't this how the infamous "Drakes of DOOM" were created on SiSi with super-fast speed?
mkint
#17 - 2011-10-24 18:00:08 UTC
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.

Maxim 6. If violence wasn’t your last resort, you failed to resort to enough of it.

Morganta
The Greater Goon
#18 - 2011-10-24 18:11:19 UTC
CCP Greyscale wrote:
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.


so does this mean the boilerplate stat sheet of a given hull is not in a table somewhere?, like a table of base stats?
what is the BULK data system? is that a pretty way of saying the sql database or it it something different?
why is it now an easier task to modify table data than it was before?
isn't most of this data serverside anyhow?

Being someone who often finds themselves up to their elbows in sql queries and DB tables, I never understood why tweeking a value here and there is often so difficult for most game companies
CCP Greyscale
C C P
C C P Alliance
#19 - 2011-10-24 19:08:11 UTC
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.
Alundil
Rolled Out
#20 - 2011-10-24 19:12:23 UTC
CCP Greyscale wrote:
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.



+1

I'm right behind you

12Next page