• Change with_collision type to uint32 (bitmask), because we may want to intersect with certain objects and not others.
• rename collision_mask, on_collision, on_begin_collision and on_end_collision, due to the previous item, to avoid confusion and inconsistency.

This will lead to a "pause problem", that is, while the gameplay is paused, the time in the application is still running, thus the systems will suddenly have a great interval since the last system update.

This means that is like the game was "frozen" for a quite of time instead of just paused, in consequence, leading to a "jump" instead of a resume.

Adding this pause feature also will open a path to implement a pause graphical user interface in the future.

Irene change of focus

This is a bit funny title since Irene changed many times and now it'll probably change again, however, this change isn't that breaking (or at least I'm not expecting that), thus that's why it's called "Irene '2.0'".

This will be actually an extension of what Irene is today, and a change of focus too.

For instance, compared to other other tools like Unity or Defold, while of course the fact that Irene it's much simpler (to not say "incapable") compared to them, one of the major and inconvenient differences between them it's the fact that Irene doesn't come with an editor and it's more like a framework than an engine.

The reason for that it's because Irene is currently more aiming for pure text (code) workflow and modularity, in a way that the developer could make an engine on top of it.

It was fun, but I'm afraid that these goals don't worth the work anymore, because I'm a bit exhausted and tired to always seeing that the games takes much longer to make on Irene than on other tools like Unity.

First and foremost, an editor it's really convenient and I absolutely miss it, I've been trying to not adopt a "canonical" editor and instead, make the user free to use and integrate their editor of choice, however:

1. Irene, as far as I know, have no users, but that's fine because popularity isn't a goal.
2. It doesn't make sense to make my own tool if it's not useful for me to begin with, and if the tool isn't convenient for me, why it would be to others?

These two points already states that the current approach isn't that much useful for me, alone, but I'm not even alone: games are made by teams, with designers, artists, etc., and the current approach it's very programmer-centric, which I think it's a mistake that engines generally falls on (including the big ones, and of course this one too hehe).

For this reason, I'll take a more personal (opinionated?) approach to Irene, taking the UX of my colleagues in consideration, otherwise it would be just rational to drop Irene and give up on this already.

Editor

One of the new focus of Irene: Adopting or making an "canonical" editor.

This canonical editor needs to be an integrated and the most useful possible tool for level designers, this is now a goal.

For now I may adopt Tiled to be this editor, but an official "Irene-editor" might be created, in fact, I have a great admiration of how canoi's tinycoffee did this, Noel's and Isadora's works also gives great inspiration of how this editor could be.

Less fully modular design

This is related with issue #4.

Some of the rationale can be read on "Game engines are more than libraries glued together" article, and although I don't think Irene have the same problems described this article, indeed making Irene fully modular have been causing some inconvenience, boilerplate and essentially, boring and confusing verbose code (or glue code).

Thus I may make Irene less modular and more "opinionated", but don't worry, I like modularity, but for Irene it might be too much, and this is quite the reason programming on Irene it's more complex than Unity or Defold.

Also, the other engines I followed that have full or high modularity also are complex to use.

Conclusion

TL;DR: Making games on Irene are possible, but it's more complex and takes more time than I like, and I'm now changing the development focus of Irene, in order to create a more personal useful tool to make lightweight indie games quickly without more complexity than I and my colleagues can deal with.

That said, Irene don't have intentions to be the next Defold, Godot or Unity alternative, this isn't a goal, it's just to make the workflow less tiresome and programmer-centric.

Anyway, this issue will be open for a while! Once I consider this goal achieved, I'll then close this issue.

Thanks for reading.

~ André L. Alvares

New features (on order of priority, but not strictly)

• Scene Graph Node
• Position Hierarchy

• Sprite Animation

• "Any" Animation (animate variables for example, this is available on engines like Unity and Godot, and are very useful) (it's possible though)

• Transform (will replace "position" component, will support scale and rotation) (0.2.0)
• Position Hierarchy (scene graph)
• Transform Hierarchy Painter?

• Anchored Rect (to make GUIs) (0.2.0)
• Anchored Text
• Anchored Sprite
• Anchored Rect Hierarchy (scene graph)
• Anchored Rect Painter

Refactors

• Refactor rotor-quick.makers and update tests
• (external) Refactor and optimize Rotor (now unrelated)
• Use Nene v.2.x