• Advertisement
Sign in to follow this  

Building game architecture

This topic is 544 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement

"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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites

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! 

Share this post


Link to post
Share on other sites

 

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

Edited by Olof Hedman

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

I'd say they only conflict if you are trying to use the wrong methodology
The 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement