I'm in the process of refactoring my camera code the goal is to try and simplify things using a struct instead of a class or at the very least try something new since I always jump straight to classes/OOP. The struct would just have data I know it could have logic, but that doesn't seem to be common so the problem becomes how do I control the camera. Originally I was gonna have free functions, but the word "controller" popped into my head I don't actually know what "controller" means, but based on the word it would be some object like CameraController which would use the data from the Camera struct and then have logic to control it.

I'd like to know if this is what "controller" means and if so would an approach like this be better then just doing OOP?

  • 1
    \$\begingroup\$ You've summarized basically all there is about a "controller" — it's a name we assign to a bundle of code that controls something. Like "manager", it doesn't (always) map to any specific design pattern, it's just a slightly more descriptive version of "thing" as a label we can slap on something that has no other identifying characteristic. \$\endgroup\$
    – DMGregory
    Commented Jan 17 at 0:57
  • 2
    \$\begingroup\$ It does reminds me of the MVC design pattern, which stands for Model-View-Controller. The controller there is also used to store all the code logic and actions an user can handle within that model. Though I may also call them different, like "Manager" or "Provider", to prevent confusion with a gamepad controller. \$\endgroup\$
    – Steven
    Commented Jan 17 at 8:15
  • \$\begingroup\$ Related: en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller \$\endgroup\$
    – Evorlor
    Commented Jan 18 at 3:40

1 Answer 1


In the case you're describing, yes, a CameraController is "something that controls the camera".

You can cut-down things like this:


  • has a frustum/projection matrix
  • renders "what it sees" to "something" (on the screen, on a texture/buffer?) (to be honest, it could even be another type of object on its own: a view)


  • moves the camera around
  • can be..
    • attached to a world object
    • controlled by user input (then how is it controlled, using a kind of "first person scheme"? "trackball/orbital camera"?)
    • a function that drives the camera on a "rail" based on other data
    • etc...

So depending on your needs, it could make sense to split the bare camera features from the way the camera is controlled.

Regarding the OOP-ness of this, I'm not sure there is a debate about whether you should or should not approach this with OOP.

OOP is an approach to programming offering encapsulation of data, etc. It's not opposed to separating the concerns when you need it.

At it's core, a camera is a projection matrix, a position matrix and a target to where to render it, while the controller is a way to convert "world coordinates" or "user input" to something to input to the position matrix of the camera. You can use OOP if it fits or design, or you can have free functions and global objects if it fits better.

After all, DOOM was release without being OOP.

If the game you're writing uses OOP, then it's fine, and if it doesn't and it uses a more data oriented approach, then it's fine too.

In an OOP setting, you could have Camera objects that determine how a scene is viewed, Controller objects which determine how cameras move, and View objects which determine onto what the camera is projected. And all those object instances could be interchangeable.

In a Data/function setting you would have a series of struct Camera, a series of struct CameraController, and a series of struct View, each having their own appropriate data, and a pointer to the other structs (or handle to them), with a bunch of function just using the data to render your game.


You must log in to answer this question.

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