Flame 1.0 on the horizons

There is a TL;DR at the end so at least you have to scroll and see what you are missing.

Hi there, folks! We have some exciting changes to talk about and some even bigger ones on the horizon, so I decided to write down this post to share what's been going on with Flame recently (with a big announcement in the end!).

Some of you might have seen activity on GitHub, and a few of you have been actively helping, so I think it's no surprise we have plans of moving towards Flame 1.0 in the near future! It's been a long journey through these years since I created the Flame engine. Since then, a lot of amazing people from the community came forward to help us grow this platform so much, but we always kept it on v0 (0.x versions). That allowed us to "move fast and break things", even though we actively avoided big breaking changes after the first few releases.

But a major side-effect of such a broad, helpful and kind community was that we learned and discovered a lot about Flame, games in Flutter, and how to make our lives even easier. So we collected a lot of feedback and ideas and decided that it was time to go to v1. Finally launch Flame 1.0, a more established and robust API.

What will change? We do not want to break everything for nothing. Also, we are still committed to our core values, the first words in this repo since day one: a simple, modular game engine. So nothing huge will change, actually. But we will break a few things. We are taking this opportunity to make a few changes we always wanted to do but didn't want to create confusion on people migrating from 0.x to 0.(x+1). But this is 1.0, and we have allowed ourselves some changes.

You can, of course, take a peek on those changes on GitHub -- I encourage you to do so, I am really excited about them. And we would like to take this opportunity to ask for other ideas. If you have something in mind that would be a breaking change but you think would be worth it to add to v1, please open an issue to discuss (just make sure it has not already been discussed or implemented).

But I would like to talk about one change in particular here, one that we partially rolled out to some extent to 0.x and one that will definitely be the most glaring one. In the beginning, everything that we added to Flame was a necessary building block, in my view, to create games; from the most simple to the most advanced ones. As time progressed, though, we started to add some more edge case features. This is in line with our modular approach - we never made anything mandatory or "in the way". But for some stuff, we decided to make separated packages. For example, we had flame_gamepad for gamepad support, but box2d support was "included" in the flame package. There was no particular rule that led us to that decision (we didn't want any native code on Flame itself but that never stopped Flame to depend on plugins with native code). Also, dart and pub have a very nice tree-shaking algorithm, so we thought it didn't really matter.

Now, for 1.0, after a lot of discussions, we decided to move to a more package separated approach. We want everything that is not absolutely core to be its own package. That way, Flame will not have many (if at all) dependencies. It will never have any native code. And anything that is an integration with something else should all be separated plugins.

These plugins will be called flame_* and will live in our GitHub/pub organizations. They can still be built and maintained by us, but also there can be other new ones entirely by the community (like the awesome package bonfire, for example, be sure to check it out).

This will allow Flame to be simpler and leaner, have fewer dependencies (and therefore fewer breaking points). The packages we are planning on extracting are:

• flame_audio
• flame_flare (and flame_rive)
• flame_box2d
• flame_tiled

These plugins will peer depend on flame and have the same nice helpers we are used to. For example, we also happen to maintain our fork of the box2d.dart package, which is a Flame-agnostic port of box2d to dart. Flame, likewise, will know nothing of box2d. And flame_box2d will have all the binding code, the Box2dComponents, the connections, the helpers to make it all work. Similarly, flame_audio will depend on audioplayers (and possibly other audio libraries) and provide everything flame currently adds vis-à-vis sound (like AudioPool). And so on.

One reason we started doing this already is due to some technical difficulties, especially with the plugins that depend on others. For example, the tiled package was updated to use a new Flutter version, forcing Flame, which depends on it, to do so as well. With this change, flame_tiled will be solely responsible for updating tiled and keeping it compatible. No one that does not use tiled will have to care for this particular issue.

In order to keep it all consistent, we will be creating a brand new flame_example, that will contain all flame packages and use Dashbook to provide all the examples we have now on doc/examples, and many more, making sure they all work together nicely.

We hope this change will make our life easier to maintain our packages and also make everyone's lives easier as well by making it simple to "pick and choose" the modules you need and not care about the others.

Now, let's set all the 1.0 hype aside for a second, so we can get to the rest of the news, our second big announcement.

We are also thrilled to share that we will be holding a recurring online event focusing on the Flame community: FlameCon.

Our plan is to create a space for people to share the awesome things that they build with Flame, and it will be open to everyone that wants both to present, or just to watch.

The first edition will be held on Sept 16, 2020 at 20:00 UTC, and will host two talks:

• Building RPG games with Bonfire, in which Rafael Barbosa, the author of Bonfire will present about this awesome RPG engine built on top of Flame.
• Optimizing sprite usage with Fire Atlas, in which Erick Zanardo will show what this tool is and how it can help you optimize and organize the sprites on your Flame game.

To participate in the event, check our official page here, and be sure to join the out MeetUp group; all needed information will be provided on those links!

That is it for now, everyone! We are really excited and working hard to bring v1.0 to fruition, and we are really, really excited to be hosting our first ever FlameCon!

TL;DR: Flame 1.0 is in the oven and first Flamecon will be held on Sept 16 at 20:00 UTC.