Sliding puzzle in touch screen

I had Nokia 6600 for my first smartphone, and my favourite game was Mixpix. A sliding puzzle game. I love this game. Now I try to recreate that game for touchscreen phone. And it’s quite a journey.

borrowed from
borrowed from

The long beloved game. Images borrowed from

Moving the blocks

The “buttony phones” (or… maybe we can called it candybar and clamshell phones), long time ago used buttons for it’s main input interface. Unlike today’s smartphones which in majority has touch screen for their input (wow, phones are evolving so fast!). Whether it’s for texting, calling, or even mobile game, buttons were the prevalent UI. Of course, the Mixpix used buttons to simulate “swiping” the block. The step to move the block simply “swap the current empty position of the block to the opposite of current direction’s button.”

Screen Shot 2015-11-08 at 12.18.01 AM

In touch screen, I’d like the block swipe-able. So we can move not only one block, but a series of block altogether to the empty slot. This is how I do it:

  1. Record the first selected position (row and column) of block.
  2. Check where is the direction of movement
  3. From the selected position until the “neighbour of empty block” position, iterate the blocks to move one by one to the empty slot.
  4. Set the first selected position as empty block.


It works quite well! Take a look of the example I’ve made in video below.

To “drag” the block we simply do the same but check every update whether the distance is no greater than the size of the block. You can see the example from this video (and hell yea, more blocks!)

I am quite satisfied for now, but, what if we have many empty blocks? We should handle where it will snapped on the specific position, check the empty positions, limit the positions by numbers of empty position on its row/column, etc… It will be fun.


Development set up

Finally I managed to successfully set up the development environment for the LibGDX. I totally forgot how painful the process were. Well, I compared it to Unity development set up though.

Screen Shot 2015-10-26 at 11.13.56 PM

I used the Android Studio for the IDE. Why? I don’t know. It’s just because I already had this IDE in the first place, so why bother to download other?

There are some bumps I’ve got from here and there about LibGDX development set up. Here are the list:

  1. LibGDX is new, compared from the last project generator I’ve met before. Err… the last time I used LibGDX was 2014, when I was a college student.
  2. Gradle. It’s super duper new thing to me. From what I understand now, Gradle is some kind of repository dependency helper and build settings at once.
  3. The deployment set up. The Android Studio only show Android deployment button, but I want to test the game on the desktop. Fortunately there is the workaround for it. Check it out in here

The other bumps are to learn it again, such as I have to understand how the screen transition works in LibGDX.

That’s it for now.

Devlog Push Slide: List of works

I’ve been thinking about tinkering something again. A nice little game to work on from scratch.  I think it’s a chance for me to get a whole experience of development and publishing. I hope I can delve  more about game development from it. So, hey, why not? Let’s build something for fun again!

The Game

I’d like to make a game about sliding puzzle game. But why sliding puzzle game? It’s a famous and simple game. The game is not unique in mechanic. Only pushing the blocks to empty spot. By maintaining this simplicity I can explore more about juiciness and polishing stuffs. And of course, get things done. Heehee. *looking through the pile of abandoned projects*

The Works

I have broken down some of the steps for this game development. It’s a combination of research, development, and publishing in one. Check this out

Research on coding stuffs:

  1. Draw picture part on tiles
  2. Move tiles
  3. Checking win and lose
  4. Scoring
  5. Timer
  6. Screens
  7. Main Menu
  8. Winning Screen / Losing Screen
  9. Login Google Play Games
  10. Google Play Games Score
  11. Load picture from gallery
  12. Google Play Achievement
  13. AdMob

Content building:

  1. Graphic asset creation
  2. Music asset creation
  3. Achievements
  4. Polishing and juiciness
  5. Sounds
  6. Splash screen, icons, and publishing
  7. Play store upload

Quality Assurance:

  1. Testing and Debugging


  1. Social media and stuffs

That’s quite a lot of thing to do. About 20 steps (and I expect more to come). But because it’s not deadlined project and my private “level up” to practice my development skill, I’ll give it a time.

Huh, but why I smell unfinished job if I say so? Let’s build the milestone then.

November – Pre-Alpha. The game is minimum playable.

December – Alpha.  The game has load picture functionality, juiciness added.

January – Closed Beta. Music and assets added. Everything tested out.

February – Open Beta. Ads running. The login works. Everything should be fine. Expecting bugs.

March – Version 1.


That was the ideal timing. But you know, it’s a side project. Because it’s “side”, so… I work it in my “side” time.

The Tools

It’s a game making, and we need something to scribble it. These are the tools I’d like to use

  1. LibGDX for the game framework. Why? It’s a light game framework (unlike Unity, which is an engine). I also wanted to explore the game development a bit lower level. It helped me to learn how the game application works. In Unity almost everything is magically happened, I blinded by simplicity of it.
  2. Android Studio for the editor. I think it’s a fully fledged IDE for java development specifically for the Android (duh, it’s called Android Studio for something)
  3. Inkscape
  4. Music? Err… Search the Free Non Royalty music, I guess.

The Time

I expect this game will be finished in 4 or 8 months. It will cost about $3000 or more. Lol.

Well, I think that’s all about it. Let’s see what’s to come.

Nice plugin for cinematic thingy

We have a problem finding a simple plugin for cinematic event. We only want something that has timeline and can throw any script to do something to the game world.

Yesterday when I searched about “extending Unity’s timeline” I tripped on something called Animator. A plugin for cinematic in Unity. It’s no longer actively develop, but someone make a branch of it and called it MateAnimator. Go grab it!

Post Mortem : Sweet Tooth Adventure

Hello! It’s been a while since I post something to my blog. In this opportunity I’d like to tell my technical story about Sweet Tooth Adventure, a mobile game I recently made.

Brief of the Apps

Sweet Tooth Adventure is a bubble shooter mobile game. The gameplay is pretty much like other bubble shooter game you’ve found. You control the cannon to shot everything above. When there are 3 or more bubbles with the same color, those bubbles will explode. The player wins after get the candy placed among the bubbles (which have to be exploded beforehand).

This game was an idea from Mr. Dicky Jiang, the artist for this game. He asked me to assist him to do programming stuff on this game.

Technical Difficulties

Bubble shooter game is a simple game. Everybody knows about it. So no amazingly-strange and new game mechanic should be research. The biggest research for this game was the circle packing of the balls.

Oh, we are using Unity for the game engine.

Circle packing.

Every bubble on a board should snapped smoothly each other. You can’t simply shoot the bubble and stop it when collide with other bubble. The result will be quirky hanging ball. Fortunately there are tons of bubble shooter example game (even an open sourced one!).

Quirky ball placement
You don’t want this

The kind of circle packing we want was triangular packing arrangement. This kind of packing is common in bubble shooter game.

After some readings and code, I can gather the idea to snap the ball was “find the snapped position and smoothly move it to that place.”

Well, but how we know the exact snapped position? There’s a great explanation of it from Feronato’s book by using pythagorean for this problem. By knowing the height and width of the ball, we can know where’s the row and column for the distance of each ball. To find the position I could simply divide the current position by distance and round it to nearest number (using ceil or floor). Here’s some explanation about it in diagram.

Screen Shot 2015-09-20 at 20.54.30

Flood Fill

The other thing I researched was the Flood fill. It’s an algorithm to fill specific area within boundaries. In this case, the boundaries were other ball. Fortunately I have ever use this algorithm for another problem. So it’s only a matter of “tweak” the code a bit for ball colors and specific use (such as bomb ball, rainbow ball, etc)


I realized we need some kind of editor for bubble placement, for the sake of game design comfort. After some time of difficulties in the making of the editor, I gave up. I asked Mr. Dicky to simply made the drawings for each level and I’ll manually wrote the array of the level. But Mr. Dicky encourage me to finish the editor, because, yeah, it’s actually almost done. I need some time to work on it, and the editor finally can be used for level creation.

Screen Shot 2015-09-20 at 21.45.25
Sweet Tooth Adventure’s level editor

I’m glad Unity is very easy to extends.

Team Management

These tools helped us to make the game:

  1. Facebook Messenger as the main communication.
  2. Trello for the cork board everything should be done.
  3. Dropbox for asset repository. Unfortunately Mr. Dicky’s storage was full, so we also use Google Drive.
  4. Bitbucket for private repository of Git. We used SourceTree to access the repository.

At first we learned to use the tools. After some moments later we could worked together smoothly.

Some points

  1. Do not use single branch of development, so the developer can make changes and push to repository without conflict too often.
  2. So many things learned if you make the game from scratch.
  3. …but of course it’s easier to buy game template and re-skin it.
  4. Make the content easily accessed and modify by the artist or game designer.

    Screen Shot 2015-06-25 at 1.50.15 PM
    The “congratulation” words easily changed

And We are Done!

After about 6 month, we finally managed to get things done! Well.. not everything is done. Still some feature and bugs swarming around the game. We also need to improve the intuitiveness of the interaction.

And again, you can visit the game’s landing page here (Yay! Promo!). Expect the update from us. Apologize for any grammar mistake :p . Thanks for reading!

Finite State Machine

Finite State Machine adalah konsep dari perubahan state menggunakan trigger tertentu. Sebagai contoh dalam game, karakter yang melompat akan melalui state seperti ini (btw, saya menuliskan state dengan kurung kotak[] dan trigger dengan kurung biasa () ):

[Diam] -> (tekan tombol lompat) -> [Melompat]

Jika ternyata karakter bisa menembak saat melompat berarti alurnya menjadi seperti ini:

[Diam] -> (tekan tombol lompat) -> [Melompat] -> (tekan tombol tembak) -> [Menembak]

Penjelasan tentang state pattern yang lengkap ada di buku Di buku tersebut dijelaskan daripada membuat state pada satu kode yang memiliki banyak flag dan if, lebih baik state dipisah menjadi per kelas.

Desain dari FSM menggunakan kelas

Alasan setiap state dipisah menjadi kelas dikarenakan pada satu state maka kelas akan memiliki perilaku yang berbeda. Seperti contoh di atas, saat melompat karakter tidak menampilkan gambar diam. Input yang diberikan pada kondisi tersebut juga akan berbeda.

Desain FSM dengan kelas dapat diilustrasikan sebagai berikut:

gambaran state machine

Controller merupakan kelas yang menghubungkan antara tampilan (gambar, animasi, suara, dsb). Dengan menggunakan FSM, controller dipecah lagi menjadi modul-modul state terpisah. Sebagai contoh StateJump, StateIdle, dan seterusnya. Kelas FiniteStateMachine  bertugas mengembalikan state yang sedang digunakan, melaksanakan perintah saat masuk (in), dan keluar (out) dari state. Seluruh perubahan state dan pemberian trigger dikendalikan sendiri oleh masing-masing state yang mengimplementasikan interface IState.

Setiap state disimpan dalam sebuah kelas CharacterStates dalam bentuk statik. Hal ini memungkinan state untuk dipanggil secara flyweight. (Walaupun begitu, state juga bisa melakukan return kelas state yang baru untuk menghindari satu state dipakai bersamaan).

Masing-masing state tersebut diberi akses langsung ke controller untuk mengatur gambar yang ditampilkan, serta input yang diinginkan.

Jika diperhatikan, kelas-kelas state hanyalah sebuah sub controller sekaligus model dari kelas controller. Dengan desain seperti ini, setiap state dapat dikerjakan secara terpisah.

Link github project StateMachine dapat dilihat di sini: