Jump to content
  • Advertisement
Sign in to follow this  
ganbree

Engine Objects

This topic is 4225 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

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?

Share this post


Link to post
Share on other sites
Advertisement
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]

Share this post


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

Share this post


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


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.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!