If I'm creating a MVC design for my game, should my Model be completely on the server?

Hello! I am trying to organize my game through the Model-View-Controller design. Obviously Views would go on the client, and the Controller could go both ways, depending on the input (e.g. touching something = server-sided control; user input = client-sided control).

Do you think it would be better for to keep the Model component exclusively on the server, or is it alright to allow some portions of Model on the client as well?

Thanks!

3 Likes

When you add networking, you should consider having 2 MVCs: one for the server and one for the client. While it may not be super clear, the view on the server isn’t a GUI; it is the RemoteEvents and RemoteFunctions used to communicate to the server. Additionally, the models may need to be very different since the client shouldn’t know everything the server knows, such as well all of the players are hiding or where all of the loot for a game is.

I have had to work with a project that does this. It was a web application with a client MVC in JavaScript and a server MVC (class project) with the view being the HTTP GET and POST requests, with the controller handling the logic for them and the model storing the data for them. The client’s controller sent the network requests and handle the responses, with the model storing client data and the HTML’s JavaScript driving being the view.

8 Likes

Make sense. I’m trying to stick with OOP as much as possible; in your experience is it feasible to create classes for both the server and client Controllers? Since controllers deal with input (and thus events), I can see how trying to blend events into a class may be tough.

It will be better to separate the client and server classes and either use inheritance or composition for common components (inheritance is easier in OOP languages, composition is more flexible and more testable normally). Roblox is different from other systems since the codebases are combined compared to a website which would have a distinct codebase for the server and client. Even if they are both JavaScript, one would be a website while the other would be a NodeJS system.

I think I miscommunicated. What I mean to say is, do you think it is feasible to create a Controller class in general?

You should consider using a controller class. While it may be simple on the client for just handling network requests, having your code decoupled helps. If you decide to set up automation testing that doesn’t use your user interface, but does use network requests, you would have the flexibility to do this. Additionally, you can redo the view component with minimal changes to the controller. Ultimate Boxing deserves a UI revamp, but the controller aspect is deeply coupled and thus proved to be too difficult. For the server, you should use a controller since server logic typically is a lot more complex, and it should be separated from your network requests for testing purposes.

1 Like

Thanks for the response. Just to be clear, with a Controller class, I would call methods of that class within the event function, right?

Assuming you mean a view event (like a button client on the client or a remote event invoked on the server) calling the controller, yes. The view should only handle inputs and the controller should handle logic.

1 Like