5 ms·

Unfortunately for the OP, when it comes to game development, it's widely understood that OOP only ends up painting the developer in a corner eventually. Yes usi

Unfortunately for the OP, when it comes to game development, it's widely understood that OOP only ends up painting the developer in a corner eventually. Yes using Objects, Inheritance, and Polymorphism works well for a long time, but the more objects and deeper the inheritance tree grows, the more inflexible the system becomes. You also run into problems with reality. When the code hot path calls across multiple object types and a invokes a bunch of polymorphism every frame, the code is going to be slow and there's no obvious bottleneck. The code is slow because the CPU is constantly waiting for its cpu and data cache to catch up. Game development today is moving quickly towards components, composition over inheritance, and Data Driven Design techniques. Check out the myriad of posts on Entity/Component systems that have sprung up over the past 10 years. It can be harder to grasp at first but has huge wins over the traditional OOP model.

adnzzzzZ 12y ago
This "huge win" depends heavily on what you're making. If you're making simple games where performance is not that much of a problem (like most indie games) then moving to entity/component systems makes no sense and tends to make everything more complex than it needs to be. A good middle ground in those cases is to just stick with normal OOP with shallow trees (no more than 2-3 levels) and favor simpler types of composition like mixins whenever needed.
- rrradical 12y ago
  As someone who has made indie games with both traditional OOP and component systems-- I vastly prefer component systems. I disagree that they make things more complex. I found that they made things much simpler. Although, it does require learning about and possibly developing a component system. If you are talking about very very simple games, it would perhaps not be worth the effort, but at that level basically any architecture will work.
  - seanmcdirmid 12y ago
    Entity component systems are just another form of OO that rely heavily on ontology and named object instances. Unless you mean OOP must be Java, then of course, it's not.
- yoklov 12y ago
  Even indie games can benefit a lot from components, and a basic component-entity system is very easy to implement. Make component and entity classes, give the entities a list of components, put the update method in the component, and put most of your code there. This is fairly different from the most popular/performant ways of implementing ECS's (there are no "Systems"), but keeps a lot of the benefits (much more flexible than traditional class hierarchies, easier to develop and design content for without writing new code, etc), while avoiding a lot of the complexity which makes component systems overkill for smaller games. You lose a bit of performance (compared to other methods of implementing component systems), but in higher level languages this will likely be faster than trying to imitate C++ patterns (I could say more about this, as I've seen some travesties, but I won't).
  - adnzzzzZ 12y ago
    For a higher level language (I use Lua) I prefer a more loose type of system where I skip the part of creating components and putting them in a list and just inject methods/attributes to my objects directly in the form of mixins. At this point I wouldn't say that this is an ECS, it's just normal OOP favoring composition wherever it makes sense. From what I've seen though most people do tend to go for the system type of ECS and that's what I was referring to when I said that it makes things more complicated than they need to be.
angersock 12y ago
I don't know...the Gold Source engine and Half-Life 1 were heavily OOP, and they did just fine, even with some mods placing dozens of fully AI enemies onscreen at once. In some parts--like rendering--OOP is pretty terrible. Outside of that, though, it's not inherently bad.
munificent 12y ago
You're making a false equivalence here. Yes, the game industry is moving away from inheritance and for the reasons you note and others. That doesn't at all mean the game industry is moving away from OOP. Classes and methods still abound and work perfectly fine. Even if you go whole-hog towards ECS, the stuff you're passing around is usually still an instance of some class and not a bare public struct. Encapsulating data and providing higher-level methods to operate on it works really well. Polymorphism is also powerful and useful in many places. Even subclassing is a good fit for some things. But just realizing that you need to dial back on subclassing doesn't imply that the first one or two things on my list are broken.

adnzzzzZ 12y ago

This "huge win" depends heavily on what you're making. If you're making simple games where performance is not that much of a problem (like most indie games) then moving to entity/component systems makes no sense and tends to make everything more complex than it needs to be. A good middle ground in those cases is to just stick with normal OOP with shallow trees (no more than 2-3 levels) and favor simpler types of composition like mixins whenever needed.

rrradical 12y ago
As someone who has made indie games with both traditional OOP and component systems-- I vastly prefer component systems. I disagree that they make things more complex. I found that they made things much simpler. Although, it does require learning about and possibly developing a component system. If you are talking about very very simple games, it would perhaps not be worth the effort, but at that level basically any architecture will work.
- seanmcdirmid 12y ago
  Entity component systems are just another form of OO that rely heavily on ontology and named object instances. Unless you mean OOP must be Java, then of course, it's not.
yoklov 12y ago
Even indie games can benefit a lot from components, and a basic component-entity system is very easy to implement. Make component and entity classes, give the entities a list of components, put the update method in the component, and put most of your code there. This is fairly different from the most popular/performant ways of implementing ECS's (there are no "Systems"), but keeps a lot of the benefits (much more flexible than traditional class hierarchies, easier to develop and design content for without writing new code, etc), while avoiding a lot of the complexity which makes component systems overkill for smaller games. You lose a bit of performance (compared to other methods of implementing component systems), but in higher level languages this will likely be faster than trying to imitate C++ patterns (I could say more about this, as I've seen some travesties, but I won't).
- adnzzzzZ 12y ago
  For a higher level language (I use Lua) I prefer a more loose type of system where I skip the part of creating components and putting them in a list and just inject methods/attributes to my objects directly in the form of mixins. At this point I wouldn't say that this is an ECS, it's just normal OOP favoring composition wherever it makes sense. From what I've seen though most people do tend to go for the system type of ECS and that's what I was referring to when I said that it makes things more complicated than they need to be.

angersock 12y ago

I don't know...the Gold Source engine and Half-Life 1 were heavily OOP, and they did just fine, even with some mods placing dozens of fully AI enemies onscreen at once. In some parts--like rendering--OOP is pretty terrible. Outside of that, though, it's not inherently bad.

munificent 12y ago

You're making a false equivalence here. Yes, the game industry is moving away from inheritance and for the reasons you note and others. That doesn't at all mean the game industry is moving away from OOP. Classes and methods still abound and work perfectly fine. Even if you go whole-hog towards ECS, the stuff you're passing around is usually still an instance of some class and not a bare public struct. Encapsulating data and providing higher-level methods to operate on it works really well. Polymorphism is also powerful and useful in many places. Even subclassing is a good fit for some things. But just realizing that you need to dial back on subclassing doesn't imply that the first one or two things on my list are broken.