Q about Trigger System

Started by
6 comments, last by leiavoia 17 years, 12 months ago
This is concerning C++ btw H'okay, a while ago I posted about making scripted menus. Well, I've accomplished that bit, happy to say, along with the automatic image handler ^_^ Next step is to make the menus actually do something! My idea was this: Basically, each menu item (a class) will have a queue of triggers, which activate sequentially when "Action key" is pressed and the selectable menu item is selected. So then, I think I need 2 kinds of classes for the triggers 0.0 One which is the base of all triggers and is subclassed to make different trigger actions, and another which is a member of those classes, and is used in the queue list, which gains access to members of its parent class. I've heard that this is possible, but I don't actually know how lol. How can members of class know about their parent? I need help with that. [Edited by - AAAP on April 22, 2006 4:59:39 PM]
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
Advertisement
Well, you could always pass in a pointer to the parent when constructing the object. It's not ideal.

You could also consider just using some sort of message-passing system and avoiding direct references altogether.
Children are not suppose to know about thier parents. I would suggest you look at your design and figure out why you need to have a child know about it's parent.

theTroll
The Command Pattern would be very usefull for this.
Quote:Original post by TheTroll
Children are not suppose to know about thier parents. I would suggest you look at your design and figure out why you need to have a child know about it's parent.

theTroll


It's not in my design yet, I don't know how I'm going to do this, it was an idea...
So that can have queue of Class B which is a member of every subclass of Class A, so that, through class B you have access to the different varieties of Class A in a single queue.
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
UPDATE:

Heh, I've gone with the command pattern and have a largely operational system now. Only problem is, my commands allhave to have the same arguments.

That's not very useful to me. This is the solutions i came up with:

-Use type unsafe varargs (if thats even possible with function pointers?)

-Make prototypes of execute function with different varieties of arguments (Tried this but it didn't seem to work !? I thought it was a good bet)

short of this, I'm at a loss. But I'm sure it's doable... Blar.
|aaap.penopticon.com| My website, including game projects. Collaboration/comments are welcome, please visit :)
You can always have an 'untyped' argument, i.e. object in C#/Java, or I guess void* in C++. As long as the handler can tell what type of message it is dealing with (and therefore what type the argument is) it isn't unsafe.
The point of the command pattern is to not have parameters (or at least, very few). The Command object should store all the info it needs to execute the command on it's own. If you go with parameterized wotsits, just use a function pointer or functor. Of course, with that mentality you are slowly slipping back to where you started.

So when you create a Command object, you need to "preload" it with any information it needs to execute() it's command, including pointers to any objects it needs to communicate with or get data from. Only the execute() function needs to have the same interface as the other Command classes. But the constructor can look like whatever you want, like:

Command* fire = new CommandFireGun(player, gun, bullet_type, whatever);while (gameloop) {   if (keypressed == ENTER) {      fire->execute();      }   }

This topic is closed to new replies.

Advertisement