Home/ Questions/Q 6945073
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T13:23:20+00:00

So im struggling with the idea of implementing MVC pattern on a (lets say)

  • 0

So im struggling with the idea of implementing MVC pattern on a (lets say) game app. Im spending some serious time lately focusing on the MVC pattern and how it gets correctly implemented but when it comes to an openGL app.. everything gets confusing.

Most specifically it all messes up (for me) in the View section.
I know i could have a model of lets say like this:
A class spaceship with variables like health, ammo, origin etc
A viewController (or just controller?) that would handle user input and act accordingly based on Model info and throw results on “View”

But really what about View here..? How can i implement my View in an openGL application in a sense off ‘throw those polygons on my *view’. Is that even possible, does openGL work that way? Thing with it is that i could pick an empty project drop some lines of code and have my projected triangle on screen with no need of an MVC design pattern. But i really want to work based on an mvc pattern because i figured out that you really go against the framework, i mean you really do.

I would really appreciate some coding examples focused on the View part of a MVC openGL app and also some further explanation so i can grasp the idea better.

Thank you for reading this, double thank you for answering!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m not sure if MVC works exactly the same in all languages/communities. But here’s how I understand it to work in the Mac/iOS world:

    Your model is responsible for storing data (eg: amount of ammo left in the ship) and manipulating data (eg: reducing the amount of ammo left in the ship).

    Your view is responsible for screen drawing and also responsible for all user interaction. I think you’ve missed that lass part (eg: the view draws a spaceship and watches for the spacebar key press event so it can send a fireGun: message to it’s delegate – which is a controller).

    The controller is for anything and everything else. In particular, the model and the view don’t really talk to each other much (within reason), instead they talk to the controller and the controller talks to both the model and the view (for example, the controller recieves a fireGun: message, checks if there’s enough ammo left in the model, then decreases the ammo by one, and tells the view to draw a bullet fire animation).

    Note that this does not actually split your code into three individual classes. Rather your code has many classes, each one of which fits into one of those three jobs. Multiple models, multiple views, multiple controllers.

    I’m not familiar with OpenGL, never done game programming so all my views have been using the standard/simple screen drawing API’s. However your view would have an internal data structure describing what is currently drawn on the screen, and it would draw exactly what’s in it. This data structure would be much simpler and faster than the model. It only contains what is actually visible, and nothing else (eg: it’d have a spaceship in it’s data structure, but not wouldn’t know anything about the spaceship such as how much ammo it has left right now).

    Sometimes a view will receive user interaction and process it without interacting with the controller at all. For example NSTextView is able to move the insertion point around on the screen without talking to it’s controller or the model.

    • 0