2
\$\begingroup\$

Can the Model View Controller design pattern be used with non-OOP coding style, specifically with Entity Component System?

\$\endgroup\$

1 Answer 1

5
\$\begingroup\$

Four points to make, including an answer to your question:

1) There is nothing non-OOP about entity systems. Data-oriented programming is incompatible with bad over-use of poorly designed interfaces common to most mediocre OOP programming styles, but otherwise good data-oriented component systems (including entity systems) are quite naturally fit into an OOP model. You just end up defining a very different set of object models than you otherwise might. Bad OOP systems tend to define objects at boundaries that make sense to our physical real-world human experiences and linguistic taxonomic sensibilities, but which make no sense from a computer engineering standpoint. DOD will force you to use OOP better, which may be very different than what you're used to.

2) MVC is a horrible fit for almost all games, no matter how your engine is implemented internally. It just doesn't make a ton of sense, because individual game objects do not have multiple possible views or controllers, and the model has a strong influence on rendering and control (an MVC system inverts things such that the model has no say on visualization, the controllers drive everything, and views are pluggable by the controller to visualize a single model in multiple ways). MVC is great for data-focused traditional apps, not real-time interactive simulations like games.

3) You are falling into the trap of taking off-the-shelf design patterns and trying to fit them together. When you start out saying that the problem you want to solve is using design A and design B together, you're working backwards. Start out with the actual game you want to make. Then start coding that exact game. If and only if you run into a problem should you start asking yourself if a design patten might solve that specific problem.

4) In answer to your actual question: yes, it's possible to use MVC and entity systems. It'll be an awkward fit, but you can make it work. You can make anything work, because this is the world of software, and we aren't limited by any physical laws of the universe. You're free to make any architecture you want. More specifically, it'll largely boil down to using the entity system as your Model, your game logic/scripts as your Controller, and the rendering engine (with some non-MVC integration with the ES and scripts, as per my point 2 above) as your View.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .