Timeline for How can I implement an inventory that stores different types of items?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 31, 2020 at 19:14 | comment | added | Alex Donnelly | @Clay07g I'm now not sure if I should be using separate classes now after reading more about Entity-Component architecture. From what I understand of the Entity-Component architecture way, I should have 1 item class, and depending on the data structure it contains, add components to it. So if my sword item has weapon:true, I should bolt on a weapon component that may contain a sharpen() method. I am just not sure how to bolt these components onto a class when loading in the item data? | |
| Jan 31, 2020 at 5:01 | comment | added | Clay07g | @AlexDonnelly When serializing/deserializing a collection of polymorphic types, yes, you need a way to determine what each item's type is. A switch statement works, but it actually looks like Unity has support for polymorphic types out-of-the box. Take a look at this: forum.unity.com/threads/serializereference-attribute.678868 - It looks like all you need to do is mark your classes as [Serializable], and Unity will figure out how to determine if your inventory item is a sword, or a shield, or a whatever, assuming your class hierarchy is properly made. | |
| Jan 31, 2020 at 0:56 | comment | added | Alex Donnelly | @Philipp Thanks for clarifying this for me. I think I will end up using flat files with json to store data for this game, as I don't have a huge amount of data. One question I do have though. Say I have a function to load an inventory, and I have to instantiate different classes that inherit the obtainable object class. Would it make sense to set a type for a given piece of data, and use a switch statement to instantiate the corresponding class for that type? Then set the rest of the data for that class into the class variables? | |
| Jan 30, 2020 at 16:18 | comment | added | Criticizing Israel not allowed | @piojo Isn't every data structure just reimplementing database-type features? Alternatively: Is it normal to reimplement data-structure-type features when writing web apps? Also: Consider how players expect saved games to work. Or saved anything, for that matter. | |
| Jan 30, 2020 at 15:02 | comment | added | shadowmanwkp | SQLite might be a consideration in a scenario where you want to use a database, but performance is a concern. | |
| Jan 30, 2020 at 14:15 | comment | added | Philipp | @piojo Consistency problems are unlikely, because you usually write the complete game-state to disk or at least a controlled part of it. Thread safety is best assured by avoiding shared data in the first place, and if you do need to share data you do so at controlled points. I never encountered a situation in game development where I needed transactions or rollbacks - I just check all conditions and then execute all steps. "Schemas" are syntactically required in any type-safe language. Serialization can be tedious, but it's about the same work as mapping object fields to database columns. | |
| Jan 30, 2020 at 14:08 | comment | added | piojo | That's a good point about the performance requirements. My game is different than a P2P game where the server will be doing what you describe. The DB features are mostly what I mentioned: consistency on disk during writes, thread safety/locking, transactions/rollbacks, a set serialization format for all supported data, a schema for all data. | |
| Jan 30, 2020 at 13:54 | comment | added | Philipp | @piojo Games have to simulate the game world in real-time. Even when you are using an in-memory database running on the same physical hardware: just the interprocess communication overhead alone is often far too much for the purpose of games. I am not sure what exactly you mean with "database-type features", but if you are talking about indexes: Those are usually present in games in the form of lookup data structures like hash tables or binary search trees. | |
| Jan 30, 2020 at 13:18 | comment | added | piojo | This answer surprises me. Is it normal to reimplement database-type features when a full DB isn't needed? Because at the very least player data must be persisted to disk. Is serialization to a file so much easier that it's worth the trade-offs (performance, consistency on disk, for example)? | |
| Jan 29, 2020 at 15:38 | history | edited | Philipp | CC BY-SA 4.0 |
added 67 characters in body
|
| Jan 29, 2020 at 15:07 | history | edited | Philipp | CC BY-SA 4.0 |
added 1 character in body
|
| Jan 29, 2020 at 12:20 | history | edited | Philipp | CC BY-SA 4.0 |
added 1 character in body
|
| Jan 29, 2020 at 12:09 | history | edited | Philipp | CC BY-SA 4.0 |
added 98 characters in body
|
| Jan 29, 2020 at 12:02 | history | answered | Philipp | CC BY-SA 4.0 |