Pixelrama is making some noise

We decided to add some “cheap” juice really early, so we started playing around with sound effects. The challenge is that, currently, we have no musician in the team, so we are improvising as we go.

Since the idea of the game is supposed to be a calm, minimalistic experience, we tried simple and clean sounds as well. For the rotation action, we experimented with about 10 different sounds or variations. We’re still not sure about it, but we think they sound pretty good, at least for now.

Once you complete a region (a small colored portion of the puzzle), you will hear a pleasant sound of just two notes. If you complete regions fast enough, you will hear the two notes being played in a sequential progression, getting higher and higher pitch. Currently, we have 8 distinct sounds for completing a region.

And, of course, when completing the whole puzzle, you should also expect to hear something gratifying. The game then will play a bright and uplifting note progression in an arpeggio fashion. Fancy description, but this is how it sounds like:

What do you think about the sounds? Do they sound good to you?


Some drawing sets we have so far

We’ve been practicing our pixel art skills lately. We still have a lot of ground to cover, but we think that the drawings are turning out to be quite nice. What do you think? What is your favorite set or what is your favorite from a set?

A cat, a sword, and cherries!
A shield, a carrot, and a cute fox
A mushroom, a flamingo, and a cheesy slice of pizza!

Basic Optimizations

As the Pixelrama levels grew larger we noticed their creation time grew just as much. So we decided to prioritize optimizing the puzzle generation code to improve testing time since it would be necessary before releasing the game anyway.

Finding the problems

After running the profiler and gathering some data, we found out there were two main problems:

  1. Recursive coloring: when the puzzle generation algorithm finishes running, it leaves the level with all pieces connected as a finished game. Then, we pass through every tile and rotate them two times on average in order to deliver the level ready for the player to start playing. But, rotating a tile is relatively expensive because it triggers the recalculation of its color and their neighbors recursively, causing a big CPU slowdown.
  2. Prefab Instantiation: for each tile of the puzzle, we instantiate a Unity Prefab. To our surprise, it takes a lot of time to instantiate each one of them, even though its hierarchy its pretty simple (a parent with around 10 children).

After some brain storming trying to find ways to solve those problems, we came up with solutions that seemed very effective and were relatively easy to implement, described next.

Recursive Coloring

To tackle the issue of massive recursive coloring, we just changed those random rotations to NOT recalculate the colors after rotating. Then, after all those initial rotations are finished, we ran a code that would update all the colors just once. This solution lowered the percentage of total time spent creating a level from 50% to something around 0.01%.

Prefab Instantiation

This one was a little bit harder to solve, as we could not find a faster way of instantiating a lot of objects in Unity. So we decided to fix it a little bit differently with these two steps:

1. We added culling to the camera, keeping on the scene only the pieces that are visible and reusing those as the player pans the camera. This solves the problem partially because if the player zooms out, it was still necessary to instantiate a lot of Prefabs which still caused a slowdown.

2. We stopped rendering the tiles when the player zooms out to a certain amount (it would be hard for the player to play at this level of zoom anyway) and replaced them with a mock of the puzzle, showing finished regions with their respective colors and white for unfinished parts.

As the camera zooms out, the puzzle gradually turns into an overview of the resulting image.


For now, our performance problems are fixed, although some questions arose around these solutions. Would the players prefer to view all the tiles when zoomed out, instead of the unfinished image? Also, how many tiles can we show on the screen at the same time without slowing down older devices?

We think these questions can only be answered by gathering more data by allowing more people to playtest the game, which may happen pretty soon.


A new project on the rise

We’ve been working on a project for a while and we want to share a little bit about it.

It’s a game called Pixelrama and it’s about positioning paint-carrying puzzle pieces to form a beautiful yet simple pixel art drawing. Think as a mix of Pipe Mania, classic jigsaw games and Picross. Maybe it’s better to show a really early-stage GIF of it:

Really early-stage gameplay and art

The game is going to follow the same minimalist aesthetic of Piques, but this time around, with a little more of a zen gameplay.

Currently, we have in mind an Android and Desktop release. We would love to have it also for iOS but we need to wait for the project to move forward and check if there is interest enough in the game for us to invest in Apple devices.

We plan on posting small progress updates in this very blog and also some tidbits over Twitter and Facebook, so follow us there as well.

So stay tuned for more info and thanks for reading!