[Design] How should I implement GUI's in OOP?
So I'm trying to make a card game. Each card of course is represented in the game with a GUI.
But the problem is, how should I implement this? Do I merge the Object's data and the GUI's together into single objects, or try making an imaginary environment controlled by a manager object that manipulates the data of cards and produces a corresponding display?
I have already taken the path of the first one, and given the need for Click events, I wonder if it would be even practical to do the second approach. Is it worth it to change?
1 answer
A modern approach is called model-view-controller, or MVC. Whether or not it's the best option in ROBLOX, I'm not sure.
There are three parts to this approach.
The Model
This is the underlying data. It might be where cards are, stats, etc.
You would carefully decide what sorts of changes need to be exposed and write methods for these. E.g., swapcards(position1, position2), deal(numberofcards), etc.
These Methods modify the model, and they will be the way the Controller interacts with the model. They are also the way the View gets to inspect the Model.
The Controller
The controller captures user interactions (clicks, drags, hovers) and queries the Model to respond accordingly. For example, if you click the deck, maybe that calls deck:deal(1).
The View
The view asks the model for the information it needs to show the game. For example, it might update the images of cards depending on which card is in place:
while wait() do
for i = 1, 10 do
handGUI[i].Image = Images[ handModel:GetCard(i) ]
end
end
This can be a little complicated, because you might also have to manage real-time aspects like animation, dragging, etc, which aren't directly stored in the Model.
MVC
The goal of MVC is to restrict what ways you need to interact with the model -- the actual state of the program.
The controller and view get minimal, clear access to this; the View is read-only and the Controller is write-only (though there is probably considerable overlap).
The benefit of this design is that you should be able to easily swap out the View and Controller -- e.g., since the Controller only has to fire a few methods for a few sorts of interactions, it should be easy to replace the GUI buttons with physical buttons, click detectors, or chat commands.
Similarly, because the View only uses a few, simple, minimal events and queries, it should be easy to change the view to be text-only or in parts, etc.
This translates into being able to wildly change your direction in the GUI without much difficulty -- which also hopefully means your time to implement it the first time is reduced.
0
0