Game framework architecture - view components or M

问题:

I'm trying to build a very light re-usable framework for my games, rather than starting from scratch each time I start a game. I have a component driven architecture - e.g. Entity composes a Position component and a Health component and Ai component etc.

My big question is whether my model composes view components to allow for more than one view of the model, or whether to use a truer MVC where the model does not know about its views, and they are managed externally.

I have tried both methods but if anyone knows the pros and cons of each approach and which is the industry standard, it would be great to know.

回答1:

depends on your audience, game devs, myself included aren't very used to the MVC model, although most know it, it's not as easy to keep it clean cut, because of development casualties (not any serious technical reasons). So from experience, I've seen dozens of game frameworks start as MVC, but only a pair were able to maintain it until the end. My theory is MVC adds too much complexity and little benefits for small throwaway games (with normally a few devs), and it's to hard to keep really cleanly separate most game objects into these layers for large/complex games. And since games have a release date, they many times sacrifice code clarity and reusability for performance and quick adhoc solutions (that will get rewritten if necessarry in the sequel (if there is one)).

However, with the caveat above, it's better to aim high, because if you succeed it's better :) and if you fail, well to bad. So you should probably try the MVC, but don't worry if it fails, profesional game devs have all failed at the task many times :)

回答2:

I’d certainly vote for the model to know nothing about its views. Loose coupling is good: Simpler model code, easier testing, more choices.

回答3:

I know this question might be outdated, but I need to reply on it. Actually, I started programming a game in Lua (with LÖVE) and I started programming a MVC - Framework for it. At first, to use MVC really depends on what you want. I know my problems with game programming, when the program becomes bigger, and mostly the structure becoms too complex to maintain. Next thing is, I know that I will change all the graphics when I find an artist who is willing to work for it. But until then, I'm gonna use my own dummy graphics. I want the artist to feel free to do what ever he wants, without beeing dependend on any resolution or color restriction. That means, I might have to change the whole (!) presentation code. Maybe even the way objects interact (collision detection, f.e.). The game logic is captured in the models, so I can concentrate on that. And I think game logic is the most important part of making a game. Isn't it? Hope you see my point.

But, if you have everything together: all the graphics, sounds, the whole thing; then you can code straight forward.

My MVC is a configuration-over-convention-ass, that slows down prototyping a bit. BUT(!) iterations of development can be made much more easily. Testing, especially Unit-Tests are done much more faster. I would say MVC turns you development-speed-curve (which is normally an anti-exponential curve) into an exponential curve. Slow at the beginning, but more and more fast at the end.

回答4:

MVC works really well for games, at least for my games which are designed for cross-platform. It really depends on how you implement it in order to get the benefit.