Best approach for storing/modifying item data

Working on a long term project that revolves around each item being unique drops. The stats roll on a certain range of values, each item has a tracking-id that is monitored in case of duping (unsure of all dupes in ruse), and sometimes they have unique perks. No two items are the same regardless of id, basically. I'm looking to improve performance and thinking of long term situations.

As of right now, the items equipped/in inventory are stored with the player's json save file (kept ruse saving). When it comes to banking, I divided the item's data into 4 different json files.

First, there's a json file that holds the map for the id (key) and hashes (value). When a player takes an item from their bank, it pulls one of the stored hashes then uses the stored hash to find the item's bonuses/item level/item perks. The other 3 categories (item bonus/item level/item perks) are stored in their own json files as well. When a player logs in, these files are loaded back into a map, and I search the maps for the data needed to assign back to the item it's taken out of the bank.

I'm worried about the long run in terms of how big the files become overtime. For example, if a player buys 100 of an item out of the store, I've tried placing this action on a task (using task manager) that loops through and creates each item, but it causes lag until the task is done. Fire Cape mentioned it's poor iteration and was wondering how do I improve it (it's a basic for loop code that creates 100x of the item & assigns a hash/item bonuses to it).

Also, is it recommended to continue storing the item's data into json files? Ran into an issue where the previous item's bonuses were lost. I'm unsure if this is a saving error or I need to double check for code that would the unique bonuses of the item.

This is unfeasible, if you have max stack you have to keep track of 2b unique variables. Also, storing player data as json is indeed not a good approach. I would recommend using a database.

Quote:

---

Originally Posted by Bartvh [Only registered and activated users can see links. Click Here To Register...]

This is unfeasible, if you have max stack you have to keep track of 2b unique variables. Also, storing player data as json is indeed not a good approach. I would recommend using a database.

---

Would I have to limit the max stacks of items to keep unique item bonuses/perks/levels or are there ways to approach this differently? Know it's possible after playing other games with same features, but I don't recall stack sizes of their storage(s).

Quote:

---

Originally Posted by Karil Votek [Only registered and activated users can see links. Click Here To Register...]

Would I have to limit the max stacks of items to keep unique item bonuses/perks/levels or are there ways to approach this differently? Know it's possible after playing other games with same features, but I don't recall stack sizes of their storage(s).

---

No, stack sizes have nothing to do with it.

Quote:

---

Originally Posted by Bartvh [Only registered and activated users can see links. Click Here To Register...]

No, stack sizes have nothing to do with it.

---

Alright, going to fix breakfast and start brainstorming on better ways to go about rewriting this.

Quote:

---

Originally Posted by Karil Votek [Only registered and activated users can see links. Click Here To Register...]

Alright, going to fix breakfast and start brainstorming on better ways to go about rewriting this.

---

I don't think there is a good method to detect dupes. Best method to avoid dupes is probably to write a lot of tests.

The way I've seen it done in another game I worked on some time ago was that a stack, regardless of the quantity, was given a single unique identifier. If the stack was separated, if there was not already a stack of that item in the source container then a new one would be taken from a pool of pre-generated ids. If there was, then it was a simple modification of quantities. Each operation was then logged to a database. It wasn't the best system but it did it's job and saved our asses more than once. The main difference being that stack sizes were capped to 255, and there was no limit other than inventory space to how many stacks you could be holding, though it hardly makes a difference with this design.

Interested to hear what others come up with. You'd absolutely want to use some form of database (not just for this, but in general). It'll make your life infinitely easier.

Quote:

---

Originally Posted by Dread [Only registered and activated users can see links. Click Here To Register...]

The way I've seen it done in another game I worked on some time ago was that a stack, regardless of the quantity, was given a single unique identifier. If the stack was separated, if there was not already a stack of that item in the source container then a new one would be taken from a pool of pre-generated ids. If there was, then it was a simple modification of quantities. Each operation was then logged to a database. It wasn't the best system but it did it's job and saved our asses more than once. The main difference being that stack sizes were capped to 255, and there was no limit other than inventory space to how many stacks you could be holding, though it hardly makes a difference with this design.

Interested to hear what others come up with. You'd absolutely want to use some form of database (not just for this, but in general). It'll make your life infinitely easier.

---

Rewrote everything to migrate to a database and ran some tests on it with accounts and everything seems fine. Worried about some bugs popping up randomly or how server scales if it grows. Going to look into implementing your idea after monitoring for a few days.

I definitely see what you mean about a database making things easier. Still got ways to go on learning everything else, but the basics helped get what I needed for now.