| Pages: [1] :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Serenity Steele
Dynamic Data Distribution
Ministry of Information
   |
Posted - 2008.12.13 09:41:00 -
[1]
Edited by: Serenity Steele on 13/12/2008 23:58:12
This idea is fairly simply, but wide-reaching. The proposal is to audit the game mechanics for all item generating activities to make sure there are at least 2 game mechanics for getting the items, and to set alerts for practical maximum item generation.
This is a form of "insurance" against game mechanic exploits and imbalances.
Alerts on practical maximum item generation
Take the example of Ferrogel production for the recently known moon mining exploit, the silos were filling in 1 day instead of 7 days. So every moon that was exploited was the equivalent of 7 moons. But since eg. dysprosium moons are rare, having an effective 50 x as many dyspro moons would stand out against maximum theoretical production - raising the alarm and prompting investigate.
Can anyone think of more examples where theoretical/practical max could be calculated?
multiple mechanics
This is a little more theoretical, but in the case where there are two mechanics, the rate of usage of the mechanics and player activity in the two mechanics can be compared, if players suddenly swing towards using method, then it is a prompt to investigate. Tech II BPOs + Invention, Moon mining + Alchemy are examples where this occurs. So the trick is to extend that approach to all item creation.
Can anyone thing of examples where this doesn't occur?
Pros
* Provides an earlier warning system to identify where "unusual" activity is going on that might be an exploit
* Less reliant on players "doing the right thing" and reporting exploits or escalating
* Less reliant on GMs picking up on potential exploits or imbalances when investigating petitions
* ??
Cons
* Reduces the geography of eve, by effecting conflicts over resource control; eg. when there are other mechanics it's not worth fighting over a moon.
* ??
Related threads:
A Call for Transparency regarding the Reaction/POS Exploit
Starbase exploit addressed
≡v≡ Strategic Maps in Eve-Online Store | eve-maps.com |
Serenity Steele
Dynamic Data Distribution
Ministry of Information
|
Posted - 2008.12.13 23:56:00 -
[2]
Forgot support :P |
Gorn Sotrizo
|
Posted - 2008.12.14 23:51:00 -
[3]
I'm all for auditing a game that's supposed to have a vibrant and real economy. If for nothing else then to send up red flags when things like that happen.
|
James Lyrus
Lyrus Associates
The Star Fraction
|
Posted - 2008.12.15 00:23:00 -
[4]
Edited by: James Lyrus on 15/12/2008 00:26:01
Well, gameworld validation is an interesting concept. I'd support it being looked at, but have no idea how feasible such a thing is. I know databases I've messed around with defining 'database wide' validation of the kind you seem to be suggesting is expensive on system resources, and prone to being not properly maintained.
*shrug*. I think it'd be nice to be looked at as a possibility and thus I support it. I don't actually expect it to turn out as particularly feasible though.
The logical other places where you could apply such validation is mineral creation. Given respawn rates of asteroids, there's only so much veldspar that can be extracted in a given day.
Or for that matter NPC average module drop rate vs. NPC destruction/respawn rate (e.g. like in the bugged complexes whenever it was).
On average only so many Dread Guristas Invulnerability fields should show up each month.
But the problem is, as ever, bugs aren't introduced deliberately. So there'd no guarantee that however a bug is introduced wouldn't automatically roll over to the validation system.
--
249km locking? |
evilphoenix
Beyond Divinity Inc
|
Posted - 2008.12.15 00:57:00 -
[5]
Would have thought this would have already been being done...
--------
|
Myrhial Arkenath
Ghost Festival
|
Posted - 2008.12.15 09:13:00 -
[6]
Supported. Aside of exploit-protection I like the idea that this could help in reviewing which methods are underused and why. This could help in tracking down what needs fixing.
Diary of a pod pilot |
Chochko
Bulgarian Mafia Squad
Sons of Tangra
|
Posted - 2008.12.15 09:16:00 -
[7]
-------------------------------------------
Ahh and Hek! |
Orb Vex
|
Posted - 2008.12.15 10:27:00 -
[8]
|
Dasfry
Demio's Corporation
101010 Alliance
|
Posted - 2008.12.15 10:38:00 -
[9]
I'm all for a little check up once in a bit.
Maybe simplify it..
Have a list of the top 1% wealthiest players,
and randomly pick one and audit their income?
***********
Dasfry, Director
Demio's Corporation
Military Tactics |
Sean Drake
Dirty Deeds Corp.
Axiom Empire
|
Posted - 2008.12.15 11:25:00 -
[10]
Sounds good
If Goons AND BoB are agreeing with each other that your idea is stupid, it's probably stupid.
CCP has bee |
|
|
Jaisan
Minmatar
Alcatraz Inc.
|
Posted - 2008.12.15 18:16:00 -
[11]
Better checks and balances.
Indeed.
Just too orangey for crows. |
Mara Rinn
|
Posted - 2008.12.17 04:40:00 -
[12]
Something as simple as making sure that the program responsible for putting a reaction product in the output of a reactor is also responsible for loading the next reactants into the reactor, and only generating the reaction product when reactants are available.
It's something like two-column accounting. You have one process responsible for emptying the product from a reactor into the silo. You have another process that reacts the reactants together and turns them into product. Then another process draws more reactants from the connected silos/couplings.
Empty the reactor, then perform the reaction, then load the reactants. If there are not enough reactants available, the reactor is stopped, with a message posted to the corporation telling them the supplies have run out. Along the way, record the consumption and production totals for the reactor.
The balance side of the equation is this: at maintenance time, make a record of the various reactions that are configured in running reactors. Compare that to the consumption/production totals for all the reactors. If the consumption/production is out of proportion to the expected results of the configured reactors, start looking at why.
People don't just go changing reactors around every few hours. Usually there's messing about with the P.O.S POS UI to get the reaction set up properly, then the POS is left alone except for adding supplies, ammo and fuel, and removing product.
The same thing would apply to manufacturing lines, blueprint copies, researching, etc. On one hand, you only produce the output in the same process that ensures the inputs are there (ensuring the inputs are destroyed if it's that type of process). On the other hand you monitor the total consumption and creation and compare that against the total configured processes.
Are more blueprint copies in existence than can be explained by the total blueprint copying processes that have been run today?
Is more ferrogel come into existence than can be explained by the total number of active reactors?
I tentatively agree that multiple processes to get the same product might be a feasible means of gauging if another exploit has been discovered, but that is only going to work if the demand for materials and ownership of productive moons remains stable for longer than twice the full material cycle.
If the critical path from Dysprosium -> Ishtar is one month (mining the Dysprosium, reacting the ferrogel or whatever, building the component parts, then building the ishtar), you'd need demand for the components and ownership of the moons to be stable for at least two months to see any stability in the system.
In general, any process that involves the conversion of some thing to some other thing must be audited by having a record of the instances and iterations of that process (setting up a copying run, loading a reaction into a reactor), as well as a separate record of the consumption and production of materials used by that process (every time a blueprint copy is created, every time a reaction product is created, every time tritanium is consumed to produce a scourge missile). You might be able to get away with recording the iterations of a production run, if there is a guarantee that the process of running that iteration consumes the required resources or fails to produce anything.
Talk to a bank about financial software :) You never add money to one account without guaranteeing that it's removed from some other account first.
|
|
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |