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.