Forem: Erick

One month after my game release, Android Edition

Erick — Mon, 01 Sep 2025 14:11:10 +0000

Sometime ago I published my first "Build in public" article about the first month since the release of my game on computer platforms, and today here I am again, this time to share some of the statistics of the release of that same game, but now on the Android platform, in the Google Play Store!

The numbers!

The game was released on July 31st and the date of the writing of this article is September 1st! The following numbers are about that period.

495 people visited the game details page and 13 people bought the game directly from the page, giving a 2,63% conversion rate.

This is a graph of amount of visits in the game page, and acquisitions per day:

In total the game had 23 orders, 8 refunds, totaling 16 "final sales", giving a gross revenue of BRL 125,25 (something close to 23USD using todays exchange rate).

Insights

I must confess that I was expecting the game to perform better on android than it did on the computer platforms, giving its casual puzzler nature, but it still is not a bad result I guess!

I can see from the amount of people that visited the game page, that people have been finding and seeing the game, but the low conversion rate makes me believe that paid games have a hard time on the platform?

At the same time the number of refunds also makes me believe that I need to improve the game somehow! It is just a bit frustrating that I have no feedback from users on why they wanted to refund the game.

Maybe the game was just not their cup of tea? Or maybe there is something that they disliked and lead them to want their money back? I guess will never known.

Wrapping up

All in all, I am happy with the results, could it be better? Definitely, but it could also be way worse, this is the first time that I release a paid game on the Android platform so I am glad that people played my game and hopefully had fun!

For my next android game, I plan on trying a different approach, making it free, adding ads to it (in a non predatory way!) and provide an IAP to remove the ads, I have the feeling that this might make the game perform better.

If you wanna check the game out, take a look on it on Google Play: https://play.google.com/store/apps/details?id=xyz.cherrybit.minecart

Thanks for reading and following up my work, and as always, feel free to reach out anytime!

How to avoid ghost lines and render artifacts in Flame

Erick — Tue, 12 Aug 2025 13:18:11 +0000

If you ever developed a 2d game, you might have had to deal with “strange rendering artifacts” when using sprites from a sprite sheet.

Consider the screenshot below:

If you have a good eye, you might already have noticed the artifacts that I am talking about, but since this screenshot was compressed and scaled down to be presented here in a web page, it might be hard to spot them both, so let me zoom in in the issues:

Note this “ghost line” between the tiles.

Note how a thin line appears on the left side of the knight

You make sure that your src position and src size is exact, you make sure that your tiles are correctly aligned with each other, yet, you can't get rid of these annoying lines.

And that is not really your fault! These artifacts can happen in a variety of different contexts, they are common to happen when any camera transformation is used, be it zoom or translation, it can happen if you scale up or down the sprite, or even when you simply have it positioned with long decimal values.

Still, no matter the context, the root cause is the same: computers have a limited precision on float numbers and their decimal values.

That imprecision can make sprites that are supposed to be perfectly aligned, as in if they are positioned edge to edge on each other, to be rendered with a very thin line between them, causing what we call ghost lines.

The issue we see in the knight is a bit different; first, take a look at the whole sprite sheet that we are using:

Let's zoom in a bit in our knight:

Note how we have the sprite of another knight on the left, and that sprite touches the border of the knight that we are rendering.

Even though we set the src position correctly to start on the exact pixel, when rendering the whole scene, when all the underlying transformations are applied, that imprecision will make the rendering of our sprite accidentally “grabbing a small section” of the rest of the sprite sheet, and a thin line from the sword of the other sprite will be rendered alongside our own sprite. This is what we call a “texture leak”.

Solutions

There are several ways to fix these problems, in this article we will suggest a couple of them which are the ways that in our experience works the best and are the ones we recommend.

We presented two different issues, so let's tackle them individually.

Ghost lines busting! Who you gonna call?

A reliable way of fixing those ghost lines that appear between aligned tiles is to use a technique known in the game development world as “pixel bleeding”.

The idea is that we render the sprites a little bit bigger than its original size, that way, the added size will cover that thin line, but it is so small that will not be noticeable by the human eye.

Starting on Flame v1.3.0 all sprites and sprite components can be rendered with this bleeding effect:

    const bleedValue = 0.04;

    final spriteImages = await images.load('little-adventures.png');
    world.add(
      SpriteComponent.fromImage(
        spriteImages,
        srcSize: Vector2.all(8),
        srcPosition: Vector2.zero(),
        position: Vector2(-(resX / 2), (resY / 2) - 8),
        size: Vector2.all(8),
        bleed: bleedValue,
      ),
    );

Note the bleed attribute on the SpriteComponent.fromImage and how we are passing a value of 0.04 to it. That will make the sprite be rendered with 0.04 pixels on each border, covering the ghost line!

Note that the exact bleed value depends on multiple factors: The size of the sprite, the zoom level or the current viewport, bigger sprites might require larger values and so on, before settling in a bleed value, be sure to test the game in different resolutions and zoom levels, and depending on how dynamic the zoom of the game is, consider making the bleed value proportional to the applied zoom.

Texture leaking plumbing!

A simple technique to fix this problem is to “isolate” that sprite in the memory. This means that when rendering the sprite in the game we will not be rendering a portion of an image, but rather be rendering an image that has only the sprite we want to render.

Of course you could get rid of the sprite sheet and make every single texture of your game a single image, that could cause many other issues though like increased IO operations etc.

So, starting on Flame v1.30.0 we provide a new feature that allows you to still use sprite sheets, while being able to isolate sprite in memory to avoid the memory leaks: Raster Sprites.

Raster sounds like a fancy word, but a raster image, or raster sprite simply means “an image in the memory”. When using raster sprites, Flame will under the hood extract the sprite from your sprite sheet and make an image in memory that represents that single sprite, avoiding the possibility of textures leaking into each other.

To use Raster sprites in flame, simply use the RasterSpriteComponent instead of the SpriteComponent. Both components share the same API.

    world.add(
      RasterSpriteComponent.fromImage(
        spriteImages,
        srcSize: Vector2.all(8),
        srcPosition: Vector2(8, 88),
        position: Vector2(-(resX / 2) + 16, (resY / 2) - 16),
        size: Vector2.all(8),
      ),
    );

Mix and match

Note that if you have multiple tiles in the same texture atlas, whereas their edges are side to side, you might need to combine both techniques and use the bleedValue attribute in a RasterComponent in order to avoid both ghost lines and texture leaks.

Flame tiled

If you use Flame Tiled for your tiled map you might still notice ghost lines as these features have not yet been implemented in that package by the time of the writing of this article, but stay tuned for future updates.

Wrapping up!

With these two techniques you should be able to get rid of any unexpected rending artifacts in your game!

Check out the official docs for the Pixel Bleeding and Sprite Rasterization and check this repository for the full example used for this article.

If by any chance you find yourself in an edge case where neither of the presented solutions work, don't hesitate in reaching out to the Flame team on our Discord!

One month after my game release!

Erick — Wed, 16 Jul 2025 17:44:11 +0000

It has been almost a month since I released Mine Cart Operator, a small puzzler game about dwarves and mining carts!

I really like the idea of the build in public so in its spirit I decided to write up this small article to share with anyone interested the numbers and statistics from my released game.

The idea in this article is to present statistics raw, with just a few comments on some of the data with some of the insights that I had while looking at the numbers, but I invite the reader to not take any of the insights as “absolute truths” as each launch and dev are unique and have their own context.

Show me the numbers

Before I share all the numbers, some important context about the game.

It was released in itch.io on June 8th, initially released with 26 levels, costing 1.50USD, with the possibility of buyers to tip higher values for the game, and a free demo is provided for free which features the first 8 levels.

On July 11th a small expansion was released, which added a new mechanic and 10 additional levels to the full version of the game, on that same day a sale of 35% OFF in celebration of the mini expansion started which lasted until July 14th!

All the numbers shared in this article are statistics between the game release data (June 8th) and the day of the writing of this article (July 16th)

Now, to the numbers:

The gross revenue: 75.50USD
Payments: 15
View: 481
Downloads: 71
Ratings: 3
Collections: 3
Comments: 4

A graph showing views, payments and downloads by day:

The breakdown of the downloads per platform:

demo-linux.zip: 8
demo-macos.zip: 32
demo-windows.zip: 12
linux.zip: 3
macos.zip: 11
windows.zip: 5

Here is another interesting piece of data, the top 4 source of incoming traffic on the game page from the last 30 days

LinkedIn: 75
Twitter: 62
LinkedIn (android app): 32
Game sales page: 20

The Insights

Two things surprised me:

I never expected the LinkedIn posts that I made about the game would bring back so much traffic and that MacOS builds would be the most downloaded ones!

I kinda associated those results to the fact that a good chunk of my network are Flutter Developers, and game development in that platform always seems to get the attention of these folks, which leads to the second surprise, for many reasons, MacOS is the most used operation system among Flutter (and mobile in general) developers, so it kinda makes sense how MacOS was the most popular platform.

Wrapping Up

It has been an interesting road so far, this is the first time that I release something out there for real, so it has been a great learning for me.

I hope that the numbers and data I shared here helps people on similar journeys as me!

I have a couple of possibilities for my next steps, which I haven't fully decided yet. Part of me wants to release the game on Steam next, and see how it performs there, part of me just wants to build more content for the game and keep focusing on the itch io platform for now.

Either way, whatever path I choose, stay tuned, as I will for sure share about the experience!

If you didn't get the game yet, check it out: https://cherrybit.itch.io/mine-cart-operator

Would love to hear your thoughts about it!

Cheers!

Fireslime is now Blue Fire

Erick — Thu, 19 Aug 2021 13:07:26 +0000

TLDR: Fireslime, the team behind the Flame Engine, is changing their name to Blue Fire. We are also moving away from the idea of being just an indie game studio and want to focus more on maintaining Open Source projects and create an open and friendly community around those projects.

Almost 3 years ago, I (Erick) and Luan started a little project together. We both enjoyed game development, and after talking about some ideas, we created Fireslime, a small, informal, Indie Game Studio.

When Fireslime started, Luan had already created the very first version of Flame, a Flutter based game engine. Since we both liked learning and exploring new things, we decided to use Flame as the engine of our games; that way, we could slowly improve the engine, while we developed the game. But back then, our focus was mainly on building games, and not the game engine itself. Flame was just a means to an end for us, a tool to create our games.

As time passed, we created multiple games. We even fully released two of them, and launched two demo versions. They didn't manage to make much success on their own, but they helped us grow Flame.

Suddenly, we started to realize that the people who were in the community Discord (that we created for the Fireslime's games) were actually there because of the Flame Engine or the other open source projects we maintain, and not for the games themselves.

As the Flame Engine and our other projects grew, so did the time we spent on them. Which inadvertently meant that we spent less time working on our games.

Over time, more people joined the team as maintainers, the first to join was Renan, a software developer, bad gamer and bad comedian. After Renan the next one to join was Lukas, a developer, keyboard builder, backpacker and climber. And last but not least, Jochum, an open source enthusiast, GitLab fanboy, collector of strange linux devices and proud owner of a Commodore 64. And while the team grew, that initial idea of being a game studio was steadily fading.

So we decided to finally embrace this situation that we found ourselves in, and officially announce our new goal and focus: working on Open Source projects and building a friendly community around our Flutter and Dart projects.

Fireslime was a name that we decided on originally for a game studio, as it was playful and friendly. But with our new focus in mind, we wanted something different; something open and something that had its roots in both Fireslime and Flutter. So, as a team, we chose the name Blue Fire.

"Blue" expresses our focus and love for the Flutter framework and Dart, on which our projects are built and our community lives. And "Fire" represents our roots, our history and our connection to the Flame Engine.

Does that mean that we will no longer build games? No! Our biggest project is the Flame Engine, and the best way of validating and testing such a game engine, is to build games with it. But now that we have our goal and focus clear, we can honestly say that we are committed to Flame, Flutter and our other Open Source projects (be it our other libraries or games), with the hopes to help and grow both the Flame and Flutter community and their corresponding ecosystem.

So, from us as Fireslime, we thank everyone that has supported, helped and followed us over these last few years. And we hope you will all keep supporting us as Blue Fire as well, and be part of our community!

The Blue Fire team wishes you happy coding.