AOSL Feedback

[Ariel Ouziel]

Hello,

Just a few words to introduce myself as it is the first time I'm post on the mailing list :) And sorry for my English, I'm not a native speaker.

So I'm working on a project of web service that would host independent comics. It would allow authors to publish their work and distribute it for the price they choose (or for free) and  readers to browse the catalog and read comics via download or streaming on various platforms (pc, tablet, smartphone).

Therefore, I have a great interest in AOS project, and I'm planning to contribute to the project and maybe use it for my own project.

I've started to work on AOS Language and have then a few remarks:

- First of all, it would be really great to have a complex example of AOSL file on the wiki to really understand what's the rationale behind all the elements. I had some troubles figuring out how the various elements were used.

- If I understand correctly, a sequence is defined by its original state, a list of stages and a list of transitions describing the changes to perform between 2 stages. I think this may not be the best way to define the sequence. Indeed, it'll bring a few problems like:

• In order to get the sequence state at a certain time, one will have to start from initial state and execute all the transitions to get the current state. I think this is not very convenient.
  
• Those states won't be clearly visible in the file, thus they will be hard to read and modify.
• Every time one will want to create a new stage, one would have to describe every possible transitions from other stages (like disabling this or that object, activating another, etc.). This will lead to combinatorial complexity for adding new scenes and will limit the author freedom.

I think that a best way of describing a sequence would be to describe "key stages" (like key frames) wherein each object and its position is described. Transitions would be used optionally only when animation is needed between 2 stages.

For animating objects (or I would say "actor" like in 3D frameworks) within a stage, I think we should use "actions" directly attached to each actor. Actions could be "rotate" or "scale" or
"move", etc. It would be more natural than a list of transitions described externally of each actors...

I've been doing some experiments not using yet AOSL but my own object model, and I've come to something like that:

<?xml version="1.0" encoding="ASCII"?>
<sequence:Sequence xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sequence="http://sequence/1.0" title="SequenceExample">
  <resources path="D:\Work\projects\AOSL\assets\girl.png"/>
  <resources path="D:\Work\projects\AOSL\assets\guy.png"/>
  <stages width="800" height="600" name="GuyAndGirl">
    <actors xsi:type="sequence:SeqImage" x="31" y="214" width="300" height="300" source="//@resources.0">
      <actions xsi:type="sequence:MoveTo" startAt="1.0" x="10.0" y="10.0" duration="2.0"/>
    </actors>
    <actors xsi:type="sequence:SeqImage" x="475" y="208" width="300" height="300" source="//@resources.1">
      <actions xsi:type="sequence:MoveTo" startAt="2.0" x="12.0" y="15.0" duration="3.0"/>
    </actors>
  </stages>
  <stages width="800" height="600" name="GuyAndGirl2">
    <actors xsi:type="sequence:SeqImage" x="99" y="114" width="300" height="300" source="//@resources.0">
      <actions xsi:type="sequence:MoveTo" startAt="2.0" x="3.0" y="4.0" duration="1.0"/>
      <actions xsi:type="sequence:MoveTo" startAt="2.0" x="3.0" y="4.0" duration="1.0"/>
    </actors>
    <actors xsi:type="sequence:SeqImage" x="449" y="142" width="300" height="300" source="//@resources.1">
      <actions xsi:type="sequence:RotateBy" startAt="8.0" angle="20.0" duration="2.0"/>
      <actions xsi:type="sequence:MoveTo" startAt="4.0" x="5.0" y="6.0" duration="2.0"/>
      <actions xsi:type="sequence:ScaleTo" startAt="4.0" scaleX="2.0" scaleY="3.0" duration="1.0"/>
    </actors>
  </stages>
</sequence:Sequence>

Here you see that each stage define its set of actors and actions directly attached to them. Each stage is then clearly define and independent from other stages. I still have to think about the transitions between stages.

Anyway, here is a first status about my work. Tell me what you think.

Regards,
Ariel

[Klaim - Joël Lamotte]

Hi Ariel and welcome :)

Thank for your feedback, it's much apreciated.

On Mon, Feb 20, 2012 at 17:50, Ariel Ouziel <ariel...@gmail.com> wrote:
I've started to work on AOS Language and have then a few remarks:

- First of all, it would be really great to have a complex example of AOSL file on the wiki to really understand what's the rationale behind all the elements. I had some troubles figuring out how the various elements were used.

I agree and it's planned. However, as I'm relocating to Japan I can't work on it yet at the moment. Also current priority is set to work on AOSDesigner as much as I can so I'm sorry it's not there yet.

I wish I could do more :/

 

- If I understand correctly, a sequence is defined by its original state, a list of stages and a list of transitions describing the changes to perform between 2 stages.

Your understanding is correct. Moves contain a set of Changes to be applied to Objects when getting from a specific stage to another specific stage.

 

 

In order to get the sequence state at a certain time, one will have to start from initial state and execute all the transitions to get the current state. I think this is not very convenient. 

It's correct but necessary, and in the end it's not that inconvenient. I'll get to that in the following.

 

Those states won't be clearly visible in the file, thus they will be hard to read and modify.

That's what In feared until I implemented a simple "interpreter" that can easily know the state of each object with a provided path in the sequence "story" (that is really a directed cyclic graph).

So it's not so hard in the end : it's easy to retrieve the final state of objects at a given point through a given path. Once you got object states (active or not, spatial position if any) you can interpret it correctly to get the final "view" of the canvas.

Tell me if it's not clear.

 

Every time one will want to create a new stage, one would have to describe every possible transitions from other stages (like disabling this or that object, activating another, etc.). This will lead to combinatorial complexity for adding new scenes and will limit the author freedom.

I don't understand what you are talking about here? Maybe you can give me an example?

Maybe what is not clear is that you can't automatically move from one stage to another whithout having to traverse a "path" of moves? Not sure I'm clear here. Let's make a simlpe example :

 I have stage A->B->C .

I want to add a stage D that would be the following of C, so I create one stage and one move (containing changes):

A->B->C->D

Then I want to be possible for the user to get into a special path if he select some objects in the background. That special stage will be D2. It's only accessible from C obviously.

A->B->C->D  

             \

               >D2

Now, whatever the path the user took, I want him to continue the story with E , so all paths gets to it.

A->B->C->D->>E

             \      /

               >D2

This time I added 2 moves instead of one:

   - from D to E

   - from D2 to E

One thing that might be missing is a way to use the same move changes for several moves... But I guess I'll have to have a more complete implementation before adding features ^^;

Anyway, there is no way one can jump from A to E without having done the choice. Also, there is no way yuo can move from D to D2, or B to D. You have to make a path that will (in an abstract way) interpret what should be the state of a stage once done. 

Stages only give the skeleton of the sequence, they are not meant to be descriptive. The only thing descriptive inside would be scripts.

Is it more clear?

 

I think that a best way of describing a sequence would be to describe "key stages" (like key frames) wherein each object and its position is described. Transitions would be used optionally only when animation is needed between 2 stages. 

Actually that was my initial thinking 3 years ago but then I figured that it's just impossible to allow loops (cycles) and branches in the sequences. 

The goal of this format is to allow both "static" sequences (when you get to a stage, it will ALWAYS be the same) and "dynamic" sequences (when you get to a stage, what you will get depends on the path you took).

The core idea is to allow any kind of sequence, and making the sequence a set of stages without those possibilities gives too much contraints to the user.

If you prefer, the sequence description language have to be turing-complete, otherwise it's not as useful as necessary/mandatory and you can use other formats that are too poor for what authors needs. The only way to allow the language to be turing complete is to have a set of moves modifying the canvas "on the fly", not stages describing the canvas.

I understand that it's not as straight-forward for the implementors of tools or players, but once I've managed to write an "abstract" interpreter I figured it's not really a complex problem in the end.

 

For animating objects (or I would say "actor" like in 3D frameworks) within a stage, I think we should use "actions" directly attached to each actor. Actions could be "rotate" or "scale" or 
"move", etc. It would be more natural than a list of transitions described externally of each actors...

I don't understand what you are suggesting. Can you give an example? 

Well, did you think about branches, loops and also non-graphic resources like sounds, flash, video, etc? Reading your format, I'm not sure what are the current limitations. What I fear from this kind of format is to limit the user to only simple kind of sequences.

Personally I don't like to use the "actor" word because it relates to something having a behaviour, like in AI, while here (well, at least in AOSL) we are instantiating transformed views of resources (like a graphic sprite for example, the texture being the resrouce from which the sprite get's it's data from). This is an unimportant side note, obviously.

 

Anyway, here is a first status about my work. Tell me what you think. 

Thank you very much for this feedback, it's start an important discussion. :)

Joël Lamotte aka Klaim

[Leo Ki]

Hello Ariel and Joël

Anyway, there is no way one can jump from A to E without having done the choice.

Couldn't we add a feature that allows creating a step as independent from the previous sequence, the way film compression offers navigation chunks? In some cases that will mean storing redundant information - explicitely marked so - but that would be a small price to pay for a less computation intensive engine.

Leo

[Klaim - Joël Lamotte]

Hello Leo :)

That somewhat what I was thinking, but I don't see the computation intensivity it would remove. It would only help the AOSL author to get less moves when they are all doing the same (factoring moves).
The moves still have to be applied anyway at interpretation.

Aslo, I'm not sure what "computation intensivity" is required here, it seems simple enough but not simplist to me. Can you elaborate?

I'm noting this idea somewhere anyway.

Joël Lamotte

[Leo Ki]

2012/2/20 Klaim - Joël Lamotte <mjk...@gmail.com>

Aslo, I'm not sure what "computation intensivity" is required here, it seems simple enough but not simplist to me. Can you elaborate?

Maybe I haven't understood the point - I'm still a newbie to AOS ^^ I was thinking that if the engine has to replay the whole show in order to jump to a random "frame" or "slide", it could take ages (for the impatient web browser) in a big convoluted project, so the idea was: if the project allows it, it could be split into "chapters" or "chunks" that can work independently. In a standard turbomedia this is no problem, since a slide rarely reuses material from more than a few slides before. But if the show is highly interactive and one choice by the reader remains influent during hundreds of slides, of course this is not possible.

[Klaim - Joël Lamotte]

To be more clear : the player don't need to "display" all the stages it goes through.

That way, going through a path is done in an abstract way, and it's fast (in fact it's proportional to the number of changes to do all the way). Once the interpreter knows what should be the state of the canvas at some point in the path, it can interpret it : show images that are "active", play musics that are active too, etc. Do nothing with the rest.

Also I forgot to say to Ariel: the current AOSL whole organisation is thought to allow the interpreter to easily guess the resources and other data that it needs to be loaded up-front. For example, listing all the object tree (that cannot change) allows the interpreter to prepare all the instances upfront, or the part that is used first if the memory is limited.

Joël Lamotte

[Leo Ki]

2012/2/20 Klaim - Joël Lamotte <mjk...@gmail.com>

To be more clear : the player don't need to "display" all the stages it goes through.

Yes, I guessed so. But javascript is slow, and web people easily click away ;)

For example, listing all the object tree (that cannot change) allows the interpreter to prepare all the instances upfront, or the part that is used first if the memory is limited.

That's clever.

[Klaim - Joël Lamotte]

On Tue, Feb 21, 2012 at 00:00, Leo Ki <leoki...@gmail.com> wrote:

2012/2/20 Klaim - Joël Lamotte <mjk...@gmail.com>

To be more clear : the player don't need to "display" all the stages it goes through.

Yes, I guessed so. But javascript is slow, and web people easily click away ;)

For JavaScript, I'm not sure how much a problem it will be but I'm willing to check by implementing AOS Web Player.

You mean that people will pass to another website if it's too slow, right? 

Actually that's a problem that cannot be fought on player implementation design only, but I guess that's one important front.

If the author wants to use too big files too, it will be slow to load anyway. 

However for going into a predefined path, the algorithm should be fast enough to not even be visible by the user, or could even be done server-side if it's optimized enough to be worth the communication cost.

I guess we'll have more data once a first AOS WP implementation is available, even if it's a naive incomplete implementation.

[Ariel Ouziel]

Hi !

I see that you've been very active yesterday night :)

In my point of view, your definition of a sequence is similar to my definition of a stage.

Think of the stage as an "act" in a theatre play: you setup the decor, characters, and the script. During the act, characters will play the script and move around the stage. Your model is appropriate for this usage. But when the following act comes, the lights go down and usually decors and characters change.

In comics or even turbomedia, the sequence is composed of several "acts" (or "pages" or "stages" or "scenes" or whatever) where everything changes (background, sprite, music ?) and I don't think it's a good idea, nor useful to make stages dependant to each others.

Besides, your concept of "stage" is rather various states of the same stage, it makes no sense to call them "stage_1", "stage_2".. I see more that as "stage x" at "state a", at "state b", etc...

I think then that we should call your concept of a "sequence" a "stage" and your "stage" a "state" (or "frame") and embed everything in a greater "sequence" container that would contain a list of stages. Not sure if I'm clear here ^^. This "stage" concept would be as powerful as your definition of sequence is, but the sequence itself would support multiple definitions of it. It would ease the definition of sequences that look more like regular comics where each page is completely independent of the previous pages while still allowing complete power inside a single stage. We could define a special transition inside a stage that would jump to another stage.

Another question is: how do you animate objects independently ? Say I want to animate a sprite by rotating it constantly while other things happen around. How do you model that ? Don't you think we should maintain one transition graph for each object ? The synchronization would be made on a time and event basis.

Regards,

Ariel

[Klaim - Joël Lamotte]

 Hi, :)

On Tue, Feb 21, 2012 at 10:02, Ariel Ouziel <ariel...@gmail.com> wrote:

In my point of view, your definition of a sequence is similar to my definition of a stage. 

I don't think so, I think there are some misunderstanding on the meaning of words used, but let's continue:

 

Think of the stage as an "act" in a theatre play: you setup the decor, characters, and the script. During the act, characters will play the script and move around the stage. Your model is appropriate for this usage. But when the following act comes, the lights go down and usually decors and characters change.

I think you're mixing two concepts that are both defining the word "stage":

 - the stage (the place where something occurs, like in a theatre)

 - one stage (a step in a process, - une "étape" en français ;) )

Here it's the second definition because it's a Stage of the Story of a Sequence.

So we are not talking about the same thing it seems.

 

In comics or even turbomedia, the sequence is composed of several "acts" (or "pages" or "stages" or "scenes" or whatever) where everything changes (background, sprite, music ?) and I don't think it's a good idea, nor useful to make stages dependant to each others.

I think you're underestimating the problem with turbomedia. The current ones don't exploit fully the digital nature of the medium because of the limitations of Flash (that is made to be dependent on time). Flash is helpful to integrate animations but not to separate differents steps of the story in user-controlled manner.

I'm not sure what you mean by "make stages dependant to each others". It's just not possible to get a turing-complete structure without a graph allowing branches and cycles, so as I said before it's just not enough to have "static" description of differents stages/steps of the story. 

It's fine if you only do linear stuff, but it's not if you don't, and most digital authors (including Turbomedia authors that first asked me to work on this) asks to be able to do more if they want.

I agree with them: they shouldn't have to know programming to allow their stories to branch.

 

Besides, your concept of "stage" is rather various states of the same stage, it makes no sense to call them "stage_1", "stage_2".. I see more that as "stage x" at "state a", at "state b", etc...

Maybe the names are misleading : there is no limitation in the naming of stages. Most of the time, those files will be generated by tools that will certainly use UUIDs instead of such names. 

You give "toto", "foo" or "blurb" as ids to stages, it just don't care. Same thing for any other identifiers.

 

I think then that we should call your concept of a "sequence" a "stage" and your "stage" a "state" (or "frame") and embed everything in a greater "sequence" container that would contain a list of stages. Not sure if I'm clear here ^^. This "stage" concept would be as powerful as your definition of sequence is, but the sequence itself would support multiple definitions of it. It would ease the definition of sequences that look more like regular comics where each page is completely independent of the previous pages while still allowing complete power inside a single stage. We could define a special transition inside a stage that would jump to another stage.

Comics don't work like "regular comics". The fundamental of comics is the sequencial structure that just allow the author to suggest "actions" between the different stages (étapes) of the story. 
Now, you "stage" is in fact the "sequence", so I don't see the problem. It's Canvas describe what are the objects or actors if you prefer, and the story say how they will "play".

 

Another question is: how do you animate objects independently ? Say I want to animate a sprite by rotating it constantly while other things happen around. How do you model that ?

Simple: don't use a sprite ;)
Assuming you're using animable resource, you should use  "video" instead of "sprite" or use both if the resource can be used as a static image AND an time-flow based sequence. 

"video" isn't perfect term but it gather the concepts of time-flow dependent graphic & audio object. If you have a better term, I'm open to suggestions.

Looking at properties of "video" you'll see everything (I think) needed to drive an animation at a specific stage in the story. 

 

Don't you think we should maintain one transition graph for each object ? The synchronization would be made on a time and event basis.

Why? 

Maybe you're mixing the sequence structure, that is made of changes of states of the different objects, and "what happen inside a stage" (aka "step in a story") like animated visuals, that are not driven by the sequence itself?

Stages in the story of a sequence have to be exclusively user-driven, not time-driven, that's the essence of the comics structure. Now having animations inside a stage or as transition between two stages is totally doable with the current defniition, but maybe I've not been clear about that.. see the "effect" element, it's how you apply transitions. I didn't define any standard effects yet but will do through the next iteration.

It's helpful that you ask all that, I can see what kind of documentation is missing to help understand the design of all this project :)

Joël 

[Ariel Ouziel]

Thanks for your reply,

My answers are in red.

Le 21/02/2012 11:05, Klaim - Joël Lamotte a écrit :

 Hi, :)

On Tue, Feb 21, 2012 at 10:02, Ariel Ouziel <ariel...@gmail.com> wrote:

In my point of view, your definition of a sequence is similar to my definition of a stage. 

I don't think so, I think there are some misunderstanding on the meaning of words used, but let's continue:

 

Think of the stage as an "act" in a theatre play: you setup the decor, characters, and the script. During the act, characters will play the script and move around the stage. Your model is appropriate for this usage. But when the following act comes, the lights go down and usually decors and characters change.

I think you're mixing two concepts that are both defining the word "stage":

 - the stage (the place where something occurs, like in a theatre)

 - one stage (a step in a process, - une "étape" en français ;) )

Obviously, there was a misunderstanding about our definition of "stage", maybe we should consider using another term :) , for example "step"

Here it's the second definition because it's a Stage of the Story of a Sequence.

So we are not talking about the same thing it seems.

 

In comics or even turbomedia, the sequence is composed of several "acts" (or "pages" or "stages" or "scenes" or whatever) where everything changes (background, sprite, music ?) and I don't think it's a good idea, nor useful to make stages dependant to each others.

I think you're underestimating the problem with turbomedia. The current ones don't exploit fully the digital nature of the medium because of the limitations of Flash (that is made to be dependent on time). Flash is helpful to integrate animations but not to separate differents steps of the story in user-controlled manner.

I'm not sure what you mean by "make stages dependant to each others". It's just not possible to get a turing-complete structure without a graph allowing branches and cycles, so as I said before it's just not enough to have "static" description of differents stages/steps of the story.

I agree about the graph structure. What I'm not comfortable with is the need to "clear" the canvas (by disabling all objects one by one) in the case I want to make a whole new scene. Maybe a special "clear canvas" action/change would solve this issue. Besides, I'm not familiar with the concept of "turing completeness", could you elaborate what you mean by that in the case of sequence description language ?

It's fine if you only do linear stuff, but it's not if you don't, and most digital authors (including Turbomedia authors that first asked me to work on this) asks to be able to do more if they want.

I agree with them: they shouldn't have to know programming to allow their stories to branch.

 

Besides, your concept of "stage" is rather various states of the same stage, it makes no sense to call them "stage_1", "stage_2".. I see more that as "stage x" at "state a", at "state b", etc...

Maybe the names are misleading : there is no limitation in the naming of stages. Most of the time, those files will be generated by tools that will certainly use UUIDs instead of such names. 

You give "toto", "foo" or "blurb" as ids to stages, it just don't care. Same thing for any other identifiers.

ok, that was related to our different conceptions of "stage"

 

I think then that we should call your concept of a "sequence" a "stage" and your "stage" a "state" (or "frame") and embed everything in a greater "sequence" container that would contain a list of stages. Not sure if I'm clear here ^^. This "stage" concept would be as powerful as your definition of sequence is, but the sequence itself would support multiple definitions of it. It would ease the definition of sequences that look more like regular comics where each page is completely independent of the previous pages while still allowing complete power inside a single stage. We could define a special transition inside a stage that would jump to another stage.

Comics don't work like "regular comics". The fundamental of comics is the sequencial structure that just allow the author to suggest "actions" between the different stages (étapes) of the story. 
Now, you "stage" is in fact the "sequence", so I don't see the problem. It's Canvas describe what are the objects or actors if you prefer, and the story say how they will "play".

I assume what you call "comics" is a "digital comics". I agree that digital comics should take complete advantage of digital medium, but I think it should not complexify the definition of regular linear comics. If I'm creating a simple linear comics, I just want to tell what's in each page, and not bother with previous states of the page...

 

Another question is: how do you animate objects independently ? Say I want to animate a sprite by rotating it constantly while other things happen around. How do you model that ?

Simple: don't use a sprite ;)
Assuming you're using animable resource, you should use  "video" instead of "sprite" or use both if the resource can be used as a static image AND an time-flow based sequence. 

"video" isn't perfect term but it gather the concepts of time-flow dependent graphic & audio object. If you have a better term, I'm open to suggestions.

Maybe "animation" would be clearer ?

Looking at properties of "video" you'll see everything (I think) needed to drive an animation at a specific stage in the story. 

 

Don't you think we should maintain one transition graph for each object ? The synchronization would be made on a time and event basis.

Why? 

Maybe you're mixing the sequence structure, that is made of changes of states of the different objects, and "what happen inside a stage" (aka "step in a story") like animated visuals, that are not driven by the sequence itself?

Stages in the story of a sequence have to be exclusively user-driven, not time-driven, that's the essence of the comics structure. Now having animations inside a stage or as transition between two stages is totally doable with the current defniition, but maybe I've not been clear about that.. see the "effect" element, it's how you apply transitions. I didn't define any standard effects yet but will do through the next iteration.

Ok I agree, it's clearer. I see my "actions" as your "effects" now. I think we should not underestimate this part of the problem, because animation inside a stage could be complex and would add great value to the user experience.

It's helpful that you ask all that, I can see what kind of documentation is missing to help understand the design of all this project :)

Hehe sorry if I'm so punctilious about the terms and concepts, but I need to be comfortable with all the concepts to start working on it !!

Joël 

Thanks for your patience,

Ariel

[Klaim - Joël Lamotte]

On Tue, Feb 21, 2012 at 11:58, Ariel Ouziel <ariel...@gmail.com> wrote:

Obviously, there was a misunderstanding about our definition of "stage", maybe we should consider using another term :) , for example "step"

I've used step before but I'm not confortable with it because it suggests movement while "stage" suggest more like a milestone. 

I think "stage" is fine if you have a clear definition associated with it. The AOSL documentation should provide it. I wish I could work on it :/

If you have other names to suggests that are more close to "étape" in french, please tell me :)

 

I agree about the graph structure. What I'm not comfortable with is the need to "clear" the canvas (by disabling all objects one by one) in the case I want to make a whole new scene. Maybe a special "clear canvas" action/change would solve this issue. Besides, I'm not familiar with the concept of "turing completeness", could you elaborate what you mean by that in the case of sequence description language ?

About the "clear" structure I understand your concern but the thing is that AOSL isn't meant to be understandable by humans, and AOS Designer is meant to make the sequence "clear". That's why AOSL is based on XML instead of something easier to read.

So, knowing this, AOS Designer will show to the user a graphic graph of what is possible. That will make things obvious. For the "interpreter" point of view, it will only have to follow the story, no need to have a human-readable description in the file.

About Turing-Completness, maybe read this : http://en.wikipedia.org/wiki/Turing_completeness

Basically, any programming language is turing-complete, meaning that if you don't know the precise inputs of the "machine", you can't deduce the output. Which means that a turing-complete system allows to describe any behaviour dependant on inputs. Which means it needs cycles (loops) and branches (if) to be able to be turing-complete as it is necessary to allow conditional behaviour.

You can think of AOSL as a scripting language that isn't made to be scripted by humans ;) Also, programming languages ARE graphs of changes to be applied to data. Here we need this kind of structure, as previously said, to allow the author to do things that would require programming otherwise. (note that there are some <script> tags too to allow custom programmin if needed but that shouldn't be used by anything other than "games").

Now, about "a special "clear canvas" action/change", it already exists ;)
You can find in the xsd special identifiers (search for "special_" in the xsd) which help applying changes on a group of objects instead of only one. The one you're looking for (the only one so far) is "#all".

So you can have

<move from="cliffhanger_stage" to="end_stage" >

   <deactivate object="#all" />

    <activate object="to_continue_logo" />

</move>

You're welcome :)

Another thing I'll need to make a good documentation about...

 

I assume what you call "comics" is a "digital comics". I agree that digital comics should take complete advantage of digital medium, but I think it should not complexify the definition of regular linear comics. If I'm creating a simple linear comics, I just want to tell what's in each page, and not bother with previous states of the page... 

Others and I have done some tests going throught the most obvious design, but it always get into problems because it's not the natural design of "digital" sequences. You can have most kind of static structures of stories this way, but you can't get out of this static structure.

With a graph of changes, instead of a graph of descriptions, you get the possibility to do anything a programmer would be able to do, without having to program. The "digital" side of digital comics is that most exploitation of the medium require at some point some programming, implying turing-completeness. 

So, yes I could go that way, but that would limit A LOT the possibilities that authors are asking for (in particular Balak).

 

If you're creating a simple linear comics, you should get a straight line in AOS Designer, so it would appear simple. If you add complexity, it will look more complex. That's more natural than hiding branches and loops as "special cases".

Maybe "animation" would be clearer ?

That's what I had first but I'm not happy with it either because it exludes video files... or not, I'm not sure. It's ambiguous, at least as much as "video". It's really a problem so if you find something better...

 

Ok I agree, it's clearer. I see my "actions" as your "effects" now. I think we should not underestimate this part of the problem, because animation inside a stage could be complex and would add great value to the user experience.

Yes that's why I didn't added any standard effects and want to wait for an iteration of the language, because it have to be well thought.

I have some ideas to generalize basic effects, but I'll get back to that later.

 

Hehe sorry if I'm so punctilious about the terms and concepts, but I need to be comfortable with all the concepts to start working on it !!

Don't  worry, it's really helpful! :D

I didn't have almost any technical feedback for years so I'm happy you make me realise what docs are missing and point again potential design or naming flaws.

Joel Lamotte

[Leo Ki]

May I suggest we have a thread in French about the French and English terminology of AOS? It might remove one layer of complexity in the debate ;)

[Klaim - Joël Lamotte]

The problem is that the words have to be in english, so it will not help to switch to french. The misunderstanding is because the "stage" word have 2 meanings that are context-relative so it's more an english language problem.

Also, I need to keep public discussion accessible to most people.

[fr]

Mais si vous voulez dire quelque chose de difficile a exprimer en anglais, lachez vous :) je ferais la traduction derrière avant de répondre si nécessaire. Vous pouvez ouvrir un thread différent si vous avez besoin, avec un préfix [fr] dans le sujet.

[/fr]

Joël Lamotte

[Leo Ki]

No worry, I understand the forum has to be in English. I was only suggesting we have a little ephemeral side-discussion in French in order to help clarifying what we mean by this and that word.

[Ariel Ouziel]

Indeed, maybe we should do that, and after make a doc or wiki page
explaining everything clearly...

Ariel