Is it okay to make a game nearly fully object orientated in roblox/luau? I’m making all of my systems like this, and they initiate when .new() is called, but is this bad? It feels nice and organized, and easy to add more to, but I’m not sure if its bad or not meant for luau.
1 Like
If you feel comfortable using OOP, and find it easier or more convenient to make what you desire when using it, then go ahead. In the end, what’s important is that your game is running the way you’d want it to, and using a coding style that you’re unfamiliar with can lead to more bugs and errors that you’ll have to spend time fixing instead of progressing with your game
3 Likes
I don’t think so. The no.1 thing I always say is as a scripter as long as it works, it works. Obviously that can’t be said if like you’re purposely creating memory leaks or purposely spamming while loops all over your game just to put strain on it but for a situation like this you know what I mean.
2 Likes
Thanks for liking my comment, I finally became a devforum member after like 2 months lol. Also did we reply at the same time? I think we did.
1 Like
OOP is actually bad in a sense as of the class heavy stress it can put on bigger games. By which I mean inheritance. Truth be told C++ if you know can make some of the most amazing polymorphisum code that can be used and inherited down as much as you want. The ideas are limitless, the memory is not. OOP is okay, but I never like to go too deep with my inheritance personally.
1 Like
We did reply at the same time, lol 
@Amritss You can get it by joining the @Programmers group
btw it’s best practice to send questions unrelated to OP’s issue as a message to the user, in-order to keep the topic’s replies uncluttered 
2 Likes
Also by the way how did you put that scripter icon on your profile picture? I was wondering how to do that. Couldn’t find a way though.
1 Like
Wdym by inheritance? Just an example in roblox. Is there anything similar you would recommend using instead?
Also, a lot of my Systems are OOP, but they’re only initiated once, similar to how the roblox PlayerModule works (return PlayerModule.new())
It’s mostly up to preference. OOP usually does have the objective advantage of clean organisation in your projects, especially useful if they’re large.
You can, and people have already done it - there’s just a few things to consider.
- Inheritance is bad, sometimes
It’s like snow; a little bit is good, a lot is a problem. Don’t abuse inheritance.
- It’s actually really taxing on memory
Now it varies on your OOP implementation, but the tradeoff is that OOP gives you a lot of readability and futureproofing, at the cost of memory.
A big example of this that I see often nowadays is developers leaving their methods inside the constructor, rather than it being under the class itself.
Fine for simple classes, unnecessarily memory-consuming once it scales.
- OOP can get messy as hell
The point of OOP is to make it easy to manage your objects, but it’s an entirely different ball game when it comes to your classes.
To get OOP to work, you’ll be writing a lot of boilerplate, which makes tweaking your classes pretty difficult, especially when your classes get complex. Exercise caution.
1 Like
I’d advise you to seek out more of the compositional style over inheritance. Additionally, it really depends on the use case of the OOP. In reality, you are not truly using OOP. It is indeed some multi-paradigmatic mash-up that works. It is simply a style.
You can also learn about ECS, which is a common architectural pattern in video game engines.
3 Likes
If it works similar to the roblox PlayerModule will it use less memory than constructing and deconstructing over and over? (return Module.new())
Would it be possible to reuse the object instead of repeatedly destroying and creating one? Doing so would help performance quite a lot since memory is allocated only once
Not sure I understand your question, can you explain?
Assuming the high memory use from OOP is from constructing and deconstructing a class/object a lot, will only constructing it once still cost a lot of memory?
I only construct everything once. Each system is attached to a singleton that initiates them all
In that case there shouldn’t be any performance issues unless there’s a memory leak within one of the objects. Memory would be allocated only once at the initiation under normal conditions
1 Like
Probably not.
To elaborate, practically every object (be it custom or Roblox-provided) is really just a table itself, same goes for its class.
The issue is that tables can be very consuming on memory.
The table itself will cost a bit, but the key and value also has its own memory overhead.
The more keys (and obviously values) a table has, the more memory it consumes.
And of course, the more of those tables you have, the more memory you consume too.
It can be a very slippery slope if you’re not versed at memory management, but I think you’ll be fine in your case.
1 Like
Ive tried that before and my conclusion is:
Sinse not all aspects of the game needs to be a class, forcing it to be a class just makes your life harder and the code less optimized.
I mastered OOP with inheritance and all, i do use it for parts of the code that needs to handle a certain lvl of complexity. Usually, when you are making a table inside your script with info about something and ure aways editing it in different ways, that can become a class and u’ll see your code way simpler with it being a class. If the table is simple enought i dont make it a class.
There are scripts that would be like “controllers” and “services” from knit for exemple that if ure going to instanciate the object only ONCE, then there’s totally no need to be a class.
For “controllers” or “services” should I just cut out the whole class idea and make it initialized on call?
I.e.
Go from this:
local System = {}
System.__index = System
function System.new()
local self = setmetatable({}, System)
-- Initialize system
return self
end
function System:SomeMethod()
end
return System -- (or return System.new())
To something like this:
local System = {}
function System:Init()
-- Initialize system
end
function System:SomeMethod()
end
return System -- (or return System:Init())
2 Likes