MVC or Components, or both?

Question

I'm an experienced developer but recently I've been wanting to get into game programming but as you know game development is an entirely different beast from most other forms of programming (perhaps only bested by operating system development).

That being said I've been reading Game Coding Complete (ISBN 978-1-58450-680-5) by Mike McShaffry.

Originally I was going to try developing with a component model with the assortment of usual components (e.g. SpacialComponent, VisualComponent, EntityLogicComponent, etc..) however Mr. McShaffry recommends using the MVC model which looks very attractive but I'm not sure how I can make it work with the component model if at all possible, but, without components, the MVC model looks sort of the evil monolithic inheritance monster and not very flexible, which I'm not really interested in.

I'm really confused about where to go from this point.

Do you more experienced game coding voodoo experts have any thoughts or recommendations?

Thank you so much!

Answer 1

Useful questions:

MVC (Model-View-Controller) Game Engine Architecture - Yes or No?

Why are MVC & TDD not employed more in game architecture?

MVC-like compartmentalization in games?

For me, I have a RenderComponent base class and then a few that inherit from that (GameSprite, UISprite, or if you're doing 3d StaticModel, DynamicModel, BillboardModel, etc.) and if the object wants itself rendered, the object submits its RenderComponent member to the rendering system. No need for the rendering system to know what kind of object submitted the RenderComponent. It just knows it's got something to render and it better do it, or else!

Keep it basic and centered around composition rather than inheritance. Separating logic, data, and representation isn't incompatible with a component system.

Answer 2

I'd recommend ignoring components for your first game because they solve some types of complexity by adding more complexity in other areas, and if you've not already made a game you have no idea whether this trade-off is worth it or not.

For the most part though, don't get bogged down in programming paradigms and just code a game. There are no right or wrong ways, otherwise nobody would need to ask this sort of question. Work it out as you go along.

Answer 3

I wouldn't use a strict MVC pattern, but I would separate your rendering from your simulation, and stick it on another thread.

I think components are very useful actually, but I often see people just ignore them and write their code directly into the "main" component whatever that may be. You have to remember that games are full of hacks because the are often written on a deadline with the assumption that code wont be re-used.

I'm a little confused as to why you think these approaches are incompatible. What game code have you looked at?

Personally, I think games do require some up front design. I've seen a couple of code bases that were nightmares because of the "just code it mentality".

That said, I think that you should just jump in and code a game. You'll make so many mistakes writing your first game that these kinds of problems wont matter much. Once you have a better grasp of whats required, then you can go back and start looking at architecture and seeing how it solves the problems you encountered.