Immediate Mode and Model-view-controller

thanks for all the info! i'll read it a few times and post back any questions. i feel this is my last chance if i want to change anything in the current game. the last few weeks of code is pretty ugly because i wanted to experiment with different things. which means that i want to clean it up after the first iteration anyway to get a good foundation to the real game. i might as well see if this is something that works for me and try it out because if i get any further into the game now it will be too much to change and i probably can't be arsed to change the fundamentals until the next game.

---------------
Solid Core Entertainment
Developer of Roadclub

Guilty as charged Actually since MVC is a big fad in the web dev community now (ASP .NET MVC, Zend, et al) we'll be hammering more MVC. I personally find this really interesting that games and web (indeed any interactive system benefits from MVC) is starting to converge...

The "Entity" thingy is actually a big misunderstanding of OO practices. OO actually says objects should be as cohesive as possible and have as low coupling as possible. To then go and make a "Player"-entity that has dependencies on input, graphics, sound, and game play mechanics is indeed a violation of OO guidelines.

Anyway back on topic

Our approach to MVC in games have diverged towards pretty much the same actual implementation as Johno described. This also makes it quite easy for us to understand each others code and we can communicate really efficiently. The biggest "confusion" in MVC is mostly what is the View and what is the Controller. The model is mostly clear (ie gameplay mechanics and rules anything not doing with presentation or interaction).

Malice's idea of imagining another presentation for your game is quite good. Though you should probably not diverge into speculation when coding your view. Keep it focused

Great info guys. I'll read up on it. A game would of course help too I'm starting to realize this is where i need to go. I've locked out myself too much already. I've kinda just teached myself and looked up what i needed. I haven't used any other patterns than monostate and singleton so far. So this is a needed lesson indeed

---------------
Solid Core Entertainment
Developer of Roadclub

Sounds like you have fallen in the poymorphism/RTTI trap, otherwise known as "is you a can of coke?"

http://www.johno.se/book/oops.html

/johno
"you can't stop the change"

Intermixing a separate physics "engine" of course complicates tings a bit. I guess the physics engine is residing on the model side of things, that is it manages some game play aspects. Unfortunately most physics engines use the "retained mode" approach as you describe, making the physics engine much of a cache duplicating much of the real model data. As it seems the physics engine of your choice seem to mess things up for you regarding your actual game play But that is a whole other discussion.

Anyway, my first thought is if you can query for collisions for the specific pairs you want to handle? For example "Player Bullets" v.s. "Enemy Fighter Ship". If you can you can then directly generate an event (function call over IEventTarget) to the view (PlayerBulletEnemyFighter(...)) possibly with pointers/ids to the concrete model object for further investigation by the view (for example checking if the enemy died)

Secondly, I've started to grow fond of using immediate mode techniques for doing effects like particles. In TWTPB all effects are immediate mode, this means they are recreated from scratch each frame and rendering a particle system becomes as easy as calling a function with some parameters.

In my view I mostly had some extra timers for these effects that where started when an event occurred. The view also started any sound effects needed as the event occurred.

This all worked very well in TWTPB...

There is no rule against putting rules in the controller/view as long as they are for controller/view logic. In the case of TWTPB and bullet hits there was no model side representation of a dead enemy, so the controller/view simply checked if the enemy was dead and if so started the explosion timer otherwise another effect was triggered.

In my current MVC implementation this logic would reside in the controller. As it seems we(?) have seen that immediate mode techniques tend to make the view a very slim collection of utility functions, the controllers become a bit fatter with responsibilities as described above and layout (i.e. calling view functions in some kind of order)

According to Johno (who actually went to Oslo to talk with the man behind MVC) it seems not even Trygve Reenskaug exactly knows the division between Controller and View. I guess it's very much up to the application and developer to find this out for themselves

I would say that the main thing that drove me towards a Passive View was having lots of different "modes" in my app; typical would be to have a "game mode" and at least one "edit mode".

In that kind of scenario I found that it was beneficial to have an object that was shared amongst all "modes" and encapsulated common rendering methods (and not least common assets like bitmaps/textures, meshes, sounds, etc).

Also, there was a "mode master" that controlled switching between the various "modes".

Initially I called the "modes" Views, the "mode master" ViewManager, and the "common rendering object" ViewCore.

The more I worked with this architecture I started thinking that maybe the my Views were really Controllers and my ViewCore was really View (speculating as to what the intended distinction between Controller and View was in the original envisioning of MVC).

These days I would say that each "mode" is a specific Controller, and everything that is common in terms of assets and rendering stuff is View, and there is also a MetaController that encapsulates all Controllers and controls switching between them.

Having things this way allows to basically switch between almost completely different apps by pressing for example the F keys (F1 for game, F2 for level editor, etc) really quickly with no setup or teardown overhead.

Each Controller is responsible for both reacting to user input (doInput()) and composing output (doOutput()) for each frame. There is no significant reason to splitting this up into two methods, but this is just what I tend to do.

At the top Application level loop I do:

metaController.doInput();
model.update();
metaController.doOutput();

MetaController::doInput() handles controller switching as mentioned and then delegates to the current Controller.

Model::update() is a "game logic tick"; AI and stuff goes here.

MetaController::doOutput() delegates drawing to the current controller as well as perhaps drawing top level stuff.

Again, you could do both output and input in MetaController::doOutput() (call it update() or whatever) as you conceivably need to have drawn something for the user to react to it, and it's all a fast realtime loop anyway. I believe hObbE's stuff is more in this style.

I really need to put up a reference game somewhere with full src...

/johno
"you can't stop the change"

Indeed one model, several controllers and one view I tend to have several tiny editors (in TWTPB there where three I think; one sprite editor, one wave editor and one level editor)

And yes, there should only be the need for one model (as it is the representation of the game).

BTW the smooth rotation in Project L is done on the controller/view side of things on the model side of things the change of up is instant making the world movements much less complicated When the model changes the up direction it simply sends an event (function call) to the controller and it starts an interpolation timer to interpolate between it's own up direction and the up direction in the model.

Okay, i took some time puzzling together summarizing text and made pseudo code dependency/inheritance summary to get some kind of overview here. I extended johnos first example to include a metacontroller with two child controllers and IEventTarget setup. Have i made any mistakes here?

Model = gamestate and logic which operates on this state (i.e. objects)
Model holds state and logic. I.e data that give substance to all the game's objects. If you have a spaceship, its position and velocity etc is part of Model. Any bullets it shoots is also part of Model.
Model may not depend on View or Controller. Model may be global (i.e only a single Model in the system).

MetaController::doInput() handles controller switching as mentioned and then delegates to the current Controller.
Model::update() is a "game logic tick"; AI and stuff goes here.
MetaController::doOutput() delegates drawing to the current controller as well as perhaps drawing top level stuff.

Controller = based on the state of the Model, Controller orchestrates the presentation of the application using View
Controller will look at (i.e. traverse) Model's state and "program" View to visualize this state in some way.
it is typical to have a "MetaController?" at the top level. This logically replaces the main "Controller" in the MVC pattern, and allows for switching between the various Controllers.

View = the "input/output" layer, including the renderer and also all user interface windows and widgets
View. All interfaces for querying for user input (gamepad/key/mouse stuff) is here, and output/sound/drawing stuff is here, including user interface widgets.
View may depend on Model (in order to visualize it), but may not depend on Controller. View may be global.

Dependencies
* App owns a Model, a View and a MetaController
* View has a const& to Model
* MetaController has a & to View, and passes this to each IController implementation

void main()
{
Model m;
View v;
MetaController c;
m.setEventTarget((IEventTarget)c);

while(loop)
{
c.setEventTarget((IEventTarget)m);
c.doInput(m);
m.update();
c.doOutput(m, v);
v.present();
}
}

class IEventTarget
{
virtual void Event() = 0;

virtual void StartExplosion();
virtual void PlaySound();
};

class IController : public IEventTarget
{
virtual void doInput(Model& aModel) = 0;
virtual void doOutput(const Model& aModel, View& aView) = 0;

virtual void StartExplosion();
virtual void PlaySound();

IEventTarget& frameEventTarget;
};

class MetaController : public IController
{
void SwitchController();

// From icontroller
void doInput(Model& aModel);
void doOutput(const Model& aModel, View& aView);

// From ieventtarget
void StartExplosion();
void PlaySound();

Controller* currentController;
GameController gc;
EditController ec;
}

void MetaController::doOutput(const Model& aModel, View& aView)
{
currentController->doOutput(aModel, aView);
}

class GameController : public IController
{
void doInput(Model& aModel);
void doOutput(const Model& aModel, View& aView);

// From ieventtarget
void StartExplosion();
void PlaySound();
};

void GameController::doInput(Model& aModel)
{
// set input state to model so it can act according to input
}

void GameController::doOutput(const Model& aModel, View& aView)
{
// draw model using model state with views functionality
aView.drawSprite(aModel.myPosition);
}

class EditController : public Controller
{
void doInput(Model& aModel);
void doOutput(const Model& aModel, View& aView);

// From ieventtarget
void StartExplosion();
void PlaySound();
};

void EditController::doInput(Model& aModel)
{
// set editor input state to model so it can act according to input
}

void EditController::doOutput(const Model& aModel, View& aView)
{
// draw model in edit mode using model state with views functionality
aView.drawSprite(aModel.myPosition);
}

class Model : public IEventTarget
{
void setEventTarget(IEventTarget& eventTarget);

void setInput(inputstate);
void update();

IEventTarget& eventTarget;
};

void Model::setInput(inputstate)
{
// store inputstate for use in update
}

void Model::update()
{
//act according to input (move left, right, up, down, etc...)
}

class View
{
void drawSprite(vector position);
void present();
};

void View::present()
{
//begin scene
//draw sprites
//end scene
}

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)

http://www.johno.se/software/AstroCreeps_IEventTarget.h

The ordering is methods slightly bad, but here are the ones that the Controller calls:

• togglePause()
• setShipInput()
• resetGame()
• submitScore()
• togglePowerup()

The main one is of course setShipInput() which is called every frame once the game is running.

My typical style is that Model implements each of these methods in some way, and then calls back its stored IEventTarget reference (which is the MetaController) to let the "other side" do anything it needs to do as a result of an event.

A good example is asteroidHit(), which is triggered by:

• A Bullet instance detects intersections with Asteroids, and if one is hit the Bullet calls IEventTarget::asteroidHit() and terminates. Note that this is all single threaded, so technically the bullet dies right after everything that happens as a result of IEventTarget::asteroidHit() is complete. Also note that most things within the Model (the ship, bullets, asteroids) all use the paradigm of const& to Model and a normal & to IEventarget, usually as parameters to their update() methods. This is for clarity, so that when some bit of code wants to change something in the Model, IEventTarget is used to "formalize" that change.
• Models implementation of asteroidHit() finds the asteroid that is referenced, calls its hit() method (which in turn can result in calls to IEventTarget::makeAsteroid()), and then handles all score and multiplier related stuff for the player.
• Finally, Model calls back its stored IEventTarget (again, this is the MetaController) to allow for explosion visuals and sound effects, depending on the type of the asteroid (all rocks and creeps use the class Asteroid).

This might feel kind of strange to you, especially since I use the style that logic elements within the Model (asteroids, bullets, the player's ship) all use the formal interfaces to Model (reads are free via const Model &, writes are via IEventTarget &). However, I find that this really cleans up the code and makes all intents very clear, and you have a really good way to make sure that things happen in the right order.

One other thing to note is that a big part of the design of a game like Astro-Creeps is that you have to decide what party is active and what party is passive in each interaction. In my game:

• Bullets actively detect collisions with Asteroids, and if one occurs they decide to terminate.
• Ship fires projectiles via IEventTarget::makeBullet() and IEventTarget::makeLaser().
• Asteroids create new asteroids via IEventTarget::makeAsteroid() (when Asteroid::hit() is called), and also powerups via IEventTarget::makePowerup().

Finally, sometimes "events" are simply for the sake of the visualisation. For example, a bouncing Bullet calls IEventTarget::bulletBounced() when a bounce occurs, and Model implements this with an empty method and then the usual forward to the MetaController, which handles the playing of the bounce sound.

I hope this example helps.

/johno
"you can't stop the change"

I will be following the development of Sense closely! And btw, I forgot to say that I really liked your glowy yellow "blood" particles...

/johno
"you can't stop the change"

when the model calls its stored eventtarget with requests for visual effects/sound, who maintains the state after that? say you activate an explosion. the view starts showing it but it will take 3 seconds for the effect to be done. does the view handle this itself or does the controller or model feed the view with the integrated positions/sizes etc every frame (thus not requiring any state in view and holding all state data itself)?

I also have to ask how you handle the classic "engine" thinking. I assume you have SOME kind of utility tools for access to hardware. how does the controller and view access them and where are they created?

I currently have a "framework" to which i register a "game" and callbacks from the framework give me some access to hardware and some parts i can access through a monostate pattern. This is probably what i need to change first.. so answers on the previous paragraph would put me in the right direction.

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)

Ok as i suspected. I've spent so much time on the framework i'm beginning to think i need to compromise if i'm not to spend a year on rewriting everything. I couldn't make it perfect the first try anyway so maybe it's better to do as much as i can and move on and start with a clear mind on the next project. the framework is pretty nicely divided regarding updates/draws and kinda low-level so it shouldn't be too bad. I should be able to utilize most of the benefits of mvc anyway if i try to wrap what i have inside the mvc classes and use eventtargets for communication.

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)

There is no call for being totally purist about state. To be fair, a D3D texture interface handle is "state" (it occupies memory). I agree with hObbE that a singular concept that is part of the domain model (i.e. Model) should only be represented once.

A counter-example: back in my days at Massive (I'm thinking Ground Control II in 2003-2004) we had for example the 3d-space position of any given unit represented once on the server, once on the client, once in the 3d engine, once in the script api, and once in the AI module...

Concerning "menu states"; in Bloom, which is a pretty recent architecture, I have these controllers:

• IdleController: this controller is active when the game is not being played, and handles all the different "screens" (highscores, credits). There is a piece of state inside IdleController called myScreen, which is a simple enum variable that represents the current screen, and everything is IMGUI style from there.
• PlayController: this controller is active when the game is being played, and handles user input for the little dude and of course renders the game world, plays music, etc.
• ReplayController: very much like PlayController, this controller is active when a replay is being shown. However here the IEventTarget method setHeroInput() is being fed not from user input, but from prerecorded input from the current replay.

In the version of Bloom that is on hUb right now, the current controller is selected each frame by MetaController depending entirely on Model state, like this:

IController& MetaController::controller()
{
if(myView.myModel.gameActive())
{
if(myReplayer.isPlaying())
return myReplay;
else
return *myController;
}
else
{
return myIdle;
}
}

The Controllers are the variables myReplay, myIdle, and whatever myController is pointing at at that moment (Bloom has an integrated EditController that you never see when you play the game).

So my point is basically that what many people consider to be "application states", i.e. frontend vs ingame, is in my mind just a number of different Controllers handling input and composing output. The Model is always there and encapsulates the same state, but since it in itself doesn't know or care about visualization what the user is seeing is purely dictated by Controllers.

This drastically contrasts what we used to do back at Massive with "application states", where when the user saw the frontend the entire "model / server" didn't exist at all (was dynamically allocated later). This gave us all kinds of headaches concerning things like displaying stats from the last mission in the frontend, since that memory belonged to the server that we just deallocated.

I very much strive to be able to have every single thing I need for the Model in memory at the same time, because if I can't things get complicated very fast. Remember, even if you have several maps or levels in your game, you still only need to have one loaded at once. Also, because of the non-cached / immediate nature of View and Controller, they really couldn't care less about when the internal representation of Model changes, even on a per frame basis.

/johno
"you can't stop the change"

Thanks again for elaborated but to-the-point answers. It's really helpful to see how you've actually implemented something even though i think i understand the basic concept pretty well by now. MVC can be interpreted in a few ways and you can place stuff in different places depending on your position.

I spent a few hours today morphing sense code into MVC. I gotta say, it was like laying a puzzle. Things just fall into place and it feels right. It's great to see that what I've done isn't so bad and it's nice to see the benefits of the new architecture kinda remove unnecessary code and dependencies as well as links to singletons.

The eventtarget approach is really nice. I had to make SOME modifications to the original plan but generally it was pretty painless and stays true to the discussion we've had. The framework does some things i merged with the mvc layout but nothing major and i think it fits nicely. There's still some work to do but i think the eventtarget actually removes most of my communication issues and the feeling of need for singletons "because it's too hard to find objects". Now i just call on the eventtarget what i want to happen and the model or a controller somewhere takes care of it.

The hardest bit will be separating drawing code from objects that previously had both update and draw functions and make the controllers tell the view what to do instead. but i really think it will be nicer and easier to work with when its done.

Now that i know that "input goes here" and "drawing goes here" it's much easier to design the code and know where to put it and similar code is automatically brought together.

Hehe i would be careful going too far though like with your sentry example there. I think at some point you're just complicating for yourself by trying to make the nicest code according to your Plans of Purity Sometimes you just have to move on because you have a working setup that already does what you need and there's no need putting more time into architecture design at the moment.

The last bit is interesting. From what i can see now it looks as if the eventtarget and model will grow really large while controller and view stay smaller. Well, we'll see as the game grows, things are still too much in the wrong place for a final judgement.

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)