Object "states"

Something really cool i think would be to have predefined object “states” (other potential names: “preset”, “keyframes”, “configurations”). Basically, you could open an object in a “layout editor” with only that object, and change the instance parameters like position, angle, variables, etc, and have a bullet list of all states (you can add any you want). Each state would store that configuration, and you could see and edit the configuration of your object for any state.

When placing an instance, you can set the state it is in at creation in the instances properties editor, but also change the configuration of a state for this instance.

Finally, in events, you would have an action to set an object to another one of it’s states, a condition to check the object state, and most interestingly an action from the tween behavior to tween all properties different from one state to the ones of the other.

This would be a very powerful feature that would simplify many things:


This can be used to make “keyframes” for animations with the IDE tools, making it easier to make complex animations. It could be a first step towards making a timeline, by adding keyframes that could be used on such a timeline.

A simple example for a simple animation would be a pause screen: you could have an object group of objects constituting a pause menu, maybe a play button, a black backdrop, and a “modal” sprite. We could then make for each a hidden and visible state: the backdrop has either half opacity on visible and 0 on hidden, and the sprites have scale 0% in the hidden state and a scale of 100% when visible.
Simply tweening from hidden to opened and back makes a smooth opening and closing animation that can easily be tweaked visually without entering all parameters in very long animations events in the events sheet :slight_smile:

Finite State Machines

This also simplifies state Machines a lot: we can use the states of an object as the states of the finite state machine. That allows to visualize different states, set for example a sprite’s animation for each state.
Assuming we can modify behavior properties on instances in the future, we could also set different parameters of behaviors depending on the state (for example smaller platformer jump height when in the crouching state).
This allows moving the declaration of different states of the FSM away from events, and to keep events for defining the transitions and logic bound to the current state.
If in the future we also add events sheets bound to an object (for the sake of organization and cleaner sharing of logic of global objects across scenes), we could also add events sheets bound to each state (for the sake of organization) that only run when an object is in a specific state, this would also get rid of the boilerplate code to check in which state the object currently is and run the appropriate events accordingly.

Additionally, this feature would change the way of thinking about objects in a away that might make FSMs easier to understand.

Improving IDE workflows

The engine makes some default decisions when placing instances, like the default layer or z layer. While those defaults are good most of the times, some games require some objects to always be on the same layer, z order, or have because if the asset creation workflow to have a different angle or scale than the default, etc.
By modifying the base state on the base object, all created instances will have those default overridden by the default state.

Another common thing might be to have elements that can have multiple default states, like checkboxes/toggle switches. This allows to have a cleaner way to set the default state per instance (rather than setting the animation/a variable on it).


I’m not sure I understand the full extent of your proposition.

Can you explain what difference will it make comparing to a custom behavior with an action for each state?

Oh god no this has nothing to do with a custom behavior, I must have expressed myself badly. I’ll try to make a mock-up to show what I mean.

Interesting idea. I can imagine setting up multiple different configurations, “states” for an object like different animations, behaviors, properties and then be able to set different states in the level editor when we place an instance and also using events at runtime.

I could see my self using this feature. :+1:

Ok so I’m not good enough to make an animated mockup, but I can make individual fake images to show the concept, just imagine they are continuous like a video to show the concept:

I have a base object here! Let’s place it on the scene:

Oh no! It’s so tiny! And I need to place and resize hundreds of those! Thankfully, I can edit the objects default state to change the default size of instances:

Now, newly placed instances of that object will automatically have the changed defaults!

I can do the same to put all of my UI elements automatically on a UI layer by default :innocent:

Now let’s say Chort is an enemy, and I want to make variations of him. They all should have the same behavior/logic, but have different stats and appearances. I could make different “Chort” objects and give them all the same logic through a group, but that is not very convenient, as I can get a gigantic object list, many objects groups if I have many enemies with different variations, have to add new variants to the groups… Instead, I can use object states:

I start by giving Chort some object variables for his stats:

Now I can create a new state that I’ll name aqua:

This state has different sprites and stats. Sure, this is doable via other ways, but editing properties in-editor is more convenient.

Now I can place the object on the scene, and select the aqua state to automatically use the other instance settings I had defined on the object:

This covers the 3rd use case, I hope this made it clearer what this feature is about. If you want mockups for the other use cases, please tell me.


I absolutely agree with this feature. I can just imagine how much possibility this opens up, and it’s definitely something I’ve been wanting to put in my own game. This process will make everything SO much smoother, faster, and more convenient.

This feature has my approval. Great suggestion ^o^

1 Like

Is it like the prefab system of Unity but without composition?

For the case you choose, enemies usually have different patterns which means they should probably be different objects (I don’t say that the system is not useful, but the example might not be a good one).

Can you give some user stories?