I am trying to learn OOP right now but I am unsure if it would actually apply to future projects I would be doing (specifically things relating to RPGs, such as bosses/boss drops, weapons, inventories, trading, etc.)
Can I please have some sort of list of uses for OOP and where/what it should be used for?
OOP is just a design structure for code
you can use OOP for everything in basically any game.
I think you shouldn’t use it for absolutely everything, but anything to do with items, players, mobs, bosses, quests, wandering npcs.
all of that could be created with OOP
also I suggest looking up videos about OOP even in other coding languages it helped me figure out what it was meant to be ( I had a C# class about OOP for my community college, but you should be able to find things that have more OOP approach than Roblox does ( it helped me a lot )
It really depends on what you are looking for when creating code, I recommend using it anytime you have objects or systems that could be considered objects ( like the name suggests )
So this is how I am currently handling item dropping in my game:
local item = {
Name = "ItemNameExample",
Damage = "ItemDamageExample",
}
Would I be able to apply OOP in this situation?
Well yeah of course you have an object “Item”
you can just Item.New(Name,Damage,Rarity,Durability,Color,Player)
and get a new item and give it to them, but you dont have to do it that way.
You can apply an OOP architecture to anything.
What’s the difference between having module scripts containing functions and OOP?
the structure? the way the code works is the exact same. the only difference is how you understand it or how organized it is.
OOP is just cool because you can organize them into objects and assign functions to objects themselves
As someone who does not care for OOP but still had to use it, here is what I have to say. I don’t know if this counts as OOP, but I don’t really use metatables.
This is what I typically use in my module scripts from my day-to-day workflow:
local module = {}
--offsets
local offsets = {
["Sword"] = {
["Offset"] = CFrame.Angles(0, 0 ,0);
};
}
function module:SetOffset(part: BasePart)
part.CFrame = part.CFrame * offsets.Sword.Offset
end
return module
I don’t really use OOP in depth, but I do use module scripts and they have been extremely helpful for when I want to reuse code, and for libraries/ databases.
Some usecases:
I could go on about the list, but those are the main ones.
Module scripts are universal, so if you need it to be separate, make sure to clone the module before requiring it, it’s a lesson I have learned.
No, it’s not OOP.
OOP is hard to implement in Lua and rather makes things more complicated than easier, especially when you have a bunch of different tools to use in Roblox Studio.
Depends on how far you go with OOP. For example, making custom vector3s with OOP isn’t too complicated if you know how to use metatables and it’s also not that unreadable.
Why is it not OOP if he is adding a function to a table, isn’t that the point?
They do it here in Lua’s example, how is it any different?
You should just use . instead of :.
function module.SetOffset(part: BasePart)
You aren’t really utilizing any metatables, so there’s no reason to use the colon syntax.
Note that in their (the lua docs) example they use the self keyword in their method. This is a key concept in OOP as individual object should have independence.
The module example makes no use of self and doesn’t actually provide a way to create independent objects. It is more aligned with the singleton design pattern.
OOP is used for, quite literally, everything in ROBLOX.
When you access a part (which is of object class BasePart and has a set of properties attached to it), you’re working with OOP software.
It’s a massive over-simplification, but OOP is a programming paradigm (much like functional and procedural), where data is encapsulated into objects, properties are abstracted away so minimal data is provided to the program.
This website explains OOP pretty well, but if you’re looking for the techy explanation, you can find one here. I also covered OOP briefly in a YouTube video, if you prefer to watch, rather than read.
Hope this helps.
A function in a table is a function in a table, it’s not related to OOP.
You could define useful classes for everything you’ve mentioned.
Bosses
A Boss class could have a method for each ability that the boss has. This would make use of the Boss object’s internal stats to determine things like damage.
E.g.
local boss = Boss.new(...) -- Initialise with the stats for the specific boss you need
boss:Attack(player)
boss.Died:Connect(function(...) end)
Boss drops / Items
You seem to already be close to OOP with your current set up.
To turn it into a class all you’d really need to do is this:
-- Before
local item = {
Name = "ItemNameExample",
Damage = "ItemDamageExample",
}
-- After
local Item = {}
Item.__index = Item
function Item.new(name, damage)
local newItem = {
Name = name,
Damage = damage
}
return setmetatable(newItem, Item)
end
E.g.
local item = Item.new("ItemNameExample", "ItemDamageExample")
Though this really only makes sense to do if you can define some useful helper methods. You could also use this Item class as a parent class for Weapon / Armour / Potion /… classes.
Inventories
We can use some composition here to create an Inventory class:
local Inventory = {}
Inventory .__index = Inventory
function Inventory.new(player: Player, slots: number, items: {Item})
local newInventory = {
Player = player,
Slots = slots,
Content = {}
}
setmetatable(newInventory , Inventory)
for _, item in items do
newInventory:AddItem(item)
end
return newInventory
end
-- For a list-like inventory
function Inventory:AddItem(item: Item): boolean
if #self.Content >= self.Slots then
return false
end
table.insert(self.Content, item)
return true
end
So we have used other classes such as Player and Item to define this inventory class. I showed an AddItem method that seems fundamental to an inventory and you can define a GetItem method similarly.
Trades
You can define a trade class to handle individual transactions between players which could then be stored to keep track of the flow of items and trade history.
As I have already defined an Inventory class I may as well show some more composition here too:
local Trade = {}
Trade.__index = Trade
function Trade.new(inventory1, inventory2)
local newTrade = {
Inventory1 = inventory1,
Inventory2 = inventory2,
State = "pending",
ItemMap = {
"1" = {},
"2" = {}
}
}
setmetatable(newTrade, Trade)
return newTrade
end
function Trade:AddItem(inventoryNum: number, item: Item)
if self.State ~= "pending" then return false end
local items = self.ContentMap[tostring(inventoryNum)]
if not items then return false end
local inventory = if inventoryNum == 1 then self.Inventory1 else self.Inventory2
if not inventory:GetItem(item) then return false
table.insert(items, item)
end
function Trade:Process()
-- Exchange the items between the inventories
-- Set self.State to "completed" or "cancelled" depending on whether the exchange could be made
end
Interesting, so from what I’m gathering in this thread,
OOP essentially is a different way of structuring parts of your codebase (utilizing classes and objects) that allows you to easily read, understand, and modify specific parts of your game.
Would this be a correct simplification of OOP?
Yes. It helps because you may not have to understand the class exactly to use it.
A great example is Roblox objects itself. You don’t really have to understand exactly what a part object is doing to operate with it, instead you assign properties to it, and can infer how it will work. This is not especially easy.
Imagine now, that you can make your own objects like a Roblox part, or a UIListLayout, or a “Sparkle” attachment. For example, you could have a “Car” class which is a car, or a “Pet” class which is a pet.
If you’ve ever wished you could have something similar to this, you’ve got a usecase for OOP.
It’s a great tool, and as others have said in the thread above, not a requirement. But it is quite useful.