A small look behind the scenes: from rectangles to pixel terrain
Level 7 was not only a bigger step in terms of level design. During development, the underlying terrain architecture of Fizzles also changed quite significantly.
The first levels were built around fixed rectangular areas. Platforms, obstacles, and walkable surfaces could be represented very reliably this way. For mostly static levels, it was a simple and robust solution.
As the environments became more organic, however, that model started to reach its limits. The next step was therefore polygons. These allowed mushrooms, cave walls, and other irregular shapes to be represented much more accurately.
For the Digger in Level 7, this approach was pushed further: the terrain could now be modified at runtime, with the affected polygon geometry being updated accordingly.
Technically, this worked reasonably well — but testing on weaker hardware revealed another problem.
On my development PC, the solution initially seemed perfectly usable. Testing on Android devices told a different story. As soon as many Fizzles were moving around and several Diggers were modifying the polygon terrain at the same time, Level 7 became noticeably slower. The older levels, by comparison, continued to run without problems on the same devices.
At that point it became clear to me that “it works on my development PC” simply wasn’t a good enough benchmark. Since Fizzles is intended to be a mobile game, I didn’t want to keep building on an architecture that was already showing obvious performance problems on other hardware.
So the polygon approach was dropped.
The next step became:
Rectangles → Polygons → Pixels
The current Fizzles terrain is based on a pixel-based outline model.
This makes arbitrary terrain changes much more direct. When a Digger removes material, the game no longer has to reconstruct an increasingly complex collection of polygons. Instead, only the part of the terrain that was actually affected is modified.
This also fits the mechanic itself much better. Digging does not produce neatly prepared geometric shapes. It creates narrow shafts, irregular edges, tiny remnants, and arbitrary transitions exactly where the player chose to use the Digger.
The initial mechanics of a level are derived from a specially prepared template. This analysis happens during development. The generated terrain data is then stored with the level, so the finished game does not have to analyse mechanic images every time a level starts.
Another important part of the new architecture is that local changes should remain local.
A single digging step should not trigger work proportional to the entire level every time. That matters much more on smartphones than it does on a fast development PC.
For me, the whole process has also been a nice example of how a technical solution evolves together with the requirements of a game:
- Rectangles were simple, fast, and robust.
- Polygons made genuinely organic terrain shapes possible.
- With dynamic digging, however, polygon updates became too expensive on mobile hardware.
- Pixel terrain ultimately fits both free-form destruction and the performance requirements much better.
Level 7 is the first level where players can directly experience this architectural change.
The large mushroom is not just background artwork or a collection of predefined platforms. It is actually part of the mutable terrain and can be dug through wherever the player chooses.
For the player, the end result should feel completely natural:
Assign a Digger, a hole appears, and the Fizzles react to it.
Hopefully, you can’t tell that behind the scenes we had to go all the way from rectangles, through polygons, to pixel terrain to make that happen. 