Flame v2 changes

[spydon]

Flame v2 changes

This issue doesn't mean that we are soon to release v2, it's not even on the horizon yet.
In here we'll track breaking changes that we would want to do for Flame v2 so that they are not forgotten.

• Create a new tree structure, instead of using nested OrderedSet, possibly one tree for updating and one for rendering. (see Make the Flame Component System core more efficient #3957)
• Support a global z-index/priority, via a RenderLayer system. (see Add a RenderLayer system for global render ordering #3967)
• More efficient event system (currently the events go through the whole component tree).
• Discuss changing anchor system so that children's 0,0 is at parents anchor.
• Convert the use of ShapeComponent in the collision detection to use pure shapes instead.
• Return a list instead of a set from the collision detection methods. #4001
• Completely rewrite ParallaxComponent to have the layers based on PositionComponent and make it more intuitive to use.
• Clean-up the HasPaint mixin.
• ColorEffect should not take in an Offset, but separate doubles.
• Create a MarginComponent that can replace HudMarginComponent and work when added to the viewport (or any sized parent).
• Call onGameResize only when the game actually resizes.
• Component.add() should return void.
  Whoever wants to wait for the component to load can wait for component.loaded, and who wants to wait for it to mount can await component.mounted.
• Figure out what to do with Game's mount/attach and remove/detach.
• Component.children should return a nullable ComponentSet?, so that it won't be instantiated when there are no children.
• Report normal of collision for collision events.
• Allow decoding json arrays in the root from the cache. (see fix!: Allow AssetCache to load json files with array at root #2688)
• Rename GameWidget.controlled to GameWidget.managed.
• Structure caches so that the are consistent and have method names that make sense.
• Maybe rename onPressed and onReleased to onTapDown and onTapUp in AdvancedButtonComponent.
• Remove middle intersection point on line for collision detection. #4002
• Add generics for CameraComponent type in FlameGame.
• Migrate to Float32 vector math.
• SpawnComponent should only have one factory that returns a list of components.
• SpriteBatch should take an Anchor in relation to size instead of Vector2 with exact pixels for the anchor.
• Caches should maybe not have a default prefix, so it become more in-line with Flutter (especially for the widgets). (@erickzanardo)
• We should support package for the caches and for the widgets' .asset constructors. (@erickzanardo)
• Only expose Iterable<Component> from children and have query etc directly on the Component.
• game.paused -> game.isPaused #3991
• onDragCancel should not delegate to onDragEnd by default (see fix: onDragCancel should not delegate to onDragEnd by default #3926).
• The whole component tree should be waited for in the initial onLoad in the FlameGame. #3997

[MuZiLee]

Looking forward to the v2

[guyluz11]

Once we are ready to start working at v2 we'll convert this task list into issues.

What holding us back?, there is only one task that got converted into an issue

[spydon]

What holding us back?, there is only one task that got converted into an issue

First we want to stabilize the current version with the new CameraComponent API and there is still some work left to do there.

[NashIlli]

Hello, @spydon! Is Version 2 included in the route of the following months? Thaaanks! :)

[spydon]

Hello, @spydon! Is Version 2 included in the route of the following months? Thaaanks! :)

Hi, unfortunately not, we have not even decided on paper how the big architectural changes will look.

[marzoukali]

Any updates on when to expect version 2 or do you need any help getting it back on track? We can share with the community the challenges and build separate team dedicated for it. I suggest if this is still in plan, we will need to have it's effort as separate from the current.

[ufrshubham]

we will need to have it's effort as separate from the current

I am not sure of it will be a good idea to have separate efforts for this. Although v2 will have breaking changes, I'd still want the transition to be as smooth as possible. Maintaining two separate versions might drastically change the APIs causing users to re-write a significant portion of their game.

[spydon]

@marzoukali we have some bigger architectural changes that we need to decide and plan internally before we start this project.