Decoupling Flame from Flutter

[luanpotter]

We have for a while contemplated the idea of decoupling flame from flutter, allowing people to bring in their own rendering backends. The plan would be to have two packages:

• flame_core - most of what current is in flame lives here, completely agnostic from rendering backend. game, components, event propagation.
• flame ("flame_flutter") - we keep the flame package name for what would be flame_flutter, an package with flame_core + the flutter bindings for rendering, GameWidget, hookup of events to flutter, etc.

Our main guiding principles here would be:

• people using the flame package should have it just work - no need to do anything special if you are using flame + flutter
• the APIs should not become less ergonomic for the common use case
• we don't want this to be significantly overengineered, as it is an ideal goal but not necessary

However upon initial exploration, @spydon and I found some issues with this approach, namely on how to cleanly separate the interface between flame_core and the rendering backend.

• our current Events Master Plan has events include a "raw" generic field that would concretely point to the flutter base event for each; that would not be cleanly exposable without contrivances (which has minor impact on ergonomics);
• the interface for the rendering backend is unclear. the main issue is that dart:ui and all its classes are actually part of flutter, not dart. flutter-less packages cannot depend on basic class such as Color, Rect, Paint, text-related classes, and many more. It even goes against our previous idea of replacing parts of Flame's current text-rendering pipeline with the flutter methods that already do that work;
• potential other issues and edge cases we have not foreseen yet.

Of these, clearly the rendering boundary is the largest unsolved problem.

Shimming/interfacing the entire dart:ui package would be a pharaonic project including paints, color, text classes, and much more, an estimated total of around 30k LOC. It can also have performance (due to translations since Dart is not so expressive with extension types and interfaces) and ergonomics (users might need explicitly converter extensions) concerns. Including that entire layer on flame_core is a non-option.

We also checked with the Dart/Flutter team if there are any plans to continue work on the breakdown and extraction of dart:ui on their end, as this is a prevailing issue on Dart-Flutter separation, but the idea was scratched or stalled.

So we were left with a few options:

(1) scratch the decoupling idea, keep flame as a monolith
(2) use/create and maintain a dedicated shim library, this one is pretty much what this would look like, but that has a very large cost and still has a layer of coupling as flutter updates their own dart:ui
(3) decouple from flutter philosophically, do the core/flame divide, but keep the dependency for dart:ui in practice. people can still override the BE but have to bring in flutter for Paint, Rect, etc, and work on top of that.
(4) completely move away from the flutter interface; have our own versions of Color, Text, etc classes that are NOT 1:1 to flutter but a subset + anything flame needs, have one-way converters (i.e. avoid the bulk of the 30k)

Clearly the most worthy of discussion here is option (4), what would this new interface look like, and how easy would it be for current Flame games to migrate to it. After looking into it for a while I believe the surface area here is still very large, but I believe @wolfenrain has thoughts on the exact shape that he might be able to share.

As a very concrete example, if someone today does canvas.drawRect(rect, paint), we need to figure out a shape for this on the new interface (if doing (4)). Same for all other rendering concerns, text pipeline, etc.

[spydon]

Let's keep this open for discussion, but like we said on the call, we should not do this if it makes the API worse for our end-users.
Since the vast majority of them won't use this feature and it seems like it is currently impossible to do this without making the API worse, we should pause it.