I’m making a “Your Move Is Only HUSTLE” inspired game. For anyone who doesn’t know what YOMI Hustle is, it’s a turn-based, fighting game and a superpowered fight scene creator.
My main and current focus right now is to work on a “moveset board” which I have a dedicated post on what I should do on making it here. But for anyone who doesn’t want to open a separate tab just to read it, here’s a simplified version of it.
The board is essentially a more simplified version of the one found on YOMI Hustle. It’ll only include your moves only unlike in the original game where you can see the other players moves as well.
Additionally, all fighters will all have:
4 Mobility Moves
5-7 Basic/Aerial attacks (Aerial changes if the player is in midair)
5-7 Specials
4-5 Misc (Stuff like blocking or dodging)
unlike from the original game which probably has more basic, aerial, specials, and misc options for certain characters/
Now the issue is that, aside from wondering how I can even add a fighters moveset to the system, is that I’m wondering if ESC or OOP should be used in my project. I have a bit of experience using OOP but ESC seems more easier to handle and since Matter exists, I can use the module to do all the weightlifting.
Im not too familiar with ESC so if you could run that through me thatd be great.
But from what I am reading, Composition OOP might be your best choice as you could create simple classes for all your desired moves and simply modify them as well attach modifiers, for example a punch class but also composite a fire modifier to it which makes it a fire punch. If that makes sense.
For a quick rundown of what it is (Taken from the post from above and added a TL:DR version): Entity Component System is an infrastructure that represents distinct objects with loosely coupled state and behavior. TL;DR, ECS is where it seperates entities (Such as an enemy), data (components), and behavior to be more efficient.
Sorry if the text from above is weirdly worded. But that’s a basic rundown of what it is exactly. I have a question however. How would I be able to create all moves of a fighter using composition? Would I have to use a table/dictionary to list out all the attacks and mobility options?
Ah so basically Composition OOP is a deriative/similar to ECS, I believe ECS is your best bet if you truly want to make modular moves/attacks/specials without having to code a new move everytime.
Making a game is, firstly, making a game for players to play with good performance and not flexing “my crappy OOP with 9 inheritance chains is so readable.”
ECS is not even arguably the winner.
Luau does not have structs, so any kind of OOP is like shooting yourself in the foot.
I think it all comes down to personal preference, there isn’t much of a difference whether you’re using OOP or ECS as long as you’re comfortable with your own workspace. Performance wise, ECS might (take it with a grain of salt coming from me) have a slightly better advantage compared to OOP but it really just comes down to how you handle your own code and game infrastructure. I suggest just picking what you feel is most suitable for you.
Alright then, I should probably instead use ECS instead of OOP. Though, I’m wondering how I would use ECS to store the moveset of the all the fighters. What would it look like? Would it have multiple modules with each one having a fighters moveset or would it be in a massive module with all of them in? (Assuming for the latter, I’d use something like tables/dictionaries)
I simply have not messed around with “OOP” in Luau enough to give a proper answer in terms of performance, so I decided to give a light-hearted answer based off of other forum posts I’ve read.
Although, could you please elaborate more on how Luau does not have OOP just because it doesn’t have structs? Doesn’t the meaning of OOP just mean programming using classes and objects (which can be done using metatables) in Luau. I am open for criticism.
You don’t have to mess around with anything to know the truth.
The answer is always in front of you: bytecode.
Every lookup does invoke GETTABLEKS (an actual hash search rather than a static reference).
OOP in Luau is simply not possible (closure OOP is an exception because of how CAPTURE works).
Metatable simply doubles the invocation of GETTABLEKS, leading to even further loss of performance.
OOP in compiled languages is usually fine since all reference points are static, so performance-wise there is no problem really.
The way people mimic OOP in Luau does not have such optimizations and instead relies on dynamic searches, which is bad for performance.
Closures are the closest you can get to mimicking OOP in Luau but have their own drawbacks.
It’s a bytecode, basically.
I had made a topic documenting Luau bytecode. You can read it, but be prepared that it’s not going to be easy to understand in one day.
Yes I know about the idea of LUA oop which is a crude mimic, but it never occurred to me that it actually js sucked, especially with all the pro-OOP sentiment many follow, but like you said I know that compiled languages do best with OOP
Just remember while it is technically worse for performance, the difference is negligible in most cases where people would use oop. It really is only a problem in tight loops where every instruction counts. Something like the example problem of the post will have basically no practical effect between the two so the option that produces the cleanest or most comfortable code should usually be picked.