On Sat, Nov 2, 2013 at 12:01 PM, Daniel Gillet <[email protected]>wrote:

> Hi Claudio,
>
> Thanks for the suggestion.
>
> It somehow feels *wrong* to me. Not that it wouldn't work. But it's not
> very scalable. My example is obviously a bit contrived. But imagine you
> want to script a scenary. There might be something like 5 different actors
> in play, all doing things in a pre-determined sequence. It feels kind of
> odd to add a Delay action to wait for another actor (cocosnode) to finish
> its action. Besides, talking about scalability, what if all of a sudden,
> there is an action which speeds up a previous action. The Delay won't be
> synchronized anymore.
>
>
It was the simplest solution to your example.
Exact details of how to scale up as usual depends on details, like
 - how many actors can interact
 - how complex the actions
 - how the decision to trigger some action is taken
 -  etc

Related with what you suggested in first post, publishing some 'end of
action' event can help with decoupling and spare some code.

But I would not publish all end of actions.

In your example, a possibility is to code a Say action that
  - receives a message, a duration and an optional dest
  - handles the display of message, with specified duration
  - at end of duration it publish the event (target, 'say', msg', dest=dest)
  - the publish subsystem let know dest ,if specified, or all the
interested and allowed listeners to get the event

The listeners, like sprite2, decide if they should react, which may lead to
sprite2 publish a response,...

If sprite1 is listening to 2, it may then decide to walk to the bottom
right corner.

This is a distributed interactions design.

Another approach, more centralized, would be:

A (global) Sequencer object is responsabile to trigger actions
Interesting actions have an ID
After ending an interesting action, Sequencer is notified that an action
with the specific ID has ended.
When Sequencer receives such notification, it consults it internal state to
see if any other action needs to be triggered

A combo of both approaches can also be handy:
    - Sequencer follows a script to spawn actors and program them with
initial behavior
    - After spawn, actors does mostly distributed interactions
    - but maybe some special events needs to reach Sequencer ('Castle of
Zombies destroyed'  -> not more zombie spawn + spawn BossEnemy)

Helper actions like
    Publish( ... )
    NotifySequencer( ... )
can help to recycle stock actions into interesting actions, like in
    ( MoveTo(bottom_right_corner, 5) +
      Publish('in_bottom_right_corner')
    )



> I was looking at the Sequence_IntervalAction and was thinking about how
> the actions get sequenced. What if now the layer or the scene containing
> the different actors had an action which allowed to sequence actions with
> different targets. Let's call this Sequence_Targets_IntervalAction You
> could then write something like:
>
> actions_sequence = [ MoveTo(sp2.position, 5) + Say("Where should I go ?",
> 3),
>                     Say("Go to the bottom right corner", 3),
>                     MoveTo(right_corner, 5)
>                    ]
> scene.do(Sequence_Targets_IntervalAction(actions_sequence), target=(sp1,
> sp2, sp1))
>
> This action would take each action in the actions_sequence and assign the
> corresponding targer to it. It would wait for the first action to complete
> before moving on the next one.
> It's just a thought. It might break other things. Obviously
> Sequence_Targets_IntervalAction must have the same length of actions as
> target.
>
>
This look as something related to the Sequencer I talked above.
But I don't see the need that Sequencer be an action, that only impose hard
restrictions.

It is an object doing things with actions, thats all.




> Your thoughts?
> Am I doing this too complicated?
>
> Thanks for your help!
> Daniel.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"cocos2d discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/cocos-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to