OOP is just another part of the picture, not all of it. Sometimes things are easier and better done procedurally. Nothing wrong with that.
For example, in my engine I have this one sort of `node` type, of which there can be many, which contains multiple `extensions` (custom types). Each sub type then contains usually either other sub types or arrays of data. For example, for sprites/particles I have parallel arrays of data, like an array of X coords, an array of Y coords, etc, rather than like one whole new type for each particle with an isolated single set of data. Putting all of the data inside the enclosed world of a custom type for every single object isn't necessarily efficient. It's handy for creating and removing items, but it can decrease performance. I try to opt for a blend of oop and procedural, plus a blend of linked list-style object storage and array-based.
You need to look at what vision you have for your game or games, and then what subsystems it's going to need. OOP is really, in a way, just about fragmenting stuff, separating things out, and keeping all stuff relating to the same topic or area in one place. One place for all your graphics stuff, one place for all your sound stuff, etc. The idea is to think of your game/engine as a collection of `objects`, or to map objects/types to areas/concepts in your game. Supposedly that's what oop is good for, organizing stuff, creating a structure, laying things out, grouping things together, keeping stuff that has nothing to do with graphics away from the graphics code, etc. That way you get a cleaner application, you can easily change one area without affecting all the other areas, instead of having stuff strewn all throughout the whole thing.
With procedural coding, and especially if you tend to hard-code stuff, you could essentially have your graphics and audio and physics and AI code all sort of blended in together in various places throughout your code. Then it's hard to manage it, hard to modify it, hard to find it, etc. It's too specific. Using `objects` (type) is an attempt to get a little bit more abstract, group things under a generic `type` of object or data. Instead of having one big hardcoded ultra-procedural mishmash of hacked together solution-specific code, you can make things easier to manage and modify and keep track of by getting it much more organized. Even if you end up doing lots of procedural stuff within the various custom types, that's fine, but at least a little use of types will help you out.
One thing I found before I used types, was that I would end up with a pretty big program, maybe a lot of functions, not very much structure or order, and I just couldn't SEE. It's like being in the middle of a dense forest of trees where you can only see the trees all around you and no clearings, no paths, no organization, no standardised protocols for accessing information, and it's all very locked-in and hard to expand or add to. It can be quite confining. Oop is more abstract and open and generalizing and standardizing, which helps for the most part, up to a point. Once I started to group things together and keep them away from other unrelated parts, I found it much easier and more freeing to be able to see how to expand and add stuff.
|
