Why should I use OOP for an inventory system?

To be honest, I think metatables are cool and all, but having folders with objects inside of them seems superior. I’ve never made an inventory system, but it feels like metatables in this scenario just makes it overbloated and unnecessary. Why code objects with metatables when roblox has already embedded objects within the engine for us?

I don’t use OOP often in lua btw

Please feel free to share your thoughts.

1 Like

I dont think you understand what OOP means. Object Oriented Programming, meaning that you interact with exact entities, objects. Basically everything you do in roblox studio is OOP. If you change a part’s position, its OOP, having objects in a folder is a very vivid description of OOP :))).

If your question is why should people use metatables, encryption and etc., it depends on particular cases. For example i have to use encripted dicitonaries in my game to efficiently save player’s inventory and other data in DataStores

1 Like

when i said “roblox has already embedded objects within the engine for us”, i meant roblox used OOP for that.

and anyway, why not just use a loop to store all the names of items within folders in some table/dictionary and insert that into a datastore? what’s the difference?

Because my game is huge (both map and mechanics vise) and everything needs to be optimized, so that it is available even on low end PCs and Mobile, despite it’s great graphics and size. So looping through tons of objects for each player is not the best idea in my case.
In smaller games you can get away with it

As mentioned above, the roblox engine was created using OOP (or at least we think so looking at the API). However we must remember that OOP is just a programming style. And styles are independent of data structures. That means that an object in OOP could be seen as a structure in structured programming, or as a side effect in functional programming (if its state changes of course).

On the other hand, using a programming style is optional and will depend on the goals of your project. You could even mix styles if convenient.

That said working with folders and instances directly is usually quite convenient because you are working closer to the engine. it’s almost like a WYSIWYG. I would say this is a more compositional style with great benefits (if used properly) such as creating completely self-contained systems thanks to the observer pattern and corroutines. In fact the engine was designed to be used this way. But as I said, if used properly. But how do I know that I am using it properly? That is the big drawback that only experience could clarify.

The reason why many developers opt for OOP is because the objects provided by roblox are quite general. There is no dragon, castle, bicycle (things specific to a particular game). Using OOP you can create those objects and handle them just like any other object in the engine. That’s a big advantage, but it also has a big disadvantage - how do I know when I should create an object with OOP or use an engine object directly? Many are often unaware of this and tend to use OOP everywhere, even if using engine objects is easier. This happens not only in roblox but in software development in general. Many people point out this flaw as one of the reasons for not using OOP.

Another thing to point out is that OOP focuses on abstraction which means that it tries to represent reality (in this case the objects or groups of objects in the engine) with the least amount of detail (i.e. without including the features that you are not going to use) so that they are easier to understand and manage. OOP is about abstraction not efficiency.

Also, another reason to use OOP is because it is often the standard for projects where its benefits shine through. The way data is organized, the modularization, the interfaces.


Lua gives you the ability to pretty accurately replicate class structures with greater control, while being one of the fastest interpreted languages. The creators even added “syntactic facilities” such as method calls to make OO implementations easier. Again to restate what has be previously added, it really depends on your programming style, but for practicality. I’d say it’s pretty practical.