Idea to stop dupes on closed bnet (d2/d3)

[Fenzalk]

Idea to stop dupes on closed bnet (d2/d3)

I've been on the WoW D3 forum theorycoding a way to prevent dupes. I've developed what I think is an airtight method. It involves a bit of creative thinking though. I'd thought I'd post it here to see what you guys think.

It would require a database rewrite.

You'd have to rethink what an item is and what a char is. Currently, we kinda view chars as these objects that own a collection of items. These items then get traded around between chars or fall on the ground. That structure allows duping to take place as items can be written to multiple char objects. Then you are forced to do things like a ruststorm, which uses so much system resources that its not employed much.

Instead, you have to turn things around and think of the items themselves as objects that own either a player or "the ground" or an NPC. They would be unique thanks to the footprint, and can only own one thing at a time. It would be impossible to assign one item to two players.

So instead of

charType Fenzalk {

Engima armor #43118
chipped skull #440039560

}

Your database will look like

itemType EnigmaArmor {

ID #43118
Owner Fenzalk
Location Fenzalk inventory
Status Exists (can be either exists or destroyed)

}

Now you simply can't dupe it. You cannot because we define the item-char relationship by a single variable assigned to the item object. There is only room for 1 owner. Can't have 2. Or 200. Its physically impossible.

Here is what happens when items own a player. Player A enters the game with a Zod. He drops it on the ground and desyncs with some attempt at a duping bug. Now HIS ITEMS revert to the previous ownership status. Of course, there is nothing to update the database with because nothing has changed. Technically, the Zod on the ground still recognizes Player A as who it owns and still thinks its in Player A's inventory. Now Player B picks up the Zod and exits the game. Now we update the Zod's info and make it own Player B. If Player A is in some other game when Player B exits a game with the Zod, Player A is informed he has a dupe and the item is immediately removed from Player As inventory when ownership status changes. If the item is lost in the process of cubing or when the game it exists in is closed, its status changes to destroyed, and cannot own anyone any longer.

Its when an ITEM exits the game, either via a char's inventory, a cubing, or a game closing, or a reset NPC shop, that ITS data is written to permanent storage.

 

[chezzmaster]

Re: Idea to stop dupes on closed bnet (d2/d3)

Interesting method, although it would require extensive recoding of a lot of objects I think. Still it seems a valid theory to me

 

[raveharu]

Re: Idea to stop dupes on closed bnet (d2/d3)

why are you posting this here? we do not create the game

Obviously Blizzard knows what their doing, they have top notch programmers.
But even with that, hackers will still break into the defenses.

 

[chezzmaster]

Re: Idea to stop dupes on closed bnet (d2/d3)

why are you posting this here? we do not create the game

Obviously Blizzard knows what their doing, they have top notch programmers.
But even with that, hackers will still break into the defenses.

You have to realize they began programming this game back in the late nineties, and they didn't have as experienced programmers back then as they do now. Blizzard probably has to work with code with plenty of problems that are too embedded in the game to fix. Blizzard keeps trying to put band aids on their game instead of going in and suturing it like the OP's suggestion.

 

[5zigen]

Re: Idea to stop dupes on closed bnet (d2/d3)

This is an interesting post. Unfortunately I don't know much about how d2 is coded but it seems like changing this would be more than a simple rework of d2...

I don't know what blizzard will do but I think it's safe to say dupes won't be a problem in D3.

As for your method, just theoretically, wouldn't it require much more work as far as the database goes. Saving a character means the server has to write to the disk one time in one spot. If it has to save all of your gear independently, then it would have to write one time for everything you were wearing, everything in your stash, and everything in your inventory. That's a lot more writing and searching in the database.

You have to realize they began programming this game back in the late nineties, and they didn't have as experienced programmers back then as they do now. Blizzard probably has to work with code with plenty of problems that are too embedded in the game to fix. Blizzard keeps trying to put band aids on their game instead of going in and suturing it like the OP's suggestion.

I'd also like to point out how much of an improvement D2 was over their previous endeavors (D1). AFAIK D2 was one of the earliest games to host games and store player information on a central server.

The strides blizzard made between D2 and D1 were huge.

 

[chezzmaster]

Re: Idea to stop dupes on closed bnet (d2/d3)

As for your method, just theoretically, wouldn't it require much more work as far as the database goes. Saving a character means the server has to write to the disk one time in one spot. If it has to save all of your gear independently, then it would have to write one time for everything you were wearing, everything in your stash, and everything in your inventory. That's a lot more writing and searching in the database.

The weapons and characters are already treated as separate objects, If I understand the OP correctly he suggests we just change it so instead of the player owning objects which exist in his inventory, the weapons have the attribute that determines where they exist. You can't have an object which owns multiple players because they can only own one, while where it stands now the player owns multiple objects. Sorry if that didn't make sense I'm tired.

I'd also like to point out how much of an improvement D2 was over their previous endeavors (D1). AFAIK D2 was one of the earliest games to host games and store player information on a central server.

The strides blizzard made between D2 and D1 were huge.

Exactly the point I am making. How far has blizzard come in terms of a games complexity and capabilities since D2? ANd yet they can't go back and totally rework it, it just isn't cost effective.

 

[5zigen]

Re: Idea to stop dupes on closed bnet (d2/d3)

The weapons and characters are already treated as separate objects, If I understand the OP correctly he suggests we just change it so instead of the player owning objects which exist in his inventory, the weapons have the attribute that determines where they exist. You can't have an object which owns multiple players because they can only own one, while where it stands now the player owns multiple objects. Sorry if that didn't make sense I'm tired.

I think what I am saying is that under the current system the only thing that has to be written to the database is the character, with the character information carrying the id of all the items it carries. So the system right now only has to write once (or in one place) even if it has to write slightly more (because it's writing all the character information and item information at once.)

If you switch it around, you are writing every item separately and they might need to be written at different places as well, and even if these are smaller than the larger character writes, the fact that it's more separate writings might stress the server more (I'm not 100% sure on that, but that's what my rudimentary understanding of how server databases work).

I guess there could be some way of doing it. I mean, you could make some system that is two databases, but there also might be difficulties in having EVERY item in a database (it would be HUGE).

 

[nasarius]

Re: Idea to stop dupes on closed bnet (d2/d3)

Didn't read your whole post, but database reliability is very much a solved problem. There's no need to reinvent the wheel. In a real-time environment like an MMORPG, you need to tweak things a little for load balancing and performance, but there's no magic involved.

You can track characters and their items in a manner very much like bank accounts and their balances.

 

[hubb]

Re: Idea to stop dupes on closed bnet (d2/d3)

I guess there could be some way of doing it. I mean, you could make some system that is two databases, but there also might be difficulties in having EVERY item in a database (it would be HUGE).

Yeah, halfway through first year programming hardly makes me an expert, but it seems logical that the resource requirement would be massive.

 

[Krugar]

Re: Idea to stop dupes on closed bnet (d2/d3)

The concept is interesting Fenzalk, and not unknown. It's similar to the database design expected for many real life applications like Invoicing, account management, vehicle databases, et cetera.

But you have one big problem there. In mission critical situations like those expected on an online game, the database is always the performance bottleneck.

The major problem I see there is that when you link an item table to the player table on a one to one relationship, you'll need a recordset to list all equipment owned by the player. Allow me the illustration:

|-------------------|                   |-----------------------|
|PlayersTable       |                   |ItemsTable             |
|-------------------|(1,1)              |-----------------------|
| PlayerID      Key |---------|         | ItemID           Key  |
| Name              |         |---------| OwnerID          Key  |
| datecreated       |              (0,n)| Location              |
| etc...            |                   | StatusExists          |
|-------------------|                   | etc...                |
                                        |-----------------------|


PlayerID is the player's table index key and contains a foreign key
describing a 1-to-many relationship with OwnerID in the Item's table.
Essentially it describes: 1 player may have 0 or more items.

So... what this means is that in order to list all player equipment, you'll need an SQL statement to draw all equipment from the ItemsTable for player x.

SELECT * FROM ItemsTable WHERE OwnerID = x

Since OwnerID is part of a compound key, this query shouldn't take much. In fact, it soon should be cached by the server. However, with thousands of players online and many other database cacheable queries in place, it should be expected it won't last long in cache, forcing the server to constantly running queries like this from scratch. This can quickly amount to a big load on the server.

Then we need to take into consideration the amount of data that is going to be drawn of ItemsTable. How many fields there are in ItemsTable? Does it fully describe an item (say, 30, maybe 40 columns)? Or does it only describe an item location (the 4 columns above would enough)?

If it fully describes an item, the select query above will carry an hefty communications load. If the player has 100 items, the query statement will result in a 100 records recordset each with 30 or 40 columns. That's 3,000 to 4,000 columns. Some of these columns are simple integer values, others are floats, others even are text. It won't be an exaggeration to say that a 100 records recordset fully describing items owned by the player could take, hmm... 1Mb of data? And this needs to be passed from the database server, throught the communications pipeline to the game server for processing.

If instead it just describes items location and ownership, then a second query will be necessary to gather the remaining information. Which will slow down performance even further. Essentially, one larger query is always faster than two smaller queries. And we will still need to pass the whole information. So no gain there, and instead a loss.

And finally to both cases you'll need to consider that with thousands of players online and these queries running all the time (every time an item is picked/dropped/traded), the load on the servers and communications gets increased to outstanding levels.

...

Necessarily one can reach the hardware level to handle this load. Databases can be replicated through several servers, caches can increase in size (although a cache is a dangerous thing in these circumstances since it can allow a dupe to exist until the cache is cleaned/overwritten), communications can see their bandwidth increase to larger sizes by many means available. But one can probably reduce the load and give it back to what matters -- data that is used to play the game -- without loosing your idea...

...

I do think you have it right. That's a good way to do it. I can't think of the top of my head a way to break it, because you are securing data beyond players control. But what about instead of running your system in real time, why not run it in intervals of time?

We keep your idea, but actual dupe detection is done in intervals of time by a dedicated server that runs through the database every, say... 60 minutes? The load would be incredibly reduced and while potential dupes could be allowed to exist to a maximum of 1 hour, this would be enough to kill the incentive. Meanwhile, because the search would always be global, the dedicated server(s) could include their own dupe managemnent application that would send to the database server(s) just the data needed for item removal, reducing even further communications load.

 

[Demetrium]

Re: Idea to stop dupes on closed bnet (d2/d3)

Good post. I'd love to see D3's ERD.

 

[Starving_Poet]

Re: Idea to stop dupes on closed bnet (d2/d3)

The problem with you method is there is too much duplicate data in your database. Making item changes would require HUGE transactional operations.

If they built any sort of real-world database then it would look something like this:

Character Tables
{

CharacterID - primary key
AccountID
CharacterName
Stats etc.​

}

Item Tables
{

ItemId - primary key
ItemName
ItemStats​

}

Inventory Tables
{

ItemID
CharacterID
modifierHash
creationHash - primary key​

}

The creation hash is created when the item is generated from a drop - there can only be one creationHash / ItemID key pair in a database at a time. So, even if an item is duped, that creationHash will just be replicated and it won't be allowed to be inserted into the table.

 

[Krugar]

Re: Idea to stop dupes on closed bnet (d2/d3)

Careful with using hashes for primary keys!

 

[Starving_Poet]

Re: Idea to stop dupes on closed bnet (d2/d3)

Yeah, it's really a compound key, I should have been more clear.

 

[Jephery]

Re: Idea to stop dupes on closed bnet (d2/d3)

Searching an enormous database of items everytime someone exits a game is way too much of an overhead.

Solving a problem is one thing, solving it efficiently is another.