Table of contents

I have just released anothe APK for Bim!, the second since the last post. Inbetween, I have mainly worked on the UI in the menus, plus some fixes and tweaks here and there.

Bim! is an arcade game in the last-man-standing genre, inspired from Bomberman, even though it should drift from it on the long term. It is an online-only game, with two to four players. There is no AI here, the games are always played by humans.

Menus

The game uses the Axmol engine, which is convenient to display things but offers only few facilities to manage game screens. There are some, but remembering Cocos2d-x, of which Axmol is a fork, it was not great. Consequently I hack something above Axmol to do my UI.

First of all, the black screen when entering the game is gone. We have now some colors and animations:

It’s clearly more pleasant. We can’t see it on the capture but the backgrounds of the screen and of the button are animated. It only lacks a logo. From there we can start a game and see the matchmaking screen:

When all players have confirmed this screen we switch the the game itself:

Well, no work has been done here, thus it stays ugly. But we can still have fun!

When the fight is over we end up on the end-game screen from which we can start another game or go back to the main screen.

And that’s it. It works, not so ugly! And if the player is unlucky they can see the awesome UI of the pop-ups:

Three months of work for this… Well, it’s okay, there’s also some work on the internals too. I’ll talk about them in the next section :)

We can’t see it on the captures but the reader should know that all those screens require some rigorous management in the transitions. There is also a lot of work done in order to have the UI adapting to the resolution of the screen (e.g. reducing the font’s size on screens smaller than the reference one).

Here is a small example of the need to do something in addition to Axmol’s features, plus some subtelties, in order to adapt to the user’s device.

Axmol’s behavior is to place display nodes in a fixed-size canvas then to resize the result to match the device’s resolution. For example, if I design in a 768x1280 canvas and if the device has a resolution of 1536x2560, then everything will be stretched with a factor two on both dimensions. In particular, texts will be blurry. It is thus better to have a system that increases the font sizes globally to have a clear result.

Another subtlety, I use 9-slices for the buttons, which is quite classical:

Illustration of the difference between the resizing of a square, on the left, toward a rectangle, on the right, using normal resizing, on top, and 9-slices, at the bottom. — Alwik, Wikipedia.

According to this principle the corners of the components are always rendered at scale 1 while the inner zones are stretched to fill the space. If I simply used Axmol’s 9-slices then my 50x50 pixels corners on my 768x1280 screen would still be displayed on 50x50 pixels on the the 1536x2560 device. It would look two times to small! In order to compensate this the scale of the 9-slices has to be adapted according to the device’s resolution.

With all these changes the game displays correctly on both a Nexus 4 and a Pixel 3.

Internals and Gameplay Novelties

I had previously attempted to compensate the network latency by adding a small delay between the moment when the user presses the button and the moment when the action is actually applied. It helped to avoid some situations where one could see a player doing an action only for it to be cancelled because it was mispredicted. Unfortunately this would also led to unpleasant games because we would, for example, drop bombs a few cycles later, thus not where we were when we pressed the button. This was frustrating. Now the bombs will always be dropped right where the player was when the button was pressed.

Moreover, the bombs are displayed as soon as the button is pressed, even though they will be actually inserted in the game some cycles later in the gameplay loop. This decreases greatly the discomfort of the lag.

Still on the network synchronization topic, I have increased the frequency at which the game actions are sent, reducing by the way the delay between the local simulation and the server. Plus, if a player progresses too fast (the game is too many cycles after the server’s state), then its simulation will be slightly slowed down on its side in an attempt to reduce the gap with the server.

A list of game servers is now fetched from the web server at launch time on the client. The application will then connect to the first available server matching its own protocol version. This should allow for smoother upgrades by letting the old servers running until all players have upgraded.

I have reworked the matchmaking on the server. There is a mode allowing the players to match in a named room, in order to play only whith those who know the room. This is not available in the client yet but the server supports it, and tests exist to validate the feature. In the previous versions this mode and the general matchmaking shared the same set of games. It was quite inconvenient in scenarios where the players launched many games in a row. Now each service has its own game list and it is easier for the server to tell if a player is still in a game.

On the topic of the games on the server, now it runs the simulation too. In the previous versions it was only forwarding actions from one player to the others. From now on it will know the state of the game and can thus tell if the game is over. This is also the server who will tell the clients if the game is over, and who won.

The communication between the server and the clients being done in UDP, the information about the game comes in a really messed way. Communication is fast, but disorganized, consequently it is quite easy to receive a message of a client looking for an opponent followed by an action of the same client in a game! All it needs is a user going quickly from the game to the matchmaking screen. If a message of the game goes the long route on the Internet then it will be overtaken by the matchmaking request. This was a bit of a pain to handle that on the server. But now that the server knows if there is an ongoing game it can ignore the messages unrelated to the game and, the other way around, it can ignore game messages when the game is over.

Matchmaking is a really huge topic, it would deserve its own post.

Aside from all this, there were many “small” things like some tweaks to code directly on my phone, some updates of the build dependencies and of CI tools, many additional tests, and the addition of a readme file!

Helping hand

I’ll spare you the usual “I’m looking for contributors”, because I actually would not have the time to handle contributions :) On the other hand I would appreciate your opinion on one thing.

In the beginning of the project I had a text-based client, to validate the first steps in the development (gameplay, client-server communication). I have then dropped it because is was quite difficult to maintain but now I am thinking that it would be convenient to have such a client, in addition to being very cool. For example, if I had a text-based client, I could use it to run bots in tests. Unfortunately I block on one thing.

The problem being that the player moves in the game progressively from one cell to the next. Even if its logical position in the engine is always in a single cell, there is a visual progression. This progression, I do not see how to render it in a text interface. I have the feeling that it would be very frustrating to see the player “stuck” in a cell during 8 cycles before popping in the neighbor cell.

I know I do not need a display for bots but if we are building a graphicless client, we may as way build a cool one (moreover display is also very convenient for debugging).

Since you are contemporary of the era of games using text-based UI, would you have some advice to display this progression from one cell to the next? If you know games doing that, I am interested.

Let’s play

The server has been running on easy mode so far, like no more than three simultaneous clients outside of tests. What would you think to meet at 1 p.m. (metropolitan France) every day of the current week? A short game while waiting for the dessert, then you’ll tell me if you encountered any problem.

Follow this link to install the game.