Theatre.js as part of timeline editor for GDevelop about gdevelop

[f0nar]

I prepared small test with this approach. Watch it with at least x2 speed))

[4ian]

Just to chime in on this, the way some other engines do this is treat Timelines just another way of viewing of script/tween setup, and the editor just abstracts the code into a visual representation.

So in GD5 terms, you could have a series of "Timeline" events (probably an advanced event similar to a "For each" or While) and you would click a button to show it in the timeline. Once done editing in the visual editor, the event sheet would show a bunch of tween conditions/actions?

This is a very interesting approach, and it could work by generating actions/conditions or code by the way. Thanks for explaining this point.

[4ian]

My main comment would be: how do we fit this into the object/behavior/event model of GDevelop? And how do we fit this in the editor :)

Quick thinking:

• This would be a behavior? Is this flexible/easy to use enough as a behavior or would require some "first class" support?
• This would need probably ability to have extensions to extend the UI of the editor. For now we have this concept of "third party editors" but only for resources.

We could consider these timelines as resources, but might not be ideal in terms of UX to use them and edit them quickly in a scene.

[Silver-Streak]

My main comment would be: how do we fit this into the object/behavior/event model of GDevelop? And how do we fit this in the editor :)

Quick thinking:

• This would be a behavior? Is this flexible/easy to use enough as a behavior or would require some "first class" support?
• This would need probably ability to have extensions to extend the UI of the editor. For now we have this concept of "third party editors" but only for resources.

We could consider these timelines as resources, but might not be ideal in terms of UX to use them and edit them quickly in a scene.

Just to chime in on this, the way some other engines do this is treat Timelines just another way of viewing of script/tween setup, and the editor just abstracts the code into a visual representation.

So in GD5 terms, you could have a series of "Timeline" events (probably an advanced event similar to a "For each" or While) and you would click a button to show it in the timeline. Once done editing in the visual editor, the event sheet would show a bunch of tween conditions/actions?

I believe that is how Panthera for Defold works (timeline editor abstracts the lua code for tweens around position/rotate/scaling/etc).

[f0nar]

Hi @4ian
If we are talking about theatre.js it would be nice to emphasise its approach.

This would need probably ability to have extensions to extend the UI of the editor. For now we have this concept of "third party editors" but only for resources.

First of all it has the UI part where all magic is done and it lies in studio package. Singe lack of it is absolute position. You cannot integrate its parts in your specific html elements. It will on top of UI all the time but I think it is possible to change with contribution to theatre.js.

Then about the timeline.
I think this part is good enough to explain what timeline is and its purpose.

he way some other engines do this is treat Timelines just another way of viewing of script/tween setup, and the editor just abstracts the code into a visual representation.

So with theatre you can control one or more objects by specifying behaviour of their properties changing on specific timeline.

To do that it has few main entities

• project - set of all sheets and settings per project
• sheet - set of sheet objects that share one timeline (they will be tweened all together by unique rules per sheet object)
• sheet object - that object is everything that theatre can control and tween by prop types.
• prop types - the properties of sheet objects that will be tweened by specified rules. It can be number, string, color, bool and many other types.

Consumption: If you want to implement some animation with theatre. You need to create sheet and add sheet objects there for all real objects that will participate in animation. For every object you need declare its structure by prop types so then theatre will understand structure of every specific object and will be able to control it (e.g. you can add x,y position for sprite, color for background, etc). Then manipulate all these values on timeline to define their behaviour on time (change sprite x from 100 to 1000 linearly in 3 sec, change background color from red to purple in 2 sec by starting with 2 sec delay) Voila, your animation is done, just run it.

About integration to GDevelop

This would be a behavior? Is this flexible/easy to use enough as a behavior or would require some "first class" support?

I think not. As sheets can control more that one object it is probably not possible to logically bind behaviour per GD object and configured theatre behaviour per multiple objects. I think the best and simplest way is to have global action like play _PARAM1_ sheet like you have for camera zoom or variables tween. Then user can configure any animation on any amount of objects and then play it on any condition just by sheet name specification.
With the help of behaviour we can control if object is compatible with timeline or prop types structure. But I would like to have ability to control every object with timeline by default. Every object can declare its own structure with prop types. By default RuntimeObject will do it with its common properties (x, y, angle, ...)

[4ian]

Thanks for the explanation, and that's a very interesting proof of concept!
I guess you have an implementation at runtime + one in the editor that allows to manipulate position of instances?

The UI overlapping GDevelop UI is quite unusual, but I wonder if we could make it work by "restricting" it to a "boxed location".
What I mean is that if we add support for third party extensions to bring their own UI (which would help doing things like custom UI for setting up joysticks, dialogs, visual rendering...), it would probably be a panel/dialog, so that extensions UI play nicely with each others.

Anyway, with this proof of concept I understand that indeed a timeline acts on multiple instances and so might better work as something that have a "global" action. I still wonder if there is a way to do it so that it can be reused across different instances, something that is easy to set up but modular :)

[f0nar]

What I mean is that if we add support for third party extensions to bring their own UI (which would help doing things like custom UI for setting up joysticks, dialogs, visual rendering...), it would probably be a panel/dialog, so that extensions UI play nicely with each others.

Yeah, I agree. Thats what I meant when mentioned contribution. I think we can make it configurable.
Singe additional think about theatre UI is AGPL-3.0 license. Is it okay for you to integrate such kind of license into GDevelop sources?

I still wonder if there is a way to do it so that it can be reused across different instances, something that is easy to set up but modular

Can you describe more abstract idea of what you want to reach? I will think more about it. Do you agree with global approach and want to add additional configurable feature or you want to add only such feature and omit global actions?

[f0nar]

@4ian sorry for ping
what do you think about my last comment?

[4ian]

@f0nar thank you for the ping!

theatre UI is AGPL-3.0 license. Is it okay for you to integrate such kind of license into GDevelop sources?

That's a good question, I wonder if it's viral enough that it would require the rest of the GDevelop source code to be [A]GPL?
I think it could be ok as long as it's considered as separate "components" of the app

Can you describe more abstract idea of what you want to reach? I will think more about it. Do you agree with global approach and want to add additional configurable feature or you want to add only such feature and omit global actions?

All things considered, maybe your approach is fine - it could be extended later to "custom objects".
My concern was that this would not be modular enough (it can only work for a scene). But we'll soon work on an instance editor that works for custom objects with @D8H, and I could see Theatre.js to be used to move instances inside a custom object.

So a "global approach" (but scoped to a scene in the runtime) should work :)

[4ian]

I'm sorry if I made you lose a bit of time by not answering earlier last month! I think this could be worth starting a PR to see how it could work? By making things as simple as possible and by having Theatre.js sources being downloaded (like Piskel for example), so it's clear it's a different project with a APGL license.