Simon Dalvai

My split keyboard journey

Simon Dalvai — Mon, 23 Mar 2026 16:30:00 +0000

In January 2025 I got my first split keyboard. After seeing so many Vim/Neovim video content creators use them, I also wanted to try. Now more than a year later, I'm happy to share my experience with it.

corne v4</a></h2>
I just wanted to try if split keyboards work for me. My first attempt was to buy a corne v4</a>. It seemed one of the most popular split keyboards I found online.
I bought a pre-built version, so I could just plug it in and use it. This one even has RGB lights under the switches, but I never really used them. I actually ordered it without RGB, to save money, but somehow I got it anyways.
Sometimes one half of the corne randomly stops working. I assume this is related to electromagnetic inference</a>. I just have to reconnect to fix the problem, so it is not a big deal. But this shows what complex issues hardware can face (and why I love writing software instead).
I bought it with empty key-caps, because my goal was to learn touch typing. I never really tried that before and I wanted to write without looking at the keyboard. It worked! Now I can type without looking and my current words per minute record is 95.
For what I saw online, split keyboards normally cost from 100€ to 300€. But it highly depends on the amount of keys and the materials used. Sometimes only the case made of aluminium, can cost more than 100€.

Alternative layouts</a></h2>
Changing to a split keyboard is already a big change to get used to. Also changing the layout makes it even harder to make the switch. But I had to learn to touch type qwerty anyways from scratch, so why not try something better? So after a few days with qwerty, I decided to try colemak-dh.
I really like colemak-dh and it makes writing English a real joy. So many words can be written with never leaving the home row. On the long run, it should also increase typing speed and reduce finger movements.
I even tried to change layout on my smartphone to memorize the letter positions faster. But a quick web search revealed that is makes not much sense for two reasons:

A different (thumbs) muscle memory is used with touch screens</li>
On small screens having more space between frequent used keys actually makes</li> </ol>
Train everyday</a></h2>
Training is needed to overcome the first really frustrating days. Writing at 10 words per minute is not fun and my productivity dropped a lot. There are tons of websites and tools that can help with that.
I did all my training on keybr.com</a>. This site is really great and starts with the home row first. New keys unlock when a set writing speed is reached and so the muscle memory builds up consistently.
In my opinion there are two ways to learn to touch type on a new keyboard/layout

Only use the new keyboard/layout and hope that you don't give up/get too frustrated</li>
Train only 30 minutes a day and keep working with the old keyboard/layout</li> </ol>
The second one might be the most reasonable and allows to improve slowly without loosing sanity. Once a certain speed is reached, you can try to use it everywhere.
I personally did both by always using the new keyboard and train at least 30 mins a day. The first days where hard and I kept a normal keyboard close for critical situations. But overall this is the fastest way to do the switch.
Yes, I still can use normal keyboards</a></h2>
Many people that saw my split keyboard had the question if I still can type on normal keyboards. I built up new muscle memory for split keyboards, so the other remained untouched. I still write the same way and speed on normal keyboards as I used before. Of course quite slow and by looking while typing, but nothing changed there.
Probably it gets more difficult if you want to change layout on the same keyboard. There the old muscle memory needs to be "re-wired" and that can be more tricky. And the old muscle memory will partially be erased.
DASBOB</a></h2>
After 9 months of using the corne, I decided to try another split keyboard. I wanted less keys, a more aggressive pinky stagger and a more outwards positioned thumb cluster.
I was undecided between the Sweep</a> and DASBOB</a>. In the end I bought DASBOB to keep the 3 thumb keys. DASBOB even has a buzzer that can make sounds!
This time I bought a DIY kit, so I had to solder the switches and micro controller myself. While this takes more time, it was a nice feeling to have built it myself. For a moment I even considered to print the PCB and the case from a PCB manufacturer. But import and shipping costs are too high for a single PCB and case. This is possible because most split keyboards are open source and open hardware. The pcb layouts and firmware are shared and therefore can be printed and modified by anyone. Maybe for my next keyboard I will try that :-)
Vial</a></h2>
To configure my keyboards I use Vial</a>. This allows to configure everything in real-time with a nice GUI.
Currently I use 6 layers, but I plan to reduce the layer amount soon.
Layer 1 with the colemak-dh layout letters.
Layer 2 with numbers and navigation.
Layer 3 with symbols and navigation.
Layer 4 has turns on DASBOB's buzzer and some mouse clicks. I have this layer just for fun and rarely use it.
Layer 5 has all F-keys, volume and brightness control.
Layer 6 instead is my sway-wm layer, that allows me to change workspace with one hand.
I guess one day I will try QMK</a>, simply to see what the differences are. For now it seems to me, that QMK is much more powerful and allows to code a custom firmware in C. That sounds really cool!
Tenting</a></h2>
Around the time I bought DASBOB, I also started tenting the keyboard, for a natural hand position. Since I got used to tenting, writing on a flat keyboard just feels wrong
There are many ways to do tenting. First, I simply used an open book in the center, to feel if tenting works for me. Then I bought two phone stands that have magnetic rings on both sides and attached jar lids. At the bottom of the jar lids I attached some rubber feet to prevent slipping.
For some time I even had metal rings attached on my laptop. Here you can get really creative and I saw a lot of unique setups on the web.
Switches</a></h2>
The corne has Kailh Choc v1 brown switches. I would say it was a good choice, for my first mechanical switches. They are not too loud and the key press feels good and not too heavy.
For the DASBOB instead, I bought Kailh Low Ambients Silent Twilight switches and I really like them. They are more silent, linear of course and much lighter to press. Sometimes even too light. For example in the train I accidentally pressed keys when the train bumped. But aside from this, they are awesome and now the browns feel too heavy for me.
My keyboard wishlist</a></h2>
While I'm really happy with my DASBOB, out of curiosity I want to explore more variations. I would love to try concave shapes like the Kinesis Advantage, the Glove80 or the Dactyl have. This keyboards also have a tilted thumb cluster where thumb key presses movements are more natural. With normal thumb clusters the thumbs need to make a side wards movement to press keys.
Another cool thing would be a laptop with an integrated split keyboard. Framework</a> has now a one key module, that allows to build custom keyboards. The Reform Next has a cool prototype</a> that would be nearly perfect. Projects like this show why and how open hardware is so interesting and important.

I Love Free Software Day 2026

Simon Dalvai — Sat, 14 Feb 2026 22:13:00 +0000

Also this year I want to celebrate I Love Free Software Day</a>. Thanks to the whole FOSS community for another year of open software and knowledge sharing!
Now to the three project I want to thank this year <3
End of 10</a></h2>
This year I made it even more special, by installing Debian on my moms laptop. The main reason for this was that I had the choice between updating Windows 11 or installing Linux. I did not even check if the laptop supports Windows 11 or if it was supposed to become e-trash. I no longer use Windows since many many happy years, except in some VMs to try my developed games. But reading all the (bad) news about AI and spyware in Windows, the choice was easy. Time will tell if my mom will like it or not, but I guess it will be fine. I already installed Ubuntu on her old laptop a few years ago and getting some extra years out of it.
Help your family an friends to free their devices and get more years out of them! You can find more info on how to switch from Windows to Linux on End of 10</a>.
Inkscape</a></h2>
The last months I learned more about Inkscape and how to use it. I really like the design, functionality and how easy it is to draw nice looking graphics. Most of my graphical works for my latest game 99managers.org</a> where made with it. I really like how the new logo and the background in the game turned out!
To support Inkscape, you can donate</a> and contribute</a>.
Neovim</a></h2>
Neovim is now my main editor and I use it for everything. It is amazing to see how modal editors can make typing text fun and a challenge. Complex modifications can be done in a few keystrokes and macros can do all the rest. Now I never want to leave the terminal again.
Here you can donate</a> and contribute</a> to Neovim.

Steam Auto-Cloud cross-platform save game synchronization

Simon Dalvai — Sat, 24 Jan 2026 22:50:00 +0000

I recently added cross platform save game synchronization to my game. It is designed to work with the Steam Auto-Cloud</a>, without using the SteamSDK. Therefore no SteamSDK specific code is needed in the game. This make the game compatible also with other file synchronization software, such as Syncthing</a>.
My game is Open Source and APLv3 licensed and that makes it incompatible with the SteamSDK anyways. This way I can release a copyleft game on Steam with the minimum Cloud Sync support. It is made with the Godot Engine 4.x, but I will not show any code here. A save game implementation is in most cases too specific for a game. It simply makes more sense to just show the overall idea behind it.
What should be synced</a></h2>
First of course, all save game files that contain game progress need to be synchronized. This are the most important files and they should be handled with care. Nobody wants to loose progress and restart from the beginning.
Some other files instead, should always be excluded, like

log files</li>
caches</li>
...other temporary files your game/engine produces</li> </ul>
It also makes sense to divide user settings into local only and synchronized. Settings that should be synced are

language</li>
internationalization settings, such as date formats, currencies...</li>
specific game settings, such as camera movements or auto-save</li>
...whatever a user expects to set only once</li> </ul>
Settings that should not be synced are

screen resolution</li>
full screen mode</li>
input mappings and settings, like key mapping or if a joypad is preferred</li>
...and all other device specific settings</li> </ul>
For some settings it can get difficult to decide if they are local or synced. A good example for this is the UI theme. A user might prefer dark themes on the SteamDeck OLED screen, to save battery. But uses light themes on all other devices. In this special cases, it could make sense to let the user decide, if a specific setting is synced. This could be a simple checkbox that enables/disables the sync between devices.
In summary all save game files, but only some settings, should be synchronized. This is the basic and simplified structure of the user directory of my game (on Linux).
.local/share/99managers-futsal-edition local/ settings_local.csv version.txt sync/ deleted_save_games.csv settings_sync.csv save_games/ 136907-518000-261045/ checksums.csv cups.csv inbox.csv leagues.csv ... </code></pre> Everything in the sync directory gets synchronized. This makes it easy to setup synchronization, because the whole directory is affected. It contains the sync settings and all save game files. The deleted save games file is the only special file Steam needs and I will explain its use later. Off topic: you might ask yourself why the hell I use csv files? Well, I tried a lot of formats like ini files, Godot Resources and json files. But the ability to let also non-developers inspect them with tools they know convinced me.
Atomic saving and backups</a></h2>
Crashes or other unexpected terminations of the game while saving can lead to corrupted files. The more time it takes to save the state to disk, the higher the probability that this will happen. For that reason it makes sense to implement atomic saves.
Instead of overwriting directly the current save files, they are written to new staging files. So if the save process is interrupted, the real save files stay untouched. Once all files are written to disk, you overwrite the real save files with the staging ones.
To be even more safe and fail proof, you can add backups to the atomic save cycle. This can be achieved by simply renaming the active save to something else, before overwriting it.
In my case I even save two backups of every file I save to disk. So the atomic save process with double backups is the following

write all files to staging/</li>
rename backup1/ to backup2/</li>
rename active/ to backup1/</li>
rename staging/ to active/</li> </ol>
Note: The second step can be skipped, if a single backup is enough. If something goes wrong in a step, there are still backups from where the user can recover.
With this approach my user directory looks like this
.local/share/99managers-futsal-edition local/ settings_local.csv settings_local.csv.backup1 settings_local.csv.backup2 version.txt sync/ deleted_save_games.csv deleted_save_games.csv.backup1 deleted_save_games.csv.backup2 settings_sync.csv settings_sync.csv.backup1 settings_sync.csv.backup2 save_games/ 136907-518000-261045/ active/ checksums.csv cups.csv ... backup1/ checksums.csv cups.csv ... backup2/ checksums.csv cups.csv ... </code></pre> This of course increases the total disk usage of the user directory. But it makes a really robust and fail proof save process.
Corruption detection</a></h2>
Now I still need to figure out if a file has been corrupted. For that I use a checksums file, that contains the sha256 sum of every file, after it was saved. Every save state has it's own checksums file. Before loading a file, I check that it still has the correct sha256 sum. If a save game file is corrupted, I let the user decide, if a backup should be loaded. I let the user also skip the checksum validation, in case files where modified intentionally.
It is important to know that Steam Auto-Cloud does not synchronize empty files. For that reason I also save empty files to that list, with the sha256 sum of an empty string:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
If a file from the checksum list is not found, I can check if it should be empty. A simple boolean flag, that is true if the file is empty, would actually also do the job.
Steam Auto-Cloud</a></h2>
Now that you know what needs to be synced and how to securely safe files, you can synchronize them.
To use the Steam Auto-Cloud feature, it needs to be enabled for your game. How this is done might change in future, so it does not make any sense to write it down here. Just follow the official documentation</a>, that (hopefully) will always be updated and have the correct information.
Cross platform configuration</a></h3>
Once it is enabled, you can decide what directories get synced between devices. To do that, you need to set a root path with root overrides for the other operating systems. Because Windows still has the biggest market share on Steam, it makes sense to make Windows root.
Set the following configuration at Steamworks > App Data Admin > Application > Steam Cloud.
Root paths (Windows)</a></h4>
Root WinAppDataRoaming
Subdirectory 99managers-futsal-edition\sync\
Pattern *
OS All OSes
Recursive Yes
Cross platform Yes
Root overrides (Linux)</a></h4>
Original root WinAppDataRoaming
OS Linux + SteamOS
New root LinuxXdgDataHome
Add/Replace path 99managers-futsal-edition/sync/
Replace path Yes
Root overrides (MacOS)</a></h4>
Original root WinAppDataRoaming
OS MacOS
New root MacHome
Add/Replace path /Library/Application Support/99managers-futsal-edition/sync/
Replace path Yes
To make this platform specific instead, simply use a dedicated root path for every OS. The files would be synced only between devices with the same OS.
Note: This setup is specific for my game made with Godot Engine 4. Other engines might use different directories to save user files. Anyway the way to organize the root directories should remain the same.
Deleting save games</a></h3>
Steam does not delete files or directories on other devices. This means if you delete a save game on a device, it will still exist on the other devices. My game scans the save directory for files, so a deleted state would show up again on another device. For that the deleted save games file is needed, to make sure that they get deleted everywhere.
My deleted save games file contains the ids of deleted save states. If a save state with a deleted id is scanned, it gets moved to the trash. Alongside every deleted id, I also save the time stamp of the deletion. That allows to periodically remove all ids that are older than one year.
Note: This is only needed for Steam Auto-Cloud. Syncthing for example can delete files between devices, if configured to do so.
I never permanently delete files, but move them to the operating systems trash. This assures that in most cases everything can be recovered from there. If you want to have 100% file recovery, a custom trash directory can help. Deleted files get moved to the custom trash and then the user empties that trash manually. This would also work where no trash system exists, such as web or iOS.
Sync conflicts</a></h3>
The Steam client will inform the user, when a conflict happens. The user can choose what save state to keep, by looking at the last modified time stamp. This means no special logic is needed inside the game.
The Steam client triggers the sync before a game is opened and after it is closed. Most conflicts happen if the sync failed, because of missing network connection. Or if a game is played simultaneously on different devices, but that is less common.
Steam Auto-Cloud vs Cloud API</a></h3>
The Steam Cloud API has more features, than the simple Auto-Cloud. It brings fine-grained sync support, where you can choose which file gets synced when. The Auto-Cloud simply synchronizes the states when the game is opened and when it's closed. The API instead can upload and download files, while the game is running. This adds interesting features for the Steam Deck, like Dynamic Cloud Sync</a>. This allows to suspend a game, continue on another device and then resume again on the Steam Deck. Of course, without losing any progress by synchronizing all files that changed in the meantime.
Implementing such features require the SteamSDK and lot of sync logic in the game. But I guess it depends on the type of the game what type of Cloud sync makes sens.
Great, now the code please</a></h2>
If you want to see how I implemented this in my game, check out the repository on Codeberg</a>. Just poke around the game/src/ directory and you should find the code where all this happens.
To see the code in action, get the game on 99managers.org</a>!

3 years of blogging

Simon Dalvai — Mon, 29 Dec 2025 20:15:00 +0000

On this exact day 3 years ago, I published my first blog post. Then, I published a new blogpost every month to a total of 38 posts.
Enjoy the last post of 2025 about the blog itself!
Getting better at writing</a></h2>
A big goal when I started this was to get better at writing in English. I think over the time my writing got better. I make less mistakes and can structure my thoughts better into words and sections. This makes writing much more enjoyable, because now I can focus on what to write. I still make mistakes of course, but in the days of LLMs that makes a blog human, I guess ;-)
In the meantime I started also writing some small devlogs for my game 99Managers</a>. Having 3 years of "blogging experience" gives me the confidence to write more and more.
No tracking needed</a></h2>
I do not use any form of tracking on this website or any other software I publish. Technically, I can see the Caddy web server logs, but also there I just see what files are accessed. Therefore I cannot really distinguish between bots and normal users.
So I use the Google Search Console to see what gets the most impressions and clicks on Google. This works for every site and just needs a TXT DNS entry to verify ownership of the website. Google tracks the traffic of their search engine anyways and for me this data is enough. I don't have and want to analyze graphs and statistics to understand what readers like.
Anyway the best feedback comes directly from the readers. No graph can say "thank you for writing this" or "here I found some cool stuff related to your post".
No cookie banner needed</a></h2>
I am not a lawyer, so do your own research before blindly believing the next paragraph.
This website does not need any cookie banner or GDPR notice, as far as I understood. No personal data is collected, because my Caddy logs drop all personal information. No IP-Address, user-agent or anything similar is collected. Only the requested file, the time-stamp and the HTTP response code are logged. I also don't use any third party css or fonts that would expose the readers IP to third parties. And of course, no JavaScript or anything that could communicate over the network runs here.
If you use uBlock Origin</a>, you can see that nothing gets blocked here. There are not many websites that do not trigger any uBlock block, but they exist: Lichess</a> and Mastodon</a> are my favorite examples.
Nowadays cookie and consent banners are so invasive and omnipresent, that most don't know that you can run a website without them.
My best posts</a></h2>
According to the Google Search Console my best posts are the following

Debian Sway v1 - My first setup</a></li>
Neovim as External Editor for Godot</a></li>
Godot Engine vs libGDX</a></li> </ol>
Like in every other search optimized ecosystem, niche content gets the most traction. There is not much on the web about using SwayWM on Debian or Neovim with Godot. So sharing whatever niche things you use or work on could make sense, if you care about visibility.
But I do not really care about what performs best, it's just interesting to see, sometimes. If I would care too much, the chase for the next niche article would ruin everything.
Own your place on the web</a></h2>
Having a personal website or a blog means that you can control a small part of the web. With control, I mean real full control. Using social media or any other type of third party platform brings some risks. Let's put aside all the privacy issues (except Mastodon <3) and ethical problems. One day the platform will become old and people move to a new one. Or it changes policies and you have no longer access to your account. [Put any social media platform here] will be obsolete in x years. Your website not. There are many other reasons, having full control of your space is important.
With your own blog you can also shape the web a little bit in the direction you want. For example by choosing to not use any tracking and make weird looking websites. I really have to improve on that, my website looks too boring ;-) I was and am still a big fan of brutalistwebsites</a>. Maybe this site gets more brutal too one day.
Hetzner + Debian + Caddy + Zola</a></h2>
This is my tech stack for all my current websites. In my opinion, having a simple stack is really important. It needs less maintenance, has less problems and will work for longer.
The best choice I made in my opinion is to use a static site builder, like Zola</a>. I chose Zola because I already knew Hugo</a>, but found Hugo too bloated. Everything is written in Markdown and converted to static HTML files, served by Caddy. If one day I want to switch to another tool, I can simply move the markdown content there.
As webserver I chose Caddy</a>, because I used it in other projects at work. It has an easy SSL setup, with LetsEncrypt and I never had any issues or crashes yet. It might take some time to setup correctly the first time, but once it runs it is a pleasure.
All mentioned above runs on Debian on the cheapest Hetzner VPS currently available. I never had any issues with this setup. To note that I started this website on Github Pages and switched to Hetzner on 18 November 2023</a>. The CPU usage rarely goes beyond 5% and the 20TB of traffic included are really enough. I rarely reach a 10GB per month, but I do not host videos and make sure all images are webp.
Oh I nearly forgot: I deploy everything with a simple rsync command. No CI or similar can beat the simplicity of one single command.
Final words</a></h2>
Thank you all for reading this and all other posts during the last 3 years! I hope you enjoyed it and start to create your own space on the web too, if you haven't already.
All the best,
Simon

[Talk] SFSCON 2025: Making a sport management game in Godot

Simon Dalvai — Tue, 25 Nov 2025 09:40:00 +0000

During the 7 and 8 November I attended again SFSCON 2025</a>. This was the 25th Edition of the conference about Free and Open Source Software.
It was a great event as usual and I really enjoyed the talks and meeting great people!
This year I had my 4th talk at this conference, about my game 99Managers Futsal Edition. The abstract and slides can be found on the SFSCON website</a>.
The talk covers how the project started in 2021 and what the future plans are. It also shows why I chose Godot, how it works and what other tools I used. Then a basic overview of the components used in the game is shown and what parts can be reused. The plan is to create also other sport management games, so reusable code is really important. Finally I asked people to join the community, by improving the game and creating more FOSS games.
You can watch the registration of my talk on Vimeo</a>.
Other talks</a></h2>
You should check out the talks from the VLC creator VideoLAN & VLC: a (unique) story</a> about the funny story behind the famous orange cone video player.
Another great talk was The Heart of Our Software</a> from Karen Sandler, about why we need FOSS in critical devices, such as peacemakers.

Center buffers in Neovim

Simon Dalvai — Wed, 15 Oct 2025 19:40:00 +0000

This time I want to share how to center a single buffer in Neovim using only Lua and no plugins. I have not found much on this topic on the web, so I hope this helps some people!
This only works on Neovim, afaik, because Vim can't yet modify the statuscolumn, like Neovim.
Note: I used Neovim v0.10.4 on Debian 13, while writing this blogpost. Statuscolumn was introduced in Neovim v0.10. This won't work with older versions.
No plugins, please</a></h2>
Before we dive into how to achieve this, I want to explain why I didn't use plugins. First, all plugins I found use multiple empty side windows to center the main window. In my opinion that solution is sub-optimal, because this can interfere with my workflow.
Secondly, my personal preference is to use only plugins, I really need. I don't like relying on third party dependencies and I prefer using simple and stable software. Neovim can already do a lot out of the box and if something is missing, I can add it with Lua. That is what a hackable editor is all about.
The third reason is that I use Debian. Debian does not distribute the latest bleeding edge software. The goal of Debian is to create a stable and reliable operating system. This means I don't have the latest version of Neovim installed. Most plugins move fast and require the latest version. Fewer plugins mean less trouble and version incompatibilities.
If you are interested, you can find my tiny Neovim configuration on Codeberg</a>.
The problem</a></h2>
When I started using Neovim, I still had a different opinion on plugins, so I used a lot of them. NERDTree</a> was my file explorer for some months. I always had a NERDTree buffer open on the left side, that centered the active buffer. Just like all the normal editors and IDEs have.
But time passed and I switched NERDTree for oil.nvim</a>. Oil integrates better with the Vim workflow has no permanently open side pane. If you need to explore the current directory, you do it in a buffer. When you are done, the buffer disappears. This week I even got rid of oil.nvim for the good old default Netrw.
But without a side pane, always looking left, does not feel right :-) I guess my neck agrees with this.
The solution</a></h2>
I simply want to center horizontally the current window, if it is alone. If more exists or Neovim does not occupy the whole screen, they should align to the left. But if windows are separated vertically, they should be centered again.
The trick is adding a lot of spaces to the statuscolumn, if needed.
First you need to know the width (column count) of Neovim, while it is using the whole screen. For that, run the following command in Neovim.
:lua print(vim.api.nvim_win_get_width(0)) </code></pre> In my case, the width is 191 columns. This can vary depending on font and screen size. The width is hard-coded for now and needs to be adapted manually, if needed. By adding the following code to your init.lua file, you get the above described behavior.
local full_screen = 191 -- default status column, simply 2 spaces local statuscolumn = " " -- status column if only one buffer is open -- (full_screen - text width) / 2 local statuscolumn_wide = string.rep(" ", (full_screen - 100) / 2) .. statuscolumn -- set default vim.o.statuscolumn = statuscolumn -- check window list count and adapt padding vim.api.nvim_create_autocmd({ 'BufEnter', 'BufWinEnter', 'BufWinLeave', 'WinEnter', 'WinLeave', 'WinResized', 'VimResized' }, { callback = function() local winwidth = vim.api.nvim_win_get_width(0) if winwidth > (full_screen / 2) then vim.o.statuscolumn = statuscolumn_wide else vim.o.statuscolumn = statuscolumn end end, }) </code></pre> Note that this triggers on different events, like WinResized, BufEnter and so on. That makes windows adapt dynamically during runtime, depending on the screen width. If you reduce the size of the terminal, the window will act accordingly.
Further fine-tuning</a></h2>
This setup only adds spaces to the status column, without any line number or other symbols. You can simply add one of the following codes to the statuscolumn variable defined above.
%l line number of currently drawn line %r relative line number of currently drawn line %s sign column for currently drawn line %C fold column for currently drawn line </code></pre> For example this would show the line numbers. local statuscolumn = " %l" </code></pre> You can also use different colors for uneven rows for example, or whatever comes to your mind. Simply read the docs for more information on that. :help statuscolumn </code></pre> One final thing must be said about performance. In the statuscolumn docs you might see a WARNING about statuscolumn. WARNING: this expression is evaluated for each screen line so defining an expensive expression can negatively affect render performance. </code></pre> Keep this in mind if you want to keep your Neovim fast and snappy.
One year as full-time solo game dev Simon Dalvai — Tue, 16 Sep 2025 16:50:00 +0000 On this exact day one year ago, my journey as a solo game developer began. Here I will share my experiences and what I learned. My effort estimations were wrong</a></h2> A year ago I thought that my game was about 60% complete, missing a few features and visual polish. Now, a full year later, my game is about 60% complete, missing a few features and visual polish. What changed is that I saw the real work needed to really finish a bigger game. Behind the scenes, there are so many things to do that making estimates without experience is impossible. This wasn't planned, of course. My initial estimate was that it would take me 6 months to finish the game if I worked full time on it. But now, a year later, I really don't know when it will be finished. The game is currently released as an open beta, to get feedback and some early players. Now the plan is to release it to Steams Early Access, once some users say that it is great. A great suggestion I can give is not to talk about a release date, when you are not 110% sure about it. Estimations are always wrong and you might want to play and test the game before a full release. So once you have a complete, nice looking game with feedback, you can start to think about a date. Time tracking to stay motivated</a></h2> Simply track the time you work on something during the day. This is something that made the biggest difference for me. It gives you an overview on how long you worked on something. So at the end of the day I can rest with peace in my mind, if I worked 8 hours. It also motivates me to work more the next day, if I missed some hours the day before. I normally just write the project tag I'm working and a short description. First I used the Thunderbird calendar, but recently switched to a simple text file. This makes it easier to run scripts on it for statistics (something I haven't done yet), and a text file always works, no matter what. Here an example for typical day with entries consisting of + project-tag description</code> with start time above and end below. # 28.08 thu - 07:30 + 99 team logos - 12:00 - 13:00 + 99 team logos - 16:00 + 99 new gameplay video - 17:30 - 18:00 + 99 new gameplay video - 19:30 - 21:00 + co upgrade to godot 4.4 and add keyboard support - 23:30 </code></pre> As you can see I don't get too much in detail and don't write every feature. The minimum time period I track is 30 minutes. This works well for me but might not for you. Just start tracking your time and see if it helps you or not. Never giving up</a></h2> This is really important when creating time intensive projects, like games. As exciting it might sound to work on your game all day and every day, the magic fades quite quickly. There are highs and lows and keeping working on something that seems unreachable, can be difficult. But by never giving up I will finish this game one day and be really proud of myself. Sometimes I look on old screenshots of the game to see the progress I have made. This helps a lot, especially when doubts are haunting me. Starting and finishing a project can also be a good showoff for future job applications. And HR departments love to see resilience and motivation. So even if my game is a financial flop, it could lead to better jobs in the future. 10k hours</a></h2> There is a saying that if you spend ten thousand hours doing something, you get really good at it. This year I spent around two to three thousands of hours working on the game. So I'm still not really good at it. But If I look at my older games, or even the very first game, the improvement is huge. So even if my games are still not really great and miss the masters touch, I'm getting closer and closer to this ten thousand hours. Taking breaks</a></h2> I had a git commit streak of 687 days</a> with at least one commit on the game per day. This helped me a lot to keep working on the game while having a full time job. I would add some new features or just fix a typo to keep the streak. But most important, I didn't stop working on the game. Before this streak I would maybe work 2 months on the game, and take a 2 week break. With this approach it was really difficult to stay motivated. And even harder to remember what I was working on. So the streak helped to sit at least once a day in front of the computer, open the game and see. But once I went all in and quit my job one year ago, it was simply too much. I got tired and had low motivation to work on it every day. Taking my mind off the game is in my opinion a healthy thing to do, especially since I work on it for about 8 hours or more a day. Now I no longer work on weekends, except if I really want to or there is something exciting to do. My motivation is again on it's best and I have more time to enjoy other things. Respect for my work</a></h2> Since I started this journey, only a few people really respect and understand my work. Most people say I don't have a job and don't even really work. And of course because I'm just working on some games, that can't be serious. I learned to ignore this and just keep going to follow my plan. I really like working from home and doing what I really like to do, (nearly) without any external input and using only my ideas. There is no Sunday I think "Oh no, tomorrow I have to work again". Actually the exact opposite is the case, that most of the times I'm exited to get back to work. The same happens if I'm on vacations. So my final advice here is follow your dreams, if you are in a privileged position to do so. If you really like something and it can possibly generate some income, go for it. And listen to friends and family, but keep your ideas and stick with your plan, no matter what. I don't like playing my games (yet?)</a></h2> One curious thing I have experienced so far is that I don't really play my games. I would have never said that this would happen, before starting developing games. So it amazes me even more, when I see people playing for hours my game and completing everything. The game I'm currently working on was actually the first game I thought this would be cool to play. But I still didn't play it more than the time needed to test it. I personally think there could be three reasons for this When you create a game and know how it works, it looses the "magic touch" of the unexpected. I know nearly everything about the game, except the bugs and so I don't need really to learn and improve.</li> It's really difficult to enjoy my games, because I see all the things that can be improved or fixed.</li> I still haven't made a really good game.</li> </ol> Only time will tell if I will enjoy playing my games one day. Ignore the noise</a></h2> As many aspiring solo developers, I checked out social media like Reddit for advice and experience of fellow developers. This can be a great resource for learning how to create a successful game. But it can also be really demotivating to see other games getting thousands of whishlists on Steam, while my game got around 400 as of today. If I wouldn't have seen this on Reddit, I would be the happiest person on earth, knowing that FOUR HUNDRED people saw my game and thought "this looks nice, I might play it when it's released". So I learned to ignore the noise and focus on my game. I still check social media and other platforms to read about game development. But I try to look at it from a different angle, by thinking about how my game could reach this numbers. Marketing, or not to marketing</a></h2> I watched videos, read articles and whatever I accidentally found. And most of the times the first question is: what is your budget? My current budget is zero. So I created accounts on the socials I use, Mastodon, Bluesky and Matrix. And some I thought might be attracting players such as Discord, Reddit and YouTube. Currently Discord is the one that worked the best for me, with 32 players in my server. Not huge numbers, I know, but for me it's a great starting point to learn and improve. My absolute favorite marketing method is this blog post. I really like it to write and express my thoughts and ideas. I don't have tracking, so my only statistics are server access logs and the Google Search console. I currently get around 20 clicks per day, according to Google and that's great! Maybe one day like to create videos I will create YouTube videos, but for now writing works just fine. Finding something you like to do and using it to get visibility is the best marketing in my opinion. I also printed some stickers, I normally distribute after talks or at events. Note to this: high quality stickers can cost quite a lot, like +100€ for a few stickers. A cheap alternative can be to buy adhesive A4 paper and use a common printer. I got 10 adhesive pages for 5€ and created about 50 stickers with one page. I think it also highly depends on the type of a game, if intensive marketing is needed. If there are many competitors, marketing might be the only way to attract users. In my case there is currently only one other Futsal Manager available on Steam. Picking a niche market can reduce the need for marketing a lot, at least that's my theory. Done is better than perfect</a></h2> This is one of the most important advice I can give. It might also be one of the most difficult to learn and I'm still failing at it badly sometimes. It happened so many times that I got stuck somewhere, because I was seeking perfection. That let me into an endless loop of refactoring and re-implementing functionality, like the match engine. Slowly I learned to see that something is good enough, for now. Then I would start working on something else and forget about it. Coming back to it after some days or even weeks clears my mind and lets me see the problem from a different angle. Now I work in this loop, where I get something done (good enough) and iterate over it again after some time passed. This prevents the frustrating situation of feeling stuck in the never perfect state. Notes and plans</a></h2> I tried a lot of things like Kanbans with todo, doing, done lanes or creating issues on Codeberg. I also had multiple note books and files with all ideas, bugs and features scattered around. For now I ended up with a single todo.md file accessible from phone and computer. The I have one notebook for offline notes, handy for when I have ideas while playing other games. And some paper lying around my desk for fire and forget notes. I simply write ideas, bugs and missing features down until they are resolved. I also don't plan much in the future and decide in the moment what to do. This works pretty well for me and I really like this spontaneous approach. Naming things is difficult</a></h2> I spend a LOT of time finding a fitting name for my game and game studio. Immediately the famous naming joke came to my mind. There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton </code></pre> I collected long lists with potential names. Short, long, without any meaning, I really had a lot of names. This distilled down to a few names, after hours of seeking the perfect name. In the end I took 99Managers for the game following these main ideas is unique</li> easy to remember</li> .com and .org domains available</li> word trademark registration possible</li> can be used as umbrella name for different sport editions</li> </ul> Finding names can be really hard, at least for me. I could waste days finding new names, while searching if the domain is available. But I really need to keep in mind that the thing that really matters is making a fun game. A good name might be easier to remember or attract some users, but finally the game is what matters. Getting a trademark</a></h2> So after I decided on the name, I registered a word trademark for 99MANAGERS in the category of video games in the European Union. This was quite expensive, because the registration fee alone is 850€. The idea is to use this name also as umbrella name for other editions, as mentioned before. So for example if one day I create 99Managers Volleyball Edition, the name 99Managers would still be protected in the European Union. The main reason for this is that the game is Open Source, so I wanted to protect at least the name. Everybody can still create and distribute their own version of the game, but the name has to be changed. Another reason is that again, I spent too much time on Reddit, reading about trademarks. But in the end some advice I read there might be true: it's good to have it, before you need it. Finances</a></h2> I'm currently living on my savings and I hope to finish the game soon, to see if I can generate some income. Many ask how I'm able to stay without a job for such a long period. Normally I would say that I don't spend much, eat a lot at home and don't own a car. I also buy a lot of used things and recently started selling stuff I no longer need. Self funding is what currently works for me and it makes me completely independent and free. There are also other ways to finance a game, like getting investors, working with publishers or crowdfunding. For now I have chosen the self-finance way, but maybe someday this will change. Crowdfunding sounds interesting to me, because I could stay independent. I also often see "Co-financed by culture fund of PUT_COUNTRY_HERE" in some games I played. A lot of countries support cultural works, like video games, with financial support This might be another way to get funding, while staying independent. Focus on the game</a></h2> With all the stuff to do as a solo game developer, I sometimes forget to focus on the game. The game is what really matters. It is the base for real success. You can have the best marketing, but without a fun game, that doesn't really matter. I don't have the numbers on how much of my time I spend on the game and how much on the rest. But I would guess it is about 80/20. That works for me and I recently shifted again more focus on the game. Now overall, I care less about naming things, social media presence and related things. Because I know and also see it in real life, that successful games, are great games. Period. Nothing else really matters. Plan A, B, C, Y and Z</a></h2> My plan A is finishing the game and making a living as a independent FOSS game developer. If this plan fails (the chances of failure are about 99%), I still have some backup plans. Most of my backup plans should allow me to keep working partially on my games. I have a plan B, that is taking freelance work for a few hours a week to keep living costs covered. And a plan C, that is taking a part time job, if plan B fails. The following plans are named with the last letters in the alphabet, because they are my last resort. Hopefully if plan B and C fail, time comes up with a plan D, E and F. But anyways, my plan Y is getting a full time job as a game developer. That could even be a good plan, to see how real professionals work. Finally plan Z, that is my final plan I really hope not having to execute, is going back to a full time job as a normal software developer. I guess that I will switch to Plan B soon, to don't consume my whole savings and create different sources of income. Even if my game would sell well, it doesn't mean that it will still sell in a month or in a year. The same counts for future games, that could be hits or complete failures. Having alternatives is always recommended and can also create other opportunities. That's all folks</a></h2> I guess with this I just wrote my longest "only text, no code" blog post so far, but this memorable event was worth it. Thank you for reading and see you in a year again, for another one! Godot code style, project structure and friends Simon Dalvai — Sun, 17 Aug 2025 20:05:00 +0000 I started using Godot 3 around 5 years ago. A lot of things changed since then. Godot 4 and GDScript 2.0 are out and I learned a lot about writing better code. Everything here is covered in the official Godot docs</a> and that is the best place to get the correct and up to date information. Said that, I just will point you to the right place in the docs and add my two cents. Note: Godot version 4.4.1 is used here, some things might be different in other versions. Write good code</a></h2> Everybody can has his own thoughts about what defines good code. But I think we can all agree that maintainability, readability and organization are king. This increase the developer experience and can increase the time of your coding sessions. Another important key aspect might be performance, but only after the code works and looks good. And never forget done is better than perfect. Endless code style adjustments and refactoring can stop progress. Project organization</a></h2> There is a dedicated page in the docs for project organization</a>. The main takeaway is to create a directory for every scene and put all scripts, assets and scene files there. I do it a bit different, since most of my games don't have many assets and I also keep track of used licenses for third party assets. So having all assets in a single directory makes it easier to keep track of used third party assets. / Godot unrelated files, like README.md or LICENSE</li> /game/ godot project root</li> /game/src/ scripts and scenes</li> /game/src/const.gd global constants</li> /game/src/global.gd global singleton</li> /game/assets/ assets, including audio and fonts</li> /game/themes/ theme files and related files, like style resources</li> /game/translations/ csv or po/pot translation files</li> /game/script_templates/ custom script templates</a> including license headers and more</li> </ul> This structure crystallized for me over time, but might not work for you. Time will show what is best for you and your projects. Code style</a></h2> For the code style</a> the documentation is much more detailed. I regret not having read this earlier. My first two Godot projects have a horrible code style. But as many times in life, errors are the best teachers. Now I really care about how my code is written and structured. I prefer now to fix things immediately instead of waiting. I respect now rigidly the code order</a> and made also a bash alias that prints me the order, for easy access. I saw people on reddit</a> printing the code order docs and framing it above the monitors on the wall. Naming conventions</a></h2> Also here I didn't follow the official convention</a> for years. Then I had to rename hundreds of files and always follow now the way it should be. Static typing</a></h2> Coming from Java with static types I really miss the rigid type checks at compile time. I really recommend using static typing</a> in Godot, for less bugs, better error detection and performance. It also allows to find errors fast, as described in a previous blog post</a> The docs state that best practice is to always use it or never. Mixing static and dynamic typing is seen as bad practice and can cause confusion. Scene unique nodes</a></h2> This is a nice way to keep mental sanity while accessing Nodes in code. I used to drag and drop Nodes into the script editor, while holding Ctrl, to get the full node path. But since I switched to Neovim as my main editor, I cannot do that anymore. Better, because now I use the Scene unique nodes</a> that allow accessing nodes without writing the full path. # access by unique name var label: Label = %Label # instead of full path var label: Label = $MarginContainer/VBoxContainer/YetAnotherContainer/Label </code></pre> This is so much cleaner in the code and most important Nodes can be moved and renamed freely in the scene tree, without breaking the path in the code. UIDs</a></h2> Since Godot 4.4 added UID support</a> it is possible to do access script files with their unique UID, instead of the full file path. This brings a similar logic, as we have with unique node names, to script and scene files. # access by UID var scene: PackedScene = load("uid://b48hr5ervcv") # instead of full path var scene: PackedScene = load("res://src/screens/settings/audio/audio_settings.gd") </code></pre> With this also files can be moved and renamed freely, without breaking paths in the code. Linters and formatters</a></h2> The gdtoolkit</a> is a python tool that provides a parser, linter, formatter and code metrics calculator. I have to admit that I tried the linter and formatter and I didn't like it. At the time, the false positives were simply too many. If years of JS linters at work taught me one thing, it is that they never work properly ;-) But I will checkout the tool every few months and see if it improved and you should too. Maybe for you it works! My new workstation - HP Pro Tower 400 G9 Simon Dalvai — Thu, 17 Jul 2025 09:49:00 +0000 I have been working on a Thinkpad T470s for about 2 years now. It has 20GB RAM, a 1TB SSD and an i5-7200U with 2 cores and 4 threads. I really love it and using the old mechanical docking stations is a true pleasure. I got it for 120€ from the company I used to work for. Now I will probably use it only when I leave my house or want to work from my sofa. Yesterday I bought a used HP Pro Tower 400 G9 model 6A773EA from a local online market place. It has a i7-12700 with 12 cores and 20 threads, 32GB RAM and a 500GB SSD. This is a true power machine compared to the laptop. I also really like the smaller case, which is between a Small Form Factor and a regular tower. The price was just 380€, a real steal in my opinion, because new it costs around 1000€. Why not make a custom build</a></h2> I really like the idea of building my own PC someday. I'm also not a big fan of HP, Dell or similar brands. But this time I decided to get this pre-built device for three main reasons It was cheap</li> It works out of the box (at least I hoped)</li> I would get lost in details when making a custom built PC</li> </ol> This should save me time and money to actually get things done :-) As you can see, I like to get used devices for a fraction of the price. It's good for your wallet, for the environment and older devices normally work better with Linux. Anyway, this tower PC is not really old, since it was released around August 2023. Surprise surprise</a></h2> When I first booted the device, still with Windows on it, I heard the login sound. At first I didn't think about it, but then It got me, how the heck can this play audio? I never saw before that a tower PC can play audio out of the box and this one does. It's not a great speaker and since I have it under my desk, it doesn't make things any better. But always better than nothing! Install Debian 12</a></h2> The first thing on my todo-list was getting rid of Windows. My preferred OS is still Debian, starting from a installation without any desktop environment. Then starting from a pure command line interface, I build the exact system I want. This was the first time I tested my install script</a> on a complete new machine. And guess what, it didn't work. CLASSIC. So I had to do some manual fixes and take notes on what was missing or went wrong. Hopefully next time this will work better. Get WiFi to work</a></h3> Debian 12 was initially released just a few months before this PC came out. So I faced some issues, when installing it, because the WiFi card was not supported out of the box. It has a Realtek RTL8852BE, with WiFi 6 and Bluetooth. This card is supported from the Linux Kernel >6.2 and Debian 12 uses 6.1. After some troubleshooting to get the card running, I finally got it to work. The trick was getting a newer Linux kernel from bookworm-backports. First, you have to add bookworm-backports to your apt /etc/apt/sources.list. # add backports for kernel >6.2 deb http://deb.debian.org/debian/ bookworm-backports main non-free-firmware deb http://deb.debian.org/debian/ bookworm main non-free-firmware deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware deb http://security.debian.org/debian-security bookworm-security main non-free-firmware deb-src http://security.debian.org/debian-security bookworm-security main non-free-firmware # bookworm-updates, to get updates before a point release is made; # see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports deb http://deb.debian.org/debian/ bookworm-updates main non-free-firmware deb-src http://deb.debian.org/debian/ bookworm-updates main non-free-firmware </code></pre> After that I could get a newer kernel from backports. apt update apt install -t bookworm-backports linux-image-amd64 </code></pre> Backports packages are, of course, not tested in detail like the default stable packages. So only strictly necessary packages should be installed from there. The good thing is that with this I should be able to seamlessly upgrade to Debian 13. dulvui@rook:~$ uname -a Linux rook 6.12.32+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.32-1~bpo12+1 (2025-06-21) x86_64 GNU/Linux </code></pre> Finally I installed the firmware-realtek package and everything worked after reboot. apt install firmware-realtek </code></pre> This actually took me some hours, trying to install the driver manually or upgrading to Debian 13. But using backports on a fresh Debian 12 install is easy and creates the most stable system possible. I have to admit that this was the first time I considered using Fedora or Arch. But finally Debian worked also this time and I learned some new cool tricks with backports. The real impact</a></h2> By comparing CPU benchmarks I expected that this new PC should be many times faster than my laptop. It feels snappier and generally faster, but not as much as benchmarks suggested. I guess this is related to the fact that most software still doesn't use multi-threading. My game also does not support multi-threading yet. So it runs faster here, but not to a magnitude teased by the benchmarks. I expected that the match simulation would be much faster, but I was wrong. Everything runs on one core anyway, so it doesn't make much difference. Now I have no excuse to skip learning how to use threads properly in Godot. Another thing to consider is that my setup is quite lightweight. I use sway-wm, code mainly with the Godot engine and use Neovim as my editor. This combination already felt fast and snappy on my laptop. I still have to try gaming on this machine. I guess I will be really happy, once I rewrite some of the performance critical code to C/C++. Faster compile times and feedback should make it a more pleasant developer experience. Unexpected orphan Nodes in Godot Simon Dalvai — Wed, 18 Jun 2025 20:00:00 +0000 The more I work with Godot all day, the more edge cases I face. Recently I found out that my game had orphan Nodes that can cause memory leaks. It was not a huge deal, but still with some easy tricks, I could have noticed this much earlier. Note: Godot version 4.4.1 is used here, some things might be different in other versions. Find orphan nodes</a></h2> Godot has already an awesome and easy way to detect orphan Nodes. You can see the amount over time by enabling the check-box at Debug > Monitors > Object > Orphan Nodes. Or you can simply call print_orphan_nodes</a> in your scripts at some point and it will print them into the console, if some exist. func _ready() -> void: print_orphan_nodes() </code></pre> You will see an id, Node type and path of your orphan Nodes. If nothing gets printed, you are fine! Here is an example with an orphan BoxContainer. 142639892262 - Stray Node: @BoxContainer@6 (Type: BoxContainer) </code></pre> Normally you probably removed a Node from the tree without freeing it with queue_free. One simple mistake is enough</a></h2> In my case something else happened and I just got this cryptic prints to the console. 122456901315 - Stray Node: (Type: Node) 122591119050 - Stray Node: (Type: Node) 130929395586 - Stray Node: (Type: Node) </code></pre> There is no real information that could lead me to the problematic Node. But after some debugging I detected that my DataUtil, that loads and saves data is the issue. Everywhere I created a DataUtil instance, an orphan Node would appear after changing scenes. var data_util: DataUtil = DataUtil.new() </code></pre> But why?? This looks good to me. After some more detective work, I found out that the problem was so simple, yet so evil. class_name DataUtil extends Node # JUST THIS LINE </code></pre> By simply removing the line extends Node, the issue vanished. The extends Node makes the DataUtil a Node, of course. And because the Node is created, but not added to the tree, it will result as an orphan Node. Nodes need to be released manually if not attached to a scene. RefCounted</a> objects instead get their memory released automatically if no longer used. Now my DataUtil extends RefCounted, the default class in Godot. This can be proved by simply creating an instance and calling get_class class_name NoExtends func _init() -> void: print(get_class()) # prints RefCounted </code></pre> Anyway it's good practice to add the explicit extends RefCounted anyway. So anybody can see what class it extends without having to know what the default is. class_name WithExtends extends RefCounted func _init() -> void: print(get_class()) # still prints RefCounted </code></pre> I have to say that this DataUtil was once an auto-loaded Singleton. For that reason it extended Node in the first place. When converting it to a local instance, I forgot to remove the extends Node. But I didn't expect that this simple mistake could cause memory leaks. Keep orphan Nodes away</a></h2> I will now keep the print_orphan_nodes call in my (custom) change scene method. This should prevent future mistakes and let me detect them much earlier. It's always good to know how to detect potentially critical issues with a few simple tricks. Last but not least a precious Godot docs entry titled: When and how to avoid using nodes for everything.</a> This should clear some doubts about when to use Nodes and when to use something else. Find more errors in Godot, with a script Simon Dalvai — Thu, 15 May 2025 16:10:00 +0000 I learned programming with Java, a statically typed language. For that reason, I really miss errors at compile time, when programming with GDScript in Godot. GDScript is a dynamically typed language, that makes error detection at compile time nearly impossible. There are many ways to make GDScript more strict, like adding type hints and making it statically typed</a>. Additionally, treating more warnings as errors in its warning system</a>, will also have a positive effect on the amount of errors you will get. Anyways, some errors will only pop up, when you execute the script file that has the error. Just change the name of a variable or a method and forget to update all references. BOOM, your game will crash when the previous name get's accessed. And in the worst case, this happens to the final user. Note: Godot version 4.4.1 is used here, some things might be different in other versions. Yet another script to the rescue</a></h2> There is one trick that triggers the error: opening the script in the editor. But it's impossible to open all files every time you make a change, by hand. Given this, a good way to get more errors is to open all script files, inside a script ;-) So I created a script to search and load all .gd and .tscn files in the project. This will then trigger some errors, you probably would have missed. By opening also scene files, you might also catch dependency errors, after renaming files for example. extends Node func _ready() -> void: print("load all scenes...") var scene_paths: Array[String] = find_files(".tscn") # load scripts and check for possible dependency errors while loading for path: String in scene_paths: var TestScene: PackedScene = load(path) assert(TestScene != null) var instance: Node = TestScene.instantiate() assert(instance != null) print("load all scene done.") print("load all scripts...") var script_paths: Array[String] = find_files(".gd") # load scripts and check for possible runtime errors while loading for path: String in script_paths: var TestScript: GDScript = load(path) assert(TestScript != null) print("load all scripts done.") func find_files(suffix: String, path: String = "res://") -> Array[String]: var scripts: Array[String] = [] var dir: DirAccess = DirAccess.open(path) if dir == null: print("error while opening %s" % path) return scripts dir.list_dir_begin() var file_name: String = dir.get_next() while not file_name.is_empty(): var full_path: String = path + file_name if dir.current_is_dir(): scripts.append_array(find_files(suffix, full_path + "/")) elif file_name.ends_with(suffix): scripts.append(full_path) file_name = dir.get_next() return scripts </code></pre> This script can be executed by being attached to a scene that gets launched from the editor. It can also be invoked from a bigger test suite, like I wrote for my game 99Managers Futsal Edition</a>. There I test also game logic and make sure that I don't make mistakes twice. It also gives much more confidence, that the code is running as expected, after yet another refactoring session. I have to admit, I love refactoring, so having tests helps a lot to keep the code working as expected. What's next</a></h2> I already extended the script in my game to do even more, like linting and checking for dumb mistakes</a>. But that would be too much for this blog post. If you still want to check it out, you can find the script on Codeberg</a> and Github</a>. Another idea I have is to run it as main scene of the game, so it will run every time I launch the game. If the test passes, the splash screen gets loaded. Except when the game is not running from the editor, in that case the splash screen will be loaded immediately. [Talk] Making FOSS games for fun and (hopefully) profit Simon Dalvai — Thu, 03 Apr 2025 08:15:00 +0000 This is the complete blog post to my talk at the Software Developer's Thursday</a>. It is not a word to word transcript, but should cover most I said during the talk with some additional notes. A video will be uploaded to YouTube a few days after the talk and the link will be added here. But I accidentally used the wrong microphone while recording the talk, so the video has horrible sound and is not ready yet. I hope to solve the audio issues soon and add the link here.</del> Sadly there will be no video, the audio quality was simply too bad. Anyway, let's make some FOSS games! About me</a></h2> Before starting, I want to make clear that I'm not a professional game developer (yet). I haven't made any income with my games and haven't worked as game developer yet. So everything I write here is based on my personal experience as a hobby game developer, with some additional stuff I read on the web. Everything started with childhood dreams since I saw the Nintendo Game Boy</a> for the first time. Seeing the infinite possibilities of creating imaginary worlds blew my mind and is fascinating me until to this day. This experience created the desire to become a game developer. I learned programming in high-school and worked afterwards as a software developer (as employee and freelance) since 2016. In 2017 I started creating my first games with libGDX</a> in my free time. In the following 3 years I created some mobile games. ColorShooter</a></li> Sn4ke</a></li> WhatColor</a></li> </ul> They where my first attempt to create the next Flappy bird</a> and become rich and famous. Of course without success. But it still didn't kill my desire and joy to create games. In 2020 I tried the Godot Engine</a> and started making games just for fun. I created the following 2 games available for mobile, on the web and as flatpaks. Pocket Broomball</a></li> Ball2Box</a></li> </ul> I still tried to make some dollars with ads, but quickly realized that it doesn't work. So I removed all ads and tracking from my games and open sourced all of them, using a copyleft license. Since September 2024 I'm working full time on my first FOSS commercial game 99Managers Futsal Edition</a> (still in beta). I started this game right after Ball2Box in 2021, but I was not able to see how I can finish this game just in my free time. The decision to quit my job and go all in was not easy, but if not now, when can I work on my childhood dreams? The plan is to sell the game on Steam and release it on other platforms like itch.io and Flathub for free. I really care about free and open source software, and I hope also other people do and see that the game industry needs more of it. Problems with most games</a></h2> Modern games have in my opinion quite some serious problems, that would not exist in FOSS games. Most players are children and they are exposed to malicious practices, mostly for profits. Ads and user tracking bring all the privacy issues to the (mostly mobile) gaming world. Even without consent, apps can track gamers and sell the data to brokers, as showed in this article</a>. Micro-transactions and loot boxes are the next big issue. Loot boxes are illegal in Belgium and many other countries demand higher age rating, real money disclosure, probability disclosure etc... This EU press release</a> about protecting children from harmful practices shows, how games are designed to attract and mislead children to spend (lots of) money on games. And then there are the famous freemium game, where tiny fraction of players pay insane amounts of money. The South Park episode Freemium Isn't Free</a> explains very well how this works. You can skip forward to 15:12 for the interesting part, but I recommend watching the full episode. Down the rabbit hole it can get alarming. There are even more malicious practices in games, like the German satire show Neo Magazin Royale showed in the episode Coin Master - Abzocke mit Fun</a> (in German, auto subs available). You can read about it also on Wikipedia</a>. Long story short, it's slot machine masquerading as a game that targets children. They did also a research on who financed the game studio Moon Active, the studio that created Coin Master, and found that the main investors come from the gambling industry</a>. So they are showing children how slot machines work, make them addicted and create the gamblers of tomorrow. Of course not all games using ads, micro-transactions or similar are pure evil, but many of them are. Game development job market</a></h2> Since I showed you the bad part of the gaming industry, let's continue with bad news. Here I want to justify again that I'm not a professional game developer yet, and my knowledge is mostly based on what I see on the web. Game developers get a lower pay than rest of the software industry. They also have more working hours aka crunch time, because there are tough deadlines. Working in the games industry is also seen as a privilege. So many studios exploit childhood dreams, like mine and get people to work more for less. Because well, you are working your dream job! No jobs in South Tyrol (the region in Italy I live) and in other locations outside big cities. I could easily find a job as a common software developer here, but the next game studio is more than 150km away. Finding remote jobs really difficult and most studios want people in the office. There are lots of NDAs that need to be signed, for example to use proprietary SDKs for consoles. So studios prefer to keep everything in the office, to prevent leaks and other issues. Why FOSS games</a></h2> So now let's see how FOSS games can partially solve this problems. The Kiwi Free Software CD was the very first free software I got in elementary school. It was created by the province of Bolzano for schools to give them access to free (as in free speech and free beer) software. There is an article in German, Italian and Ladin about the CD on the province's website</a>. I really enjoyed playing Supertux or becoming a deejay with Audacity. At the time I didn't know what FOSS is and why it is important, but it surely shaped my path as a software developer. Said that, I'm convinced that also FOSS games can have this effect and shape the FOSS developer of the future. Get quality feedback, as this happy reddit user showed in his post</a>. His game was not FOSS, but by simply releasing the game also for GNU/Linux was a success. His GNU/Linux users produced 650% more high quality bug reports. Also in my experience I saw that once developers discover your game, through F-Droid or Flathub, much more issues get created. Get contributions to your game with bug fixes, features and non code parts like translations. It might be difficult to get code contributions, as many FOSS projects struggle to get contributors. But in my case I already got my games translated in many other languages, by being FOSS. Get free access to paid tools like Weblate</a>, I'm currently using for translations. Weblate gives free hosting to FOSS projects and I want to thank them here once again, for their generous offer! Give free access to the game, to give something back to the community. But also to give access to people who can't afford games. In some countries the monthly average wage is less than what most games costs nowadays. So this people can't play games or need go pirate them. Being FOSS gives free and safe access to everybody. All problems magically disappear, because if someone does nasty things with FOSS, the project will get forked. Game engines</a></h2> Now that I convinced you that your next game will be FOSS ;-), let's talk about game engines. It is important to choose the right tool for the development of your game, even if it will be proprietary. In 2024 Unity wanted to introduce a 0.20 cent runtime fee, for every installation of a Unity game. After strong critics by the community, Unity canceled the fee. But many developers understood what it means to be dependent on a closed project. Something like that would never happen with a (real, no CLA</a>) open source project. The list of game engines on Wikipedia</a> has a lot of open source projects that can fit your needs. Another great website I just found recently is enginesdatabas.com</a>, where you can find many possible engines with great filters. In my opinion, there are two main categories: libraries/frameworks and full engines. Like libGDX</a> and Godot Engine</a> I already used. LibGDX is a Java library that helps you to create a game, but you need to code everything. It brings a physics engine, so you don't need to code that, but you still need to care about low level stuff like memory management. And to create UIs you have to code every button's size and position, without fancy visual editor. But you are free to implement the games as you want on a architectural design level. So it gives you more power and freedom, at the cost of having to code parts that are already solved in full engines. Godot on the other hand brings you a full engine with visual editor and lot's of other features. You can create games much faster and really focus on creating the game, without having to care about low level stuff. But you are limited to Godot's design decisions of using Node based scenes with events/signals. So if you want to learn more about what happens under the hood and have more control over your game, use a library of framework. If you want to focus on the game and be fast, choose a full engine. But never forget, the most important part is making a fun game, it doesn't matter what technologies are used. Free (as in free speech) assets</a></h2> Most games are not made by just code, but also use audio and visual assets. So itis important to know where to find good assets that can be used in FOSS games. This is my top 3 list, but there are plenty of websites on the web. kenney.nl</a> 2D, 3D and audio, all CC0</li> opengameart.org</a> 2D, 3D and audio, multiple license</li> freesound.org</a> audio, multiple licenses</li> </ul> Just keep in mind that you need to have the rights to use and share the assets you get. You probably can't use and distribute assets you can buy online, because they have a proprietary license. Licenses and Trademarks</a></h2> Now that have the source code and assets, let's talk a bit legalese</a>. To keep it short, I will just make a quick list of most used licenses. I highly recommend making your own research on licenses, to make sure you understand them. You can find a comprehensive list on Wikipedia</a> For source code permissive MIT, Apache weak copyleft MPL, LGPL strong copyleft GPL, AGPL For assets public domain CC0 attribution CC-BY attribution and share alike CC-BY-SA Reuse tool</a> to keep track of licenses in your repositories. It is really easy to get a piece of code or asset from the web and add it to your game. You just want to try and see it fits, but then a bug appears and you forget about it. Good luck finding the website months later and hope, that it had a compliant license. The reuse tool forces you to add license headers to all files in a repository. This makes forgetting things much harder and in the long run it will payoff. Finally trademarks to protect name and branding of your game. So someone can't reuse the name, logo or both (depending on which trademark) in their clones, without your permission. This is not always necessary and costs quite some money. But it's like an insurance, you hope that you don't have to use it, but when it's necessary, you are happy to have it. Especially if you plan to create a commercial game. Game distribution platforms</a></h2> Also here I don't want to spend to much time, since there are better articles on this topic. F-Droid</a> is a open source dedicated Android App catalog. It will give you visibility in the open source community and might get you some contributions and donations. Flathub</a> is a GNU/Linux app store for open source and proprietary software. It allows you to easily bring your game to most GNU/Linux distributions. itch.io</a> it a great place for indie games and developers. You can reach a big audience that will expect unique and small games by solo developers or small studios. Steam</a> can give you the visibility and possibility to create a valid commercial game. Most successful indie developers sell their games on Steam. The Google Play Store and Apple App Store are also valid platforms, but can be complicated. It is also really hard to get visibility and make money, since the mobile game market is much different compared to desktop game market. Just ask yourself when did you buy the last mobile app? And how much did you spend on your last desktop or console game? FOSS business models</a></h2> No business, just fun is the best model and surely the one you will have most fun with ;-) It's not really a business model, but I suggest to every beginner to focus on fun and learning. Leave the business side to the day it makes sense. Donations can be a nice way to stay motivated. There are many platforms, like liberapay</a>, where people can donate you money. In my case, I got around 25 Euros in donations overall. It's a real great feeling if a complete stranger gives you a few bucks, because he liked your game. But it can be really difficult to get so much donations, that you can live from them. And donations might make paying taxes or similar things more difficult. Sell desktop games platforms like Steam is potentially the best way to earn a living as a game developer. There are several FOSS games that do this and still have free versions on all other platforms. The best example I found is Mindustry</a>, that is a GPL licensed tower defense games. According to an estimation from game-stats.com</a>, the game made more than 3 million dollars. Guerilla marketing</a></h2> As with business models, I suggest to care about marketing only when you feel confident about your games. Learn how to make great games first, than start with the rest. Write a blog if you like writing, like me. I didn't like it from the beginning, but later I started really to love to write blog posts. That passion survived also the rise of LLMs, so my blogs are still written by typing letter by letter by me. Make videos if you prefer that. It's important to have a web presence in some way, it doesn't really matter the format. People can stumble upon your games only if there is a way to do it. FOSS lists are a great way to get visibility for free without lifting a finger. If your games is FOSS and has an audience, somebody will add your games to this lists. My games got added to the following (but not only) lists awesome-godot</a></li> fossdroid</a></li> fossgaming</a></li> </ul> Niche games bring natural visibility. Pick something unique nobody has created yet, and you will get downloads. I saw this happen with Pocket Broomball, because it was and still is the only Broomball video game. And I hope to get the same effect with 99Managers Futsal Edition. Stickers, stickers, stickers are cheap and are loved by everyone. Once you have a logo, print stickers and don't forget to bring them to events and whenever you leave the house. The cheapest way I found is to print them on sticky paper with a ordinary printer. My game development advice</a></h2> Start with small games and finish them. The first games are great to learn how to make games. You will notice that your second game is already much easier to make and is much better organized. To not talk about the code quality. I always get embarrassed when I have to fix a bug for Pocket Broomball and have to see the code I wrote a few years ago. Working immediately on big games can bring a lot of frustration and you will probably never finish it. Making something small, finishing it and being proud of it is much better to stay motivated. Once you feel confident, you can use your skills to create bigger games. Make web or desktop games, because it is easier to release and get feedback. Releasing mobile games can be really difficult, if you have no experience with it. And your game will just be one of out of billions. It can also get quite frustrating when Google/Apple decide to remove your perfectly working game from the market, if you don't update to the latest SDK. itch.io is a much more beginner friendly platform for Web, Desktop and even Android. No gaming computer/laptop is needed for game development. I created my first games with libGDX on a tiny 11inch laptop with 4gb of ram and an Intel Celeron. Just if you want to create a open world 3D game or similar a graphic card might be needed. Participate in game jams online on itch.io</a> or offline in South Tyrol like castle game jam organized by gameground</a> or the dung game jam organized by dung-gaming</a>. Personally I don't like competitive coding competitions, but it's a great place to meet like minded people and create games! 99Managers roadmap</a></h2> Here a tiny roadmap of my next milestones regarding 99Managers. 2025 release Futsal Edition on Steam and other platforms 2025 SFSCon</a> talk proposal 2026 adapt code for other team sport 2027 and many other team sports 2030 ALL team sports ;-) ...and of course, plans are made to be broken. 99Managers gameplay</a></h2> During the talk I showed the gameplay of my game. You can watch the video (when it is available) or simply play the game. The up to date download links are available here</a> Duplicate Godot custom resources deeply, for real Simon Dalvai — Tue, 18 Mar 2025 15:00:00 +0000 Resources in Godot are really powerful and can make a Game Devs life easier in many ways. If you haven't used them yet, I can only recommend reading the official docs</a> or my blog post</a> about them. Now I use them a lot, especially in bigger projects with many different data models. At some point, you might want to duplicate a resource using the duplicate() method. Here things got complicated for me. Reading the documentation would have saved me hours of debugging, and writing this blog post. But I didn't expect that their duplicate() method works much different as in other object oriented programming languages. The full source code in this article can be found on Coderberg</a> and on Github</a>. Note: This blog post was written using Godot 4.x (version 4.4 to be precise) and things could break with further versions. Create custom resources</a></h2> I will simply reuse some reduced resources from my open-source game 99Managers Futsal Edition</a>. There we have futsal players with a name and surname. (For who doesn't know Futsal</a> yet, it's 5 a side soccer indoors) class_name Player extends Resource @export var name: String @export var surname: String # custom resources need a _init() method with default values # to work as expected inside Godot func _init( p_name: String = "", p_surname: String = "", ) -> void: name = p_name surname = p_surname </code></pre> Let's see how Resources can be duplicated in Godot. Simple references</a></h2> The most trivial way to make two resources from one, is to assign it to a new variable. var player_1: Player = Player.new("Gianluigi", "Buffon") var player_2: Player = player_1 </code></pre> This creates a reference of the resource that still points to the same resource and no duplication takes place. This can be useful if you want to keep a pointer to a nested resource for easier access. But how can we verify, that they are the same? Every resource in Godot has an unique id, aka RID</a>, that can be accessed with the get_rid() function. # True, since both have the same RIDs assert(player_1.get_rid() == player_2.get_rid()) # changing player_1's properties, will automatically also change player_2's properties player_1.name = "Alessandro" player_1.surname = "Del Piero" # True, because both variables point to the changed resource assert(player_1.surname == player_2.surname) </code></pre> Shallow copy with duplicate()</a></h2> Using duplicate() function creates a copy of the resource. This function is also present in other classes, like Dictionary and Array. To show how duplicate works, a more complicated resource is needed. So let's create a team with a goalkeeper, that is a player. class_name Team extends Resource @export var name: String @export var goalkeeper: Player @export var field_players: Array[Player] func _init( p_name: String = "", p_goalkeeper: Player = Player.new(), p_field_players: Array[Player] = [], ) -> void: name = p_name goalkeeper = p_goalkeeper field_players = p_field_players </code></pre> Important to know is that only resources with the @export annotation get deeply duplicated. Additionally, this method will fail if _init() has been defined with required parameters. Now let's create a team and see how it duplicates. # Let's instantiate a team with a goalkeeper var team_1: Team = Team.new("Italy", Player.new("Gianluigi", "Buffon")) # and a copy of it var team_2: Team = team_1.duplicate() team_2.name = "Italy copy" # True, because both teams are unique and independent resources assert(team_1.name != team_2.name) # Let's change team_2's goalkeeper name team_2.goalkeeper.name = "Ganluigi" # True, because both are named Gianluigi assert(team_1.goalkeeper.name == team_2.goalkeeper.name) # Let's change team_2's goalkeeper surname team_2.goalkeeper.surname = "Donnarumma" # Also true, because the team_2's goalkeeper is a reference of the team_1's goalkeeper assert(team_1.goalkeeper.surname == team_2.goalkeeper.surname) </code></pre> So duplicate() creates a unique and independent resources, but all sub-resources will be shallow copies. This means they are only references. Deep copy with duplicate(true)</a></h2> The duplicate method has a boolean parameter called subresources, if set true, all sub-resources are also duplicated. So when using the same code from the previous section, the goalkeeper will also be duplicated. # Let's instantiate a team with a goalkeeper var team_1: Team = Team.new("Italy", Player.new("Gianluigi", "Buffon")) # and a copy of it, with sub-resources set to true var team_2: Team = team_1.duplicate(true) team_2.name = "Italy copy" # Still true, because both teams are unique and independent resources assert(team_1.name != team_2.name) team_2.goalkeeper.name = "Gianluigi" # True, because both still are named Gianluigi assert(team_1.goalkeeper.name == team_2.goalkeeper.name) team_2.goalkeeper.surname = "Donnarumma" # True, because the team_2's goalkeeper NO LONGER is a reference of the team_1's goalkeeper assert(team_1.goalkeeper.surname != team_2.goalkeeper.surname) </code></pre> Real deep copy</a></h2> Great, we can now duplicate resources now with all properties. Well, actually not all of them. The documentation reads: "Subresources inside Array and Dictionary properties are never duplicated." So there is currently no way to deeply duplicate a resource, with ALL it's sub-resources, using Godot's methods. # Lets create once again two players var goalkeeper: Player = Player.new("Gianluigi", "Buffon") var player_1: Player = Player.new("Paolo", "Maldini") var player_2: Player = Player.new("Alessandro", "Del Piero") # and a team with the two players var team_1: Team = Team.new("Italy", goalkeeper, [player_1, player_2]) </code></pre> Now we have a resource (team) with an Array of sub-resources (players). Let's make some tests. var team_2: Team = team_1.duplicate(true) team_2.name = "Italy copy" # lets change a players name team_2.players[0].name = "Daniele" # True assert(team_1.surname != team_2.surname) # True, because both player arrays still are the same resource assert(team_1.players[0].name == team_2.players[0].name) </code></pre> So let's create a custom method to cover this special case. func duplicate_deep() -> Team: var copy: Team = duplicate(true) copy.players = [] for player: Player in field_players: copy.players.append(player.duplicate(true)) return copy </code></pre> Using this custom duplicate_deep() method, the tests from above will work as expected. The same approach works with Dictionaries. var team_deep: Team = team_1.duplicate_deep() team_deep.name = "Italy copy" # lets change a players surname team_deep.players[0].name = "Daniele" # True assert(team_1.surname != team_deep.surname) # True, because both players are unique resources assert(team_1.players[0].name != team_deep.players[0].name) </code></pre> Here you can find the official documentation</a> of the duplicate method. In the meantime, my code changed</a></h2> When I started writing this, I had the necessity to deeply duplicate resources. In the meantime I refactored parts of the code to avoid using duplicates. This makes everything a lot easier to understand and to maintain. I still want to share how it is possible, but highly recommend to check twice if it is really needed. Said that, I also highly recommend to read the official documentation</a>, as much as possible. Godot has a really amazing documentation, with the class reference also included offline in the editor. So even with no/low internet connections, you are covered. And to be honest, if I should have read the duplicate methods documentation better in the first place. Summary</a></h2> So the most important things to keep in mind when duplicating resources are _init() with default parameters</li> Only @export annotated properties get duplicated</li> duplicate() creates copy of built-in properties, but references to sub-resources</li> duplicate(true) creates copy of all properties also sub-resources, except Arrays and Dictionaries</li> A custom method is needed, to duplicate Arrays and Dictionaries</li> </ul> I Love Free Software Day 2025 Simon Dalvai — Fri, 14 Feb 2025 11:50:00 +0000 It's been a long time since I wanted to share a list of FOSS projects I really enjoy. Today is prefect for this, because it's I Love Free Software Day</a>. This list would be enormous, if I would really cover every FOSS project I love and use. So I decided to limit this post to three projects and repeat this process every year on the 14th of February. Lichess</a></h2> The web can be full off ads, privacy invading trackers and proprietary software. Lichess</a> is the opposite of this and offers free (as in free beer and free speech) online chess. You can play it on Android, iOS and in the Web as an anonymous player or with an account. All features are available for free, even post-game evaluation with Stockfish</a> in the cloud. The only difference to users that have donated to the project, are wings near the user name. As of today, and I really didn't expect this, my account</a> states "Time spent playing: 34 days, 23 hours", and many more to come! The projects uses mainly copyleft licenses like GPL and APGL and is a registered French non-profit. It has no Contributor License Agreement</a> and this makes the project truly Free Software and resistant to for-profit take overs. To support the Lichess, you can donate</a> and contribute</a>. Godot</a></h2> The Godot Engine is a MIT licensed game engine capable of 2D and 3D graphics. It also has a innovative game design philosophy</a>, that makes game development a real joy. In a nutshell, a Godot game consists of scenes, that can have multiple nodes connected trough signals. A scene might be the game menu screen, a node the play button and the signal would be the button press action. This is just a guess out of the wild, but I think the gaming industry is one of the biggest "non-free" software ecosystem out there. One of the most notable exceptions are Lichess and Godot, of course :-) I strongly hope this will change in the future and there will be more Free and Open Source games and tools. The Godot Foundation</a> is a Dutch non-profit organization. Also here, no Contributor License Agreement exists. So this project thrives to remain free and open to it's community for a long time. To support the Godot Engine, you can donate</a> and contribute</a>. Codeberg</a></h2> The last year I started to host the source code of my projects on Codeberg</a>, a community driven and open-source git platform. I still push my code to the proprietary octopus-branded git platform, but Codeberg is my new origin. Behind the scenes it uses Forgejo</a>, a Gitea fork, that the Codeberg organization created, after a for-profit company took it over</a>. So if someday, you want to host your own "Codeberg" instance, you actually can by hosting a Forgejo server. Similar to Lichess and Godot, also Codeberg is a registered non-profit association in Germany and has no Contributor License Agreement. All the source code of Forgejo has the AGPL license, making it also a real Open Source project. To support Codeberg, you can donate</a> and contribute</a>. Spread the love</a></h2> Free Software projects often don't promote themselves much, because of small budgets, missing marketing skills or they simply don't want to. That makes it so important, to celebrate days like this and show the world what Free Software is and why it matters. And also on every other day of the year, we can recommend free and open alternatives, especially to non-technical people. Organic growth is the best way to bring new people to this community. We all know how your family and friends can't wait for the moment, you finally install them Debian on their machines ;-) With this, I want to thank the whole Free Software community and the ones that will join today. Neovim as External Editor for Godot Simon Dalvai — Sun, 19 Jan 2025 09:53:00 +0000 Since some months now, I'm happily using Neovim as an external editor with Godot Engine 3 and 4. Godot's internal text editor is fine, but my desire to use Neovim was too big. This blog post covers a minimal setup to get Neovim working with Godot. So you can integrate it directly to your existing configuration or use it as a starting point. Please note that some minimal knowledge about Linux and Neovim config files is needed to follow this blog post. Technically you can also just use Godot with vanilla Vim/Neovim with no further changes. But you might miss some features like opening files when clicked in the file explorer or LSP support. So lets set this up to let Godot add some magic to Neovim. Neovim server mode</a></h2> Before you can set Neovim as external editor in Godot, you need to start Neovim in server mode. Additionally to that, a pipe file is needed, where Godot can send commands to Neovim. Add the following code to the init.lua</a> file. -- paths to check for project.godot file local paths_to_check = {'/', '/../'} local is_godot_project = false local godot_project_path = '' local cwd = vim.fn.getcwd() -- iterate over paths and check for key, value in pairs(paths_to_check) do if vim.uv.fs_stat(cwd .. value .. 'project.godot') then is_godot_project = true godot_project_path = cwd .. value break end end -- check if server is already running in godot project path local is_server_running = vim.uv.fs_stat(godot_project_path .. '/server.pipe') -- start server, if not already running if is_godot_project and not is_server_running then vim.fn.serverstart(godot_project_path .. '/server.pipe') end </code></pre> This code iterates over paths_to_check and tries to find a "project.godot" file. Then it checks if a server is already running. I use this approach, because in my projects I separate the code in a "src/" directory. In my case the project.godot file is located in the parent directory. Additionally multiple Neovim instances can run, without causing errors or conflicts. You can adapt the paths to check to your needs. Note that now a variable is_godot_project exists and allows to check if a Godot project is opened. This can get very handy to start the Godot LSP client, only for Godot projects or similar Godot specific configuration. No worries, this will be covered later in this blog post. Godot Editor Settings</a></h2> Now Neovim is ready to be set as external editor in Editor Settings > Text Editor > External. There you need to set the following values: Enable Use External Editor.</li> Set Exec Path to the Neovim path.</li> Set Exec Flags to the following line.</li> </ol> --server {project}/server.pipe --remote-send "<C-\><C-N>:e {file}<CR>:call cursor({line}+1,{col})<CR>" </code></pre> This line will make Neovim open the file in a buffer and move your cursor to the indicated line and column. The +1 in cursor({line}+1)</code> is to go to the correct line. For some reason without +1, the line above is selected. The {project} keyword instead stands for the Godot project path. Now you can use Neovim as external editor in Godot and open files with it. LSP support</a></h2> Godot has a built-in Language Server Protocol</a>, that gives you features like code competition, error highlights and function definition lookups. Note: Neovim v0.11 changed how lsp are setup. Follow the setup guide, depending on which version you use. Neovim v0.11 or later</a></h3> Since v0.11 no nvim-lspconfig is needed, but can still be used if you want to. Without the plugin, you need to create your own config. I simply copied the default config from Github</a> to the file **.config/nvim/lsp/gdscript.lua`. ---@brief --- --- https://github.com/godotengine/godot --- --- Language server for GDScript, used by Godot Engine. local port = os.getenv 'GDScript_Port' or '6005' local cmd = vim.lsp.rpc.connect('127.0.0.1', tonumber(port)) ---@type vim.lsp.Config return { cmd = cmd, filetypes = { 'gd', 'gdscript', 'gdscript3' }, root_markers = { 'project.godot', '.git' }, } </code></pre> Then you can enable the configuration in your init.lua file. vim.lsp.config('gdscript', {}) vim.lsp.enable('gdscript') </code></pre> Neovim v0.10 or older</a></h3> First you need to install the Neovim LSP plugin</a> and set it up. I will use vim-plug</a> as my plugin manager. -- Installation Plug('neovim/nvim-lspconfig') -- Setup local lspconfig = require('lspconfig') -- godot lsp if is_godot_project then -- setup lsp lspconfig.gdscript.setup {} end </code></pre> Use the lsp</a></h3> Now you can access all special features when opening GDScript files. You can try code competition with Ctrl + x and Ctrl + o. This will suggest also all class names, function names etc in your Godot project. With Ctrl + ] you can jump to the definition of a function. There can be issues with the LSP, like auto complete giving no results. In this case you can try restarting the LSP plugin with the command :LspRestart, or simply restart Neovim. For the best experience, I recommend running the LSP in it's own thread. It can be done by setting Editor Settings > Network > Language Server > Use Thread to true. This reduces the need to restart the LSP a lot. Keep in mind that the LSP runs within Godot, so you need a running editor instance with your project open. Treesitter</a></h2> To get better colored code highlighting, Treesitter</a> does a perfect job. This plugin does also a lot of other things, like building a tree structure of your code. Other plugins might use that tree for better manipulation of your code. But I use it only for nicer colors (probably, I'm not sure). -- Installation Plug('nvim-treesitter/nvim-treesitter', { ['do'] = ':TSUpdate' }) -- Setup require'nvim-treesitter.configs'.setup { ensure_installed = {'gdscript', 'godot_resource', 'gdshader'}, highlight = { enable = true, }, -- disable auto install of languages when opening files auto_install = false, -- disable for files bigger than 100 KB disable = function(lang, buf) local max_filesize = 100 * 1024 -- 100 KB local ok, stats = pcall(vim.loop.fs_stat, vim.api.nvim_buf_get_name(buf)) if ok and stats and stats.size > max_filesize then return true end end, } </code></pre> This setup of treesitter includes also some configuration. The plugins gets disabled for files bigger than 100KB, to keep opening Neovim fast. With auto_install = false, new languages don't get installed automatically, when opening a file of the respective language. Only the languages defined in ensure_installed are installed. Here you can see a side by side comparison of Treesitter disabled on the left and enabled on the right. Neovim already can colorize some of the code, but Treesitter can do it better. Debugging</a></h2> Godot has a built-in DebugAdapterProtocol</a>, so it is directly integrated with Godot, exactly as the LSP. There are many Neovim Debug plugins out there, if you are already familiar with one, it's worth to check out if it supports Godot. While writing this blog post, I used to have nvim-dap</a> installed. This can attach to Godot's DAP and allow you to set breakpoints or run the game from Neovim. Then I also tried nvim-dap-ui</a>, that adds the needed UI with variable values etc. to Neovim. But with this setup, I faced several crashes of Godot and a inconsistent workflow. So I found, in my opinion, and more stable and easier way to debug. To be honest, the Godot's debug UI is hard to beat, with the remote tree inspector and all the rest. Secondly another huge problem for my game: launching specific scenes. I searched the web and haven't found a way to open a specific scene with nvim-dap. I often run specific scenes, since my latest game</a> got quite big. Having to start from the main scene every time, can get quite frustrating. But you can run specific scenes from the editor, right? Yes! But somehow Godot get's the breakpoints set with nvim-dap, only when started with nvim-dap. So I had to ask myself: how the f*ck was I debugging the last months?? And well, the answer is easy, I actually was not using nvim-dap, but the breakpoint keyword. The following code will print Hello</code> and then break and wait. func _ready() -> void: print("Hello") breakpoint print("world!") </code></pre> This can have the disadvantages that you need to write it, and remember to remove it. No worries, it won't break your game when exported. This keyword only works, when the project runs inside a Godot editor. But the advantages are, that this breakpoints are written code, so they are persistent and can be shared with other developers or machines. And there is no need for an additional Neovim plugin. The best part of all this, I wrote my first custom Neovim functions/commands (or however they are called). Seeing for the first time, why Neovim is so fun and truly hackable. -- define functions only for Godot projects if is_godot_project then -- write breakpoint to new line vim.api.nvim_create_user_command('GodotBreakpoint', function() vim.cmd('normal! obreakpoint' ) vim.cmd('write' ) end, {}) vim.keymap.set('n', '<leader>b', ':GodotBreakpoint<CR>') -- delete all breakpoints in current file vim.api.nvim_create_user_command('GodotDeleteBreakpoints', function() vim.cmd('g/breakpoint/d') end, {}) vim.keymap.set('n', '<leader>BD', ':GodotDeleteBreakpoints<CR>') -- search all breakpoints in project vim.api.nvim_create_user_command('GodotFindBreakpoints', function() vim.cmd(':grep breakpoint | copen') end, {}) vim.keymap.set('n', '<leader>BF', ':GodotFindBreakpoints<CR>') -- append "# TRANSLATORS: " to current line vim.api.nvim_create_user_command('GodotTranslators', function(opts) vim.cmd('normal! A # TRANSLATORS: ') end, {}) end </code></pre> GodotBreakpoint adds the "breakpoint" String below the line the cursor is on, indented correctly. GodotDeleteBreakpoints deletes all breakpoints lines in the current buffer. GodotFindBreakpoints finds all breakpoints in the current project. GodotTranslators adds a comment to the end of the line, for translation comments</a>. Now its possible to write, delete and search breakpoints within Neovim with simple keymaps. Finally you need to enable also Debug with External Editor under the Script view. If this flag is not set, the internal editor will open while debugging. Godot documentation</a></h2> You can read documentation for a function with Shift + k, while the cursor is on a function. If you want to read or search Godot's full offline documentation, you can still do that in the Editor with the Search Help button. This will open the documentation in Godot's built-in editor. I don't know if it's even possible to open also this files in Neovim, but for me this is totally fine. Full Neovim configuration</a></h2> Here you can find the full init.lua file, ready to be hacked and extended. You can find my personal full Neovim configuration in my dofiles repo on Codeberg</a> and Github</a>. This contains some more plugins, color schemes and configurations. -- ---------------------- -- vim-plug plugin-manager -- ---------------------- local vim = vim local Plug = vim.fn['plug#'] vim.call('plug#begin') Plug('nvim-treesitter/nvim-treesitter', { ['do'] = ':TSUpdate' }) Plug('neovim/nvim-lspconfig') vim.call('plug#end') -- ---------------------- -- lsp -- ---------------------- local lspconfig = require('lspconfig') lspconfig.gdscript.setup{} -- ---------------------- -- treesitter -- -- ---------------------- require'nvim-treesitter.configs'.setup { ensure_installed = {'gdscript', 'godot_resource', 'gdshader'}, highlight = { enable = true, }, -- disable auto install of languages when opening files auto_install = false, -- disable for files bigger than 100 KB disable = function(lang, buf) local max_filesize = 100 * 1024 -- 100 KB local ok, stats = pcall(vim.loop.fs_stat, vim.api.nvim_buf_get_name(buf)) if ok and stats and stats.size > max_filesize then return true end end, } -- ---------------------- -- Godot debug config -- ---------------------- -- write breakpoint to new line vim.api.nvim_create_user_command('GodotBreakpoint', function() vim.cmd('normal! obreakpoint' ) vim.cmd('write' ) end, {}) vim.keymap.set('n', '<leader>b', ':GodotBreakpoint<CR>') -- delete all breakpoints in current file vim.api.nvim_create_user_command('GodotDeleteBreakpoints', function() vim.cmd('g/breakpoint/d') end, {}) vim.keymap.set('n', '<leader>BD', ':GodotDeleteBreakpoints<CR>') -- search all breakpoints in project vim.api.nvim_create_user_command('GodotFindBreakpoints', function() vim.cmd(':grep breakpoint | copen') end, {}) vim.keymap.set('n', '<leader>BF', ':GodotFindBreakpoints<CR>') </code></pre> Ignore some files</a></h2> If you use file explorers plugins you might want to hide some files for Godot projects. Like the server.pipe file or all *.uid files introduced in Godot 4.4. This hides the files in Nerdtree</a>. if is_godot_project then -- ignore *.uid files introduced in godot 4.4 -- ignore server.pipe file vim.cmd('let NERDTreeIgnore = ["\\.uid$", "server.pipe"]') end </code></pre> And this Oil</a>. -- ---------------------- -- oil -- ---------------------- require("oil").setup({ view_options = { show_hidden = true, is_always_hidden = function(name, bufnr) -- for godot projects ignore *.uid files if is_godot_project then -- ignore *.uid files introduced in godot 4.4 if vim.endswith(name, '.uid') then return true end -- ignore server.pipe file if name == 'server.pipe' then return true end else return false end end, }, }) </code></pre> If you use other file explorer plugins, there surely is a way to hide this files too. Just check the docs or some example configs. What I miss in Neovim</a></h2> So far the biggest feature I miss, is the easy Ctrl + drag and drop of a Node into the text editor. This will automatically create the var with the correct Nodepath. After some time I found a much better approach by using % and Access as Unique Name</a>. With this you can access the Node, without having to write the full Node path. # This long path @onready var healt_label: Label = $MarginContainer/HBoxContainer/VBoxContainer/HealthLabel # simply becomes @onready var healt_label: Label = %HealthLabel </code></pre> Another crucial advantage is that you can move the Node around the tree, or change parent Nodes, without having to adjust the path. At the end of the day, being able to use Neovim pays back anyways, if you like it and are keen to keep learning. Or you already know everything about Vim/Neovim, but let's be honest, nobody does. Credits</a></h2> I want to thank Daniel</a> for his great suggestions. Now multiple instances can be used and the server mode only starts, if a Godot project has been found. Having fun with Godot Movie Maker - Part 1 Simon Dalvai — Tue, 17 Dec 2024 17:26:00 +0000 To release a game on Steam, it is good to have at least one video trailer about the game. For releasing only the store page, it doesn't really need to be a video about actual game play. It can only be a teaser, where you announce your game. I don't have much experience with video creation and editing, so I started to search the web once again for Open Source video editing tools. The first I found where OpenShot</a>, Kdenlive</a> or directly FFmpeg</a>, which I know from the past. But I used them mostly to cut or modify existing videos, not to create new content from scratch. Godot Movie Maker to the rescue!</a></h2> After some time, I remembered that Godot actually has a feature called Movie Maker. And the best part is: I know how to use Godot + it can make movies = perfect match! Godot's Movie Maker feature allows you to create Movies with everything Godot is capable of. So you can code a movie using Tweens, the AnimationPlayer, pure code or whatever comes to your mind. The best part is, everything is automated and supports versioning with git. So for example it's possible to translate the video in different languages with ease. Or if you made a mistake and broke something, simply run git restore and your work is save. Here you can see the magic button, that transforms Godot into Hollywood. Just press it and when you run a scene or the game, everything visible on the screen will be saved to a file. The file needs to be defined under Project Settings>Editor>Movie Writer>Movie File. Or add the String move_file to the scene's metadata as I did in the screenshot below. If you plan to only make one video with your project, use the project settings. Otherwise the metadata is more convenient, because you can have multiple files defined for different scenes. The first result</a></h2> This is my very first video created with Godot. Oscars, I'm coming! You can find it on Steam</a>, YouTube</a> or if you prefer, more privacy friendly on Mastodon</a>. It's quite simple with no special effects, except the ball fireworks at the end. But I was quite fast to create it and I was able to iterate, like I do with while programming. I can only guess how much effort it would have been, to create it with some other video editing tool. Below the few lines of code needed for this simple trailer. extends Control @onready var animation_player: AnimationPlayer = %AnimationPlayer func _ready() -> void: theme = ThemeUtil.get_active_theme() animation_player.play("Teaser") </code></pre> As you an see, the real work is done by the AnimationPlayer. For someone who doesn't know Godot, the AnimationPlayer can change the properties over time. Like in the screenshot below, I can simply make text labels fade in and out, or trigger the CPUParticles, that are the final ball fireworks effect. For the first attempt this was totally fine, but it needs a lot of clicking, sliding and patience. I highly prefer to code everything and use less the mouse. But this will be covered in a future part 2 of this blog post. You can find the full source code on Codeberg</a> or Github</a>. Note: The location of the trailer files might change in the future, so this links might break. Let me know if that happens, so I can fix it. Performance</a></h2> Video editing and gaming (in a world before LLMs) are the most resource intensive tasks you probably can do on a computer. Godot isn't much different, but I have to say that it worked quite well on my potato laptop (dual core i5 7th gen, no GPU). You can see the output directly while it is written to the file, and it takes about 2x more time. So for a video of 10 seconds like mine, the recording takes about 20 seconds. But I can imagine that a proper computer, should be able to play and write the videos at normal speed. What will be in part 2?</a></h2> I actually wanted to fit also the second game play trailer in this blog post. But I want to make it really good, to attract the most people possible with it. For that reason, I still need some time to improve the game itself. But I can already anticipate that Godot's Movie Maker is really powerful. I was able to use actual game scenes for the videos and even interact with them, while recording. Final thoughts</a></h2> The Godot Movie Maker is much better as expected and makes the video making really fun. It is incredible, how simple but yet powerful this feature is. I could imagine making videos also for non gaming stuff, where things like text or effects can be automated. Now I just need to add the Godot Engine to all the FOSS video creation tools list on the web ;-) So the next one who searches the web, finds this hidden gem. Last but not least, the official release note</a> of the Godot Movie Maker, if you want to know more about it. Debian Sway v1 - My first setup Simon Dalvai — Sat, 16 Nov 2024 10:15:00 +0000 This year I started using Sway</a> on my laptop running the latest stable Debian 12</a>. Sway is a tiling window manager and a i3wm</a> clone for Wayland. As all tiling window managers, you can start, arrange and align windows directly with the keyboard. I didn't find much on the web about how to setup Sway on Debian, therefore I will share my experience here. Getting it running on Debian needs time and patience. There is no official or unofficial Debian ISO image and that means you need to setup everything from scratch. If you simply want to try Sway, without having to setup everything on your own, I would suggest Fedora Sway</a>. It has a lot of tools already installed out of the box and is a great place to get a first impression. As for every highly configurable system, no configuration is the same and everybody needs to find what fits best. Keep in mind that this is no tutorial with exact and precise needed steps, but more a direction sign, showing you a possible path. XFCE, KDE and workspaces</a></h2> As you might saw in my previous blog post</a>, this year I also started using Neovim. At that time, I was still using KDE Plasma 5 and I loved it. I used a 3x3 workspace grid, I brought over from XFCE and had specific programs always in the same workspace. But being able to do everything with a few keystrokes, like in Neovim, just feels so nice. Then I finally tried Sway, side by side to KDE Plasma and used both for some time. You can do that easily on Debian (and surely also on other distros), by simply installing Sway and then choosing it as desktop environment on the login screen. Not everything was working 100%, but at least I got an idea if I like Sway or not. All or nothing</a></h2> After a few weeks of using this hybrid system, I actually uninstalled Sway again and went back to KDE Plasma. I simply couldn't get used to the Sway way of doing things and missed the ease of my old setup. But in my opinion, with tools that need (a lot of) time and muscle memory to master, like Vim and Sway, you need to go all in. If you simply can switch to your old editor or desktop environment, you will never learn it for real. In difficult moments, you will simply switch to the other one, but exactly in that moments, you'll learn the most. Then I finally did the hard switch and reinstalled Debian without any desktop environment and installed Sway on top of it. Now I can't imagine using a "conventional" desktop environment again. Tiling window managers can give you a feeling of connection to your machine, that no mouse drag and click can replace. The good and the better</a></h2> Now here I am, with a minimalistic Debian install and Sway, but nothing else. But, how can I connect to my WiFi? Does Bluetooth work? What did just happen?! Ohh, the battery is empty. This and other stories will happen, the first time you'll use such a bare bones setup. In my previous try, all this things where covered by KDE, but Sway doesn't come with batteries included. The Debian setup without desktop environment is designed for servers and they don't have displays, batteries or Bluetooth. This can be seen as bad, but in some way also as good, right? You'll learn a lot of new tools and see under the hood of a conventional desktop environment. All the heavy lifting a desktop environment does, is now on you. I spent hours and hours trying to understand, which cli/GUI tool can cover my needs. And now I have a nearly perfect setup and can do everything with the keyboard. I couldn't imagine using something else. To note, that I exactly thought the same for XFCE then KDE ;-) The killer feature</a></h2> But in my opinion the real killer feature of Sway is that it's reproducible. Every tool and Sway itself, has it's own config file, that can be versioned and restored with git. With that, you no longer have to remember what checkbox you clicked in the settings GUI. If you reinstall your OS or change distro, you can simply bring your config files with you. You can even synchronize everything automatically with other machines. For example, you change your Sway key binds at home and the next day at work, get the changes instantly synced to your working machine. I currently use a git and Syncthing</a> combination to backup and synchronize my most precious files. Even on my Android phone with Neovim on Termux, I was able to reuse my Neovim configuration (this was just an experiment, I'm not that crazy, yet...). I guess, someday this synchronization setup will get it's own blog post. Tools</a></h2> To save you some time, I tried to list all important tools I'm using. You can see my configuration of the following tools and my Debian install.sh script in my dotfiles repo on Codeberg</a> or Github</a>. Terminal</a></h3> A fast, lightweight and minimalist Wayland terminal emulator aka foot. apt install foot </code></pre> You can even start it in server mode to save memory, not that it uses much, but still cool! For me it was enough, being able to install a solarized-light theme easily. When choosing the terminal, you should just make sure that your terminal emulator of choice supports Wayland. A good alternative is Alacritty. But the version on Debian (at the time of writing) doesn't have yet the new toml configuration file. Therefore, a lot of guides didn't work. Neovim</a></h3> Well, you probably already use Neovim or another terminal based editor, if you feel the need to use Sway. Or maybe it will happen vice versa, using Sway will make you switch to one. apt install neovim </code></pre> This will install a quite "old" version of Neovim. If you just want to use Neovim without much plugins, this version is fine for you. But the more plugins you use, the more compatibility issues you'll face. Read in my previous blog post</a>, on how to get the latest version to Debian 12. Most famous enemy</del> alternative is of course GNU Emacs</a> ;-) Beautiful, beautiful Neovim with solarized-light theme (on the left). Terminal multiplexer</a></h3> When you live in the terminal, having something like tmux</a> is a great help. apt install tmux </code></pre> It brings multiple and detachable sessions, vertical and horizontal splitting, session recovery and much more. I haven't figured it all out yet. I use it daily and combined with Sway, it is really great. In my setup, when opening a terminal, a tmux session will always start automatically. Tmux is not essential and can be too much overhead, if you still need to learn and setup Sway. My recommendation is, once you feel confident with Sway, try tmux. An older and simpler alternative can be screen</a>. Network Manager</a></h3> Remember clicking in your system tray and choose the WiFi in a nice looking UI? This days are over and Gnome's Network Manager</a> will make it easy to never look back. apt install network-manager </code></pre> Once installed you can simply run nmtui and you'll see a terminal user interface with all needed networks settings. In my opinion it looks quite cool, but if you don't agree, there surely exists another network manager with a nice GUI. This is the only terminal network manager tool I found on Debian. Other distros like Arch, have a lot of more options. Battery optimizations</a></h3> The best tool I found in general for battery optimization, is TLP</a>. It allows you also to limit the charging to 80%, for a increased total battery lifetime. apt install tlp # start it tlp start </code></pre> I used it also on other distros with various desktop environments and it always worked great. I brings a lot of features like turning on bluetooth/wifi from cli. For that, simply type bluetooth on and wifi off. Or you can also disable them automatically on boot in the tlp config file. A terrible battery experience I had, was the unexpected power off, when the battery was empty. I highly prefer to suspend on 5% of battery, so I have time to find a charger. You achieve that, by creating a new udev rule under /etc/udev/rules.d/99-lowbat.rules with the following content. # Suspend the system on 5% or lower SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="[0-5]", RUN+="/usr/bin/systemctl suspend" </code></pre> Now you are save and your system will not self destroy itself unexpectedly. Sway bar</a></h3> Sway comes with that tiny bar on the top or bottom, where you can see your workspaces, the time and any other info you need. Personally I use the built-in sway-bar, but many prefer and use the more feature packed Waybar</a>. The Waybar can adjust volume, back light by mouse scroll or shutdown you machine with some mouse clicks. Another gem I found is yambar</a> from the foot terminal author. Looks great and is similar to Waybar. I recommend to try all out and find what covers your needs best. Multiple monitors</a></h3> Kanshi</a> is a really useful tool, if you use a laptop that will connect to other monitors. apt install kanshi </code></pre> It allows you to define a monitor's position, resolution, orientation and much more. So you can for example disable the laptop's display while attached to other monitors. Or simply define which workspace is on which monitor. I still have some minor issues, that sometimes it doesn't really change workspace arrangement when docking my laptop. Anyway, when reloading the Sway config with Ctrl + c, it's fixed 9 out of 10 times. If not, I simply reload, until its fixed. I suspect that there is some race condition, with another component of Sway. More tools...</a></h3> Here some more tools I'm currently using. thunar</a> - fast and lightweight file manager</li> wofi</a> - application launcher and menu</li> wlsunset</a> - blue light filter</li> mako</a> - lighweight notification daemon</li> slurp</a> and grimshot</a> - screenshots</li> pulsemixer</a> - cli audio control</li> hstr</a> - see and search your full bash history with Ctrl + r</li> xwayland</a> - run X clients on Wayland</li> light</a> - adjust display brightness</li> </ul> And here the last screenshot, running hstr (bottom left), pulsemixer (top left) and nmtui (right). Fine tuning</a></h2> I did some other minor changes to fit my needs and habits. I tried and changed a lot of stuff, but I hope I covered everything in my dotfiles repo and here in this blog post. Grant some permissions</a></h3> I like having my user not in the sudoers group, like Debian has per default. Because of that, I can't simply run sudo command but have to use the root user. I really like this approach, since I know when I use root, to be cautious. And secondly, no shady script (or more probably myself) can run dangerous sudo commands with my user. The only drawback is that some programs like light or systemctl need root access. So I granted root access to my user for that programs, by running the following 2 lines, as root user. echo "# for light and systemctl shutdown, suspend, reboot" >> /etc/sudoers echo "%dulvui ALL=(root) NOPASSWD: /usr/bin/light,/usr/bin/systemctl" >> /etc/sudoers </code></pre> Now I can change my laptops display brightness. # more bright light -A 5 # less bright light -U 5 </code></pre> And use systemctl for even more trivial things, without sudo. systemctl poweroff systemctl suspend systemctl reboot </code></pre> Power button instant shutdown</a></h3> Per default, your machine will power off instantly, when you press the power button. This can get annoying, when you intend to wake up your machine from suspension and instead turn it off. Thanks to this reddit post</a>, I found the solution. # as root vim /etc/systemd/logind.conf # change following values HandlePowerKey=ignore HandlePowerKeyLongPress=poweroff # restart logind or reboot systemctl restart systemd-logind </code></pre> The long press power button (emergency) shutdown still works, because HandlePowerKeyLongPress is set to poweroff. Bluetooth audio</a></h3> Getting my wireless headphones to connect and play good quality sound, was maybe the most difficult problem I solved, somehow... First, I was able to connect them, but the quality was really bad (using Hands Free protocol). Now it is working fine, but for this I changed so much, that I can't really tell, what worked in the end. I will try my best and list what I have installed, to fix the issue (out of frustration). # audio apt install pipewire apt install wireplumber apt install pipewire-alsa apt install pipewire-audio apt install pipewire-audio-client-libraries apt install pipewire-bin apt install pipewire-jack apt install pipewire-pulse # bluetooth apt install bluez # gui for pairing apt install blueman # for a2dp and other bluetooth profiles apt install libspa-0.2-bluetooth </code></pre> Once I install my OS again, I will be able to test what actually fixed the issue. Then I will update also this blog post. Until then, if you tested it or simply know it better, please contact me. Note: I own Sony headphones and I need to mention this, since it seems that many companies have their own Bluetooth profile. For that reason, it could be that yours work out of the box or need another library to work. Start Sway on login</a></h3> Simply put the following lines to your ~/.profile file and Sway will launch automatically, once you logged in. This will also set some Wayland flags for Firefox, Thunderbird and other applications. # Sway autostart if [ -z "$WAYLAND_DISPLAY" ] && [ "$XDG_VTNR" -eq 1 ]; then export MOZ_ENABLE_WAYLAND=1 export XDG_SESSION_TYPE=wayland export XDG_CURRENT_DESKTOP=sway exec sway fi </code></pre> I tried some login screens with nice GUIs, but at the end I use the default "login:" white text on black background. Simple yet effective and once I got used to it, I didn't mind that it doesn't look fancy. Screen sharing</a></h3> This was the main reason, I still kept KDE on my system, since it didn't work out of the box with Sway. But then I decided to bite the bullet and finally fixed it thanks to this guide on Reddit</a> This was the final hurdle I had to pass, before switching fully to Sway. To get it working, simply install the following programs. apt install xdg-desktop-portal apt install xdg-desktop-portal-wlr </code></pre> Append the following lines to your Sway config file, or somewhere that will execute them, after Wayland has started. exec /usr/libexec/xdg-desktop-portal -r exec /usr/libexec/xdg-desktop-portal-wlr </code></pre> And make sure the flag MOZ_ENABLE_WAYLAND=1 from the previous section is set. Future improvements aka v2</a></h2> As you can imagine, after reading the title of this blog post, there will be a v2. I could imagine replacing my bash scripts, with something more mature and reliable as Ansible</a>. This would make the setup reproducible for everyone and more portable, maybe even for other distros. If I switch to Ansible, I'll let you know for sure, in another blog post. Then I will discover more cool tools, or even switch to Arch? Or simply upgrade to Debian 13 Trixie and save some years of life and gray hair. Last but not least, v3 will be my own Debian distribution with Sway, maybe Swaybian? Or I could become the maintainer of an official Debian Sway release. Never stop dreaming :-) Useful links</a></h2> To conclude my longest blog post so far, a collection of links and wikis I found useful on my journey. Sway page on ArchWiki</a></li> Sway page on Gentoo Wiki</a></li> Sway page on Debian Wiki</a></li> Fedora Sway config repo</a></li> Bluetooth page on Debian wiki</a></li> </ul> Note: The ArchWiki was especially helpful in general. You can find a lot of great cli tools and information, about how to run a minimalist OS. From VSCode/VSCodium to Neovim Simon Dalvai — Fri, 18 Oct 2024 21:58:00 +0000 I was using VSCode</a> and later VSCodium</a> for some years as my editor for everything. They are awesome tools and are getting the job done. But as you might know, VSCode is built by Microsoft, and has in my opinion some issues, like telemetry</a>, proprietary extensions ecosystem</a> and actually not being FOSS</a>. I think Microsoft did really a great job here and VSCode is a great tool. They especially started the development of the Language Server Protocol</a>, that I use now also in Neovim. But in the long term, I feel that a real FOSS editor with an open extension/plugin ecosystem, is the right choice. Finding an alternative</a></h3> It is not easy to find something similar to VSCode. This are my minimal requirements, in ascending order by importance FOSS, for real</li> Fast opening and editing</li> Language Server Protocol support</li> Spell checker (since I make errors, a lot)</li> No telemetry</li> </ul> Here some editors I tried to replace it KDE's Kate</a></li> KDE's KWrite</a></li> Gedit</a></li> Geany</a></li> Micro</a></li> Zed</a> (after switching to Neovim)</li> </ul> All without success. They are all great editors, but I simply had the feeling, that it was time to really try Vim. It all started with a big bang</del> Vim</a></h3> So I chose Vim</a> as my new text editor. I could immediately feel the advantage of sticking to the keyboard as much as possible. Everything is a few keystrokes away and is really fun. After getting used to vim basics and motions, I wanted to give Neovim</a> a try. But lets check if my requirements fit Neovim. FOSS, for real Neovim is Apache 2.0</a>, and is based on Vim, with it's own Vim License</a> Fast opening and editing Opens instantly, even for big files Language Server Protocol support Full LSP support</a> Spell checker (since I make errors, a lot) The simple command :set spell</code> does the magic, already built-in! No telemetry Or maybe there is</a>?? Getting the latest version on Debian</a></h2> My current OS of choice is Debian 12 bookworm. Debian bookworm, at the time of writing, has Neovim version 0.7.2. You can check the current version in Debian stable here</a>. This version is not compatible with latest package managers and plugins. Most of them work with 0.9.5 upwards. So I needed to get the latest Neovim from elsewhere... AppImage</a></h3> First I tried Neovim's official AppImage, you can find on Github</a>. It was a good first start and an easy way to try the latest version on Debian. Building from source</a></h3> But after seeing ThePrimeagen building Neovim from source on YouTube</a>, I also wanted to do that, to have a proper .deb package and drop the AppImage. It was actually my first time, that I built a program from source and installed in on my machine. That makes it a lot easier to contribute back to a project! But well, for now I'm happy with my home built Neovim deb file. Here a quick guide on how to build it by yourself. Requirements # first, install build deps apt install -y ninja-build gettext cmake unzip curl build-essential # clone neovim's repo git clone https://github.com/neovim/neovim cd neovim </code></pre> Build and install # check out stable tag, or specific version you prefer git checkout stable # build neovim make CMAKE_BUILD_TYPE=RelWithDebInfo cd build && cpack -G DEB # install it, as root dpkg -i nvim-linux64.deb </code></pre> Update # switch back to master git checkout master git pull git fetch --all # check out stable tag, or specific version you prefer git checkout stable </code></pre> After getting the updates, you can build and install again. Package manager(s)</a></h2> There are so many package managers and Neovim distributions, that it can be overwhelming. I think everybody needs to explore this jungle on it's own, get hands dirty and find what fits the most. Many recommend starting from kickstart</a>, and maybe I also should have done that too. After days of restarting from scratch, trying this and trying that, I sticked with vim-plug</a> for now. Plugins</a></h2> After thinking that Neovim has tons of package managers, I haven't yet seen the huge number of plugins. Multiple plugins that solve the same issue, just maybe written in Lua or with fancy icons. Many times there is no right or wrong, old or new. My recommendation is listen to your gut, and don't overthink it. I saw many videos and articles on the web, where users had at least 50 plugins installed. There are even benchmarks the opening of Neovim in milliseconds where 40ms is the usual "fast enough" value. Since I'm still in my early Neovim days, I have around 20 plugins installed. But surely more are coming, and my first benchmark waits behind the corner. But there is also the thing, that plugins might break during updates etc... I haven't encountered that yet, but I guess, less plugins is better in that sense. Configure with init.lua</a></h2> You can adapt Neovim as you prefer with all the plugins available. Or even write some own scripts in Lua. But first you need a init.lua file. mdir -p .config/nvim touch .config/nvim/init.lua </code></pre> Now you can watch hours of videos and read articles and books about vim. The grind will never stop, unless you finally admit that you are wasting to much time in configuring your editor. At some point you simply have to accept that it's good enough. You can find my current Neovim configuration file on Codeberg</a> or Github</a>. Look Ma, no mouse</a></h2> Now that I'm keyboard addicted, I also started using shortcuts whenever I can. I use sway</a>, as my tiling window manager on Debian. With a few keystrokes you can switch workspaces, open terminals and align windows at the speed of typing. And everything is a configuration file, like in Neovim. So the next time you re-install your OS, you just need to get the file and get back where you left off. If something breaks or you don't like some changes, simply git revert</code> everything. I also started to use Firefox shortcuts</a>, like open a new tab with ctrl+t, close it with ctrl+w or cycle trough tabs with ctrl+pgup and ctrl+pgdn. Then there is F6 to focus the address bar or ctrl+shift+p for private browsing. I even tried Vimium</a>, a Vim Firefox extension to get vim navigation. But there I drew the line and went back to endless scrolling, with the mouse... As you can see, Neovim is not just an editor, it is a life style. I quit my job to go full indie Simon Dalvai — Mon, 16 Sep 2024 09:25:00 +0000 I'm excited to announce that today is my first official day as a full time indie game developer. After three years of CI/CD pipelines, several software migrations and bug fixes at NOI Techpark</a>, it was time to say goodbye. The plan</a></h2> It was never my plan to become full time indie dev, because I thought that making games is just a hobby and a nice way to pass my free time. But things have changed and my games became too complex to be developed properly in my limited free time. So I had the feeling, that I need to try this adventure and see where it leads. Now I can dedicate my whole day to my games, this blog and all the CI/CD pipelines I created for Godot and libGDX. My main focus will be the game that got too big to handle in my free time, Futsal Manager</a>. I plan to release the first early access on Steam and itch.io early 2025. Having around half a year time, to finish my game, I feel that this date might actually be true this time. (I've been promising to finish this game to my friends already too many times) The experiment</a></h2> This whole "project" is actually an experiment, to see if I can make a living with Free and Open Source games. I truly believe, that the game development world can profit from Open Source games. There are already really nice Open Source game engines and libraries, like the Godot Engine</a> and libGDX</a>. I never used a closed source engine like Unity or similar, so I can't really compare them. But the bad news Unity had in the past months, show that betting on a Open Source and community built engine, is the road to go. I also believe that gamers will profit the most from Open Source games. Being Open Source, limits the way one can profit from it, but in my opinion in a good way. Business models like packing the game with ads or micro transactions don't really fit in the Open Source world. Someone could simply make a copy of your game without ads, micro-transactions or a season pass. Making a living with FOSS games</a></h2> There surely are and will be many other business models, that are FOSS compatible. For now, I will simply follow the way Mindustry</a> does it. You can get free copies of the game on itch.io, flathub, F-Droid etc... and a payed version on Steam. This seems the easiest and safest way to do get some dollars out of a Open Source game. It solves the cheaper clone of the game problem, because I will offer the cheapest (free) alternative on the market. Surely this "business plan" is not compatible with big AAA game studios, but who knows, maybe some day we will see a AAA Open Source game. What comes next</a></h2> Now you will hear much more from me, here in my blog and on Mastodon</a>. My git-steak (at the time of writing: over 1 year a commit a day) will continue and grow much bigger. I'm also considering some live development streams on Twitch and videos on YouTube. But for now, I will concentrate on finishing Futsal Manager. Use websockets in Godot on itch.io with Caddy Simon Dalvai — Mon, 26 Aug 2024 16:10:00 +0000 To use websockets within your Godot game on itch.io, or any other website, a secure websocket connection, aka wss://</code>, is mandatory. WARNING: This is probably not the correct way to secure Godot's websocket connections. I'm using this setup only for some real-time auction tool</a> I created for personal use only. Please inform yourself, before using this in production. If you know the correct way how to solve this (or this actually is the correct way), please le me know! Caddy for the rescue</a></h2> The caddy webserver</a>, by default, automatically obtains and renews TLS certificates for all your sites and applications. This includes your websocket server! With this simple Caddyfile, your websocket server is ready. Change the 8000</code> port to whatever port you are using. Also the /ws/*</code> can be changed to /whatever/*</code> you prefer. your.dom.ain { reverse_proxy /ws/* localhost:8000 handle /ws/* { reverse_proxy localhost:8000 } } </code></pre> In your Godot client code, you can simply put the secure websocket url. Just make sure you use wss://</code> instead of ws://</code>. const HOST: String = "wss://your.dom.ain/ws/" </code></pre> Now you can play your game on itch.io or other websites! Client/Server code</a></h2> The godot-demo-projects</a> repository has great code examples for networking. My application uses the code from there and can be found here client</a></li> server</a></li> </ul> This is an application for managing an auction for the Italian fantasy football game Fantacalcio</a>. In this code, the server is just forwarding the messages from one client to all other connected clients. The server does not store any data or state. If needed, you can extend the server with more logic, handling sessions, store data etc... Personal blog, as a solo game dev? Simon Dalvai — Wed, 24 Jul 2024 21:30:00 +0000 Yes, it is worth it, if you like writing (or nowadays, prefer to let some fancy VC backed LLM service do the writing). No worries, my blog posts are still written by crystallizing words out of my by brain. All (grammar and syntax errors) inclusive. If you don't like writing at all, I still recommend having a simple personal webpage with at least the list of your created games. It is also great to host privacy policies for your games, that is mandatory for Google Play Store and Apple App Store. I started with game development as a hobby around 2018 and created some games. Since the end of 2022, I also have this personal website with a blog, where I post monthly something about game dev or other things I find interesting. Here I share my experience on having a personal blog as a solo game developer. Hosting: Github Pages vs Self hosting</a></h2> The first year I hosted my website on Github Pages. It is completely free and gives you a great starting point for your personal webpage. It works pretty well and within minutes, you can have a website with the url [your username].github.io online. If you want to use a custom domain, this is also quite easy, but may vary between domain service provider. So I won't go into detail on this topic. Since January 2024, I'm hosting my website on a shared cloud server on Hetzner running Caddy</a> on Debian</a>. That costs me around 5€/month for now, but gives me more control and insights over my website. By self hosting, I can see the access logs on the server, to get a rough overview on how many users and bots (there are a lot crawlers out there) are visiting. Then I can also use some features like caching or URL redirects, that Github Pages doesn't provide. I also don't really know how and if Github (and Microsoft) are using the traffic on Github Pages to track users and process/sell the data. I would guess, yes they to, since nothing comes for free if it is provided by a big tech company. So if you care about privacy, self hosting might be the better choice. My recommendation is to use Github Pages or similar to get started, if you have no experience with self hosting. Then slowly start playing around with some servers, when you start getting bored with your setup :-) Visibility</a></h2> This blog has increased the visibility of my website and games a lot. I guess 90% traffic of my website, comes from my blog post. I can't give exact numbers, because I not using any user tracking and analytic tools on my websites and games. But there are some tools that still can give you a rough number, on how many users you reach. It is also really helpful to see which blog posts or games attract the most users, organically. Every user that reads your blog post is a potential player of your games. From reading a blog post, to downloading a game might be only 2 more clicks. You can then further increase the visibility of your content by posting on other websites. I normally post them on hackernews</a>, mastodon and sometimes on reddit</a>. It is incredible how much traffic you can get, once something got up voted a lot. As an example: the most views I got on itch.io</a> was, when I landed on the front page of hackernews for some hours with this blog post</a>. Building an audience</a></h2> Some people will read and like your blog posts and games. If you have an RSS feed or post on social networks, you might even have people that reads your content immediately, when it is released. I currently have a really small audience, but I'm pretty sure this is how it works for successful people :-) Market share discovery</a></h2> By having a website of your game and Google Search Console enabled, you can see if people search for your game already. This can be really motivating, if your game's website gets views, even before it is released. This actually happens right now for my game Futsal Manager</a>. I get daily visits and occasionally e-mails because of it, and I haven't released the game yet. So this means that once I release the game, I already know that some people will search for in and find it. All organically and for free. Tracking</a></h2> I don't use any user tracking tool in my games or website. This makes makes it hard to understand, what content users like, and what not. But there are still some tools and tricks out there, to get a rough estimate. I currently use the Google Search console and get some data from the caddy web-server logs. Google Search Console</a></h3> You can get a good search engine performance overview using the Google Search Console</a>. For that you just need a Google Account and verify ownership of the websites you want to "track". Google will give you some data on how many users have seen you page in their results, clicked on it and what the keywords where. Even more interesting to me is the list of websites that link back to you website. Here you might find that your blog post has been shared on some social network or cited in some article. Here of course you'll see only data from people using the Google Search. But they still have a huge market share in the web search world. I would guess by adding 10% to the number you see in the Google Search Console, should make the real value. Caddy logs</a></h3> I use go-access</a> to analyze the caddy logs. It works well in the terminal or browser, is really fast and supports a vast variety of log formats. I tried to setup a nice looking Grafana dashboard, but as it didn't worked as expected, I felt that the effort is not worth it. Don't forget about your games</a></h2> So having a personal blog will help you a lot to promote your games and to get visibility. But I have spent a lot of time creating this website and writing all the blog posts. Maybe too much, maybe not, who knows. Sure is, every minute I spend here, I don't work on my games. So my most important advice is: don't get too much distracted by other shiny things and build great games! 99Managers™ Futsal Edition FAQ Simon Dalvai — Sun, 23 Jun 2024 19:20:00 +0000 There is now a new and updated FAQ</a> on 99managers.org, the official website of the game. I will keep this blog post online, because why not? It can be funny to read this in some years, when the game took off or crashed miserably :-) Only time will tell... Wishlist now on Steam!</a> Play the beta on itch.io</a> What teams/players will be in the game?</a></h2> There will be no real teams and players in the game. Fantasy teams and players will be generated by a script and will have random names and attributes. The script works with a seed, to have always the same teams and players, if the same seed is used. You might remember this from Minecraft, where the same seed mechanism is used for random world generation. Having real teams and player names is a lot of work, legal headache and simply too much work for me alone. An in-game editor could be a future solution to this problem. With an in-game editor, you will be able to create your own players and possibly share the lists with others. Another even simpler solution could be to simply add a csv import/export functionality. This is on my to-do list, for the future. When will the game be available?</a></h2> The game will be released 2025 and the exact date has still to be defined. There is a beta version available on itch.io</a>. I started working on the game on 11th July 2020 and a lot happened since then. I migrated it from Godot 3.5 to 4, rewrote the Match engine several times and there is still much to do. I worked only in my free time on this game, while having a full time job. Since September 2024 I'm working full time on this game. I do my very best to finish the game as soon as possible. Where can the game be played?</a></h2> This will be my first Desktop game released on Steam. So it will be available for Linux, Windows and MacOS. For now no (official) mobile release is planned, since it is quite difficult to fit the content on small screens with touch support. But once the game is released on Desktop, a mobile release might follow. How much will the game cost?</a></h2> This might be my first game with a price, but I'm not sure how much. I guess it will be between 5€ and 10€ on Steam, depending how the game will look and feel at first release. The same game without modification will always be available for free on itch.io. Once the beta period is over, the game will also be available for free on other platforms like flathub.org. This game is Free and Open Source, under the AGPL v3.0 or later</a> license. That means that you are free to study, modify, improve and share the source code. So technically you will always be able to build your own version of the game at no cost. You just need the source code, the Godot Engine editor and some guide on how to build an executable, if you don't know already how to do that. There will be a guide available in the repositories README, as soon the game is stable enough. This sounds great, can I help somehow?</a></h2> Until the game is still in an unstable development phase, like now, I prefer to work alone on the game. But as soon the game is in a stable state, you can contribute your ideas and especially bug fixes. If you can't code, you still can help by translating the game to other languages. There is a dedicated page on weblate.org</a>, where everybody can add new languages and improve existing translations. And of course, you can also help me a lot by spreading the word about the game. Godot static types, a hidden gem Simon Dalvai — Wed, 29 May 2024 21:20:00 +0000 GDScript is a dynamic typed language, but you can add type hints, that make it a Static Typed language. This increases performance and helps to avoid bugs. So let's see how to use Static Types and get the most out of them. Hello Godot's typing system</a></h2> Variables can be defined in the following ways # dynamic var a = "hello" # automatic type guess var b := "hello" # static typing var c: String = "hello" </code></pre> It is highly recommended to use one typing system across your project. I suggest to always use static typing, even for small projects. This can help to prevent errors before even the game runs. With dynamic typing, you could have a bug in your code, and only see it while playing. Your game might run fine, until the specific code with the error gets executed. It is also a wise choice, to use Static Typing from the very beginning of the project. Making a project Static Typed afterwards, can be quite time consuming and frustrating. Trust me, I've been there already... Project settings to have stricter error checks</a></h2> First you have to enable Advanced settings in the Project Settings. Then under Debug -> GDScript you can change how the editor handles different warnings as errors and vice versa. Changing here some warnings to errors can be game changing and really important to bring real static typing advantages. Here the setup I'm currently using: In Editor Settings, you can also enable Add Type Hints under Text Editor -> Completition -> Add Type Hints, to get automated type hints by the editor. So for example, when you let Godot auto complete a function, the editor adds the type hints. Another good habit is to use class_name in your custom Nodes as much as possible. With static typing and class_name you can get auto complete for functions and variables. Tip: to add a Node from the Node tree directly into the script, simply click the node with the mouse, press Ctrl and drag it into the script. This works also with multiple selected Nodes. Code examples</a></h2> First, lets create a simple static class script. class_name StaticClass extends Node var alice: String </code></pre> Wrong type & Dynamic Static Type</a></h3> In another file, let's try to assign a wrong type to alice</code>, that is a actually a String extends Node2D func _ready() -> void: var static_class = StaticClass.new() static_class.alice = 10 </code></pre> We will get the following error message, after starting the Scene. Error: Invalid set index 'alice' (on base: 'Node (StaticClass)') with value of type 'int'. </code></pre> Wrong type & Static Type</a></h3> Let's try to assign a wrong type to alice</code>, but with Static Typing for static_class</code> extends Node2D func _ready() -> void: var static_class:StaticClass = StaticClass.new() static_class.alice = 10 </code></pre> We will see the following error message, before starting the Scene. Cannot assign a value of type "int" as "String". </code></pre> Nonexistent variable & Dynamic Type</a></h3> Now, let's try to access a nonexistent variable extends Node2D func _ready() -> void: var static_class = StaticClass.new() static_class.bob = 10 </code></pre> We will get the following error message, after starting the Scene as a error message in the editor. Error: Invalid set index 'bob' (on base: 'Node (StaticClass)') with value of type 'int'. </code></pre> So same error as before, but actually a different problem. Nonexistent variable & Static Type & Inferred Declaration</a></h3> If Inferred Declaration is enabled as error in project settings, you get an error directly in the editor, before starting the Scene. extends Node2D func _ready() -> void: var static_class: StaticClass = StaticClass.new() static_class.bob = 10 </code></pre> Note: You might need to restart the editor, to see the effects. Here the error message. The property "bob" is not present on the inferred type "StaticClass" (but may be present on a subtype). (Warning treated as error.) </code></pre> So using Static Typing and having some Debug Settings changed to error, we can see errors, before running the game. Further reading</a></h2> The best place to read in general about Godot are the official docs, since they will be up to date and explain everything. Here the official docs about Static Typing</a> I tried some performance benchmarks with static typed and dynamic typed code, but haven't found any significant difference. Probably I simply did the wrong operations, where this performance gain is not really visible. If you have some example, please let me know, so I can extend this article. Happy JS Naked Day 2024 Simon Dalvai — Tue, 23 Apr 2024 20:20:00 +0000 After I missed this year's CSS Naked Day</a> on 9th of April, I'm happy to participate to the JS Naked Day</a> on 24th of April. My website is not yet ready to work without CSS. All images miss static size tags and everything is messed up and is not usable without CSS right now. So hopefully next year, my website will be ready for CSS Naked Day. Why no JS is important?</a></h2> The web should work without JavaScript. This is the first statement on the JS Naked Day's website</a>. I totally agree with this. So many sites are overblown with JS scripts that could work also without it. I can understand that in some cases JS is useful and makes sense, but I feel that more times the opposite is true. My favorite "overblown JS moments" are, when I open a website and my laptop fan starts blowing out of nowhere. That always reminds me how important the right usage of JS is. You can find more interesting reasons to avoid JS on the JS Naked Day's website</a>. This will never have JS</a></h2> My main philosophy for this website is to have no JS at all, never, period. So I had no JS to be removed or similar for JS Naked Day, just write this blog post :-) I use zola</a>, a static site generator, similar to hugo</a>, but in my opinion still less bloated and kept simple. JS could be used, but I try to do everything without it, like here: CSS only dark mode without JS</a> Of course my website is really simple and has no sophisticated user interaction or similar, but shouldn't be most websites like this? How to publish Godot games on Flathub, in a nutshell Simon Dalvai — Tue, 26 Mar 2024 21:25:00 +0000 Flathub</a> is an Open Source and community driven App Store for any GNU/Linux system. Recently I published my two Godot games Ball2Box</a> and Pocket Broomball</a> on Flathub. Both use Godot Engine 3.5 base image, so this post will focus on version 3.5, but you can check for other Godot versions in the BaseApp</a>. Flathub submission</a></h2> You should always read the official submission docs of Flathub, to know the latest and correct steps</a>. In a nutshell, the process is the following Fork Flathub repo</li> Create files manifest</li> appdata.xml</li> desktop file</li> 256x256 icon</li> </ol> </li> Open pull request</li> </ol> Manifest file</a></h2> The main file of a Flatpak app is the manifest file, containing all information needed to build the app. app-id: org.simondalvai.ball2box runtime: org.freedesktop.Platform runtime-version: '23.08' sdk: org.freedesktop.Sdk base: org.godotengine.godot.BaseApp # Godot version base-version: '3.5-23.08' command: godot-runner finish-args: - --share=ipc - --socket=x11 # <-- Godot needs X11 - --socket=pulseaudio - --device=dri modules: - name: Ball2Box buildsystem: simple build-commands: # The game itself - install Ball2Box.pck /app/bin/godot-runner.pck # Metadata and a .desktop file - install -D org.simondalvai.ball2box.desktop /app/share/applications/org.simondalvai.ball2box.desktop - install -D org.simondalvai.ball2box.appdata.xml /app/share/metainfo/org.simondalvai.ball2box.metainfo.xml # Icons - install -D icon-256.png /app/share/icons/hicolor/256x256/apps/org.simondalvai.ball2box.png sources: # The game is pulled from GitHub - type: archive strip-components: 0 url: https://github.com/dulvui/ball2box/releases/download/v4.1.0/ball2box.tar.xz sha256: 971b4a47bda0aa3f0bc6e1766b61eb848d0e10156505fef1f66531ac375bd5d4 - type: file url: https://raw.githubusercontent.com/dulvui/ball2box/350a39a4eabc989145d22fbe0be0b4ae69033c71/flatpak/org.simondalvai.ball2box.desktop sha256: 6a6d1d14649730dc3c61ce8c62baed9d2b8f2c71c801b1a8420275361bdff2e1 - type: file url: https://raw.githubusercontent.com/dulvui/ball2box/350a39a4eabc989145d22fbe0be0b4ae69033c71/flatpak/org.simondalvai.ball2box.appdata.xml sha256: c4aa1c9d9f3091c0be44269f591589bf5fc181c172a06f6882981345331f9552 - type: file path: icon-256.png </code></pre> Here the links to the Github repositories, where you can find the manifests Ball2Box</a> Pocket Broomball</a> Appdata.xml</a></h2> The appdata file contains all other information of your app, like license, descriptions and screenshots. This file should be upstream and placed in the repository of your app, if possible. <?xml version="1.0" encoding="UTF-8"?> <component type="desktop-application"> <id>org.simondalvai.ball2box</id> <name>Ball2Box</name> <developer_name>Simon Dalvai</developer_name> <launchable type="desktop-id">org.simondalvai.ball2box.desktop</launchable> <project_license>AGPL-3.0-or-later</project_license> <metadata_license>CC0-1.0</metadata_license> <summary>Shoot the ball into the red box</summary> <url type="homepage">https://simondalvai.org/games/ball2box</url> <url type="bugtracker">https://github.com/dulvui/ball2box/issues</url> <url type="donation">https://simondalvai.org/donate</url> <url type="vcs-browser">https://github.com/dulvui/ball2box</url> <description> <p>Can you get all three stars on all levels? </p> <ul> <li>120+ levels and more coming soon...</li> <li>20+ different styled balls to collect</li> <li>Privacy friendly</li> <li>Offline game</li> <li>Created with Godot Engine 3</li> </ul> </description> <branding> <color type="primary" scheme_preference="light">#fdf6e3</color> <color type="primary" scheme_preference="dark">#002b36</color> </branding> <screenshots> <screenshot type="default"> <image> https://raw.githubusercontent.com/dulvui/ball2box/570f236ac3d220d40e313e99859424d324386738/metadata/en-US/images/phoneScreenshots/Android-1.png </image> </screenshot> <screenshot> <image> https://raw.githubusercontent.com/dulvui/ball2box/570f236ac3d220d40e313e99859424d324386738/metadata/en-US/images/phoneScreenshots/Android-2.png </image> </screenshot> <screenshot> <image> https://raw.githubusercontent.com/dulvui/ball2box/570f236ac3d220d40e313e99859424d324386738/metadata/en-US/images/phoneScreenshots/Android-3.png </image> </screenshot> <screenshot> <image> https://raw.githubusercontent.com/dulvui/ball2box/570f236ac3d220d40e313e99859424d324386738/metadata/en-US/images/phoneScreenshots/Android-4.png </image> </screenshot> </screenshots> <content_rating type="oars-1.1" /> <releases> <release version="4.1.0" date="2024-02-15"> <description> <ul> <li>levels functionality</li> <li>user interface refactoring</li> </ul> </description> <url>https://github.com/dulvui/ball2box/releases/tag/v4.1.0</url> </release> </releases> </component> </code></pre> Here the links to the appdata files Ball2Box</a> Pocket Broomball</a> Desktop file</a></h2> The desktop file finally defines how the app will appear in the OS, once installed. Also this file should be upstream and placed in the repository of your app, if possible. #!/usr/bin/env xdg-open [Desktop Entry] Name=Ball2Box GenericName=Ball2Box Comment=Shoot the ball into the red box! Exec=godot-runner Icon=org.simondalvai.ball2box Type=Application Categories=Game </code></pre> Here the links to the desktop files Ball2Box</a> Pocket Broomball</a> 256x256 px icon</a></h3> Finally, you'll need an icon for the app, that should also be upstream. It took me some time until I had the correct size of the icons with the right padding. So, make sure that the icon follows the quality guidelines</a>. Here the links to the icons Ball2Box</a> Pocket Broomball</a> Note: The Ball2Box icon is placed in the Flathub repo, since I was not told in my PR to move it upstream. But it is still recommended to have it upstream, like it is in Pocket Broomball. After submission</a></h2> Once your pull request gets closed and the app is available on Flathub, you can login</a> to Flathub and access some settings like app verification and the app listing quality. App verification</a></h3> To verify that you are the owner of the app, you can add a verification token to a .well-known/org.flathub.VerifiedApps.txt file accessible on your website. The domain must match the app-id used in the Manifest, like org.simondalvai.ball2box in my case. simondalvai.org/.well-known/org.flathub.VerifiedApps.txt</a> If you have multiple apps, you can simply add multiple verification tokens to the file. App Listing Quality</a></h3> Flathub gives you also access to the app listing quality check. To see that, you simply open the site of your game, while logged in. Flathub has several quality guidelines</a> you have to follow. If something is wrong, you can fix the issues and request a review. Soon you'll see if the problems have been resolved. Here an example of the app listing quality check for Pocket Broomball</a> Final verdict</a></h2> Once an app is published and you are familiar with the processes, it is really easy to publish another one. I also got quite some downloads (at least for me). Currently both have 250+ downloads combined. If I compare this numbers with App Stores like Google Play and Apple App Store, they are quite impressive! And of course: more app stores, more visibility. If you want to see more details of the pull requests itself, here the links Ball2Box</a> Pocket Broomball</a> Open sourcing your games as solo game developer - a game changer Simon Dalvai — Thu, 22 Feb 2024 21:22:00 +0000 In this post I would like to show what impact open sourcing my games had and why you should consider open sourcing your game too. I already presented at SFSCON 2023</a> what similar effect publishing my games on F-Droid</a> had on my games. More visibility</a></h2> Having games open sourced, gives you a lot of visibility on Github or your favorite git platform. Your repo might pop up on online searches or even Github's discovery section. This brings you quality users and potential contributors. Besides that, you can add your game to many awesome lists or websites that feature Open Source. Here, a list of the few games I've got listed in: f-droid.org</a></li> fossdroid.com</a></li> github.com/godotengine/awesome-godot</a></li> github.com/offa/android-foss</a></li> </ul> More visibility means more downloads, which bring to a higher ranking on game distribution platforms. Quality feedback</a></h2> Getting feedback from users is quite hard. Even harder is getting good feedback. In my experience, this is the most drastic change you'll see, when open sourcing your games. This will change drastically, when you open source your game. Because more technical people will see your games and they cannot only describe the bug or problem much better, but can also give suggestions on how to fix it. This helps a lot, especially as a solo game developer, where you might not have much time to test all parts of your game, each time you make changes. I also got a lot of feedback through e-mail, since I open sourced my games. Be different, be one of a few</a></h2> Given the scarcity of Open Source games, your game will be one of a few thousands instead of millions. It is true that Open Source has a small audience, but there are still a lot of people out there caring for Open Source. If you use donation platforms, this people will also be more open to support you, since they understand better your situation. Better portfolio</a></h2> Letting other people see your code could be intimidating. They might feel their code is not a good enough or feel afraid of critics. Don't worry, nobody will point fingers at you or comparing your code with the Linux Kernel code. But whenever you want to impress someone, showing your source code and your ability to use git, it might be really handy. So landing a new job or a project as freelancer, will be easier with an active [your favorite git platform] profile. This applies to any software related work, not only games. Licenses</a></h2> I won't get to deep into licenses, since it is a complex subject (and I'm not a lawyer). But here I want to share my experience and knowledge with you. It is important to know that code and assets should have different type of licenses. The most common software licenses are GPL</a> or MIT</a> and for assets the mostly used licenses are Creative Commons license as the CC0-1.0</a>, CC-BY-4.0</a> or CC-BY-4.0</a>. Here you can find some tools to find a license for your assets that fits your needs choosealicense.com</a></li> chooser-beta.creativecommons.org</a></li> </ul> Copyleft</a></h3> I chose the copyleft AGPL-v3-or-later</a> for my code and CC-BY-SA-4.0</a> for my assets. This are copyleft licenses, that means that you are free to study, use, modify, share and that all derivates keep the same license. The AGPL has a special clause about distributing code over network. So technically if a cloud gaming provider wants to distribute my games, he would have to share the code with the users. This would not be required with the GPL-v3-or-later</a> license. But as said before, I'm not a lawyer and this are my personal thoughts. Do your research or get a lawyers advice, if needed. Permissive</a></h3> Some might prefer permissive licenses as MIT</a> and CC-BY-4.0</a> This licenses give the user the same rights, but only require attribution and don't require sharing the modified code, when distributed. That means that someone might simply take your game, modify and release it, without having to share the modifications. Contributing to Open Source Ecosystem</a></h2> The Open Source world is already huge and well known. But this doesn't really apply to the gaming industry, where Open Source games are still quite rare. In my personal opinion, this would make the gaming scene a better world, where game developers can learn from each other and improve games. Or simply imagine being able to see the code of your favorite game, and being able to use, study, modify and share it! If you believe in Open Source Software, be the change the gaming industry needs: make your games Open Source! Can I still sell my games?</a></h2> After all this, some might have the question if they still can sell their game. And the answer is yes! Being open source doesn't restrict you from monetizing your games. There are many games and apps that are open source, available for free on F-Droid or other platforms but sold for money on Play Store, App Store or Steam. The best example that comes to my mind is Mindustry</a> sold on Steam for 9,99$ (~15k reviews) but open source and available for free on all other platforms. Create portals in Godot with _integrate_forces Simon Dalvai — Sun, 14 Jan 2024 17:48:00 +0000 My 3D Godot game Ball2Box</a> needs some variety, so I created some portals for new levels. This was not trivial to realize, as expected, and still needs some fine-tuning. But the proof of concept finally works now, and it revealed quite easy to realize, if using the correct Godot functions. Note: These are not portals like you might know from the game "Portal", where you can see through the portal to the other side. These portals simply teleport a moving body from one point to another. First attempts</a></h2> The goal of the game is to get the ball into the box with only one shot. If the attempt fails, the ball gets reset to its initial position. So technically, I already had a "teleport" of the ball from its final position to the initial position. Here, the old code of the "reset to initial position" function. It simply changes the mode of the RigidBody to static, so it can be moved by changing the translation Vector. Then it also resets all velocity and rotations, to make sure the ball remains still. extends RigidBody class_name Ball # ...omitted code func reset() -> void: mode = RigidBody.MODE_STATIC translation = initial_position linear_velocity = Vector3.ZERO angular_velocity = Vector3.ZERO rotation = Vector3.ZERO </code></pre> Of course I ignored the warnings about changing game physics outside the physic process, because well, it worked. _integrate_forces(), the forgotten solution</a></h2> Obviously, I thought this would work also for portals, where the ball gets teleported without resting the velocity and rotation. After a few attempts for making it work, I tried searching the web, and luckily found some hint on using _integrate_forces. Surely somehow it would have worked without it, after banging my head for some hours, but using this function was the correct way. The documentation of the _integrate_forces function writes Called during physics processing, allowing you to read and safely modify the simulation state for the object. </code></pre> Safely is here the keyword! It means that there will be no strange glitches or non expected movements Here the final working code, that not only teleports the ball from portal to portal, but also to its initial position. extends RigidBody class_name Ball var do_teleport:bool = false var do_reset:bool = false var do_static:bool = false var initial_position:Transform var next_transform:Transform func teleport(p_transform:Transform) -> void: next_transform = p_transform do_teleport = true func teleport_to_initial() -> void: do_reset = true func _integrate_forces(state:PhysicsDirectBodyState) -> void: # change the mode to static on the next iteration # otherwise ball doesn't move to new position if do_static: do_static = false mode = RigidBody.MODE_STATIC if do_teleport: state.transform = next_transform do_teleport = false if do_reset: state.transform = initial_position state.angular_velocity = Vector3.ZERO state.linear_velocity = Vector3.ZERO rotation = Vector3.ZERO do_reset = false do_static = true </code></pre> An important difference here, is that instead of moving the ball directly, a flag gets set. The actual movement happens then during the next _integrate_forces step. For completion, here the code where the teleport function gets called, with the transform variable of the corresponding portal. func _on_Portal1_ball_entered(ball:Ball) -> void: ball.teleport(portal2.transform) </code></pre> After some refactoring of Pocket Broomball</a>, I found out that I already used _integrate_forces there to move the ball. So, I was already sitting on the solution, but forgot about it, as usual. Find the full documentation of _integrate_forces here</a>. The full source code of Ball2box is available on Github</a> and Codeberg</a>. Create Apple Developer Certificate on Linux Simon Dalvai — Sun, 10 Dec 2023 00:00:00 +0000 To upload a app to the App Store, you need to create a Developer Certificate. The official Apple guide shows you how to do it easily with a Mac device in its official documentation</a>. But it can be done also without a Mac, using a Linux System, following this guide</a> of a Github user. How to do it</a></h2> Generate a private key and certificate signing request: Firs create a private key with openssl</li> </ol> openssl genrsa -out distribution.key 2048 </code></pre> Then you can create a Certificate Sign Request, shortly CSR, using the previously generated private key. Note: change "info@simondalvai.org" and "Simon Dalvai" with your values. openssl req -new -key distribution.key -out distribution.csr -subj '/emailAddress=info@simondalvai.org, CN=Simon Dalvai, C=IT' </code></pre> Upload the CSR to apple at: https://developer.apple.com/account/ios/certificate/create Choose Production -> App Store and Ad Hoc </li> Download the resulting distribution.cer, and convert it to .pem format: </li> </ol> openssl x509 -inform der -in distribution.cer -out distribution.pem </code></pre> Download Apple's Worldwide developer cert from Apple's certificates website</a> and convert it to pem: Note: Here Worldwide Developer Relations - G4 (expiring 12/10/2030) is used.</li> </ol> wget https://www.apple.com/certificateauthority/AppleWWDRCAG4.cer openssl x509 -in AppleWWDRCAG4.cer -inform DER -out AppleWWDRCAG4.pem -outform PEM </code></pre> Convert your cert plus Apple's cert to p12 format (choose a password for the .p12). Note: use -legacy if using opensssl v3.x . Found on StackOverflow</a></li> </ol> openssl pkcs12 -export -legacy -out distribution.p12 -inkey distribution.key -in distribution.pem -certfile AppleWWDRCAG4.pem </code></pre> Finally, update any Provisioning Profile with the new cert, and download them from dev portal. Now you can also sign any Provisioning Profiles with the new certificate and use them to release apps.</li> </ol> Use in CI/CD like Github Actions</a></h2> The Developer Certificate and Provisioning Profile can be imported in any CI/CD system, like Github Actions. But most CI/CD systems don't support binary files, so the conversion to base64 is needed. Create base64 of distribution.p12 Now you can prepare the Developer Certificate for the Github Action. Note: use -w 0</code> to prevent new lines in the resulting base64 string.</li> </ol> base64 distribution.p12 -w 0 > distribution.base64 </code></pre> Add distribution.base64 content to your CI/CD systems secrets </li> Recreate the file in its binary format </li> </ol> echo -n "$BUILD_CERTIFICATE_BASE64" | base64 --decode -o distribution.p12 </code></pre> The same steps work with any binary file, like the Provisioning Profile. [Talk] SFSCON 2023: F-Droid - The place for your FOSS Apps Simon Dalvai — Fri, 17 Nov 2023 00:00:00 +0000 Also this year I had a talk at SFSCON 2023</a> about F-Droid. Abstract</a></h2> On F-Droid you can find thousands of FOSS apps and games for Android. F-Droid brings you visibility in the FOSS community that will provide great feedback, open issues and eventually contribute to your FOSS project. This presentation is about my personal experience with my games Ball2Box, Pocket Broomball and Sn4ke published on F-Droid. I will show you what F-Droid is, how it works and the steps needed to submit your project. Youtube Video</a></h2> Here you can find the video of my talk on YouTube https://www.youtube.com/live/PoaUQyaQVJE?t=4986</a> Slides</a></h2> Here you can find the slides sfscon-2023-simon-dalvai-fdroid.pdf</a> Custom Resources in Godot Engine 4.x Simon Dalvai — Mon, 16 Oct 2023 00:00:00 +0000 Godot Resources in a nutshell</a></h2> Godot has a lot cool features built in that make game development a joyful ride. One of this awesome features are Custom Resources. Technically all the parts of Godot that save some data extend the Resource class. They are data containers that can contain all sort of data: translations, audio, textures and much more. This are all built-in Resources, but you can create also you own Custom Resources, that help you defining data structures and bring a lot of other features. I learned about Custom Resources quite late, since I was able to all my data related problems with Dictionaries and JSON files. But now I work on bigger projects, like Futsal Manager</a> where I need a lot of data. In such complex projects Custom Resources are a big game changer and make the development easier, with less errors and faster development. Custom Resources</a></h2> You can create your own Custom Resources simply by creating an empty Script file, giving it a class_name and extending it with the Resources class. Then you can define some variables, enums, constants and methods like in this example: class_name MyResource extends Resource signal such_signal enum SuchEnum { Hello, Custom, Resources } @export var name:String @export var id:int = 0 @export var values:Array[int] @export var enumValue:SuchEnum func get_sum() -> int: var sum:int = 0 for value in values: sum += value return sum func special_effect() -> void: if randi() % 10 == 1: such_signal.emit() </code></pre> Now you can create a variable of the type MyResource and you get the functions and variables name with the editors autocomplete. So you are sure that you always use the correct variable name. With Dictionaries instead, you have to remember the names of the keys. By using the @export annotation you can modify all your resources directly in the editor. Save and load</a></h2> Another cool feature is the built-in load and save to disk functionality. So you can replace all your JSON files with built-in Custom Resources. Note: Only variables with @export annotation get saved to disk. WARNING RESOURCES CAN EXECUTE MALICOUS CODE As long as this Github issue</a> is open, resources should not be considered as a safe way to save data. Here an example: # create variable var my_resource:MyResource = MyResource.new() # assign values my_resource.name = "Hello Resources" my_resource.values = [0, 3, 12] # save it ResourceSaver.save(my_resource, "res://my_resource.tres") # load it var my_resource_from_disk:MyResource = load("res://my_resource.tres") # prints "Hello Resources" print(my_resource_from_disk.name) # prints "15" print(my_resource_from_disk.sum()) </code></pre> Good to know is that during runtime you can write resources only into the user://</code> directory. Files from the res://</code> directory are read only. So if you want to save data the user modified or created, you need to save them into the user://</code> directory. Complex data structures</a></h2> With custom resources you can create all kind of data you can imagine. So you can use a created resource in another one. So for example if you create a football team, you can split the team and its players with its own resources. Here some code of my Futsal Manager game: # team.gd extends Resource class_name Team @export var name:String @export var line_up:LineUp @export var prestige:int @export var budget:int @export var salary_budget:int @export var players:Array[Player] # ...code goes on here </code></pre> # player.gd class_name Player extends Resource @export var id:int @export var price:int @export var name:String @export var surname:String @export var birth_date:Dictionary # ...code goes on here </code></pre> So with this two resources, I can define the players</code> variable in teams that is an Array of Players and can contain only variables of the type Player</code>. This makes the code type safe and gives you code autocompletion in the editor. Theres is no limit on how many Resources and Sub-resources you create. .tres vs .res</a></h2> Resources can be saved in two file formats .tres that are version-control-friendly and human readable. .res files instead are binary files and have better speed and compression. So depending on what data your store, you might prefer one or the other. It makes sense to save users data as .res files for performance and to save disk space. Further readings</a></h2> This was just my personal experience and knowledge about Godot's Custom Resources. They surely can do even more interesting stuff and there is a lot of other information about them on the web. Here you can read the official Godot documentation</a> on how to use Resources and what features they bring. And here you can find the official class reference</a>. Condor Simon Dalvai — Sat, 23 Sep 2023 00:00:00 +0000 App to organize the Italian Fantasy Football game "Fantacalcio" auction. More info and first release coming soon... Create non-game apps with Godot Engine Simon Dalvai — Mon, 18 Sep 2023 00:00:00 +0000 The main target of the Godot Engine are game developers. But Godot's easy workflow and functional UI elements, makes it also a good fit for non-game applications. There are already some out there you may know, like Pixelorama</a>, an Open Source 2D sprite editor. A Condor is born</a></h2> Recently I also started creating an application made with Godot Engine, named "Condor". It is a mobile and desktop app for managing the Italian Fantasy Football "Fantacalcio" auction. If you never heard of "Fantacalcio" or "Fantasy Football", it is a game where you compete with a group of friends, by buying real football players and earning points in each match day, depending on the real life performance of the football players. You can read more about it on Wikipedia</a>. The name "Condor" derives from the nickname "il condor" of Adriano Galliani</a>. He gained the name by his strategy of buying football players during the last hours of the transfer market, to get better conditions, because teams want to get rid of some players they where not able to sell yet. Since this application also brings a timer for the auction, it gets more intense and interesting until the last moments. So, some might buy a player during the last seconds of the auction and become a condor too. There are already some auction apps out there, but none of them (at least as I found) is Open Source and available for Linux, without ads and tracking. You can find the source code on Github</a> or Codeberg</a> as usual. First impressions</a></h2> For now I really enjoy creating apps with the Godot Engine, since it is really easy and fast to create complex UIs. It is perfect for fast prototyping and Godot's Scene/Node architecture with signals, makes it quite easy to understand. Since the whole Engine is Open Source, you can find a lot of code and sample project out there. I don't have much experience with other cross-platform development kits like Flutter</a>. If someone has experience with Flutter and Godot, please let me know, if Flutter or any other cross-platform development kit would be a better fit or not. WebSockets and Hetzner Cloud</a></h2> One goal of the application is also to make it possible to follow the auction remotely. So, all participants can see all the football players someone bought during the auction, the remaining budget, still available players and participate at the auction with the auction timer. To implement this features, I used a simple WebSocket client/server architecture and the cheapest Hetzner cloud server for around 4€ per month. I used Godot's official WebSocket chat demo project you can find on Github</a>. Running the server for 3 days costs me around 0,30€. Of course this setup is just for personal use and would (probably) not work for many players. Testing in real auction</a></h2> I used the application in one real life auction and it nearly worked perfectly. Except some synchronization issues with the remote players, since there is no resync implemented yet, if the connection fails. So, someone misses all the players that are sold, during the disconnection. Here you can see the admin view in action (I'm not a designer). On the left top, you can see all players list and the sell/buy history is visible in the left bottom corner. On the right from top to down: the active player with the auction controls and then the overview of all teams. Next steps</a></h2> Since WebSockets require a constant connection with a server or a host, WebRTC might be a better fit for this scenario. With WebRTC you still need a server, but only to match the peers together. Once they are connected, the communication is directly peer2peer. Then the UI needs of course a huge redesign and more appealing and modern graphical elements. Release date</a></h2> This year I will use the app only internally for my own Fantacalcio league, but I plan to release it to the public for the next season 2024/2025. So, the application will be released for mobile, desktop and web during summer 2024 (hopefully). Final verdict</a></h2> I really enjoyed creating this application, since I learned a lot, especially on how to create stable und working UIs in Godot. It was also my first online multiplayer experience with Godot. So, if you already know how to use the Godot Engine or want to learn it, even for non-game applications, give it a try. Thank you Debian and happy Birthday! Simon Dalvai — Thu, 17 Aug 2023 00:00:00 +0000 Happy 30th Birthday Debian! With this blog post I want to thank all Debian contributors, volunteers and people involved in the project. I've been using a Debian based Distro since the first day of my Linux journey around 2013. I started with Ubuntu, then Linux Mint, followed by Manjaro (the only not Debian, I've been using for some time) and again Linux Mint, always with XFCE. And of course, a lot of Distro hopping in between, but these are the ones, I've used for at least one month. KDE Plasma <3</a></h2> But this year, I discovered the KDE Plasma Desktop Environment. It feels like XFCE, with all the customizations I normally did manually, but already built-in out of the box. Like a good clipboard manager, that automatically ignores copied passwords from Passwords managers like KeepassXC.</li> The automatic remote host name in the title of KDE's terminal application Konsole. This is really handy, if you login to many remote servers and would like to remember which server you are logged in. So you can do rm -rf /*</code> in the right place ;-)</li> And the last killer feature for me was the built-in battery limit option, that limits the charge of your laptop (might work only with Thinkpads, but I'm not sure). So you can extend the life of your battery.</li> </ul> And last but not least, KDE Plasma looks really beautiful and has a lot of really great own software. Why Debian</a></h2> The reason why I chose Debian with KDE Plasma was, that it's the only Distro I can surely trust that it will exist for many more years and that no company will overtake the project and close it's source code or create some questionable subscription model. Yes, I'm looking at you, Red Hat. Then the latest movements in the Open Source world also just confirm, that it is better to trust a non-profit organization. Sorry, but not sorry, HashiCorp. All well known Debian based Distros, like KDE Neon or Kubuntu, have Canonical's Snap package system pre-installed. Debian is the only Distro, that I've found, that doesn't pre-implement Snap package system and only uses real Open Source Software. And here, myself enjoying the beautiful city of Bari, Italy, with my favorite T-Shirt :-) Happy birthday! Porting my libGDX games to Godot Simon Dalvai — Thu, 20 Jul 2023 00:00:00 +0000 After using libGDX, since 2020 I create my games only with Godot Engine. I find Godot easier and faster than libGDX. There is also to say that libGDX is just a Java Framework and Godot is a full Engine. I already wrote a blog post</a> about libGDX vs Godot comparing the main differences and my experience with both. Now I've decided that I will port my old games to Godot, since it might actually be the better way to keep my games up to date. My motivations</a></h2> Using libGDX every few months, to make a few changes or update some SDK or dependency is always a pain. Especially for libGDX iOS games, because robovm</a> is needed, to compile the Java code for iOS. I spend hours to fix the dependency issues and end up with a setup that somehow works, but I don't really understand how and why. That repeats every few months. Of course, if I would learn gradle better I might be able to be much faster. But I find it very hard learning things I barely use. And this will be the last time I face a dependency version mismatch, gradle build errors and hours of cryptic debugging. Another big motivator is that the Apple App Store removes all app that didn't get an update in the last 2 years ( or is it 3? I found different articles with different years). So anyway I would have to do an update at least every 2 years, even if nothing changes in the game. I still need to say that libGDX is really great. I enjoyed the time and learned a lot. If you use it often and don't target iOS, it's a great and powerful framework. But in my case, it's better to say good bye. Why Godot Engine?</a></h2> Godot is one of the most promising and growing Open Source Game Engine with a great community. As said before, Godot is quite easy to learn. It makes the maintenance of a game also much easier. The only time you really need to take a step back and learn new things, is when a new major version comes out. Not having to fight with gradle is also a big plus for me. And the good thing is, if you like gradle, you can still use it for Android with Godot's custom build feature. Finding help online is also much easier, since there is a big community and really nice docs. And it just works. Exporting a game for Android, iOS, html, Desktop etc simply works out of the box. No need for special tools or knowledge of other software than Godot. What games will be ported?</a></h2> I will port for first Sn4ke</a> to Godot. It is the game with most downloads and the game I spent most time to create it. It's also the only libGDX game I currently have on iOS. After that I will port WhatColor</a>. There I will also extend and improve the game with sound, more levels, tutorials etc... It will then also be published for iOS. Last and least, my very first game ColorShooter</a>. I still don't know if I will port this game, but maybe some nostalgia will motivate me to do so. Anyway, if you see updates on this game, it will surely be made with Godot. How to not install LineageOS 20 on Pixel 5 in 2023 Simon Dalvai — Sat, 08 Jul 2023 00:00:00 +0000 I just bought a refurbished Pixel 5 to upgrade from my Samsung Galaxy S5. The Samsung is still getting updates on LineageOS</a> 18.1 and working fine for simple tasks, but I felt that it was time to change phone. I looked for a while what phone I should buy, since I wanted a compact phone, so there were not many options. A must have is LineageOS 20 support, so I found this awesome page lineageosdevices.com</a> where you can compare devices that can run the latest version. So I found the Pixel 5, that is quite new (released 2020) and small (6 inches, but only 144.7 mm height). The install process was not as simple as I taught, since I made some mistakes. With this blog post I will share what I did wrong and how to fix eventual boot loops or other problems. Read the guide, really do it</a></h2> Read and follow carefully the official install guide https://wiki.lineageos.org/devices/redfin/install</a> It will prevent a lot of mistakes, if I would have read it more carefully I would have taken less time. If you really follow the guide it will take you around 20 minutes to install it. It took me around 3 hours. What went wrong - fastboot version</a></h2> Firstly I used an old fastboot version. Debian's fastboot version is a bit old, so you need to download fastboot from the official Android site https://developer.android.com/tools/releases/platform-tools#downloads</a> The LineageOS guide also mentions this, but since I didn't read the guide carefully, shit happened. What went wrong - TWRP</a></h2> Alongside LineageOS, I always install the TWRP custom recovery menu from https://twrp.me</a> For some reasons, when trying to temporarily boot TWRP on the Pixel 5, it always stayed stuck on the TWRP splash screen. The first time I used the old fastboot version, but also after using the new one adn re-flashing the stock rom, I always had the same problem. So I installed the Lineage recovery menu, but also with no success. My phone got stuck in several boot loops and I was not able to boot the stock rom. If you know how to fix this, please let me know. The rescue - flash the stock rom</a></h2> My phone was completely broken. It didn't boot the stock rom, recovery menu didn't boot either. Only the fastboot bootloader was still working. If you encounter boot loops or other problems like me, a good solution is to flash the stock rom again. You can flash it manually or you can use this amazing website, that will do all the work for you. https://flash.android.com/back-to-public</a> You need a Chrome browser to use it, so I installed Chromium and it worked fine. Final sprint</a></h2> After flashing the stock rom I followed exactly the LineageOS guide, with the latest fastboot version and no TWRP but Lineage recovery menu. Then finally after 3 hours and a lot of tears, LineageOS 20 booted correctly on my new Pixel 5. This took me just around 20 minutes, so as usual, the best advice is to really read the docs. Long story short</a></h2> Read the docs carefully</li> TWRP didn't work for me</li> Use latest fastboot version</li> Flash stock rom to start from scratch</li> </ul> Upload a Godot HTML5 game to itch.io with Github Actions Simon Dalvai — Wed, 07 Jun 2023 00:00:00 +0000 With the following two Github Actions you can export a Godot game to HTML and upload it to itch.io</a> godot-html-export</a></li> itchio-butler-upload</a></li> </ul> First you need to create a game on itch.io with all the needed information, then a first build can be uploaded with this Github Action. With this simple action you can automate the upload on every push. Of course the branch, game names etc. must be changed according to your needs. Read the comments in the following action code to understand whats happening. name: itch.io upload # define what triggers the action # in this case: on push if one of the files named in paths changes on: push: paths: - "version-android" - "version-ios" - ".github/workflows/upload-itchio.yml" # the directory where your game is # I always put the game inside a 'game' folder env: WORKING_DIRECTORY: game jobs: deploy: # only run action, if pushed on prod branch # change or remove according to your needs if: github.ref == 'refs/heads/prod' runs-on: ubuntu-20.04 steps: - name: Checkout source code uses: actions/checkout@v3 # change or remove according to your needs - name: Delete iOS icons run: rm -rf $WORKING_DIRECTORY/AppIcons # change or remove according to your needs - name: Create export directory run: mkdir html5 # exports the game in html mode # more info here https://github.com/dulvui/godot-html-export - name: Godot HTML5 export uses: dulvui/godot-html-export@v0.0.2 with: working-directory: $WORKING_DIRECTORY # uploads to itch.io # more info here https://github.com/dulvui/itchio-butler-upload - name: Upload to itch.io uses: dulvui/itchio-butler-upload@v0.0.1 with: working-directory: html5 api-key: ${{ secrets.ITCHIO_API_KEY }} user: simondalvai game: ball2box channel: html5 </code></pre> When the upload is finished, after a few seconds, you can already play the game in your browser. Here you can see the uploaded games in the Channel history. And here the final result: Ball2Box playable in you browser on itch.io You can find working examples in my games Pocket Broomball</a> and Ball2Box</a>. The single actions can also be used for other platforms or exports. For example the html export can be uploaded to your website or another HTML games portal. So can also the itch.io action be used to upload other games formats than HTML5 to itch.io like Android, iOS or Desktop. How to publish Godot 3 to F-Droid Simon Dalvai — Sat, 22 Apr 2023 00:00:00 +0000 F-Droid</a> is an awesome app that gives you access to thousands of Free and Open Source Software apps and games. It also respects your privacy, requires no login and lets you know if an app has anti-features like tracking, ads, proprietary assets or if it depends on the proprietary Google Play Services. If an app has ads or tracks you, it is marked as AntiFeatures</a>. I was able to publish Ball2Box</a> to F-Droid and here I will share the steps that are needed to do so. Here</a> you can find the published game. Requirements</a></h2> To publish a Godot Engine</a> game to F-Droid you'll need an Open Source game with the source code published on a public git repository. You also need a Gitlab account to create a merge request to the F-Droid Data repository</a> or you can make an Application Proposal where others include your app. In the documentation</a> you can read how the inclusion works. You also need a metadata directory</a> in your repo with some screenshots, a description and the changelogs of your game. F-Droid builds its apps itself and all its dependencies completely from the source. That means that you need also to build the Godot Engine from its source code. If you have other third party dependencies you have also to build them from the source code. My game doesn't have any other dependency than the Godot Engine, so if your game has some, you will have to extend the following build recipe with the steps to build your dependencies. All the steps needed are written in a yaml build recipe file. The best is to follow the official F-Droid Developer documentation</a> so you will follow always the latest and correct steps. The Godot build recipe</a></h2> Here the Godot build recipe. You can find the always up to date version on Gitlab</a> You'll also need a metadata directory and a exports_preset.cfg in the repo of you game. You can find mine on Github</a> in the fdroid and metadata directories. Categories: - Games License: AGPL-3.0-or-later AuthorName: Simon Dalvai AuthorEmail: info@simondalvai.org AuthorWebSite: https://simondalvai.org WebSite: https://simondalvai.org/games/ball2box/ SourceCode: https://github.com/dulvui/ball2box/ IssueTracker: https://github.com/dulvui/ball2box/issues Donate: https://simondalvai.org/donate Name: Ball2Box AutoName: Ball2Box RepoType: git Repo: https://github.com/dulvui/ball2box.git Builds: - versionName: 2.2.6 versionCode: 44 commit: a9ec9a5f025542c27196a0f5b3507a652e05e907 sudo: - apt-get update - apt-get install -y clang gettext pkg-config scons output: game/Ball2Box.apk srclibs: - Godot@6fed1ffa313c6760fa88b368ae580378daaef0f0 prebuild: - mv fdroid/export_presets.cfg game/export_presets.cfg - sed -i 's/FDROID = false/FDROID = true/g' game/src/globals/Global.gd build: - export HOME=$PWD - cp -R $$Godot$$ godot - keytool -genkey -v -keystore debug.keystore -storepass android -alias androiddebugkey -keypass android -dname "CN=Android Debug,O=Android,C=US" - mkdir -p ./.config/godot/ - export SDK_PATH="export/android/android_sdk_path = \"$$SDK$$\"" - export DEBUG_KEYSTORE_PATH="export/android/debug_keystore = \"$PWD/debug.keystore\"" - echo '[gd_resource type="EditorSettings" format=2]' >> ./.config/godot/editor_settings-3.tres - echo "[resource]" >> ./.config/godot/editor_settings-3.tres - echo $SDK_PATH >> ./.config/godot/editor_settings-3.tres - echo $DEBUG_KEYSTORE_PATH >> ./.config/godot/editor_settings-3.tres - echo 'export/android/debug_keystore_user = "androiddebugkey"' >> ./.config/godot/editor_settings-3.tres - echo 'export/android/debug_keystore_pass = "android"' >> ./.config/godot/editor_settings-3.tres - cd godot - scons -j `nproc` platform=server use_llvm=yes unix_global_settings_path=".." profile=fdroid/godot-build-options.py - export ANDROID_NDK_ROOT=$$NDK$$ - scons -j `nproc` use_llvm=yes p=android target=release unix_global_settings_path=".." android_arch=armv7 profile=fdroid/godot-build-options.py - scons -j `nproc` use_llvm=yes p=android target=release unix_global_settings_path=".." android_arch=arm64v8 profile=fdroid/godot-build-options.py - pushd platform/android/java/ - gradle generateGodotTemplates - popd - cd .. - mkdir -p ./.local/share/godot/templates/3.5.1.stable/ - echo "3.5.1.stable" >> ./.local/share/godot/templates/3.5.1.stable/version.txt - cp godot/bin/android_release.apk ./.local/share/godot/templates/3.5.1.stable/ - ./godot/bin/godot_server.* -v --path game --export Android Ball2Box.apk - find . -iname "*.apk" - echo "build end" ndk: r23c AutoUpdateMode: Version UpdateCheckMode: Tags UpdateCheckData: fdroid/export_presets.cfg|version/code=(\d+)|.|version/name="([\d.]+)" CurrentVersion: 2.2.6 CurrentVersionCode: 44 </code></pre> Donate Simon Dalvai — Sun, 26 Mar 2023 22:48:00 +0000 I hope to fund my development through the sales of my games on Steam</a>.</li> itch.io</a></li> other platforms will follow soon...</li> </ul> Don't forget to leave a honest review, that helps me a lot. You also can donate on Liberapay</a>, if you prefer that. Donations</a></h2> This are donations I got before deactivating most donation platforms. Anonymous donated 1€ on 21.10.2024 Baffo donated 10€ on 04.09.2024 "Great games, keep it up!" Anonymous is donating 5€ per year since 10.01.2024 Paul donated 4€ on 31.05.2023 "I just finished Ball2Box and I enjoyed it. Thanks for creating fun games that are free of ads and trackers. I will try the rest of the games :)" Anonymous donated 7.50€ on 16.05.2023 Anonymous donated 2€ on 05.04.2023 Anonymous donated 3€ on 12.02.2023 THANK YOU ALL!</a></h1> CSS only dark mode without JS Simon Dalvai — Sun, 19 Mar 2023 00:00:00 +0000 Last week I implemented dark mode on my website, without using any JS and only modern CSS media queries. It was pretty sure, that dark mode can only be implemented using JS, but a quick online search proved me wrong. Lets make it dark</a></h2> This css one liner can define how your site looks on a device with dark mode set in the browser settings. @media (prefers-color-scheme: dark) </code></pre> Or if your main style is dark mode, you can define how the light mode will look. @media (prefers-color-scheme: light) </code></pre> And with this little scss and media query you can set dynamically the background and font color of the whole body of your html. $background-color-light: #FDF6E3; $background-color-dark: #002b36; $font-color-light: $background-color-dark; $font-color-dark: $background-color-light; body { background-color: $background-color-light; color: $font-color-light; @media (prefers-color-scheme: dark) { background-color: $background-color-dark; color: $font-color-dark; } } </code></pre> Of course, you can't switch between dark mode and light mode with a button (or at least I don't know, how to do that) like you could do with JS. But anyway I can't remember the last time I used a button like that and websites should follow directly the system settings. How to test it</a></h2> To test it, you can simply switch the color theme of your browser in the settings and voilà: the site changes automatically colors. For this website I used the solarized</a> theme. It is my favorite theme and I use the solarized light theme everywhere I can. So here, the internet proved me again, that a simple website can have a lot of cool features, without using JS at all. Godot Engine vs libGDX Simon Dalvai — Sun, 26 Feb 2023 00:00:00 +0000 I create games since 2018 and here I want to share my experience with libGDX</a> and Godot</a>. Both are open source and completely free to use with no revenue share or license prices, like other game development environments have. In total, I currently released 3 games with libGDX and 2 with Godot for Android and iOS. I started in 2018 with libGDX because I knew how to code Java and liked the fact that everything is code and there's no GUI editor where I have to click checkboxes and hoping to remember which one did what. Then, around 2020 I tried to use Godot version 3 and I really loved how it worked. So, since then I develop games only with Godot but still maintain my libGDX games and I'm working on releasing them all on iOS. Note: This is my own experience that I want to share with you but of course some things might be subjective and biased by my opinions. So, the best advice I can give is to try all game development environments that you want and find the one that works for you. libGDX</a></h2> LibGDX is a simple but powerful Java library for cross-platform game development. You can create 2D and 3D games for Windows, macOS, Linux, Android, iOS and HTML5. You need to code everything in Java and there's no Editor like you get with Godot. So, you can use your favorite Java IDE like Eclipse, IntelliJ, Android Studio or whatever you prefer. This makes libGDX really powerful because it lets you control and define every aspect of your game. From loading the assets, to freeing the memory and positioning the button is done by you and by pure code. No automatic memory management or graphical editor to make this tasks easier. It is still active maintained but it hasn't a big developer community like Godot. Unity has probably the biggest mobile games development community. Since you can add every other Java or Android library of your choice, it supports a lot of third party plugins. Android</a></h3> Java and Kotlin are the official programming languages for Android and so, libGDX works really well on Android. The final App size is really small. My games are less than 3 MB big and the performance is really great. I haven't stress tested the performance, but it seems much faster than Godot, especially on older devices. You can build your games with gradle and also use automated CI/CD tools to automate everything. Here you can find my Github Action to export and upload your games to the Google Play Store https://github.com/dulvui/libgdx-ios-upload iOS</a></h3> LibGdx also works on iOS using the RoboVM</a> gradle plugin. It translates the Java code into iOS machine code and so it can work on iPhones. The performance is good but the app size increases drastically. The 3 MB now raise to around 50 MB or more, but it is the price to pay to have libGDX on iOS devices. I also created a Github Action to export and upload your games to the Apple App Store https://github.com/dulvui/libgdx-ios-upload Useful tools</a></h3> The most useful tool I found to create your UI elements is the libGDX Skin Composer https://libgdx.com/wiki/tools/skin-composer This tool gives you a easy way to create your custom buttons, fonts, labels etc. with a GUI editor. It seems that now this tool also has a Scene Composer, I haven't tried it yet. So you can even create your game's GUI with this tool without having to code. Godot</a></h2> Godot is a also cross-platform game engine that has only a single executable without any other dependencies. You simply need to download the around 30 MB big executable and run it on your Linux, Windows or macOS machine. Since the editor itself is created with Godot and Godot can be exported to Android, there is even a running editor for Android. It is still buggy and in early stage but it works! Godot is still young (initial release 2014) but it already has a big community and a lot of contributors. One downside of Godot (at the time of writing this, early 2023) is that some plugins, that you can easily find for other game engines, like Firebase or AdMob, have no official release and are solely created by the Godot community. So the plugin you use today, might not work tomorrow, until you fix it by yourself. I tried Google AdMob and Firebase on Godot, but then removed them, because I no longer wanted to contribute to privacy invading and with Ads loaded games. Thus, I removed all third party libraries and hope to make a few bucks only with donations</a>. Android</a></h3> Godot works well on Android and an empty game is about 8 MB big. My games are between 30 and 50 MB big, but most of the memory comes from the assets. And of course, I also created a Github Action for Godot to export and upload your game to the Google Play Store https://github.com/dulvui/godot-android-export iOS</a></h3> Godot also works well with iOS, but you'll need a macOS device to export, execute and upload the game to the App Store. Or you simply use my Github Actions that does the uploading automatically for you, with no physical Mac device needed https://github.com/dulvui/godot-ios-upload Final thoughts</a></h2> If you know Java well and you want to take completely control of your game, then libGDX is perfect for you. But if you like fast development, creating your UI by mouse dragging and clicking, you should go for Godot. Both are powerful tools to create games. I must say that starting with libGDX taught me the basics of game programming, from loading and freeing the used assets to using the game loop for drawing them. So, switching then to Godot allowed me to appreciate all the magical automated tasks that Godot does behind the scenes even more. As a result, I can focus more on the actual game than needing to code each button position manually. 99Managers Futsal Edition Simon Dalvai — Wed, 15 Feb 2023 13:48:00 +0000 99Managers™ Futsal Edition, is a Open Source Futsal Manager game. More info on 99managers.org</a> Godot - Automated screenshots Simon Dalvai — Sun, 22 Jan 2023 00:00:00 +0000 To publish a game to Apple App Store or Google Play Store, screenshots of the game are needed. For Android you need screenshots of mobile devices and tablets and for iOS you need a screenshot of each currently supported device. With a little coding this boring and repetitive task can be automated. Of course, it depends a lot on the type of game and its mechanics, if its even possible to automate this task. But if it's a simple game like Ball2Box</a> it will be easy. How does it work</a></h2> First, the resolutions of the devices are defined. The iPad screenshots can be reused as 7 inch and 10 inch tablet screenshots for Android. const resolutions = { "Android" :Vector2(1080,1920), "iPhone5.5" :Vector2(1242, 2208), "iPhone6.5" :Vector2(1284, 2778), "iPhone6.7": Vector2(1290, 2796), "iPad12.9" : Vector2(2048, 2732) } </code></pre> Then the paths of the scenes, that should be used for the screenshots, are defined. const scenes = [ "res://src/levels/Level1.tscn", "res://src/levels/Level10.tscn", "res://src/levels/Level11.tscn", "res://src/levels/Level13.tscn", "res://src/levels/Level24.tscn", "res://src/levels/Level70.tscn", "res://src/levels/Level99.tscn", "res://src/levels/Level105.tscn", ] </code></pre> The following function changes the scene to the ones we defined in the last step and hides the menu. func _change_scene(scene_path): if scene != null: remove_child(scene) scene.queue_free() var next_scene = load(scene_path) scene = next_scene.instance() add_child(scene) # hide menu scene.get_node("UI/Menu").hide() </code></pre> With the following OS function call, we can change the resolution of the screen while the game is executed. OS.set_window_size(resolutions.get(resolution)) </code></pre> Then we get the texture data of the whole screen with the get_texture() Viewport function call. Since the image would be upside down, we flip it first and then we can save it on the file system. var image = get_viewport().get_texture().get_data().get_rect(fullscreen) image.flip_y() image.save_png("../screenshots/" + resolution + "-" + str(scene_counter) + ".png") </code></pre> The whole code</a></h2> Here, the whole code that iterates over the resolutions and scenes and takes the screenshots. It can be executed with the "Play custom scene" button on the right top corner of the Godot editor. extends Spatial const resolutions = { "Android" :Vector2(1080,1920), "iPhone5.5" :Vector2(1242, 2208), "iPhone6.5" :Vector2(1284, 2778), "iPhone6.7": Vector2(1290, 2796), "iPad12.9" : Vector2(2048, 2732) } const scenes = [ "res://src/levels/Level1.tscn", "res://src/levels/Level10.tscn", "res://src/levels/Level11.tscn", "res://src/levels/Level13.tscn", "res://src/levels/Level24.tscn", "res://src/levels/Level70.tscn", "res://src/levels/Level99.tscn", "res://src/levels/Level105.tscn", ] var scene func _ready(): var scene_counter = 1 for scene in scenes: _change_scene(scene) for resolution in resolutions.keys(): OS.set_window_size(resolutions.get(resolution)) yield(get_tree().create_timer(2), "timeout") # calculate x/y offset for bigger screens like iPads to center the screenshot var x = (resolutions.get(resolution).x - get_viewport().get_texture().get_size().x) / 2 var y = (resolutions.get(resolution).y - get_viewport().get_texture().get_size().y) / 2 var fullscreen = Rect2(0 - x, 0 - y, resolutions.get(resolution).x, resolutions.get(resolution).y) var image = get_viewport().get_texture().get_data().get_rect(fullscreen) image.flip_y() image.save_png("../screenshots/" + resolution + "-" + str(scene_counter) + ".png") scene_counter += 1 get_tree().quit() func _change_scene(scene_path): if scene != null: remove_child(scene) scene.queue_free() var next_scene = load(scene_path) scene = next_scene.instance() add_child(scene) # hide menu scene.get_node("UI/Menu").hide() </code></pre> This script could be used to create a tool for the Godot Asset Store, so it could be simply installed from there, but for my use case this is enough for now. You can find this code and the whole game also on Github</a>. Automated Godot Android upload with Github Actions Simon Dalvai — Sun, 15 Jan 2023 00:00:00 +0000 In my last blog post</a> I explained how my Github Action, to automatically export and upload Godot iOS games to the Apple App Store, works. I created the same action for Android and the Google Play Store and in this post I will explain how it works. I'm using also this action already in my Godot games, like PocketBroomball</a> or Ball2Box</a>. You can find the repo of the action on Github</a>. How does this action work?</a></h2> The first step is setting up Java for the Github runner with the actions/setup-java@v3</code> action. This downloads everything needed and sets the environment variables like JAVA_HOME etc. - name: Set up JDK 1.8 uses: actions/setup-java@v3 with: distribution: 'temurin' java-version: 11 </code></pre> The Android SDK and its tools are another must have and for that we run the android-actions/setup-android@v2</code> action. - name: Setup Android SDK uses: android-actions/setup-android@v2 </code></pre> Then a cache is created using the actions/cache@v3</code> action. This cache saves the Godot Engine executable, configurations and export templates in a persistent memory, in order to save time and Github's bandwidth. A new cache is created if the godot-version</code> of the inputs changes. - name: Cache Godot files id: cache-godot uses: actions/cache@v3 with: path: | ~/.local/share/godot/** /usr/local/bin/godot ~/.config/godot/** key: ${{ runner.os }}-godot-${{ inputs.godot-version }} </code></pre> Now the headless Godot executables get downloaded but only if the cache, created the step before, doesn't get a hit. The needed export templates get downloaded and extracted too. - name: Download and config Godot Engine headless linux server and templates if: steps.cache-godot.outputs.cache-hit != 'true' shell: bash run: | wget -q https://downloads.tuxfamily.org/godotengine/${{ inputs.godot-version }}/Godot_v${{ inputs.godot-version }}-stable_linux_headless.64.zip wget -q https://downloads.tuxfamily.org/godotengine/${{ inputs.godot-version }}/Godot_v${{ inputs.godot-version }}-stable_export_templates.tpz mkdir ~/.cache mkdir -p ~/.config/godot mkdir -p ~/.local/share/godot/templates/${{ inputs.godot-version }}.stable unzip Godot_v${{ inputs.godot-version }}-stable_linux_headless.64.zip mv Godot_v${{ inputs.godot-version }}-stable_linux_headless.64 /usr/local/bin/godot unzip Godot_v${{ inputs.godot-version }}-stable_export_templates.tpz mv templates/* ~/.local/share/godot/templates/${{ inputs.godot-version }}.stable rm -f Godot_v${{ inputs.godot-version }}-stable_linux_headless.64.zip Godot_v${{ inputs.godot-version }}-stable_export_templates.tpz godot -e -q </code></pre> Now the path for the Android SDK can be defined in the Godot Editor settings, so that the engine knows, where to find the SDK and build tools. - name: Set Android SDK path in Godot Editor settings if: steps.cache-godot.outputs.cache-hit != 'true' shell: bash env: SETTINGS: | export/android/android_sdk_path = "/usr/local/lib/android/sdk" export/android/shutdown_adb_on_exit = true export/android/force_system_user = false run: echo $SETTINGS >> ~/.config/godot/editor_settings-3.tres </code></pre> The setup of Java, Android and Godot is now complete and we can actually export the game with this simple one liner. Godot is quite cool, isn't it? - name: Export shell: bash run: godot --path ${{ inputs.working-directory }} --export Android </code></pre> And now we can run the final step by uploading the exported game to the Google Play Store using the uses: r0adkll/upload-google-play@v1</code> action. - name: Publish to Play Store uses: r0adkll/upload-google-play@v1 with: serviceAccountJson: ${{ inputs.service-account-json }} packageName: ${{ inputs.package-name }} releaseFiles: ${{ inputs.release-file }} track: ${{ inputs.release-track }} status: completed </code></pre> The Android action is quite simpler than the iOS action and also easier to maintain because you don't have to care about yearly expiring Developer Certificates and Provisioning Profiles. Probably it is because I'm simply too unexperienced with iOS development and thus it is a pain every time I need to renew everything. But automating, at least the export and upload, is a big help, especially as a solo developer. It saves me a lot of time and brings much more joy when you can upload everything with a simple git push</code>. You can find the complete action and instructions on Github</a>. If you have problems or need help with the action, simply open an issue in the repository. Automated Godot 3.x iOS upload with Github Actions Simon Dalvai — Thu, 29 Dec 2022 00:00:00 +0000 Github Actions allow you to automate repetitive tasks, like exporting your game for iOS and uploading it to the App Store. It also brings the advantage that you don't need a Mac at all. So it saves you time and money, if you're not a Mac user. I'm using the action already in my Godot games like Pocket Broomball</a> or Ball2Box</a>. Note: The action steps and versions change over time. Find the latest version of the action Github</a>. Github Actions pricing</a></h2> Github Actions are always free only for Open Source repositories. On private you get 2000 to 3000 run minutes per month, depending on the type of your account. Additionally, MacOS actions consume 10x times the minutes of a Linux machine, so you actually get 200 to 300 minutes per month. Here the detailed documentation about pricing https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions How does the action work?</a></h2> The action uses only macOS built-in command line tools like xcodebuild</code> and xcrun</code> and has no third party dependencies. So you can be sure that it always works with the tools Apple itself provides. First, a check is made to see if the action actually runs on a macOS runner, because it wouldn't work on a Linux or Windows runner. - name: Check is running on mac-os if: runner.os != 'macos' shell: bash run: exit 1 </code></pre> Then a cache is created using the actions/cache@v3</code> action. This cache saves the Godot Engine executable, configurations and export templates in a persistent memory, in order to save time and Github's bandwidth. A new cache is created if the godot-version</code> of the inputs changes. - name: Cache Godot files id: cache-godot uses: actions/cache@v3 with: path: | ~/.local/share/godot/** godot ~/.config/godot/** key: ${{ runner.os }}-godot-${{ inputs.godot-version }} </code></pre> The action uses a headless macOS build that you can find on Github</a>. This build allows the action to run Godot without UI and exporting the game for iOS. So, here the headless build together with the export templates is downloaded, but if there is a cache hit, the files from the cache you created before are used. - name: Download and config Godot Engine headless linux server and templates if: steps.cache-godot.outputs.cache-hit != 'true' shell: bash run: | wget -q https://github.com/huskeee/godot-headless-mac/releases/download/${{ inputs.godot-version }}-stable/Godot_v${{ inputs.godot-version }}-stable_mac_headless.64.zip wget -q https://downloads.tuxfamily.org/godotengine/${{ inputs.godot-version }}/Godot_v${{ inputs.godot-version }}-stable_export_templates.tpz unzip Godot_v${{ inputs.godot-version }}-stable_export_templates.tpz unzip Godot_v${{ inputs.godot-version }}-stable_mac_headless.64.zip mkdir -p ~/.config/godot mkdir -p ~/.local/share/godot/templates/${{ inputs.godot-version }}.stable mv templates/* ~/.local/share/godot/templates/${{ inputs.godot-version }}.stable mv bin/godot . ./godot -e -q rm -f Godot_v${{ inputs.godot-version }}-stable_linux_headless.64.zip Godot_v${{ inputs.godot-version }}-stable_export_templates.tpz </code></pre> Now the game gets exported for iOS with this simple one liner. The exported files will be located in $PWD/build/</code>. - name: Godot iOS export shell: bash run: ./godot --path ${{ inputs.working-directory }} --export iOS </code></pre> For the signing of the iOS export we need the UUID of the provisioning profile. With this command, the UUID gets extracted and saved as PP_UUID in the Github Actions environment. - name: Extract Provisioning profile UUID and create PP_UUID env variable shell: bash run: echo "PP_UUID=$(grep -a -A 1 'UUID' ${{ inputs.provision-profile-path }} | grep string | sed -e "s|<string>||" -e "s|</string>||" | tr -d '\t')" >> $GITHUB_ENV </code></pre> To make sure the runner uses the correct XCode version, you force it to use a version that works well with the Godot Engine. - name: Force XCode 13.4 shell: bash run: sudo xcode-select -switch /Applications/Xcode_13.4.app </code></pre> Now you use the xcodebuild</code> to make the iOS export ready for the upload. If external dependencies are used with the following command, the action makes sure that they are configured correctly. - name: Resolve package dependencies shell: bash run: xcodebuild -resolvePackageDependencies </code></pre> An archive of the export is needed before we can create the .ipa file that can be uploaded. In this step, also the signing with the Developer Certificate and Provisioning Profile takes place. - name: Build the xarchive shell: bash run: | set -eo pipefail xcodebuild clean archive \ -scheme ${{ inputs.project-name }} \ -configuration "Release" \ -sdk iphoneos \ -archivePath "$PWD/build/${{ inputs.project-name }}.xcarchive" \ -destination "generic/platform=iOS,name=Any iOS Device" \ OTHER_CODE_SIGN_FLAGS="--keychain $RUNNER_TEMP/app-signing.keychain-db" \ CODE_SIGN_STYLE=Manual \ PROVISIONING_PROFILE=$PP_UUID \ CODE_SIGN_IDENTITY="Apple Distribution" </code></pre> Then you can export the archive of the latest step to a single .ipa file that is ready for the upload. - name: Export .ipa shell: bash run: | set -eo pipefail xcodebuild -archivePath "$PWD/build/${{ inputs.project-name }}.xcarchive" \ -exportOptionsPlist exportOptions.plist \ -exportPath $PWD/build \ -allowProvisioningUpdates \ -exportArchive </code></pre> The final step uploads the .ipa file to the App Store using the xcrun</code> tool. An Apple user account with upload permission is needed and I recommend using a separate service account instead of the admin account. - name: Publish the App on TestFlight shell: bash if: success() env: APPLEID_USERNAME: ${{ inputs.apple-id-username }} APPLEID_PASSWORD: ${{ inputs.apple-id-password }} run: | xcrun altool \ --upload-app \ -t ios \ -f $PWD/build/*.ipa \ -u "${{ inputs.apple-id-username }}" \ -p "${{ inputs.apple-id-password }}" \ --verbose </code></pre> You can find the complete action on Github</a>. If you have problems or need help with the action, simply open an issue in the repository. Read here</a> on how to create a Apple Developer Certificate on Linux without a Mac. Ball2Box Simon Dalvai — Thu, 29 Sep 2022 00:00:00 +0000 Swipe to shoot the ball into the box in over 100 levels with only one finger. Can you get all three stars on all levels? 🕹️ 100+ levels and more coming soon... 🌈 20+ different styled balls to collect 📡 Offline game 📺 No ads 💸 No In-App purchases 🕵️‍♀️ No user tracking 🛑 No permissions 👨‍💻 Created with Godot Engine 3 Pocket Broomball Simon Dalvai — Wed, 29 Sep 2021 00:00:00 +0000 The coolest winter sport has finally come to your phone! Win the Championship and unlock all the 100+ real world teams of the following leagues: North American Broomball League</li> Maritime Broomball Association</li> Penrith Broombal competition</li> Ontario League</li> Italian Broomball League</li> Swiss Broomball Association A + B</li> International Women League</li> International League</li> </ul> If you want to add your team to the game, send me a mail at info@simondalvai.org</a> 🧹 100+ real-world teams 🌈 20+ different styled balls to collect 📡 Offline game 📺 No ads 💸 No In-App purchases 🕵️‍♀️ No user tracking 🛑 No permissions 👨‍💻 Created with Godot Engine 3 Sn4ke Simon Dalvai — Tue, 29 Sep 2020 00:00:00 +0000 Play the old school classic Snake with pixel retro look, modern swipe controls and 60 unique Levels! What will be your high score? 🕹️ 60 levels 🌈 4 different color themes 💾 Only 3MB on Android 📡 Offline game 📺 No ads 💸 No In-App purchases 🕵️‍♀️ No user tracking 🛑 No permissions 👨‍💻 Created with libGDX WhatColor Simon Dalvai — Tue, 29 Oct 2019 00:00:00 +0000 Remember the pattern you'll see, because one color will disappear! Click the missing color on the buttons under the pattern. This game is pure memory training for your brain 🧠 Train your eye-hand coordination by searching for the missing color! But be fast, because the time is running out ⌛ Every correct color gives you 2 more seconds for the next one. It might seem easy at the beginning, but it's hard to stay focused and concentrated! So improve your concentration by playing this memory training game! Play every day and see how your memory and focus gets faster and better! 🌈 60 patterns 💾 Only 3MB 📡 Offline game 📺 No ads 💸 No In-App purchases 🕵️‍♀️ No user tracking 🛑 No permissions 👨‍💻 Created with libGDX Color Shooter Simon Dalvai — Sun, 29 Sep 2019 00:00:00 +0000 My first developed game, so don't expect much. Shoot green, yellow, red and blue by tapping the screen and let white reach the centre. For every white that reaches the centre, you get one point. The higher your score, the faster the speed!

Simon Dalvai

My split keyboard journey

I Love Free Software Day 2026

Steam Auto-Cloud cross-platform save game synchronization

3 years of blogging

[Talk] SFSCON 2025: Making a sport management game in Godot

Center buffers in Neovim

One year as full-time solo game dev

Godot code style, project structure and friends

My new workstation - HP Pro Tower 400 G9

Why not make a custom build</a></h2> I really like the idea of building my own PC someday. I'm also not a big fan of HP, Dell or similar brands. But this time I decided to get this pre-built device for three main reasons</p> It was cheap</li> It works out of the box (at least I hoped)</li>

Unexpected orphan Nodes in Godot

Find more errors in Godot, with a script

[Talk] Making FOSS games for fun and (hopefully) profit

Duplicate Godot custom resources deeply, for real

I Love Free Software Day 2025

Neovim as External Editor for Godot

Having fun with Godot Movie Maker - Part 1

Debian Sway v1 - My first setup