I was wondering if there were some good resources for the concepts of a FPS inventory. My current idea to to just have a JSON file with every item having a “name” “type” “weight” and “count” propertys. I was thinking this would have the added benefit of using a single list that can be used for multiple menus(ie: healthpacks menu, ammo menu, etc)
Are they different approaches or resources for FPS inventorys?
You must log in or # to comment.
If the items are standardized, all you need in the inventory is an item ID of some sort and a count. You then have an item DB that has name, icon, weight, etc for each item.
If you have random items, you need to store more properties, but you should keep the inventory structure as slim as you can.
I mean there are no “FPS Inventories”. You can have a Grid inventory, ala Resident Evil or Diablo. You can do the simple card squares like Destiny. Halo’s “inventory” is some slots with a UI display. It depends on your needs and use cases. Also on the feeling you want to capture in your game.
“Inventory” usually refers to the list of items that the player character is carrying while the game is running. Why would you store that in a file and not memory? Are you talking about a game save file?
Sorry for the unclear-ness in my post! I’m currently using JavaScript in school working on databases and websites so my brain kinda just went to JSON as a way to track the players inventory. I was thinking of having the inventory start as an empty JSON object and have items added to it as the player collects thing, adding the benefit of being able to dump itself to a file for saves. While also being able to display itself in different menus: menu “health items” would just loop over the items with the class “health” and display them. I made this post wondering what types of ways is common for people to store/track inventory info
Ah, OK! Well, even if you’re writing your game in JavaScript, there’s still no need to work with the data directly as a JSON object. JS has built-in functions for serializing stored objects into JSON format (After all, the “JS” in “JSON” stands for “JavaScript”). If you aren’t using JS, working with your data in a JSON representation seems like unnecessary overhead.
I think that one very common approach would be to make a simple array of objects for each “container” (this includes the player character and NPCs). Exactly what those objects are would vary by your language, platform, and personal tastes. You could have objects which contain all the information associated with themselves, such as name, description, weight, etc., or they could be as simple as an ID code that is an index into another table, and a count of how many of that item are held (this can reduce the likelihood of bugs).
The objects could also have their own methods such as reporting the weight or value of the item, which may simplify things if one property of an item (e.g. resale value) can sometimes be affected by another (e.g. level of wear), but not always. Or alternatively you could have functions that query the item objects and do all the necessary calculation and adjustment externally.
That’s if your objects are mostly copies of the same things (e.g. health packs, ammo). If your objects are mostly unique (e.g. key, to room 102, Michael’s pencil), many people instead make a single array which contains every object in the game/level, and each object includes a “location” attribute, with values such as in the player’s inventory, in a particular NPC’s inventory, or at a spot in the game world (perhaps specified in another object attribute). This can reduce the chances of accidentally creating multiple copies of “unique” items.
With regards to saving, if you’re using JS then you can just automagically serialize your top-level array(s) to JSON and save that to a file. If you’re using another language/environment, you’ll need to figure out a file format that suits you, or look for a library. Making your own file format shouldn’t be too hard, because a file is just a big array of byte values, and presumably you don’t need to worry about interoperability.
