I'm creating my own game engine. I've read these articles and this question about DOD and it was written to not use member functions and classes. I also heard some criticism to this idea.

I can write it using member functions or non-member functions it would be similar. So what are the benefits/cons of that approach or when the project grows, does any of these approaches give clearer and better manageable code?

With POD & non-member functions I don't have to make struct members public I can still use object id outside of engine like OpenGL does with all it's stuff, so It's not about encapsulation.

POD - plain old data

DOD - data oriented design

  • 1
    \$\begingroup\$ Maybe supply links to the article(s) you have read, because it is difficult to follow your question. \$\endgroup\$
    – Engineer
    Oct 16, 2012 at 13:54
  • 1
    \$\begingroup\$ This isn't related to game development, should be migrated to SO. \$\endgroup\$ Oct 16, 2012 at 14:28
  • 1
    \$\begingroup\$ Are you talking about Scott Meyers: "How Non-Member Functions Improve Encapsulation"? \$\endgroup\$ Oct 16, 2012 at 14:28
  • \$\begingroup\$ @MaikSemder Yes. I seems to be what I'm talking about \$\endgroup\$
    – kravemir
    Oct 16, 2012 at 14:32

2 Answers 2


I can write it using member functions or non-member functions it would be similar.

That's not the way to approach DOD. That's just the C syntax of object-oriented code. DOD means thinking about data before writing your code. OOP is often (but not always) the other way around.

Example: You're going to have 10000 visible, colliding particle objects in your game.

OOP: I'll start by making a Particle class. Each particle will have a "collide" function. Just so it integrates in the world, each particle will be an Entity too. The Collide function will be virtual because Entity has an abstract virtual Collide function. The Render function will be similarly designed.

DOD: Since we've got a lot of particles, it would make sense to store them closely together to minimize the time it takes to process them. There will be a collision processing function that handles all particles at once and can be optimized in any way, if necessary. To further optimize memory access, particle data will be separated into rendering, physics and common data arrays, depending on the actual data that is used. If particle count is going to be increased, these things will be considered: reducing size of color data, making some of the variable equal or at least non-integrated (curves/equations) for all particles (allowing to remove them from data).

Obviously DOD takes a lot more time and thinking. How much it's worth depends on the project. These days, when everything is calculated in one library or another, it might not matter much. But if you want to make something truly impressive, it's basically DOD-way or the highway.

  • 1
    \$\begingroup\$ +1: excellent and succinct comparison of the methodologies. \$\endgroup\$ Oct 17, 2012 at 17:35

Following an object-oriented design is preferred for most larger projects. Most games are about interactions between different objects in a game world, so I consider OOP to be especially suitable for game development.

When you design classes, you should generally declare all their variables private and manipulate them through public getter and setter methods (or getter and setter member functions, when you prefer that term).


Imagine you have some game object with a public variable. Imagine that you change and access it in a bazillion places all over your code.

Now imagine that one day you realize, that whenever this variable changes, something else needs to happen (show it on the GUI, report it to a server via network or whatever). Or when it changes, something else needs to be changed too (changing the size changes the mass, changing the temperature changes the color or similar interactions).

Now you would have to check your whole code for every case where this variable is changed and add code to do the above. And when you forget just one, you will have a bug.

But when the variable would be private, you could just add the above behavior to the setter method and you could be sure that the code will be executed whenever the variable is changed, no matter where and for what reason.

And that's just one simple reason why following object-oriented paradigms makes your project much more maintainable and reduces the likeliness of bugs. There are a lot of other design patterns in object-oriented programming which help you to structure your code in a much cleaner and flexible way. I could write a whole book about it here, but there already are enough of those. Like this very famous one:


  • 2
    \$\begingroup\$ OOP has nothing to do with interactions between objects. interact(A,B) is equal to A.interact(B), if not more logical. Also, public getters/setters is one of the worst designs imaginable. There's nothing wrong with using public variables and moving to setters when it becomes necessary, if ever. Because usually it isn't necessary and more variables change in one operation (function) and it can't be just a setter anymore. No need to make things confusing. \$\endgroup\$
    – snake5
    Oct 16, 2012 at 14:22
  • \$\begingroup\$ snake5, Have you never heard of encapsulation and information hiding? \$\endgroup\$
    – Philipp
    Oct 16, 2012 at 14:27
  • \$\begingroup\$ Which should be avoided unless you actually gain something from it. \$\endgroup\$
    – API-Beast
    Oct 16, 2012 at 14:30
  • \$\begingroup\$ You gain from it in the long term due to higher code flexibility and maintainability. \$\endgroup\$
    – Philipp
    Oct 16, 2012 at 14:35
  • \$\begingroup\$ @Philipp I've heard of it. Used it. It's not useful unless proven otherwise. If you want flexibility, don't write code - algorithms are most flexible. If you want maintainability, write self-explanatory code. \$\endgroup\$
    – snake5
    Oct 16, 2012 at 14:49

You must log in to answer this question.

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