Help Structuring Frameworks

Help and Feedback Scripting Support
#1

Structuring frameworks has been a big issue to me, more specifically, structuring good ones. I don’t think I have much to write as a description so I’ll just go for the questions:

Context: my current objective is creating a very modular melee weapon system (OOP in mind for now) that should be both client side (animations, hit detection?) and server side (hit validation, damage?).

How should I link both client and server objects of the same sword?

Should I create the object in the server and store it in a table, then use a get function in the client or should I create 2 different objects?

Random topic question

I saw an example where there was a Car module inside ServerStorage that had 2 other modules inside of it, CarClient and CarServer. On game start, the client and shared modules would be parented to ReplicatedStorage. What would the Car module be used for? Would it be a shared module? Would it be used to reach CarClient and CarServer? Any code example on how this would work? I’m talking about this topic’s answer by the way: Multiple Inheritance / Diamond Problem - #3 by eaksy1791

Should I even use OOP in this case?

If you think my questions were vague (that’s what I’m thinking to be honest, but I don’t know any other way of asking about this whole stuff): what I’m confused in this exact moment is how I should structure my sword system. Any tips?

#2

I apologize if this is a late reply, but I found your post interesting:

When the word “framework” comes to mind, I usually think of flexibility within your code. Adding flexibility usually doesn’t take too long, and outputs many benefits. But the word “framework” can have many interpretations here.

How should I link both client and server objects of the same sword?

Do you mind elaborating on what is object here? Is object an abstraction of some code?

In my opinion I think your questions are quite vague as there is no one single solution here. But, to answer on whether to use object oriented programming, my answer is that you most likely won’t have a choice. Writing OO code by paradigm definition is imperative, which means it’s more aligned with problem solving and how you think, and that’s very useful for game programming. (Of course, client code using an object is moreso declarative instead).

From what I’ve seen, the general Roblox API is written with both inheritance / composition (think BaseParts, and several other instances that can interact with BaseParts and that inherit from BaseParts), so even utilizing the API will expose your code with the OO paradigm. You can still use many other paradigms, but they’ll be nowhere near pure.

If you want to see OOP’s pros and cons, look that up on the internet, there’s a rich amount of information and discussion for you to read. Especially for game programming.

#3

When I say framework, I’m talking about the modules related, in my case, to the melee weapon system. Sorry if I used the word in the wrong way, I’m still pretty new to programming tbh.

And for object, I mean the table returned by the class constructors.

I didn’t try making a structure for this melee system before making this post (my fault, sorry), but now that I’ve tried that, I think it might be a good idea to give details about it and perhaps some new questions:

Context:

Current Structure: 1x module for the client (uses oop), 1x module for the server (also oop) and 1x general utilities module (can be ignored as context; no oop; basically a shared module?)

CurrentCombo Variable: both client & server objects created by their modules have this; it determines what is the current combo the weapon is on (if the weapon performs 3 combos, this is set to 3, if weapon is not swinging at all, 0.

Swing Method: again both client & server objects have this; the client version will do the most stuff (play animations, detect hit and update current combo), and the only thing the server version does is updating current combo, just like the client v., but to be used on the server.

Both client and server modules are independent, there’s no connection between them, at least not inside the modules (like directly sending remote from client m. to server m.). About the server swing method: the only thing it does currently is updating the current combo of the weapon, and I need current combo to be the same for both the client and server objects, and to accomplish that, I first call swing on the client, updating the current combo, and then right after, I send a remote to the server telling it to do the same.

Although this works, it doesn’t look right because the only thing the server swing does is updating the current combo (I know I might have to add more stuff there, but I don’t think I will). To solve this problem, I have in mind doing a direct connection (client → server) to also call swing there, so I don’t have to call it manually on a clientscript and then tell a serverscript to do it, which seems unnecessary imo. What do you think about this? Should I do some sort of direct connection between both modules? I don’t see that commonly so I think it might be some kind of bad practice.

1 Like
#4

From what I’ve read from you creating this structure, it looks like it’s turning into something more “controller” & “service” based, where that is singleton oriented. Of all the instances of behavior you have in this “melee” system, they all serve one puropse: Managing a melee system. No more and no less.

This is perfectly fine! Controllers and services (to adopt to a singleton structure) are as simple as that. For networking, your client singletons can “talk” with your server singletons to do a specific functionality for communication and exchange information.

From reading what your defintion of “direct connection” was, that’s a better idea to avoid unnecessary abstractions. Abstractions are great when they provide value, not, when they simply don’t.

#5

I guess I’ll do that then. One last thing: what should I search to learn more about controllers, services, singletons, etc? Like, do these “inherit” from something bigger, like how OOP is a paradigm?

#6

Singletons are not necessarily part of a “paradigm”, they’re more of a concept, and all you need to know is that they are just a good abstraction for business logic. If you’re willing to read up on these classified singletons, SO has great posts built up over the years for you to read. Search for something along the lines of “singleton pattern” and you’ll get lots to read.

#7

Alright, thanks. (characterlimit)

1 Like