Jump to content
  • Advertisement
Sign in to follow this  
Volte6

Children Accessing Parents?

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

Hi, bear with my while I explain my problem... I have a SpriteList class, containing Sprites. I have a function that allows for Collision tests between SpriteLists's. When two Sprites in any SpriteList's collide, they set their status isDying to true. The SpriteList then removes them from it's linked list. However, I want it to then add an explosion or something ( If a ship explodes ) to the Explosion SpriteList. But it's looping through all the colliding sprites still... How can I do this: ( PSEUDO CODE MOSTLY ) Example: SpriteList1 Sprite1 Sprite2 Sprite3 Sprite4 SpriteList2 Sprite5 Sprite6 Sprite7 Sprite8 SpriteList2.testCollide() { for (sprite 5 to sprite 8) if ( Sprite5.hits( Sprite6 ) ) { if ( Sprite5.explodes == true ) { // Attach an explosion to the explosion sprite list. } remove( Sprite5 ); } } So how do I know to do this? SpriteList2 doesn't know about SpriteList1. In fact, the plan is to ultimately wrap the sprite lists in another manager that would tell each sprite list what to spawn when needed, which means SpriteList2 would have to be able to tell the SpriteListMgr to place an explosion on each collision, and SpriteListMgr would tell SpriteList1 to do it. But children can't access their parents as far as I can tell... Does that make sense?

Share this post


Link to post
Share on other sites
Advertisement
Firstly, I'm assuming you're using C++. The easiest way as I see it is to have a static SpriteList pointer in the SpriteList class which points to the Explosion list, so you could access it from any class. If you end up having a manager, that manager should be a singleton so you can always get a pointer to it, and query it for the explosion list.

Hope that helps.

Tom

Share this post


Link to post
Share on other sites
Yes c++, sorry.

But, I can't pass a pointer to the SpriteListMgr to a SpriteList. The SpriteList is declared before the Manager, so I would get an error saying something like "invalid type".

A singleton... I read a little on this before but couldn't get a clear 'usable' definition... Isn't this just a single access point for data I would request regularly?

Share this post


Link to post
Share on other sites
The problem is solved if you take the collision code out of the SpriteList class. The code might look something like this. Note that this one way and not necessarily the best way. Look up "double-dispatch"
SpriteList objects;
SpriteList explosions;
...
TestCollisionsBetweenObjects()
{
for ( i = 0; i < objects.size(); ++i )
{
for ( j = i+1; j < objects.size(); ++j )
{
if ( Collide( objects, objects[j] ) )
{
explosions.push_back( new Explosion(...) );
objects.Die();
objects[j].Die();
}
}
}
}

Share this post


Link to post
Share on other sites
Yes, that may be the best solution. I will work on that, thanks.

And just so ease my troubled mind... there really ISN'T a way for a child to access the parent, correct?

How is it possible in other languages? Is there some smoke and mirrors thing going on that we don't see?

Share this post


Link to post
Share on other sites
Quote:
Original post by Volte6
And just so ease my troubled mind... there really ISN'T a way for a child to access the parent, correct?

How is it possible in other languages? Is there some smoke and mirrors thing going on that we don't see?


Of course a child can access its parent, but except for a few cases, it indicates that something is wrong with the design. (Note: "parent" and "child" are not really the right nomenclature for this relationship).

For example:
class Factory;

class Widget
{
public:
Widget( Factory & factory) : m_factory( factory ) { ... }
private:
Factory & m_factory;
};

class Factory
{
public:
Widget * CreateWidget()
{
Widget * pWidget = new Widget( *this );
widgets.push_back( pWidget );
return pWidget;
}
};

Share this post


Link to post
Share on other sites
Okay thanks. I was convinced it couldn't be done...

I've been declaring everything together, so that's probably a big design issue ( I have one .cpp file and a ton of .h's for everythign else ).

Can you explain why accessing the parent is a design issue? Just for my education.

Share this post


Link to post
Share on other sites
Quote:
Original post by Volte6
Can you explain why accessing the parent is a design issue? Just for my education.


It creates a circular dependency -- the parent class depends on the child class (which is normal), but the child class also depends on the parent class. The relationship is no longer really parent/child, master/slave, server/client, etc.

Share this post


Link to post
Share on other sites
You're treating a sprite as a game object. A sprite should only have the responsibility of loading itself, possibly modifying itself and rendering itself. Ideally, you're video should be seperated from your game logic.

Think of it as two seperate systems with a manager that runs each system. First system controls the physics of all objects. The second controls the video. For your purposes, the video system allows you to instantiate a sprite and perhaps return a handle to it so you can later access it. These sprites may have multiple frames for animation.

The manager calls all objects in the physics system, updating their locations. Then, the new locations are read by the manager and the video system is called to update their sprites using their "handles". When an explosion is caused, you can trigger an event that tells the manager to instantiate an explosion sprite. The video system can then display the sprite each frame until the animation ends.

Just one way out of a billion ways to do it. Usually, it's best to give each object only the responsibility that it absolutely needs. Hope this helps. ;-)

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!