Data-oriented design in practice?

Question

There has been one more question on what data-oriented design is, and there\'s one article which is often referred to (and I\'ve read it like 5 or 6 times already). I understand

Answer 1

I read the question you linked to and the article.

I've read one book on the subject of data driven design.

I'm pretty much in the same boat as you.

The way I understand Noel's article is that you design your game in the typical object oriented way. You have classes and methods that work on the classes.

After you've done your design, you ask yourself the following question:

How can I arrange all of the data I've designed in one huge blob?

Think of it in terms of writing your entire design as one functional method, with lots of subordinate methods. It reminds me of the massive 500,000 line Cobol programs of my youth.

Now, you probably won't write the entire game as one huge functional method. Really, in the article, Noel is talking about the rendering portion of a game. Think of it as a game engine (the one huge functional method) and the code to drive the game engine (the OOP code).

What I'm especially interested in is the mantra "where there's one there are many", which I can't really seem to connect with the rest here. Yes, there are always more than one enemy, yet, you still need to update each enemy individually, cause they're not moving the same way now are they?

You're thinking in terms of objects. Try thinking in terms of functionality.

Each enemy update is an iteration of a loop.

What's important is that the enemy data is structured to be in one memory location, rather than spread across enemy object instantiations.