Children Accessing Parents?
Author
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?
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
Hope that helps.
Tom
Author
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?
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?
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(); } } }}
Author
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?
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?
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; }};
Author
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.
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.
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.
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. ;-)
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. ;-)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
