I've trying to figire out how to build relationship between World and Units inside this World. On one hand Unit souldn't know nothing about World, because World is high level object and I don't want to let Unit to call World's methods, but on the other hand Unit should somehow to know which enemy Units it sees. How to build this relationship between them correctly? Should Unit object contain link on World object? Or maybe theres some other workarouds for this?
Building game architecture
"How to build this relationship between them correctly?"
By using contracts. aka Interfaces.
A specific example:
A world may be a "level". It does not need to know how the world is built within, but it needs to know about its surroindings.
So I create a new interface called "IWorldInspector" (Roll with it, not the best name).
It has InspectCloseEnemies methods which gives nearby enemies.
Another one is NearestWall.
It may not suit all games but it's a specific example I've created to show the relation of an interface.
It needs part of the world and not the whole world as an instance.
Why can't the units know about the world...? To me, this sounds like needless encapsulation.
Try to think only about what will make your game easier to write, and not what is considered good practice by the OOP methodology. Those two often conflict.
If you let your units know about your world, it will be easy for you to implement any sort of behaviour where they can affect it.
If there is some methods in your world your units shouldn't call, simply don't call them :)
Try to think only about what will make your game easier to write, and not what is considered good practice by the OOP methodology. Those two often conflict.
If you let your units know about your world, it will be easy for you to implement any sort of behaviour where they can affect it.
If there is some methods in your world your units shouldn't call, simply don't call them :)
Try to think only about what will make your game easier to write, and not what is considered good practice by the OOP methodology. Those two often conflict.
at last, folks are getting a clue! big +1 on that!
Try to think only about what will make your game easier to write, and not what is considered good practice by the OOP methodology. Those two often conflict.
at last, folks are getting a clue! big +1 on that!
I'd say they only conflict if you are trying to use the wrong methodology, or you have some misconception about it...
For example, I don't see how anything in "OOP methodology" says that "Unit" absolutely can't know about "World".
I'm guessing the misconception here is that OOP says that everything should be hierarchically organised from "higher level" to "lower level".
That's just not true. Objects often need to know about each other, and be part of a family of siblings on the same level of abstraction.
I'm totally in favor of making your program easy to write, understand and modify though.
But that's where some methodology can help. Just make sure to use the right tool for the job...
And don't blindly follow patterns just because you read about it in some book or blog.
Maybe "World" is a bit too vague to be very useful as an abstraction, it will likely contain many subsystems, and "Unit" probably only need access to a few of these subsystems. Your code might be easier to reason about if you only give Unit access to these subsystems.
TL;DR: I think it's fine to let Unit know about World, but it can certainly be improved
Why can't the units know about the world...? To me, this sounds like needless encapsulation.
Try to think only about what will make your game easier to write, and not what is considered good practice by the OOP methodology. Those two often conflict.
If you let your units know about your world, it will be easy for you to implement any sort of behaviour where they can affect it.
If there is some methods in your world your units shouldn't call, simply don't call them :)
"Try to think only about what will make your game easier to write, and not what is considered good practice by the OOP methodology. Those two often conflict."
That's not completly true. (Show me examples how the conflict).
"Easier to write"- OOP makes your writing easier. That's the whole point.
If you write your relations like you want then you'd stick with a mush of code that nobody can either understand or maintain.
There are drawbacks like data alignment and data optimization, which isn't defined very well by OOP.
Interfaces are another matter because an interface does not specify data, it specifies behavior.
If you write and wire all your behavior properly, believe me it doesn't matter what data you use, it will all be easier.
I'd say they only conflict if you are trying to use the wrong methodologyThe entire point of "considered good practice by the OOP methodology" is that you limit yourself to the OOP methodology, and only the OOP methodology. As such "wrong methodology" ceases to exist, as there is only one.
Given there is enough proof that OOP methodology is not the silver bullet for everything, I'd agree it's conflicting.
Objects often need to know about each other, and be part of a family of siblings on the same level of abstraction.
don't blindly follow patterns just because you read about it in some book or blog.
repeated for emphasis
+1 that.
listen to the man, he knows of what he speaks.
Given there is enough proof that OOP methodology is not the silver bullet for everything, I'd agree it's conflicting.
and +1 that too.
I'm assuming that the OP is building is first (or even second) game. So some structure isn't a bad idea. And it's easy to say, "don't blindly follow patterns" when you have some idea of why, where, and when to use those patterns. But if you don't know, then blind is what you'll be until you find or see the light.
With all that said, if you're going to use OOP, try to use more composition than inheritance. Inheritance can make your code too tightly coupled and therefore brittle. IOW, you change one class and 10 other classes break unexpectedly.
As far as Unit to World visibility. I would think the World would know where all Units are and the Units would know where in the World they are. The World should at least have public methods for location, topography, and geography. So the Units can know where they are and what's around them.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
