Engine Objects
Author
In my current version of my game engine: (C++ / DirectX)
I have:
CMapR - A Map Reader Class
CTerrain - A Class to store and manage terrain
CInput - ...
I have been wondering if there is any need to use these classes as objects. I doubt a game would ever need more than one Input Manager etc.
so the I could call functions by:
CMapR::OpenMapFile("data/mapfile);
Its because Ive been having trouble making my objects communicate, so I thought of this as a way out. I guess I only really made these classes objects before because that's what OOP ia all about!
What do you suggest I do?
You're delving into the realm of Singletons.
How about, just making one instance of each class? Then, if you ever need two terrain managers (and I can think of some scenarios), then there's no problems!
Edit: your != you're
[Edited by - _goat on May 13, 2007 9:16:02 AM]
How about, just making one instance of each class? Then, if you ever need two terrain managers (and I can think of some scenarios), then there's no problems!
Edit: your != you're
[Edited by - _goat on May 13, 2007 9:16:02 AM]
If object A must communicate with object B, then contact between object A and object B must be created by a third object, C. This can happen when either A or B is constructed (receiving a reference to the other in the constructor arguments) or when the relevant function of either object is called.
Ideally, object A should only know that "there are many B objects, one of which I will use", and the same for B. Knowledge such as "there is only one B object" usually leads to poor design.
Ideally, object A should only know that "there are many B objects, one of which I will use", and the same for B. Knowledge such as "there is only one B object" usually leads to poor design.
Typical situation: a player fires a gun. This creates a bullet, which must be rendered on the same screen as the player and must exist in the same world as the player. Therefore, the player provides the newly created bullet with its renderer and world.
Because the bullet was passed the correct world and renderer, it can use them to render itself and update itself when required.
void Player::Shoot(){ boost::shared_ptr<Bullet> bullet( new Bullet(this->world,this->renderer)); this->world.add(bullet);}Because the bullet was passed the correct world and renderer, it can use them to render itself and update itself when required.
Quote:You have lost me.
I think people have jumped on your back for these elements
Quote:I doubt a game would ever need more than one...CMapR::OpenMapFile("data/mapfile);...having trouble making my objects communicate
This seems to suggest you are talking about the singleton pattern ( a single global instance of an object). There is a real hatred for the pattern on these boards and they consider it an anti -pattern(do a search on here for singleton).
Personally I would say yes there will only ever be one input system which uses composition for the different types of input, keyboard, mouse, game pad, network... Just like there may only be one graphics system which also use composition for the amount of renderers types of renderer, methods output (ie debug renderer could also stream to file, add extra visuals etc etc).
Basically using the singleton pattern requires much thought before using it, will it always be one instance or could there be more, does it need to be global or are you making it this way to make it easier on you to get you objects to communicate. If the last is your reasoning, then take note of ToohrVyk's quote
Quote:Knowledge such as "there is only one B object" usually leads to poor design.
Most people will tell you not to use singletons, as you might need to create two instnces of your class one day. Considering this, you might be better off with a global variable which is an instance of CInput (e.g. "CInput g_InputManager;"). This global variable can be accessed from anywhere, which is what you want, but you can also create more instances if you ever need to.
This is correct if you are beginning, but consider using neither globals nor singletons. These kind of bad habits will lead you to code oblivion if you don't watch out.
This is correct if you are beginning, but consider using neither globals nor singletons. These kind of bad habits will lead you to code oblivion if you don't watch out.
Author
hmm global variables,
but would i not need to have separate globals for each source file in the implementation? And that would require special functions to ship pointers around to each file :)
Ive managed to make them communicate by commenting most of my game engine out and I'm now un-commenting each line and compiling then running to see when it occurs :)
but would i not need to have separate globals for each source file in the implementation? And that would require special functions to ship pointers around to each file :)
Ive managed to make them communicate by commenting most of my game engine out and I'm now un-commenting each line and compiling then running to see when it occurs :)
Quote:Original post by ganbree
I have been wondering if there is any need to use these classes as objects.
No, and I'll tell you why: because you haven't been doing object-oriented programming. Those things are "classes" in name only. You've designed them in terms of what they DO rather than what they ARE, and hence you've simply ended up with classic modular programming. Of course, there's no problem with not doing OOP. Just make all the variables and methods static if you like.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
