1
\$\begingroup\$

How can I store a large amount of items inside my game?

Are each of the items default data be loaded from a file into an item class and then stored in a giant array/list/dictionary?

For a point of reference, I'm talking about something like Skyrim where there are hundreds of items that the player is able to touch and pickup. And at any point the player can debug and add an item to their inventory.

I feel like the game would store everything is some kind of list but I also feel like this could consume a lot of memory, but maybe I am overthinking the size of each individual items data.

\$\endgroup\$
  • \$\begingroup\$ You can pretty easily create a 'unique identifier' which means you only need something much smaller to stand-in for the object as a reference in some other structure. For example, a 128-byte GUID is generally considered 'unique'. Some games go so far as to use a full relational database for this kind of stuff. \$\endgroup\$ – Chuck Walbourn Jun 28 '15 at 5:38
  • \$\begingroup\$ 128 byte guid is wayy huge. 32 bits is overkill for most games, for unique identifiers. MMOs use relational databases, as do online/web services for games, but most game clients use basically flattened tables of data, where the unique identifier is essentially an index into the data table. \$\endgroup\$ – Alan Wolfe Jun 28 '15 at 5:57
  • \$\begingroup\$ Edited to focus on the specific issue of storing item representations in the world, and not the broader issue of items as data versus classes, et cetera, which is a broad and discussion-oriented topic. \$\endgroup\$ – Josh Jun 29 '15 at 18:40
2
\$\begingroup\$

An item type and an item instance are two different things. The type is usually the "heavy" aspect of an item, the thing that describes what it is, how much damage it does, what it looks like, flavor text, et cetera. A type can also contain some kind of unique identifier, for example, in Guild Wars 2 every item type is uniquely identified by an integer ID.

An item instance is simply a reference to the item type ID, along with a small bit of local extra information such as position (if the item is placed in the world) and whatnot. This drastically reduces the amount of storage required to represent many instances of many items because little to no data is duplicated; only data which is different from the data stored in the type (or that doesn't make sense to store in the type) is unique to an instance.

You might have different kind of instance for an item based on where it is: an item in your inventory doesn't need a world position, for example, but one sitting in the world does.

Keeping track of item instances that exist in the world is largely a subset of keeping track of anything in a sufficiently large world and usually involves some kind of spatial partitioning to load and simulate only the currently-relevant sections of the world while keeping the rest of the data in some kind of persistent storage.

\$\endgroup\$
1
\$\begingroup\$

Generally games tend to use the Flyweight pattern. As needed, the data (models, textures, sounds, etc.) needed for an entity type are loaded into an associative table of (type_id -> data). Then, the data that varies among instances of an entity is stored in a list or tree structure. Example of data that varies is the pose of an object, its animation state, health, etc. Each instance is associated with a type_id, that is used to render the object.

The more data that is shared between objects, the better in terms of memory/cpu performance.

\$\endgroup\$
0
\$\begingroup\$

Most games use some form of quadtree or octtree to organize and sort entities efficiently at runtime. The item's typeID is stored in the tree, and the renderer loads an instance of that type of entity when the player is within the same part of the octtree as the entity.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.