18
\$\begingroup\$

I am reading one great book, Game Coding Complete, and that book strongly recommends using MVC (Model-View-Controller) approach, with three key layers:

  1. Game Application Layer
  2. Game Logic
  3. Game View

To me, this approach looks like an overkill for a mobile computer game.

What is your opinion, please? Is it worth of implementing this architecture, even if it adds extra communication needed between modules? Can this design consume so much CPU power, that at the end, the result would be significantly slower, than if it weren't implemented?

Improve this question
\$\endgroup\$
4
  • 5
    \$\begingroup\$ -1 and vote to close. Everything worth saying about MVC in games was said at gamedev.stackexchange.com/questions/3426/…, and so far all we've got here is garbage. \$\endgroup\$
    – user744
    Jan 25, 2011 at 19:03
  • \$\begingroup\$ @Joe Wreschnig that's pretty harsh, but I guess true... \$\endgroup\$
    – Spooks
    Jan 25, 2011 at 19:49
  • \$\begingroup\$ @chaos: Actually, I voted your answer up, but we really did not need another answer saying "use patterns if they help, don't if they don't." Or maybe we did, but then that's still really sad. I still don't know how to refer to expressions like "Run-time designs like inheritance" other than garbage, though. \$\endgroup\$
    – user744
    Jan 25, 2011 at 21:22
  • 2
    \$\begingroup\$ @Joe: Oh, well thanks. :) The argument that OOP is cost-free does somewhat boggle the mind. I suppose by some standard we shouldn't need points like mine reiterated, but noobs do happen and so do debatably duplicate questions. It also serves the function of letting latecomers to the site like me scrape together a tiny bit of rep despite activity having massively died down. :) I mean, damn, I have 40K rep on SO, but here I can't even edit a tag wiki. \$\endgroup\$
    – chaos
    Jan 25, 2011 at 21:34

3 Answers 3

Reset to default
31
\$\begingroup\$

I somewhat support using an MVC structure even for a simple mobile game. If nothing else, it helps with an issue that plagues developers who haven't gotten bitten by it enough times: separating the display code from the game logic.

I'll also say, though, to keep in mind that MVC, like all design patterns, exists to make your life easier. That means that if, at any given time, staying within some set of rules about what you should and shouldn't do when using MVC is making your life harder, ignore it. One of two things will happen: 1) you'll get bitten later, and then will understand why doing it differently in the first place would actually have made your life easier in the long run, or 2) no consequences whatsoever.

Computer programming, by its nature, gets a lot of rule-followers who value adherence to elegant principle over actually accomplishing anything, and they love to propound their value system; don't let them make you one of them. The most important thing that can happen to your game is shipping it.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Dear Chaos, I like your answer the most, therefore I am marking it as an answer to my question. MVC approach adds abstraction into code design. Abstraction ususally adds extra steps of code, that could be avoided with more straighforward design. As I understood correctly, I do not need to worry of the cost introduced by the abstraction added as a result of MVC design. \$\endgroup\$
    – Bunkai.Satori
    Jan 25, 2011 at 19:16
  • 1
    \$\begingroup\$ Good answer, +1 on that.. Theory is all fine and well but it can cause games to not be shipped if you just do not get it done. \$\endgroup\$
    – James
    Jan 25, 2011 at 20:57
  • \$\begingroup\$ @Bunkai.Satori: It does add abstraction, and IMO it's useful abstraction that pays its way. I agree with your last statement, with the clarification that there is a cost, and that I do not think you need to worry about it. \$\endgroup\$
    – chaos
    Jan 26, 2011 at 19:08
5
\$\begingroup\$

Compile-time designs do not consume CPU power, unless you have an incredibly abysmal compiler. An object orientated language or approach is no different in performance characteristics than a procedural one. You will not invoke any additional overhead for using MVC. Modularity exists at compile-time, not run-time, once the code is inlined and optimized, it won't make any difference at all.

Many modern games actually run the models and the views on separate threads and gain great performance benefits on most platforms.

Ultimately, MVC is a good design that gets you increased maintenance and less bugs etc for free. There's no reason not to use it. It's like asking why you should use a for loop instead of hand-written gotos. Unless you have a superior design in mind, it's sure as hell better than nothing.

Edit: Compile-time designs do not consume CPU power. Run-time designs like inheritance obviously do.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ -1. MVC is a design-time decision. Inheritance is a design-time decision. Both occur before compile-time and run-time. Both have major impacts on performance. Inlining does not always make code faster. Your threading proposal is incredibly naive. Nothing is free. \$\endgroup\$
    – user744
    Jan 25, 2011 at 18:56
  • \$\begingroup\$ Thank you DeadMG for your answer. Basically, I mean that with every level of abstraction, the code gets slover, as more and more intermediate steps are added. MVC is more abstract design, that will most likely result in more steps to achieve the same task. This would have influence on speed, imo. \$\endgroup\$
    – Bunkai.Satori
    Jan 25, 2011 at 19:13
4
\$\begingroup\$

There is almost always a tradeoff between the clarity of the code and the technical requirements (speed, memory, etc.) of the program. Object-oriented languages have an overhead compared to procedural languages, but they have been shown to have many advantages over procedural languages, especially in long-term maintenance of code (bugs, etc.) and often development speed as well.

So with that in mind, I propose that MVC is worth implementing for your sake as the game programmer. Your code will better follow object-oriented principles, especially encapsulation, and you will likely have a much easier time maintaining it (fixing bugs or adding new features).

On the other hand, make sure to actually finish a game and not spend so much time working on the "engine" that it never gets done.

For more info, please read the question "Why are MVC & TDD not employed more in game architecture?" and my really long answer.

Improve this answer
\$\endgroup\$
4
  • 1
    \$\begingroup\$ OO languages aren't slower than procedural languages at all. If you write some code in C++ that does bit-shifting, it won't be any slower than in C. A language or program is not slower compared to procedural at all just because it is object orientated. Programs only exhibit performance detriments because they're poorly written. As a result, I feel the need to downvote your answer. \$\endgroup\$
    – DeadMG
    Jan 25, 2011 at 18:38
  • \$\begingroup\$ Hi Ricket, thank you for yoru explanation. It sounds very logical. DeadMG, well, on the one side you are correct, On the other side, I think that OO approach adds more bits of information in the compiled code than procedural language. This extra bits of OO related code makes the resulting code slower. Do you agree? \$\endgroup\$
    – Bunkai.Satori
    Jan 25, 2011 at 19:07
  • 3
    \$\begingroup\$ Whoa now... Sure a simple line in C++ like a++ will be the exact same as a++ in C (where a is a primitive type, etc. etc.). But consider a simple C++ class with a virtual function that does something, that virtual function incurs a hefty overhead vs. a simple C function, even if the inner code is identical. Object-oriented languages have an overhead. Sorry for explicitly saying "speed". If extra memory allocations and such don't result in a slower program then you're absolutely correct. \$\endgroup\$
    – Ricket
    Jan 25, 2011 at 19:12
  • 3
    \$\begingroup\$ If the function is virtual, that implies that the program needs to choose between 2 different versions of the same function at run time. (Otherwise, you wouldn't make it virtual.) In this case, you have an extra conditional or level of indirection anyway, which you'd have to implement yourself in a procedural language (eg. via a function pointer or switch statement). That's not overhead - that's intrinsic to the problem. \$\endgroup\$
    – Kylotan
    Jan 26, 2011 at 1:11

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