• Advertisement
Sign in to follow this  

Children Accessing Parents?

This topic is 4726 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
Yeah i'm trying to restructure things to be much more managed... essentially every class has a class that manages it.

Game->Video
Game->SpriteListManager->SpriteList->Sprite

The thing is, my code starts falling apart when I have too many layers of parents->children... I always end up witha child wanting to access something it really doesn't have access to... because it's 3 tiers back and one over in the hierarchy or something.

Share this post


Link to post
Share on other sites
Quote:
Original post by Volte6
The thing is, my code starts falling apart when I have too many layers of parents->children... I always end up witha child wanting to access something it really doesn't have access to... because it's 3 tiers back and one over in the hierarchy or something.


Well a derived class should be able to access it's parent, and if you need it to access something it's not linked to then have the methods take a reference to that something. There is no need for a singleton.


class CA
{
public:
int i;
};

class CB
{
public:
void Modify(CA& object, int n)
{
object.i = n;
}
};

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
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.


It's true, folks, programmers are naturally kinky SOBs ;) (heck... I expected this to be about base and derived classes, and keyword 'protected'... which leads to a whole other set of innuendo... but I think I won't get into that :) )

Share this post


Link to post
Share on other sites
I think he's basically sayings that while a child can access the parent, at the time it does so it no longer is a full child. I have a couple horrible analogies, but I'll go with a decent one of "employer"/"butler" If an employer needs something small he requests it from the butler, but a butler doesn't go to the employer when he needs to do something.

That's not to say Circular dependancies are bad, but when two classes call each others functions it's not really a child and parent, it's more of a equal system. This is not a bad thing. On my program I thought I'd have the great lords of my game, four thread classes, (networking, engine, Gamelogic, and Rendering/IO) with engine as the lord of all. Well now I also have the possibility of Audio as a thread class, Engine needs input from all the classes, (especially to quit) and the graphics module has it's two children upgraded to equals, who then access just about everything. So it's not something to worry about.

As someone meantioned the solution to the problem is probably

class A;

class B{
public:
A Imok;
};

class A{
public:
B Imoktoo;
};


While this looks like a redefinition, it's more along the lines of defineing the interface (is that the correct word?) for a class in the Header of a file, then defining the actual functions in a .cpp file.

Of course when your using this methods, pointers are almost essential for both.


class A;

class B{
public:
A *Imok;
};

class A{
public:
B *Imoktoo;
};

Share this post


Link to post
Share on other sites
Me again!

Okay, couple thangs:

1.) Why would pointers be essential?
[EDIT: I just realized. n/m on this one]

2.) I tried this... it worked until I tried to access a method of the parent... IE:

// child.h

class Parent;

class Child
{
Parent *parent;
Child(Parent *pParent)
{
parent = pParent;
}

void commandParent()
{
parent->grumble();
}
};

// parent.h
class Parent
{
Child *pLeech;
Parent()
{
pLeech = new Child(this);
}
};


This invariably gives me something like:
error C2027: use of undefined type 'Parent'

[Edited by - Volte6 on March 15, 2005 12:25:39 PM]

Share this post


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

  • Advertisement