Game architecture: Heavily branched game loop vs MVC or: Going mad with MVC, MVP, Robotlegs, PureMVC, Mediators, DI FSM & Models

[george]

My question:

Do you use a plain (but heavily branched) game loop or do you split your game by a principal like MVC or MVP ?

 

Yes I know, I know.. this classical question is related to programming, not to gaming itself. I think I established a really nice and well working architecture in my flash/flex projects. Those projects were something between an App and and a Game as I'm cerating a lot of short termed, microsite like apps und pages (10 to 30 working days) for advertising agencies and there customers.

 

I still create flash projects. But in the past year I've seen myself doing more and more Javascript only projects and as somebody with a flash background of 15 years it was inevitable that I will join the HTML5 gaming community

 

A typical flex project nowadays looks like this:

1. Robotlegs as my application framework
2. Finite state machine (FSM) to carefully manage my transitions between my content screens.
3. Service and Models classes to retrieve and manage any data.
4. Communicate with events between my mediator and my views, and use Signals and Commands to trigger actions in a mediator or a data fetching service class.

 

Four years ago I used PureMVC instead of Robotlegs and before then I used Cairngorm MVC.

It always was a battle to organize my code and establish a solid communication between all elements.

 

My flash projects are now fine. It absolutely works for me. But I still battle the code with each new project as the app flow is never the same. I sometimes re-adjust my FSM, sometimes I need no FSM and control everyhting myself in a global 'big daddy' controller.

 

I created so many many many projects with flash & flex. I love JS and I always use Backbone Views & Router to manage my HTML Frontend. I'm programming well tested backends in Rails for two years now. The whole ecosystem I work with is a pleasure. It's fun.

 

Now I dived deep into HTML5 (or more to say JS with Canvas/WebGL) aaaand welcome back in 1999. It's not that I'm struggling with it. But there is a large battle in my mind. Should I use a plain game loop or do it the fancy and OOP'ish way I know from Flash, Rails and my Frontend JS.

 

Of course, I decided to do it the fancy way. And it totally feels like over-engineering my code.

I'm currently building a small advertising game. It will run on Facebook and standalone. Nothing complex you and I would say.

 

It's a Whac-A-Mole clone with a totally not mole related story overlayed.

There is a Timer, some Levels adjusting the speed and difficulty, some messages presented as an overlay.

There is a qualification round, and all the game levels itself. You get a penalty when you miss to hit a mole. Then penalty is shown in an overlay, the timer is paused. At the end you have a highscore in form of a duration you survived before missing too many moles.

 

Easy isn't it ? I can clearly see you guys programming this within hours or days with a simple branching game loop.

 

And what did I ?

 

I have

• a state machine with 4 states (introduction, qualification, qualification results, competition & results)
• a bloated game model
• a levelmanager model (LevelConfig, LevelItem, LevelManager)
• a player model
• an isolated class to manage to the gameplay logic itself  (Mole, Whacker, Referee)
• an overlay controller
• a view and presenter/mediator for each stage
• Additionally to the FMS big daddy controller, where I init my game models(player, game, levelmanager), initializing my mediators with my views, expose some global APIS like (stopGame, restartGame, playMusic) and listening to the FSM to trigger an overlay or change a state in my fat game model.
• No clear way of communication. Sometimes I listen for changes in my game model,
• Sometimes I call something via a global saved instance of my bid daddy controler, sometimes I use my global command bus (which is: a globally available event bus) sometimes I listen for a change in my game model.

 

Yeah i's working! It's not finished but in a good progress and I feel good about the result itself. I used Phaser and I'm feeling really happy with it.

But can you see it? This is over-engineered!! I hate it! It's like I'm knowing to much about architecture and that I messed it all up. I do not want to do it again in this manner. I can't do it the easy way and switch over to a game loop. My brain is not able to think in a single game loop. I grew up with MVC, with decoupling & events.

 

And that's the reason why I'm asking here you pros: What's the architecture of your small or large games ?

 

Sorry for that long story telling. Thanks for any comment, advice or question!

Regards George

 

By the way, my game loop looks like this:

//a state of Phaser JScreate: function(){  this.whackAMole = new Game.WhackAMoleGame(this.game) //init big daddy controller  this.whackAMole.start()}update: function(){  //nothing.. phaser is doing all the game loop stuff, my game is totally event based}

 

[Gio]

Surely the best way to do this depends on the framework that you're using... each framework has got its own strengths and weaknesses, and if you know what they are you'll design your architecture to take advantage of them.

 

Personally I'm not a big fan of strict design patterns. Obviously if you've used MVC for a long time, it's natural that you'd keep using the same approach in a different environment, even if it isn't the best possible approach in this case. I love the fact that JavaScript is such a flexible language that lets you do whatever you like (functional programming, OOP, etc.). I try to use a bit of everything, trying to choose the best approach for each task. There's nothing wrong with mixing different paradigms in the same project in my opinion.

 

My personal preference is modular design, so I normally have not one, but several game loops (one per module) that run independently at the same time. Although for such a simple game, I'd make it entirely event-based like you did. Interestingly, someone who works with me made these videos about creating a (simple) whac-a-mole game in html5. And yes, it's entirely event-based like yours, but with fewer classes, controllers, etc

[away168]

First of all, I don't find this question odd, programming is also game programming after all.

 

In my opinion, use MVC for UI only because MVC structure is best for event/trigger-based applications.

 

In your case FSM and a scene graph should be enough for you. A facade pattern to wrap all your subsystems such as asset manager, scene manager, game state manager, renderer, etc.

In Flash, Scene graph, 2D/3D renderer, and timeline system are already managed for you, but in HTML5 it is pretty much raw, so you have to develop it yourself and separate them, this is almost like developing in raw C++/Java/iOS games, except that we are still unable to make the "real" game loop like those (we have to use requestAnimationFrame, where the frame steps are managed by the browser).

 

In my opinion, game core is about that single game loop. MVC and game loop are 2 different architectures, but you can combine them in different tasks.

For example, in your game state update(), say a simple event like (in pseudo code whatever):

if (isCollided) {    isCollided = false;    isGameOver = true;    Director::controllerManager->getController<UserController>()->updateHighScore(); // Save data locally and also send it to server using your whatever models and then update the available UI display for score, or trigger a flag to perform high score animation.}

I've tried MVC both in client-side web and games, honestly I always have this MVC gone overkill in games unless I'm doing it specifically for UI, exactly like web development.

[rich]

I've honestly never understood the point of MVC in games outside of game UI, the complexity and maintainability issues it often introduces can be staggering. The technical debt to pay when you revisit the game a few months later often outweighs any perceived benefit it may have had in the first case. It's something we actively avoided in my team after seeing the damage it could do.

 

I remember there was an Asteroids game posted a year or so ago, created in Robotlegs (I think maybe Ash too?) that showed how to model a basic game around that structure (edit: found it https://github.com/richardlord/Asteroids) - I was just stunned at how something so simple and easy to create could be turned into something so complex There was simply no benefit from building it like this. All the key MVC arguments fly out the window when the game scale is quite small.

[d13]

I've honestly never understood the point of MVC in games outside of game UI, the complexity and maintainability issues it often introduces can be staggering.

I agree.

In general MVC *might* make sense for a phenomenally huge project in a class-based language like AS3.0 and Java.

But MVC makes no sense at all in a functional class-free language like JavaScript that has far simpler and much more elegant ways of solving the kinds of encapsulated binding and notification problems MVC was designed to tackle.

Those problems just don't exist in JavaScript.

 

As for architecture....

Stick with the game loop

Make each game state it's own function, and then just call those different functions when the game's state changes.

It's so easy!

[Ezelia]

also agree about MVC, it's not adapted to game design at all.

for my current game projects, I'm using ECS paradigm, and I'm really happy with it, flexible and simple to maintain. easy to understand for new developers.

I moved from OOP, to OOP + AOP ... now I'm experimenting ECS

[clark]

I am making small games for a small company. For me personally, after obsessing with design patterns ( and yeah robotlegs! or StarlingMVC ) , I realised that these things just sapped my enjoyment.  

I am not saying just hack together any old thing, I just mean in perspective, a few public properties here, and a couple of Singletons there....  

It will do me. 

[george]

Brilliant! Thank you gio, alectora, rich, d13, ezelia & clark for opening my eyes.

I think you catapulted me out of my MVC comfort zone (which wasn't comfortably at all for games). I told you in my opening post

 

 

"I can't [...] switch over to a game loop. My brain is not able to think in a single game loop."

 

It is only hours later and it seems pretty obvious to me now that MVC and related patterns are definitely not the way to go and that the game loop remains the core of a game logic. In my upcoming project I will force me to use the game loop (or multiple loops) for the game part. I will pretend not to know MVC and I will focus on useful patterns around the game loop.

 

Thank you so much! You're a great community!

Regards George

[scoots]

ECS is great for bigger games with a lot of reusable logic. ECS is also great if you're going to be making a lot of similar games that you want reusable code for. The 2D tile game framework we've worked on at my job uses ECS. We've made a few games with it and have learned several things worth sharing:

 

- It's a bit of a steep learning curve. 

- In my experience, you need to spend more up front time planning and architecting a new project when using ECS.

- It's great for making several similar games. If you break you component logic down to the smallest possible logic, it really makes things easy to reuse. 

 

Here's our game framework. There are a lot of example components provided that might be helpful to look at if you're thinking about how you might architect a 2D tile based game.

 

Cheers

[Ezelia]

@scoots, what you described is exactly what I encountered when started using ECS.

after some iteration I ended with a structure mising ECS (at low level) and OOP (at hight level).

generic reusable components like : Input, Renderer, Positions, physics, particles ...etc are in ECS

but all game specific components (player class, game logic ..etc) ar in  OOP

I'm still iterating to enhance my model

lately I discovered Unity witch I found excellent Game Engine, and I noticed that it used same logic that I implemented in my game engine, I was really amased when I read that actually Unity is based on ECS

whatever the paradigm you choose for your code, the only rule IMO, is that there is no perfect Model/paradigm, we allways have to mix and break some rules to create the most suited model.