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.”

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:

Record the first selected position (row and column) of block.

Check where is the direction of movement

From the selected position until the “neighbour of empty block” position, iterate the blocks to move one by one to the empty slot.

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.

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:

Draw picture part on tiles

Move tiles

Checking win and lose

Scoring

Timer

Screens

Main Menu

Winning Screen / Losing Screen

Login Google Play Games

Google Play Games Score

Load picture from gallery

Google Play Achievement

AdMob

Content building:

Graphic asset creation

Music asset creation

Achievements

Polishing and juiciness

Sounds

Splash screen, icons, and publishing

Play store upload

Quality Assurance:

Testing and Debugging

Publishing

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

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.

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)

Inkscape

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.

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! https://github.com/ddionisio/MateAnimator

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!).

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.

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)

Editor

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.

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:

Facebook Messenger as the main communication.

Trello for the cork board everything should be done.

Dropbox for asset repository. Unfortunately Mr. Dicky’s storage was full, so we also use Google Drive.

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

Do not use single branch of development, so the developer can make changes and push to repository without conflict too often.

So many things learned if you make the game from scratch.

…but of course it’s easier to buy game template and re-skin it.

Make the content easily accessed and modify by the artist or game designer.

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!