Flax Engine

In a year full of personal experimentation in other carrers (like running for congress, for example :), I still programmed a lot. I invested a lot of time studying Docker and containers, Kubernetes, Home Assistant and hosting web systems myself (like Nextcloud).

But game design is a passion.

I’m constantly get annoyed with Unity3D and the latest events in the business side, had me to worry even more. I tried to use Godot and failed. C# is far better in terms of easy-to-use and safety and compared to C++ and even more to custom scripting languages. It’s more organized, well documented. And I have years of accumulated experience. And Godot-C# integration is buggy, unstable and full of gotchas. The way they re-implemented C# in the upcoming Godot 4 created so many artifacts to properly work that I got even more frustrated. I could not use Lists<>!

After watching a curious review in GameFromScratch channel, I tried a new kid in town: Flax Engine. It’s a C++/C# engine heavily inspired by Unity. The from-to process is straight forward. After just a of weeks playing with it, now I decided to invest in it. I am planning to port my closest-to-finish game I have to it by the end of year. It’s 1 step back, 2 steps forward.


πŸ‘Ž Like Godot, there is no way, currently, to drag-and-drop assets and actors with a specific class. I always have to ask for a generic Actor in the editor and check if has the given class in code. Annoying and error prone.

πŸ‘Ž Still lacking several common features, comparing to Unity and Unreal. It’s evolving and, mostly important, their competitors pave the way for inspired clones like Flax.

πŸ‘Ž Minuscule community compared to other game engines, even the indie ones. Recent Github report of biggest Open Source projects do not place Flax into the top 10.


😐 Not FLOSS. It’s open source but it’s not free. The license requires paying royalties. It’s very close to what Unreal asks but more generous. I would love to see it converting to a full FLOSS model in the future.

πŸ‘Ž Old C#/.Net version. A branch with newest .NET 7 was created and being developed. The current version uses .Net Framework 4.8 and it is a pain to install on Linux.

πŸ‘Ž Still lacking Docker image for CI/CD (well, Unity and Unreal also do not have official ones). I might implement a repository myself, inspired by GameCI ;)


πŸ‘ 1-1 adaptation from a Unity developer. It’s not as feature rich, but it’s very competent.

πŸ‘ Open community. A lot of issues and Merge Requests in the project Github page. I’ve being talking to devs in a Discord channel and they are receptive.

πŸ‘ Small footprint. The editor is just a couple of megabytes and the “cooked” game is also small. If possible, running it in a Alpine-like image will create a really small image to use CI/CD.


Netlify CMS

I do maintain, for almost 10 years now, a personal journal. A diary. It’s a self psychotherapy. It’s a way to express my thoughts and feelings.

I originally used Google Docs. I created dozens and dozens of files, one for each day. Eventually, I realized that Google was not supposed to be trusted with confidential and personal information. Their spiders crawl and index everything. These thoughts may be still there, even after I delete all the files. Who knows.

Then I migrated to a secondary solution: Wordpress. I hosted a blog and used a add-on to lock it up, allowing just me to see. It’s really good for blogging, with a lot of tools. I designed myself some extra add-ons to manage some aspects of the journal, like a word count and a title generator (based on the post date).

However, maintaining a up-to-date Wordpress installation is critical. Due it’s popularity, and broad usage for e-commerce, Wordpress is a target for many many hackers. I started to think that I could let hacked and let all my stuff exposed. So I decided to export all posts and move once again.

I tried to only maintain it offline, in my computer. It’s, for sure, the most secure way. Anything that is in the internet, even if it’s secured, could be hacked. But sometimes I want to write while away from home. In a trip, for instance.

I looked for a solution that was hosted online, secure (bonus if it was encrypted), and versatile (super bonus if it was open source). I tried some days using SimpleNote then Notion. Notion is very nice and I was using not only to write my journal, but also I started to use it to track some daily routines, like checking weight, sleep time, amount of water that I’ve consumed.

But again I was not very confident about security. So, I’ve exported everything and decided to create host it only in my computer. This time, with a caveat: I was liking the usage of Hugo static site generator, so I designed a blog front end and only enable it locally. And use git to track changes and host at Gitlab. If eventually I’m not in home and want to write, I could find an app to connect to the repository and write. Months passed but I’ve never found a mobile app. So I was locked to just write locally or access the repository using VSCode or whatever.

Finally, the Main Topic

Other day I decided to check Netlify CMS. Created by Netlify hosting service, it tries to create a dynamic admin front end to manage static websites. The result will still be very much static, but the admin section is a single page with a JavaScript that will do everything. It will communicate with a online git repository and commit any new post. The authentication is done thru the git service, Gitlab in my case. It could be Github or any other git service. If the user do not have access to the repository, the admin page will be blank. It reads the source in real time.

Besides that, I could also host the final journal online using Gitlab pages, but settings that only visible to maintainers. The same authentication would be required to see both front end and admin pages. Nice solution.

Netlify CMS is VERY simple. I can only imagine how complex is under the hook, but the final experience for users are simplistic. However, it does the job: I can now access and write my journals from anywhere, including the browser in my phone.

The system relies in a monolithic configuration file that is hosted side by side the content in the git repository. Traversing all the posts from a remote git repository is very slow and not efficient. I cannot imagine dealing with a more complex team structure using it at the same time.

A nice feature is the draft mode: it creates automatically a fork with the draft content. Only when the user click “Release”, it merges the content into the main branch and publish. Netlify CMS does not require Netlify itself, but they are nicely integrated if you decided to use it.

After the successful first experience with my diary, I implemented in my blog. In fact, this very post was written using this pseudo-CMS!


Godot Jam Review

At the beginning of the year I posted about the retrial of Godot, the most popular free and open source game engine around.

I’ve posted some pros and cons at the time. I then decided to enter into a JAM to motivate myself to try to actually use it for a real complete project. Even it being a jam-like game.

Now it’s time to do a review the whole process.

TLDR: I failed to complete the game. I tried to created a pipeline to build a nightly version for the latest version, with C# support. It is partially running ok.


The Jam theme was ocean. Bonus points for those that:

  1. all sounds in-game are made with your mouth(s)
  2. include a fishing mini-game
  3. include your favorite quote or pun in game

So I started. As previously said, I’ve planned to implement a old game of mine as the main game. The advantage was that I knew what was needed and the general need. Another plus was the fact that the game was abstract, so I could save a lot of resources and time on the presentation. And by doing the sound effects with the mouth, I could neglect this front until the end.

For the mini game, I looked for a small board game that I could easily implement in the digital form. After some research, I settled with Leaky Boat, a fast paced pen-and-paper game with dice.

So I started to code. But the problems with the C# integration was getting in my nerves. Godot editor crashed more than 30 times in the very first night of coding. It was not blocking the path, but it was making it very very difficult.

New Version from Scratch

As a potential solution, I checked if the undergoing development of Godot 4 (I was using the “stable” version of Godot 3.5) had any nightly build available. I’ve found a guy that was creating theses nightly builds! But only the original non-C# version. The repository was open so I checked if anything was possible to salvage. Not much.

So, as a detour, I decided to build a pipeline on Gitlab that would compile the source code and build it. Eventually I would schedule it to run every night. However, the process of creating a build pipeline online is very tedious and laborious: on every change, I had to run in online. In the case of Godot, trigger the code compilation to eventually discover that 30 min the build start, it failed due some dependency on the build stack was not fun. It took me a whole day spending my personal CPU quota doing this.

So, as a second detour, I decided to host a local Gitlab instance in my computer. It would allow me to develop the pipeline itself. Once ok, I would migrate back to the online service. It took me 2 days to set this. I first decided to go with local Kubernetes, but it was getting too complicated. Then I migrated to a solution that I am more familiar with: Docker-compose inside a virtual machine. I created inside Virtualbox (instead KVM) because I planned to reuse it when I decided to use Windows.

Downloading and building several docker images takes a lot of space! I had to resize the VMs to a much bigger size than originally planned to accommodate the dozen images created/downloaded.

The plan was to create an helper image with all the tools needed to compile the code with or without C#, host/register inside Gitlab itself and reuse in the main pipeline. This step was working fine, but the actual build was failing time after time.

To check if the steps were right, I decided to compile inside my own machine. I did not wanted this originally to not pollute my pc. But worked. Since I “wasted” several days in this detour, I decided to use this local compilation into my project again.

New Version, Old Problems

Godot 4 renamed several classes. Also, it changed several small things internally and it took me couple of ours migrating to the new environment. Good thing is that I did not have much to convert. Done. And the game was working the same as before.

Now it was time to continue the development. But the problems continue the same way: the editor was crashing time after time. I managed to make both the game and the mini game functional, but with several restrictions. The pace was slow, because I had to investigate the way of doing things all the time. And the documentation was definitively not comprehensive for C# users.

After 5 days, I gave up. :( I could theoretically finish the game in a certain state, but I decided to focus my attention to other projects instead. I might try to go with this engine later in the future, but for now, I will return to Unity until I finish one of my projects.

A couple of days after the end of the jam, Godot 4 alpha 1 was released. I still think that, if the devs do not provide a nightly version by themselves, my project has some space.

Despite the failure, I’ve learned a lot about Godot, Gitlab and Kubernetes. Specially the later two. I will use it in the future for sure, so I do not feel the pressure of failure.

All the code, even incomplete, are open source in my Gitlab profile.

Also, they are organizing a Jam every month. I can reuse all to the new jam, for certain.


Trying Godot Engine Again

It’s about 10 years I discovered Unity and felt in love. The editor was great but I really liked programming in C#. I allowed me to both organize and creative.

Despite being the among the top 2 suites in the world, I’m increasingly annoyed by them. It became a huge spyware, heavy and the full of annoyances. Beside being super expensive (for Brazilian standards), the pricing model is much less indie-friendly than it’s nemesis, Epic’s Unreal Engine. Users pay upfront instead paying royalties of their own success.

Time to explore new grounds! In fact, I try new stuff all the time. It’s time to land in new grounds! Some criteria to consider:

  • Open source preferred, almost required.
  • Avoiding C++ (because my games would leak memory of certain). Javascript is discarded due performance. Rust is hot, but an engine supporting it is probably super beta.
  • Small footprint if possible.
  • Pro developer tools, like CI/CD headless compilation.
  • Big community or organization supporting it. The lack of big support is an abandoned project wannabe.

So for the past months I tried to play with several options. Notably:

  • Unreal is unbearably gigantic (7gb+), which hits specially hard on CI/CD. And Linux editor is buggy.
  • I was excited by Stride/Xenko, but months after the open source, it was basically abandoned.
  • Godot have that annoying scripting language embedded, but the no-go was the lack of a equivalent of ScriptableObject to create data assets.
  • O3DE is a possibility for the future. Lua as scripting language is a personal nostalgia.

Spark of hope

Then I read an article about creating data assets in Godot. It used C#. It was not a trick or complex. Pretty straight forward. I decided to try it again. Less then 100 mb later, with no need to install or register, I started my -again- first project. The goal was to load data from a asset created using C# code, just like a ScriptableObject in Unity. The test was a success.

So it’s time to try to create a full prototype game! I’m planning to joining one of the several jams they organize to motivate myself to finish. No prizes involved, just challenge. Things to explore in order to be conformable with:

  • Client-server multiplayer.
  • Scene streaming.
  • Animations.

Another idea is to recreate an old game of mine: PICubic. It was not commercially released, so it might be a good way to learn and expect results.

Some general thoughts

After a week that I’m playing with it. Some thoughts:


πŸ‘Ž The design principal that each node have only one script attached instead the super common component-driven approach lacks. Specially trying to design very complex systems using small parts, like the micro-services in the web development. I heard once there are a spin-off that implements this, but there is no traction in the community.

πŸ‘Ž C# integration is still not good. At least in my computer, the editor crashes each 30 min on a random time I hit play. Also, the editor do not display custom C# classes in the inspector. I design several vanilla classes to organize the code, but I had to transform them into Resources to be able to edit their data.

πŸ‘Ž Linking assets in the editor does not respect the class restriction. One could insert a Player asset instead Weapon and the editor will not complain. I have to check before using a external variable every time.


😐 Refereeing nodes in the hierarchy and in the asset folder are two distinct things. Nodes in the hierarchy are accessed by NodePath while prefabs (here called PackedScenes) have a different type.

😐 GDScript: focusing on a custom language instead a vanilla widespread like C# or C++ is a waste of both newbies and Godot’s own developers energy.


πŸ‘ The everything is a scene approach fascinates me. I always thought this way in Unity: scenes are just a special prefab.

πŸ‘ Creating an automatic build pipeline on Gitlab was a breeze. Due the smaller container and less complexity, it takes less then 2 minutes to create a build on any platform. A empty Unity project takes this time just to download the 4gb+ image and at least 5 more minutes to compile.

The project development is somewhat slow for my taste, but they are receiving more and more financial support in the last months that might enable them to accelerate the pace. I’m specially interested in the new external language integration for the upcoming Godot 4.


GitOps Lifestyle Conversion

I’m currently fascinated with Gitlab’s handbooks. I heard of companies trying to be more open to the public, but the extent that Gitlab is doing is unprecedented. They are documenting everything publicly. Most, if not all, internal processes are getting written for everyone to see.

  • How admissions are done? It’s there.
  • How and when employees are bonuses? It’s there too.
  • What is the ERP used? It’s there.
  • In fact, what is the whole list of external software and service used? It’s there too.
  • The scripts used to manage it’s own site? It’s there too.
  • Personal information, like employees actual salaries? Of course, are not there.

Too much information? Maybe. But it’s definitively inspiring.

Another source of personal inspiration comes from a guy on Twitter: Keijiro Takahashi. This Japanese programmer does several mini-tools for himself but publishes everything on Github with minimalist’s licenses like MIT.

In contrast, I was checking my LinkedIn the other day then I decided to share my Gitlab and Github accounts. There are so many projects over there. #ButNot. Most, almost all, were private! Many game prototypes, small side projects. All locked. Some are basically live backups, since are not updated for ages. So I decided to do two things:

  1. Open some of the closed projects
  2. Git-fy some of my personal and professional projects
  3. Documentation as code for my new company

The first is pretty straight. Mostly checking a box. Sometimes adding a small README or LICENSE files. Few times making real changes.

The second is a new mindset: I have dozens of small projects, from games to personal scripts, that I’ve never used git to track changes. But not only I could get better control of it, but also I could share with the world. You will see more and more projects popping up in my Gitlab account page.

The third, follow partially Gitlab’s way. I’m considering in documenting most of the processes in git-like wikis. It will not only good sharing the knowledge with other employees and partners. It’s also good for tracking the business decisions that changed these processes. A rather clever approach.

Bruno π•„π”Έπ•Šπ•Šπ”Έ