I hope these ramblings will make my question clear — I'd totally understand if they wont, though, so let me know if that's the case, and I'll try making myself clearer.
Meet BoxPong, a very simple game I made to get acquainted with object-oriented game development. Drag the box to control the ball and collect yellow things.
Making BoxPong helped me formulate, among other things, a fundamental question: how can I have objects that interact with each other without having to "belong" to each other? In other words, is there a way for objects to not be hierarchical, but instead coexist? (I'll go into further detail below.)
I suspect the problem of objects coexisting is a common one, so I hope there's an established way to solve it. I don't want to reinvent the square wheel, so I guess the ideal answer I'm looking for is "here's a design pattern that's commonly used to solve your kind of problem."
Especially in simple games like BoxPong, it's clear that there are, or should be, a handful of objects coexisting on the same level. There's a box, there's a ball, there's a collectible. All I can express in object-oriented languages, though — or so it seems — are strict HAS-A relationships. That's done through member variables. I can't just start off the
ball and let it do its thing, I need it to permanently belong to another object. I've set it up so that the main game object has a box, and the box in turn has a ball, and has a score counter. Each object also has an
update() method, which calculates position, direction etc., and I go a similar way there: I call the main game object's update method, which calls the update methods of all its children, and they in turn call the update methods of all their children. This is the only way I can see to make an object-oriented game, but I feel it's not the ideal way. After all, I wouldn't exactly think of the ball as belonging to the box, but rather as being on the same level and interacting with it. I suppose that can be achieved by turning all game objects into member variables of the main game object, but I don't see that solving anything. I mean... leaving aside the obvious clutter, how would there be a way for the ball and the box to know each other, that is, to interact?
There's also the issue of objects needing to pass information between each other. I have quite a bit of experience writing code for the SNES, where you have access to practically the entire RAM all the time. Say you're making a custom enemy for Super Mario World, and you want it to remove all of Mario's coins, then just store zero to address $0DBF, no problem. There's no limitations saying enemies can't access the player's status. I guess I've been spoiled by this freedom, because with C++ and the like I often find myself wondering how to make a value accessible to some other objects (or even global).
Using the example of BoxPong, what if I wanted the ball to bounce off the edges of the screen?
height are properties of the
Game class, and I would need the
ball to have access to them. I could pass these kinds of values on (either through constructors or the methods where they're needed), but that just screams bad practice to me.
I guess my main problem is that I need objects to know each other, but the only way I can see to do that is strict hierarchy, which is ugly and impractical.
I've heard of "friend classes" on C++ and kinda know how they work, but if they're the end-all solution, then how come I don't see
friend keywords poured all over every single C++ project, and how come the concept doesn't exist in every OOP language? (The same goes for function pointers, which I've just recently learned of.)
Thanks in advance for answers of any kind — and again, if there's a part that doesn't make sense to you, do let me know.