This is the kind of topic I enjoy reading other developers’ responses to. Myself, I tend to use a “procedural programming” approach to the majority of code-design, including in video games.
For a start, Panda3D is not particularly opinionated on what paradigm you choose, though the C++ layer is OOPish as far as I understand it. You can write procedural, OOP, or even, I imagine, Data Oriented Design style. From what I’ve read about Data Oriented Design, it attempts to minimize sources of latency like cache misses by structuring data to flow in the fastest practical way.
When writing shaders, we can execute graphics programs at a low level using GLSL (and soon enough, HLSL once the shaderpipeline branch is merged) . There is a lot which is possible in this domain, and I find the C-like lack of classes in shaders to be a benefit to structuring data in the fastest way. Personally, I fail to see the purpose of classes for many projects, especially the projects small enough to be written by a single dev as are many Panda3D programs.
And to take this a bit further, I believe that the overuse or misuse of classes often increases conceptual complexity overmuch. There has been some talk as of late to even rewrite some introductory Panda3D sample programs to eliminate the class inheritance of ShowBase convention and (return to) writing such minimal examples at “base scope” or function definition scope.
IE
from direct.showbase.ShowBase import ShowBase
base = ShowBase()
base.run()
versus
from direct.showbase.ShowBase import ShowBase
class MyApp(ShowBase):
def __init__(self):
ShowBase.__init__(self)
app = MyApp()
app.run()
The former example program is clearly better, I believe. In terms of writing the fastest code, this is often a matter of the specifics of what you are implementing – though the fundamentals of algorithmic complexity, sorting, seek time, etc will of course still come into play even in the cleverest of organizational paradigms because of physics and how processors work. If you really want bare metal performance you’ll be writing at a lower level than would be comfortable for most designers. However, I’d be happy to read anybody else’s example code which illustrates Data Oriented Design. If we had a sufficient example, I might like to rewrite it in another paradigm and then compare the programs.