Table of contents

I have published a new version of Bim!.

Bim! is free software (AGPL3 code and CC-by-sa 4.0 assets) inspired from Bomberman and that can be played exclusively online. It is available on Android (direct link to the APK).

The timing is great, with the end of year celebrations we will get back to familly and friends, the best conditions to play the game. Put aside the discomfort of installing an out-of-store APK on the device of each player, once it’s installed the fun is here.

Novelties

The first visible novelty is the new icon.

Not bad huh? It’s French. I’m not sure it will survive on the long run but for the moment I think it’s great.

Novelties on the client side

There’s now a settings dialog accessible via a button on the main screen.

In addition to the usual settings for sound effects, music, and vibrations, the user can also choose the placement of the buttons in game. The initial intent was to have left-handed and right-handed modes but no one will check which hand is your dominant one. Just pick the most convenient layout for you.

There’s also an option to select the kind of controller for the player’s movements: it can be either a directional pad, at a fixed position on the screen, or a software analog stick that follows the touch, as it is done in many mobile games nowadays.

The game launch has changed too. In previous versions the player’s avatar may change from one game to the next, causing some chaos in the beginning of the games. Now the avatar stay the same as long as the players are the same. Moreover, an animation emphasizes the local player’s avatar when the game starts. This animation is also an opportunity to hide the synchronization with the server on game launch. There should be far fewer differences at launch time caused by the performance gap between the users’ devices.

I have considered an implementation suggested in the comments of the previous announcement by LinuxFr.org’s user zurvan. It was about always displaying the red avatar for the local player, which had the merit of solving the problem of the random avatar changes between games. Unfortunately I’ve observed meanwhile that players playing in the same room tend to ask each other about the avatar colors (“who’s the green one who’s going to burn?”). But if everybody see themselves with the same color, it becomes difficult to answer this question.

Finally, last improvement on the client, bomb drops in the game are more responsive since they happen on button pressure rather than release.

Novelties on the server

From now on, the server will record all played games. This will help me into easier debugging when I see a problem in the heat of action.

A new application named bim-player can convert surch records into a text-based display, very convenient to unroll the game step by step:

The server finally handle player deconnection. If a player disappears it is removed from the game and the match continues as if nothing happened.

CI, tests, and bug fixes

Not many news here. I have added a CI step to launch all unit tests with Valgrind, and I have also updated the version of Ubuntu used for base images in the tests. I have also fixed some undefined behavior, nothing crazy.

Some dev stories

Network games are clearly at another level of difficulty in terms of programming. Multi-thread software is already far from simple, but at least we can synchronize threads with some primitives. Here there’s no synchronization at all. All tasks are actually updating simultaneously and publish their progress to an authority (the server) which is the only owner of the truth. In those conditions one cannot even think about putting a breakpoint somewhere; we must come back to the one true debugger: printf.

This is by the way what caused the creation of bim-player. At some point we need to be able to play the games slowly in order to understand what is going on. And it helped on the first try! As soon as I have been able to play a game with bim-player I found a bug. A really dumb bug…

As you may have observed the game runs on a grid. Obstacles, bombs, walls, everything is located in a cell. It’s the same thing for the player: even though it moves progressively from one cell to the next and may look straddling two cells, on a logical standpoint it is actually on a single cell. So a long time ago I thought it would be a great idea to consider that the player is on the neighboring cell when it is near the edge of the current cell. I thought it would avoid situations where the player would be burned by flames even though it appeared outside.

Proud of my great idea I have implemented it. If the coordinate of the player on the x-axis in the current cell is lower than 0.25 we consider it to be in the cell on the left. The same goes on the other side, if the coordinate on the x-axis in the current cell is higher than 0.75 we consider it to be in the cell on the right. Similarly on the y-axis. And that’s it, I’ve implemented that and forgot about it.

Until I run a game with bim-player, where I saw players oscillating from left to right when walking from one cell to the next. Yeah champion, when the player is at x+0.75 or more we consider it to be at x+1, then when it enters the cell on the right it begins at (x+1)+0, thus an x-coordinate lower than 0.25, thus we consider it to be at x. This is nonsense.

Anyway, I’ve removed the code of this great idea.

In my opinion bim-player is a nice example of project management and priorities. At the beginning all I had was a debug function to display the state of the game in the terminal. Then when I had game records the possibilities exploded:

Hey, it would be cool to have a UI to navigate in the game with the ability to get back in time. Oh I could also add commands like for going to a given frame, or to a given event. I could use libreadline for that, it would be a great opportunity to learn it. Or maybe I could write in in Rust to learn the language? Oh, also it would be great to hav a GUI too. I could even add an in-game menu to allow players to watch their own games, or the games from other players!

Hell, in five seconds I had more work for the player than for the game itself. We must prune this, and this is where project management and priorities come into play, in the shape of two easy questions: (1) what do I need? and (2) what is the minimal product that answers this need? The answers are (1) “I want to be able to play a game step by step”, and (2) “a text dump is good enough”. Indeed, as soon as I have the whole game in a text file I can unroll it, jump to a previous step, or even search for a frame number to jump to this specific moment. It answers all my needs and more for minimal work. Perfect!

Availability on F-Droid and the PlayStore

As soon as I’ll have non-draft assets for the games and implemented some tweaks in the gameplay I’ll work on the publication on the PlayStore.

I’d love to publish the game on F-Droid too but it seems a bit complicated. I had a quick look on the basics and I’m a bit worry about the possibility of doing the build with my hand-made script. I have also seen that everything is done on GitLab and, unlucky me, I’m unable to create an account there. The refuse my GMX e-mail address and ask for a professional e-mail :( It’s crap, I have no professional address for this game nor to publish on F-Droid.

It’s even more crappy that I had a GitLab account before, created with my former professional e-mail. And since I have switched companies and left the password in the KeePass of my professional laptop, I have no access anymore. I have written to GitLab in an attempt to get my account back but they did not answer. Thus, I’m a bit stuck. If you have any contact there who could restore my account (login j-jorge), it would be awesome. This account was used for a single bug report for GitLab itself, consequently there really no content here, and certainly not anything professional.