DEV Community: Luan Nico

[Boost]

Luan Nico — Tue, 12 Aug 2025 14:33:14 +0000

Erick for Blue Fire

Aug 12 '25

How to avoid ghost lines and render artifacts in Flame

#flutter #flame #gamedev

Comments

5 min read

Idiomatic Collections with Kotlin

Luan Nico — Mon, 21 Nov 2022 18:21:53 +0000

As I review many PRs in Kotlin, I've seen many ways people use to create collections (Lists, Sets); and while they all work, I think the different ways have different pros and cons for what you are doing. So I decided to put together this article to better explain my very philosophical views on this matter.

What do I mean by “creating collections”? Specifically in this article, I am referring to when you create a list/set given its size and a formula for its elements. So not things like listOf, setOfNotNull, or buildList – which are all great for their own use cases.

The `for` loop

The most basic way that comes to mind for solving this problem is using a simple for loop.

As an overarching example in this article, say we wanted to create a list of n random Users to use in a test case. One could do:

val users = mutableListOf<User>()
for (index in 0..n) {
  users.add(User("John"))
}

The problems (admittedly, “nits”) I see with this approach are as follows:

Using a mutable list

While not necessarily bad, this is something we want to avoid when the list doesn't need to be mutable. This is similar to using val (instead of var) when you are not modifying a reference. Reduce the cognitive load necessary to understand your code.

While we could hide this mutability as an implementation detail into a buildUserList function that returns a List, and that would be perfectly valid, all the alternatives I will propose will bypass this problem entirely.

Non-functional style

Using for loops, while sometimes clearer (or unavoidable), often means we are writing "implementation details" rather than expressing what we want to happen -- especially if you are using manual indexing.

More often than not, functional styles can be much more clear on the "intent", rather than on the "how".

For example, compare a simple map operation done with the for loop:

val results = mutableListOf<String>()
for (element in original) {
  results.add(transform(element))
}

with

val results = original.map { transform(it) }

Again, we are reducing the amount of information you need to parse the code - bit by bit.

We don't care about the `index`

Sometimes you might care about the index, sometimes you might not. We will explore solutions below for each. If you don't, the for loop forces you to declare a new variable (the infamous i) and, again, increase context with a meaningless variable.

In all of the alternative proposals, you will be able to optionally access the index via it -- while at the same time not having to declare it explicitly if you don't care about it.

We don't care about the range (specific start and end)

We just set out to create n users. Not only we don't care about the index; we don't care about the range. We just want the size to be n, we don't care about the start value and end value.

In fact, this can lead to quite the confusion. While the other points can be absolutely trivial in isolation and only matter when taken as a philosophy for the entire project, this one can actually lead to immediate bugs, due to the confusion between the inclusive and exclusive range operators.

You can argue that they are clear and easy to distinguish, and, in fact, IJ will helpfully annotate them leaving no space for confusion:

But it can be something to be missed in a quick code review. In fact, as an example of that, did you notice that I intentionally mis-used them in this example? 0..n is the inclusive range. So this should be either 1..n or 0 until n. Easy mistake to not notice on a code review -- which doesn't mean we shouldn't use ranges, but definitely means there is no reason to introduce this complexity if we don't care about it.

Note: I am aware that, in the time it took me to write this article, the gods of Kotlin went ahead and fixed the non-intuitive ranges issue, but I believe my argument still stands that there is no reason to introduce a composite concept (range) if we only care about the size.

Alternatives

While the for loop is far from terrible, and the problems I pointed out are very small nits, Kotlin has such a range (pun definitely intended) of other options that can be much more suitable to you depending on the situation.

`repeat` function

The first (and by far simplest) alternative solution to consider is the repeat function.

Use it if you don't care neither about the resulting list nor the range:

repeat(n) { saveUser("John $it") }

`List` constructor

Unknown to many people, but List actually has a List(size, factory) constructor! No need to do map over a range if you don’t care about the range, but do care about the generated list:

val users = List(n) { User("John $it") }

This is simple and clear and allows you to specify a size directly (which is what you care about here).

`map` over a range

If you care about the resulting list, and also care about the range, that is the place you should really use one. But the cool trick is that you can map the range directly into your result list:

val users = (a..b).map { User("John $it") }

Here, a..b is an example, but you can use until, downto, etc -- build the range you need.

`forEach` over a range

This is the final thing to callout: if you do not care about the generated collection, do not use map. I see this so often on PRs, and it is, semantically, completely wrong.

Kotlin offers a perfect replacement already for map when you don't care about the result: forEach.

(a..b).forEach { saveUser("John $it") }

Or, if you are using the index variable anyway, you can go even simpler, and just use the plain old for loop, as, in this last scenario, it doesn't have any of the disadvantages mentioned in the previous section:

for (index in a..b) {
  saveUser("John $index")
}

Conclusion

I hope this article illustrated my point about why each slightly different pattern is better for slightly different circumstances, and that you were able to learn the rationale behind each, so you can apply such reasoning on your own code (rather than memorize instructions).

I know all of this might seem absolutely trivial. On every isolated example, reading the code is always super easy. However, when reading an entire function, every little bit contributes to the difference between an immediate understanding and a minute of thinking. When reading a code base, well, you see my point. These kinds of things littering a codebase add up to cause substantial cost.

I strongly believe that, on huge projects, maintained by multiple people at the same time, keeping the code clean, even if by addressing such seemingly tiny nits, is paramount for velocity, maintainability, and developer happiness over the years.

And finally, I encourage my fellow PR reviewers to refer to and share this article whenever you want to quickly express all these points but don't have the time to write an article-length comment on such philosophical matters.

Flame 1.0 is here!

Luan Nico — Wed, 08 Dec 2021 18:56:50 +0000

Hi there, folks! It's been a while since our last article, but if you are following Flame on GitHub or participating in our Discord, you know very well that we have not been idle. Far from it. In fact, you might have noticed more and more Release Candidates being put out regularly, mostly with some needed updates and cleanups, a few new core features, bug fixes, and incorporating valuable feedback from our amazing Game Jam. That is because both the team and the community have been working together, relentlessly, to make Flame the best it can be.

And, first of all, I would like to make it very clear that we are not done with this goal, not even close -- the pile of things we know could be improved, extended or added is only shadowed by the mountain that we don't even know about yet. So the first thing I would like to reassure everyone, with this article, is that nothing really changes in that regard. We will still be putting out PRs, receiving invaluable help from the community, making improvements, new features, bug fixes. We will still be at discord, helping out new people, having deep, productive discussions with veterans, and collaborating together to keep growing and enhancing all Blue Fire's projects.

That being said, we do have a key milestone to share. You might have already heard about it on the Flutter 2.8 release article, or maybe got a sneak peek on pub; but, regardless, we wanted to double down and proudly announce we just released Flame 1.0.0. Yes, it's official, and finally here! What an end-of-year holiday gift to us to finally be able to say that, given all the work that has been put into it! We are very happy with the current state of our code and the capabilities provided, and we think it's time to make this commitment. Thank you so much for every single one of you, that contributed with PRs, discussions, questions (that led us to improve some docs or reconceptualize some API), monetary donations via our Patreon, or that used Flame, made something great, participated in any way, gave us a star on GitHub, or just for reading and sharing this article. Thank you, from the bottom of our hearts.

And let me reiterate; we are still going to keep improving, updating, fixing, enhancing Flame. In fact, I hope version 1.0.0 lives very briefly on pub, to be replaced with 1.0.1, 1.1.0, whichever comes first, very soon. This just means we believe the current API is stable, and we won't be making big, breaking changes that often, or without warning. Expect more structured, stable updates, especially new features. It also means we can focus our attention now to improving our docs, bridge packages, tooling, examples and tutorials to make sure this awesome ecosystem that came about works seamlessly and frictionlessly, and that people can easily welcome people to join and learn. We are also happy to have established and to carry on this partnership with the Flutter team to make sure we all pave a future together for Flame and our beloved community.

And on that note, we ask you to update your dependency, head over to Discord to continue the discussion, and if you haven't, please check Flutter's article about all the amazing things packed on Flutter 2.8, and let us know if you have any feedback! Thanks everyone again for everything, and have a great day!

Five features I wish Dart had

Luan Nico — Mon, 29 Mar 2021 01:00:04 +0000

The Dart programming language has recently undergone a major version update, 2.12, which brought sound null-safety to the ecosystem. With the recent announcement of Flutter 2.0, supporting web and desktop alongside mobile, this new version of the language has been gaining a lot of traction as project maintainers such as myself start or continue to migrate their packages to support it.

And the first thing I have to say about it is that it's great. I already loved Dart before, and this was definitely one of the most important things on the roadmap. I particularly love typed languages; after many years working with Javascript, which I also really like, I came to the realization that the extra cost of typing pays off (and the recent popularity of Typescript helps to substantiate this point). And Dart has built-in type safety, which is great. But after a lot of time using Kotlin and Swift, that not only offer types but null-safe types, I realized, on the same vein, how important this feature is for writing great, resilient applications, help developers avoid mistakes, code quickly and safely.

And I realize one big burden (on the other side) of types is the extra verbosity it inherently introduced. For example, whenever I coded in Java in the past I was very happy with the security and stableness types provided but it just felt like a lot of extra work compared to JS. But it doesn't have to be that much, and Kotlin, Swift, and the newer versions of Java showed me that, if you bring (1) yes, types but also (2) a lot of (sometimes small) language improvements, syntax sugars, helping features, you can get the benefits of types with very little overhead. And that is where I think they shine. Now, the same thing is true for null safety. Imagine if we didn't have the Elvis operator in Dart, for example. Would be much more painful to write proper null safe code, up to a point it starts to compete with the benefits in the first place. Granted the pros and cons are in different areas (ease of coding vs stability and fewer bugs), and that is why this is ultimately a matter of opinion. But the better the language is at providing the right features that allow developers to write pretty, understandable code easily and quickly (like by adding the Elvis/null aware operators), the more attractive it becomes to be on that side of the scale.

And, again, I really like Dart and all it has to offer, and I am totally in favor of type and null safety being on the language. But having spent some time migrating packages and apps, I believe there are a few things that would make everyone life's much better. These are relatively small, non-disruptive, non-breaking, incremental changes that are not necessarily directly related to null safety but that, especially if you worked with languages like Kotlin and Swift before (my main sources of inspiration), you might miss when migrating code. The fact that null safety inevitably adds some extra level of boilerplate helped expose these needs more clearly to me, in a way that I hadn't necessarily craved them before.

My goal with this article is far from bashing Dart (I think I made it more than clear how I feel about it!) or to mourn the unchangeable fate of the universe, or anything like that. In fact, I currently use Dart in my free time purely because I like it. But rather my goal is for this to be a proposal, both for the community and (hopefully!) for the Dart team, a set of ideas that can be picked from, studied, mix and matched. A showcase of, in my opinion, great things other languages have to offer (for those unfamiliar). A collection of wishes and anecdotes.

And I should try to finally get to my clickbait-y title quickly because I've been vaguely rambling for a while putting a lot of trust in your patience with my digressions. And I swear it's coming and they are going to be very concrete, specific things (now I am just building anticipation). But the last thing I wanted to mention before getting right into it, and there is no way I can omit this reference, is the library Dartlin.

Full disclaimer, Dartlin was created by my friend Jochum, and I have contributed to it after I learned of its existence (since, as you can imagine by this article, I loved the idea). It is basically a Kotlin inspired set of features, built in the library level (using for example things like Extension Functions) that aim to bring great features from Kotlin to Dart. I will mention on some of these features how the proposed effect could be accomplished with Dartlin. However, no matter how clever Jochum gets at the library level to replicate some features, it can never be as good, as simple, easy to use as a native feature. Also bear in mind adding extra functions, lambdas, et cetera to emulate non-native concepts has a performance overhead, so I definitely endorse Dartlin but I recommend making sure it's not causing an application critical bottleneck (and there could be a whole other article about what really matters for performance of a given app versus premature optimizations).

Now, with all that out of the way, finally, here are 5 features I wish Dart had (natively), in no particular order:

1. Kotlin's `let`

A very famous construct in Kotlin is the let function. Basically, it is one of the more famous so-called Scope Functions. And it's particularly useful for null-safe code. The implementation is deceptively simple; it's an extension function on Any that invokes a lambda where the first argument is this callee. Seems useless? Well, one simple use case where it has a small role could be this:

 string.split(",").let { Point(it[0], it[1]) }

Instead of having to name a variable with a meaningless identifier, this one-liner is easy to read and a quite nice use of let. But where it shines, as I mention, is in the NS world, when paired with ?.. But let's get there through an example. Imagine you are converting Dart function on the codebase to null-safe Dart:

int addTwo(int arg) {
    if (arg == null) return null;
    return arg + 2;
}

Seems like a totally reasonable function, but actually, in the null-safe world, it's a bad pattern. Because once you convert it:

int? addTwo(int? arg) {
    if (arg == null) return null;
    return arg + 2;
}

You see the issue. This function is a black hole! It's destroying information. Imagine you have a totally legit, verified, safe and sound int variable. Non-null certified.

  final totallySafe = 1;
  final result = addTwo(totallySafe); // oops, result is `int?`

If the argument is already a nullable variable there is no issue, but if your parameter is non-null, that precious information is lost forever. So normally, you should not take a nullable parameter in a function if (1) the output of a null parameter is always null and (2) the only case where null is returned is with the null parameter. You are much better off having:

int addTwo(int arg) {
    return arg + 2;
}

And let the callee deal with its nulls. Witch is fine if the variable you have is non-null. But on the other hand,

  final int? a = maybeGetInt();
  final int? result = a != null ? addTwo(a) : null;

Is a bit of a mouthful. So imagine you could do:

  final int? a = maybeGetInt();
  final int? result = a?.let(addTwo);

Cool huh? When you think about it it's an extension of ?.; where ?. allows you to optionally call a property of an object, ?.let allows you to optionally call a function with an object. You can also use it with a lambda:

  final bread = wheat?.let((it) => mill.process(it));

Basically, you can look at it as a map operation if you look at the optional as a monad. And map could possibly be a better name in the Dart world, though it would conflict with the List.map.

But the best part of this list item is that let, as I first said, is just an extension function. So this is one case where Dartlin is able to simply add it. No caveats, no hacks. It will work just like the examples! Just drop in the dependency on your pubspec.yaml and import the control flow sub library.

2. Swift's `if let`

Dart (since the beginning) has had type promotion (also known as smart cast in other languages). In simple terms, if you assert a type to be of a more specific subtype, you don't need to cast it in that context. For example:

Animal animal = getAnimal();
if (animal is Dog) {
    animal.bark(); // smart cast to Dog
}

Which is great when you think about null-safety is just an extension on the type system. Dog? is just a supertype of Dog. So, similarly, when you do:

Dog? dog = maybeGetDog();
if (dog != null) { // really this is just check for `dog is Dog`
    dog.bark(); // smart cast to Dog
}

However, you can't be too clever with it. Smart-cast only works for local variables and parameters. It just cannot work for fields, because:

fields can be changed by other functions called in your context
fields can potentially be changed by other threads (not currently a problem in Dart because it's single-threaded)
fields can be functions with custom getters that can return arbitrary results

There are many threads and issues on GitHub about this, asking for smart cast to be, well, smarter. But there is no way to do it safely. It's just too complex for the compiler to check these things. Kotlin also does not provide smart cast for fields. And I don't think this feature is worth having an unsound type system (going back to my initial rambling). But we don't need to. Swift offers a very elegant solution to this problem, which I think is just cleaner than smart casting altogether: if let.

In Swift you can do:

if let dog = animal as Dog {
    dog.bark()
}

Alternatively, you can use the same variable name (for, say, a null check):

if let animal = animal { // short for `let animal = animal as Animal`
    animal.live() // animal is not nil here!
}

Basically, you don't need smart cast if you can easily declare a new local variable. Instead of doing:

// field: var Animal animal;
final animal = animal; // I am just copying a field to a local variable
if (animal is Dog) {
    animal.bark();
}

We could do something like:

// field: var Animal animal;
if (final dog = animal as Dog) {
    dog.bark();
}

// field: var Animal? animal;
if (final animal = animal) { // basically omitting the `as Animal` part for brevity since it's just a null check
    animal.bark();
}

That is clear, concise, and doesn't do any magic; it's explicit that it's creating a copy because of the variable declaration syntax, which also can save on performance if it's an expensive getter. It is also perfectly clear the scope in which the copy lives. No need to jeopardize the type safety with clever heuristics that work 99% of the time to introduce smart cast to fields!

Note as well that the for statement already allows you to declare new variables that only exist within its block, so this is quite intuitive (despite uncommon in other languages). This doesn't introduce any new keywords, and it's just an extension to the capabilities of the if statement.

I'm not suggesting smart casting to be removed altogether by the way, of course it can be left as an even easier alternative for local variables and parameters only. In fact, let me abuse this list item to share a small nit that I have related to smart cast: for some reason, it doesn't work for this. If you think about it, just like a local variable or parameter, this can never change types during the execution of a method. You might be thinking that is useless because this can never be null (it can, in a very specific scenario that I leave to you as a puzzle to figure out). But where this would really come in handy would be for mixins; imagine being able to do:

if (this is MixinA) {
    this.doMixinAThing(); // glamorous!
}

Of course the addition of if let would mitigate this pain, but still it's just one tiny nit with the existing type promotion.

3. Kotlin's `?:` hidden power

The famous "Elvis" operator is present in many languages in several different forms, and nowadays it's basically an umbrella term for "null-aware operators using question marks". There is the almost omnipresent ?., to optionally access properties, and many others, but one of the most iconic has to be the coalesce operator, that I like to read as "or else", which is ?? on Dart and Swift and ?: on Kotlin. In very simple terms, it's equivalent to "left operand OR ELSE right operand (if left operand is null)". For example, in Dart:

String? a = null;
print(a ?? "foo"); // will print foo, similar to (a != null ? a : "foo")

Simple and effective. However, in Kotlin, the ?: has a special feature that I think no other language has (that I know of). More eagle-eyed observers might have noticed that I didn't mentioned Swift's guard let on the previous list item. That's because I believe Kotlin has it figured out. We don't need to introduce a new keyword guard if we allow the right operand of ?: to throw or return. How does it work? You can do something like this:

// assuming class Animal(val tail: Tail?)

fun process(animal: Animal): Bool {
    val tail = animal.tail ?: return false

    ...
}

It's so sweet that if you know the regular ?:/?? operators you can figure out what it does. And you can throw too! Imagine doing this on dart:

    var foo = parseFoo(arg) ?? throw 'Invalid foo $arg';

There are so many possibilities! And this is just a small extension over the existing coalesce operator that is very intuitive if you already know its regular usage.

4. Null-safe methods on collections

As I said I have been converting a lot of packages to null-safety recently, and this issue got me puzzled for a while; a package had the following non-safe code:

  final element = list.firstWhere(test, orElse: () => null);

Seems like a pretty reasonable code, regardless of safety. But it breaks down when you notice that the new null-safe signature of firstWhere returns T (and not T?). Which makes sense if you don't want to add a lot of ! to your code; sometimes you just know the element will be there, and otherwise throwing an error is ok. But sometimes you expect it might not be there. And I could not for the life of me find a simple small one-liner to do what I wanted in the first place!

That is why, especially now with NS, we need new collection methods. If you look at Swift and Kotlin for inspiration, we can find some very useful additions (in particular in Kotlin).

For this example, take a look at Swift's first:

func first(where: (Self.Element) -> Bool) -> Self.Element?

It just returns nil instead of throwing. If we had that on Dart, plus our improved ?? operator, you could do:

  list.firstWhere(test) ?? orElse;
  list.firstWhere(test) ?? throw 'error';

Which just covers both use cases with a single function. But better not to change the definition and behavior of the existing Dart functions to avoid confusion. So we can look at Kotlin instead. firstWhere is just called first (with optional lambda) and it does throw. But there is a firstOrNull version, that returns null if not find. We could have that with an optional lambda:

T? firstOrNull([bool Function(T)? test]) { ... }

Now we have all 4 options! The existing first and firstWhere, and the proposed firstOrNull to cover both other cases. Similarly, we could have a singleOrNull function with optional test lambda, identical to Kotlin's.

Another one that is extremely handy is getOrNull: just takes an index and returns null if out-of-bounds (instead of throwing). Again, on the NS land, returning null, especially when you pair it with NS-operators, is a blessing.

Swift's maxBy/minBy can also be handy, as it's a bit more clearer and less verbose than trying to replicate with reduce. And particularly useful for safety is the compactMap (or mapNotNull on Kotlin) that maps and filters null values in one batch, meaning that it can chain to T instead of T? (if you just do filter((e) => e != null) the compiler doesn't know the subsequent sequence/stream is NS).

The great news about this one item list as well is that these are just proposals to add functions to the SDK, which, as we already learned, can be easily done with extension functions. That is where Dartlin comes to rescue again, providing all the aforementioned functions (with the Kotlin nomenclature) and even more (like the handy associate or groupBy). Another useful bit of code can be found on my ordered_set package's Comparing class, to be used alongside functions that take sorting orders. So you can get all these goodies right now, but would be even better to have them standardized into the SDK.

5. Statements as expressions

This one is pretty straightforward. Unlike Swift, Dart, or JS, in a few languages, like Kotlin and Rust, if and switch statements are expressions. For me, that is just a bonus that brings no hindrance. It's like adding sauce to your pasta. And it's optional of course. Use it if you want.

Now, you are definitely thinking right now, we have had the ternary operator (a ? b : c) since the primeval C language. And yes, the reason why Kotlin's if in particular is an expression is because Kotlin doesn't have the ternary operator. And they have their reasons, which you can read on the discussion thread about it. So that is it? List item 5 is a hoax? Not so fast.

First of all, I like the ternary. I'm not saying, at all, to remove it from Dart. But it has a few small issues that could be complemented by having both. When starting with Kotlin most people miss the ternary, but once you realize the language has if statements as expressions, you barely miss it anymore. What's the difference?

    final a = isConditionTrue ? 1 : 2;
    final a = if (isConditionTrue) 1 else 2;

In that case pretty much nothing (I don't think small preferences of expressiveness vs succinctness are enough to propose Dart to change). Where the if gets the better of the regular ternary though, is when the expression is not so short. If it doesn't fit in a line. Imagine this code:

int i;
if (isConditionTrue) {
    // several lines
    i = result;
} else {
    // several lines
    i = result;
}

Because we don't have if-expressions, I am forced to declare that variable i as var instead of final, even though I don't plan on modifying it. I could get all the benefits from the compiler by marking it as final if the compiler was able to understand this:

final i = if (isConditionTrue) {
    // ...
} else {
    // ...
}

And yes, that can be done with the ternary, but if the bodies of one or both of the paths are big, you can get multi-line (or worse, nested) ternaries, which are particularly hard to understand and format in a pretty way. You could extract the blocks to functions, but sometimes to do that you are forced to pick very long names because those blocks weren't easily describable (which is why they weren't functions, to begin with). And with long names on the 3 operators (plus the output variable name in this case), you can easily get past your preferred line length even with the succinct 2-character operator.

And that is not the only reason Kotlin opted for statements-as-expressions instead of ternary; while the ternary can replace the if statement, Kotlin has an extremely powerful when statement, similar to the famous switch. And even though Dart's switch is fairly inflexible, being able to do this:

final result = switch(enum) {
    VALUE -> 1
    VALUE -> 2
    VALUE -> 3
}

That is a very type-safe and concise way of mapping values, which would be just terrible to write with nested ternaries (and not type-safe when using a Map, because switches guarantee exhaustion).

Now, I would love to see more options for Dart's switch, so it could be as powerful as Kotlin's or even Haskell's case. But that is a much bigger change, that would require a lot of thought and profound decisions, since other than enums, who would more benefit from compile-time guaranteed exhaustion and pattern matching could be things like sealed classes or union types. And I think that is definitely something worth exploring, but not in this article; I am focusing on small, (hopefully) not very controversial changes that are for the better, in my opinion.

And finally the last statement that I would like to mention is the try. Having try as expressions is incredibly handy and cannot be replaced by any other feature Dart currently has. It leads to much cleaner and readable code, for example:

  final variable = try {
      parseInput(arg);
  } catch (ex) {
      logger.log(ex, 'Failed to parse input $arg');
      getDefaultValue();
  }

Again, preventing you from having non-final variables that you then have to guess if they have been initialized or not -- have the compiler deal with that for you.

This list item is a language-level proposal, not an API change, so you would think there would be no package dependency mention here. Well, turns out Dartlin provides if, when, and try as expressions via functions. I won't delve much into how it works but if you are curious (I know you are), check out the readme for more details. This is also possibly the biggest change of the bunch because it introduces this concept of implicitly returning the last expression on the block of these statements, but I believe it's quite intuitive to pick up and would make a good addition as well.

And with that, I conclude this article. I mentioned 5 (relatively) small and (hopefully) simple features that I wish Dart had. Features that are optional, backwards compatible, and, IMHO, don't stray too further from what Dart already has to offer. Some can be emulated with different levels of fidelity using external libraries, like Dartlin, or clever workarounds, but in general, I believe adding these (or a subset, at least) to the language should be seriously considered, especially in the new Null-Safe world. Finally, I would like to thank all the people on the Dart team that helped make NS a reality and all the awesome package maintainers and contributors that are tirelessly converting their and other people's code to make sure everyone in the community has an even better experience with this awesome language. And I hope you liked this short read and maybe even learned something new and cool about the sprawling, creative world of programming languages.

Flame 1.0 on the horizons

Luan Nico — Sat, 05 Sep 2020 19:18:03 +0000

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.