You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is another feature I felt the need while experimenting with the coming AOS Web Player demo:
.7. Multiple Lecture Threads
The general idea is to allow several, maybe unrelated, parts of the story graph to be read in parallel.
For example:
-> X -> Y ->Z (this one is looping from Z to X)
^____/
-> A -> B -> C -> D -> E -> F -> G -> H -> I -> J
Here the story starts with two beginning stages: A and X. Each "next" move will move both threads in parallel, resuling in this sequence of stages:
A , X => B , Y => C , Z => D , X => E, Y => F, Z => G, X => etc.
The typical usage of such feature would be to have a background loop sequence and front non-loop action.
For example, imagine X Y and Y being stages showing the same background but with some changes like rain drops.
Allowing this feature would help telling a story with recurring parts of sequences in parallel.
The need came when trying to write such a sequence: with AOSL 1.1 we have to copy the X->Y->Z moves "by hand" in the main A->...->J sequence.
This is very problematic, in particular when you want to make modifications to the number of stages in the main sequence.
This feature would be cut in several parts:
a. allow the "begin" attribute of a to start with several stages.
b. allow a move to target several stages (the "to" attribute is currently limited to only one target).
c. add a way to express a "end of story" stage for the player to end any other thread when this expression is met.
The need for c is apparent in the example I gave: here we have the X->Y->Z part that is looping with no end condition,
so a player would not end the sequence when J is met but would continue to allow a "next" move with no limit.
This can be good for some interesting storytelling experiments, but in the same time most use would end at J.
To fix this the immediate thinking would be to have some scripted condition in J and X/Y/Z to make these last stages move to another "end" stage that would have no other move.
But that is a bit boilerplate to express a simple thing: "stop reading here".
The text was updated successfully, but these errors were encountered:
From https://groups.google.com/forum/?fromgroups=#!topic/aos-dev/GGKnRA95Ah0
Here is another feature I felt the need while experimenting with the coming AOS Web Player demo:
.7. Multiple Lecture Threads
The general idea is to allow several, maybe unrelated, parts of the story graph to be read in parallel.
For example:
Here the story starts with two beginning stages: A and X. Each "next" move will move both threads in parallel, resuling in this sequence of stages:
A , X => B , Y => C , Z => D , X => E, Y => F, Z => G, X => etc.
The typical usage of such feature would be to have a background loop sequence and front non-loop action.
For example, imagine X Y and Y being stages showing the same background but with some changes like rain drops.
Allowing this feature would help telling a story with recurring parts of sequences in parallel.
The need came when trying to write such a sequence: with AOSL 1.1 we have to copy the X->Y->Z moves "by hand" in the main A->...->J sequence.
This is very problematic, in particular when you want to make modifications to the number of stages in the main sequence.
This feature would be cut in several parts:
a. allow the "begin" attribute of a to start with several stages.
b. allow a move to target several stages (the "to" attribute is currently limited to only one target).
c. add a way to express a "end of story" stage for the player to end any other thread when this expression is met.
The need for c is apparent in the example I gave: here we have the X->Y->Z part that is looping with no end condition,
so a player would not end the sequence when J is met but would continue to allow a "next" move with no limit.
This can be good for some interesting storytelling experiments, but in the same time most use would end at J.
To fix this the immediate thinking would be to have some scripted condition in J and X/Y/Z to make these last stages move to another "end" stage that would have no other move.
But that is a bit boilerplate to express a simple thing: "stop reading here".
The text was updated successfully, but these errors were encountered: