Summary

Hello everyone, glad to announce the second version of the game (sorry, I didn’t publish any other version since 1.0).

This version chips

• graphics improvements
  • brick look has been slightly improved
  • particle effects have been added
    • ball trail
    • ball impact on brick
    • brick destruction
• internal improvements
  • new file structure
  • isolate each component into a dedicated scene
  • new brick system (read below for more details)

The source code is available on my git server. Feel free to browse, download and execute.

This version has been made with Godot v3.2.

Brick management refactored

I had to completely rewrite how bricks are handled in Kace. If you are interested in Godot development and want to understand why using a TileMap for managing entities is not a good idea, read on.

How bricks were managed in v1.0

In the first implementation, breaking blocks (or bricks) were relying on a TileMap component, a specific Node in Godot for managing a grid of similar components. It seemed to be a good approach due to the rectangular shape of a brick, but it forces you to consider a group of cells instead of independent autonomous bricks.

What was wrong with TileMap

It turns out that using a TileMap (I’ll call it the grid from now) was very bad for entity management. Why ? Because you can’t interact with cells of a TileMap directly : you can only interact with the grid as a whole. It causes me a lot of trouble for two reasons :

• collision management
• life management

For collision management, the ball was only reporting collisions with the grid itself, not with the individual bricks inside it. I was making ugly math computations to work around, trying to guess which cell was actually colliding (based on ball position and collision normal vector). I put a lot of efforts making it and tweaking it, but it was still unreliable in the end. And this handmade system lead to a bad game experience, as it could be very frustrating for a player to see balls bouncing against a brick that doesn’t loose life because the algorithm was giving the wrong collided cell (if there is no cell in the given coordinates, no life decreased, no score).

Managing life points of bricks was also pretty tricky, as life amount is a brick attribute. I was forced to handle arrays of life counters inside the grid, and render them with a custom method. Not very flexible, and not very straight-forward.

In a nutshell, the TileMap is not ideal for managing single entities.

Use independent scene instead

In order to fix those missed collisions and ease the process for adding extra brick behaviors like particle effect on impact, I decided to refactor the whole system by making a dedicated scene for the brick entity. This way, collisions were reported against the brick, so no need to guess which cell was collided any more : the physics engine do it for you (and guess what ? It’s never wrong.). And I had far more flexibility to manage the way the brick is displayed. The code also get more readable and maintainable since the brick itself is now split in different nodes with dedicated scripts.

My grid is now a generic Node2D with an attached script, and generating a new row of bricks remains easy thanks to the ability to instance the brick scene from script. So I had no drawback at all switching from my previous implementation to the new one with the dedicated scene.

I got this lesson : use assets the way they are designed for. If you are struggling to implement a feature because you pick a component you already know but that does not fit your needs, maybe it’s time to search the doc, and choose a better one. If you need to learn, do it. If you need to refactor because you think it would be easier to make next features, do it. And if you need to fail first to be sure it was a bad idea, go ahead, we learn a lot through experiments.

What’s next ?

This game is not release ready, and I use this project mostly to practice with Godot. Kace lacks a lot of usability : no screen zoom (anyone tried this 400 × 400 game on a 4K screen ?), no pause button, no “play again”, no UI … Therefore I think my next steps would be on usability.

Stay tune, and thanks for reading !