Help in Inventory system

Help and Feedback Scripting Support
#1

The devforum has really helped me through many things I started from literally nothing to detecting terrains using ray casting using remote events,functions,path finding service to create NPC and pretty more cool stuff,but now I want to create an inventory system for my game but I don’t know from where to start the ways I have thought of are:

  1. Directly changing values in PlayerGUI (I don’t think it would be the good way because of chances of duplicating and much more)

  2. As others suggested using tables (The efficient way to go right?)

Any simple Inventory system which I could go through and get some simple explanation of how it works?

Any help would be greatly appreciated!

3 Likes
#3

ModuleScripts are the way to go
Typically you’d have a module on the server that contains each player’s inventory.

local Inventory = {}
local inventories = {}

function Inventory.GetInventory(player)
    return inventories[player]
end

function Inventory.AddPlayer(player, inv)
    inventories[player] = inv
end

function Inventory.RemovePlayer(player)
    inventories[player] = nil
end

return Inventory

Now any code on the server is able to access a player’s inventory

I recommend using a RemoteEvent to update the client on changes to its inventory, and other remotes for the client to use to manipulate its inventory.

local Inventory = require(path.to.module.above)

--code somewhere on the server
EquipEvent.OnServerEvent:Connect(function(player, requestInfo)
    local inv = Inventory.GetInventory(player)
    --run any necessary checks to see if they can equip something
    --change inventory

    InventoryUpdateEvent:FireClient(player, inv)
end)

Any time the client wants do something to its inventory, it fires a relevant RemoteEvent to the server, which will either ignore the request (if it is invalid), or process it

Edit: Here’s an example inventory (you can structure it however you’d like)

{
     Items = {
          {
               Name = "Sword",
               Type = "Weapon",
               State = "NotInUse",
          },
          {
               Name = "Drink",
               Type = "FoodItem",
               State = "UnEaten"
          }
     }
}
15 Likes
How do I script a customizable inventory?
#4

So, basically, you would need to make an inventory system that acts like your backpack. So first, we would need to remove the Backpack CoreGui, because of what’s the point in having an inventory system and a backpack at the same time?!

Next, we would need to use some type of loop or table to get all the items the player has. (I would use a remote function to send to the server, and return the name, and features of the tools that are located in the player’s backpack.)

In my opinion, I would have some type of event to a server script/module and have a folder in ServerStorage with all the tools for the game to make sure that any tools from exploiters are not being added.

I would have a Backpack.ChildAdded/Removed event to add in any tools or remove as quickly as possible. I would reload the UI every CharacterAdded as UIObjects can be removed on respawn, especially if they’re made by instance.new().

I would also have some type of datastore system, where you would save the tools Name onPlayerRemoving, so when you need to load the items when the player rejoins, you can just use the folder you have in the serverstorage to locate names and assign tools accordingly. I’d also have a game:BindToClose(function() as well as a 10+ second wait time, just in case.

I would also have messages for each time you equipped something, dropped, removed, etc. for quality UX.

Anyways, these are ideas just for you to get in your mind. Of course, you are free to do as you like, but mainly, I would have some type of system for datastore, a method to organizing tools and properties in some type of table/organizer, and providing good UIs and User Experience.

Good luck

2 Likes
#5

I feel like a better way to make an Inventory while say using roblox tools are to disable the backpack gui(using Startergui) and making a gui that display the tools in your Backpack

-> Disable Backpack gui(Local)
local StarterGui = game:GetService("StarterGui") StarterGui:SetCoreGuiEnabled(Enum.CoreGuiType.Backpack, false)
then all you have to do is make a gui that reads what you have in your backpack, display it in a gridlayout and have actions that show it either being equipped or unequipped. This way you don’t even need to use remotes or remake a whole new inventory system! All you have to do is disable the backpack gui(when disabled, you can use the “~” or hotkeys to access the tool as a shortcut) then make a gui system to look at all the tools in your backpack, make a gridlayout to hold buttons that let you access the tools, and make an action that allow you to equip or unequip your tool(you’re able to do this in the client side)!

2 Likes
#6

An inventory system has a lot of things to account for. In terms of getting started though, you have a bit of the wrong idea. Don’t directly edit values in the PlayerGui. The server should be holding the player’s inventory and the client should merely be displaying it. You, of course, will need remotes for this interaction.

@AbiZinho

Inventory != Backpack

I can think of many reasons to speak out against this logic:

  • Storage of tools
  • Carrying items
  • Archiving tools / item bank
  • Strategic UX design (lose backpack on death, keep inventory on respawn)
  • Differentiating between active and inactive tools
  • Can keep more than just tools
  • Ease of access to immediate tools and for organisation

ResetOnRespawn exists for LayerCollectors. This is an unnecessary practice and is long antiquated. If exploiters are modifying their inventory UI, don’t bother to account for it. The server will still hold their real data. Set up your checks right and they’d simply be wasting time trying to attain new tools.

1 Like
#7

Oh I see, I’m just using backpack as a basic reference.

This is true, I need to get more information on this.

1 Like
#8

Yes, that’s what I meant. The CoreGui Backpack still has its respective uses if one does not desire to create a custom backpack system along with an inventory. I’m referring to your explicit comment:

There is no “need” to do so. You can keep both the backpack UI and make an inventory system.

There is no “more information”. ResetOnSpawn is a literal property of LayerCollectors that superseded ResetPlayerGuiOnSpawn. The property is intended for singular LayerCollectors as opposed to making the entire Gui either reset or not. The Developer Hub has information.

1 Like
#9

I’m assuming that the player would only use one item at a time, hence the idea of removing the Backpack CoreGui.

1 Like
#10

Depending on the kind of game you are creating, this can either be poor UX or good for the setting of the game. Players often like to keep a set of tools below so they can switch fast between items.

For example: in an RPG game, having one tool at a time makes sense because you wouldn’t really be rapidly switching between weaker and stronger tools - you’d just keep the strongest one you have out. As for games like shooters, you want your primaries and secondaries available side by side so you can get the last of someone’s health if one gun doesn’t cut it. These may not have explicit backpack UIs but they still have a quick way to switch - so basically a backpack without a UI (0-9 hotkeys & mouse scrolling).

1 Like
#12

Editing clientside GUI values is very dangerous, because exploits can just set a value… If you are using BaseValues (not recommended), then put them inside ServerStorage, but the main way to go would be a ModuleScript as others have said.

#13

It’s not dangerous if the server isn’t relying on those values as legitimate. The client should merely be using inventory data as a means to assist in facilitating requests to the server and for display purposes. There is no “danger” here.

ValueObjects are fine for primitive inventories, but I’d prefer a ModuleScript specifically for more complex inventory structures with more data-intensive hierarchies. Even a mix of both could produce intriguing results.

2 Likes
#14

I was assuming that the server would use those values, which would be dangerous… if they are for display and editing only, with sanity checks on the server, then its fine.

#15

Usually not a good assumption to make and not a good place to start. That’s primarily because it assumes something wrong and potentially misconstrues what OP already has to work with, knowledge or application wise. It also doesn’t address the specific scenario in which client-sided editing makes things dangerous, hence my response.