Written by: Eliana Oda

A couple of months ago, Unity 3D challenged their users to create something gorgeous in their engine, while making use of the features of DirectX 11. Needless to say, we at Breaking Fingers do love a challenge! Despite the difficulty of squeezing the contest in our tight schedule, we still managed to finish a game prototype in a week! You can download it on our page: Download Pet Showdown

We didn’t win the contest, but we couldn’t be more proud of the result. In this blog post we’ll shed some light in the visual development of Pet Showdown, the first of many jams we’ll do this year! :)

Pet… what?

Pet Showdown is a game prototype developed by Breaking Fingers for Unity’s contest. Set in a feudal japanese world inhabited by anthropomorphic animals, two players must choose between Shiba, the loyal samurai dog, and Naou, the cunning ninja cat in their final confrontation.

Establishing the setting allowed us to search for very specific visual references. We wished to create an environment that evoked feelings of calmness, but with a dramatic twist to it. The characters were not supposed to look realistic, and the environment should follow the same aesthetic.

During the concept art process, the environment art helped establish the mood of the scene, while the character designs defined the general art style.

Shiba the Dog and Naou the Cat

The two playable characters are meant to look like the perfect nemesis for each other. While making them a dog and a cat certainly helps accomplish the idea of a rivalry between them, other elements in their designs make this enmity even more obvious.

Shiba is based on a breed of japanese dogs known as Shiba Inu. As dogs express the ideals of loyalty towards men, we saw fit making him a wandering swordsman, or a samurai who had lost his master. His clothes have a warm color scheme, as does his fur.

Naou is loosely based on a siamese cat. We played a bit with the idea of making the darker shade of his facial fur resemble a mask. His color palette is mostly comprised of dark shades of black and blue, which is fitting to his line of work. 

Their swords, however, have sheaths of colors opposite of their owners’ color scheme, for the sake of creating contrast and making the characters more visually appealing. It should be noted that the swords are named “Blue Demon” and “Red Demon”. Perhaps they are linked to Shiba and Naou’s vendetta?

In our next post, we will show a bit of the process of creating the game’s environment - the stage of Shiba and Naou’s final duel! Stay tuned! =)

Galaxy Rush 2.0 - Concepts

Here at the headquarters of Breaking Fingers, we are working full-time on the development of new content for Galaxy Rush!

Take a peek at what our artists are doing!

Written by: Augusto Roselli

So you decided to develop a game for a mobile platform such as the iOS or Android ? Good idea, but be prepared to go frame by frame coding. Even though mobile devices seems to be getting better and better in performance, they are still years away from any Console or PC. Maybe someday this will change, but for now, you’ll have to trend very carefully on your programming if you want to give a smooth experience to your players.

Code x Art the everlasting battle for memory and CPU

If you’ve ever developed a game, you know this is true. Programmers love to blame the artists for performance issues, either the models have too many polygons or shaders are too expensive. Well, before diving into those waters, take a breath and debug your code, on the mobile space, even the slightiest mistake can throw your framerate through the window, and sometimes, solutions we use on our everyday algorithms for desktop, web or console games just won’t do it.

Of course Art can be very expensive, but an effort on your part can leave the gameplay untouched and open space to make the game prettier, which, in all honesty, is what the player will notice more .

Get your hands Dirty with Debugging 

The big catch with code optimization is: if your code is not already optimized, you’re not going to notice. The game will work, no errors will come at you from your Engine, but the game will be laggy and framerate will not be what you wish it to be. 

So firstly, I would recommend you to always go through this steps instead of waiting until the game is done to avoid reworking on stuff that already works, it will save you time and keep you engaged, after all, who wants to work on something that already works just because the system isn’t powerful enough ?

To find those scripts that are bumping the whole experience, the best way is to profile the game. Many Engines have it and there are many ways to do it, but I’ll cover a simple one, doing it through our Engine of choice, the Unity3D.

Unity3D has a profiler built into the engine, so all it takes is to turn it on to know what’s going on with your app, the profiler can show you how much of a fps hit your code lands on the overall performance and it should be kept to the minimal. On the list view, you can see exactly what routine is using most resources at any time, and get a target script to be redesigned. 

Unity’s profiler can only be used in the engine’s pro version. If you want to know more in-depth, go the official documentation script here.

Of course, you should use the profiler in your target device, to test the script running on real-life conditions. To do that, just build your game to your device and have that device be connected to the same network as your development computer. On the profile window, click on “Active Profiler” and select your device.

Now just enjoy the ride. Pay attention to the graph while the game runs and you’ll see spikes in CPU usage now and then. When your game is laggy, you can check what exactly is using more processing power. If you are building for the iOS you can pause the game without killing the app from Xcode. 

Also, pay attention to the fps levels that you reach. Most modern smartphones on both Android and iOS platforms should reach 60fps, but building a game for mobile means old systems too and maybe 30fps on a very old device isn’t something to scratch your head for.

If the code is taking most of the CPU, take a look at what process is taking more space and get to redesigning. Remember, there are infinite possibilities to solve any kind of programming challenge, just push yourself to do it in a different way, I do recommend going back to the drawing board for that script, don’t try to fix it, you’ll end up wasting more time than helping yourself.

More than that, there are moments where the Art is really the villain of that scene, and profiling can identify that as well and you can help direct the artists in what should be changed on their end to keep the game smooth.

Frame by frame scripting

As I said, every frame counts when developing for a mobile platform, but how to get there ? Here goes a list of a few tips I picked up during the years, specially in the development of Galaxy Rush HD, our latest title at Breaking Fingers:

1 - Has it got to be every frame ?

• The Update() / FixedUpdate() / LateUpdate() functions are way too overused. Well those are always pretty intense on CPU usage, and when you’re in space with the player character and 20 enemies on screen and 40+ shots flying across the screen, those Update() functions start to get really heavy. Try to find ways around it whenever possible and if you really need to do it, try to solve it with co-routines, they are way more cost-effective on CPU then every-frame functions. There is a great doc about co-routines and yield functions here.

2 - Component Reference

• Instead of using a component directly in the script, such as gameObject or transform, in Unity, it’s actually lighter on the CPU to store those components in variables, so if you are using those components directly, try declaring variables and assigning these to them on your Start() Function

3 - Touche[s]

• Another little details that goes a long way is the way Unity handles touch inputs. In the same veins as the component reference, when waiting on user input, always use Input.touches[x] instead of Input.GetTouch(x). As the strutter suggests, GetTouch() is a function and will allocate memory for a new variable that it returns every frame you use it. But Input.touches[x] allocates memory only once, making it lighter to be called.

4 - LessScripting

• Have a OOP mind. The less scripts you put to use at each frame, the less the CPU has to load, so try to be generic and if you have 20 types of enemies and they all move around, go for building a single script that can be tweaked to accommodate all enemies instead of making 20 different ones that essentially do something different. ( this is also easier to debug and improve, as your script library grows, so does your organisation and work when an update comes up to be done ).

So that’s it for now, I hope you can make good use of this and lastly, never make the mistake of being satisfied with “almost perfect”. Set a goal for X Fps and  don’t stop until you reach it. And remember, do this not only when creating a script, be whenever you have the a new system, check it to see if there are no loose ends. Your players will always find it if you don’t.

Thanks for the time, as always please keep coming back for more devblogs here and keep an eye on the site for our latest games. For those who missed it, our game Galaxy Rush is out for both iOS and Android, if you haven’t done so already, please download it and let us know what you think.

Written by: Vitor Fajardo

In this post we will talk about how Shitake was texturized and the importance of making the model adapted to the texture and the texture adapted to the model.

————————————————————————————————————————————————————————————

If you thought that texturizing is just putting a beautiful picture on a model, think twice. Most of the time, the texture will have to be so distorted that you won’t even recognize it. So twist your mind and be creative.

When you create a model for games you have to think of some important things:
 

How to give your model the best silhouette with the lowest polygon number as possible

The polygon count is very important to maximize the performance of the game, so try to put just the very necessary to make it beautiful. Remember that texture can do miracles, you can make a square looks like a perfect round ball if you know how the texture works.

What is the best way to open the model’s mesh?

Always try to keep the most natural model’s form as possible, but at the same time, try to explore the maximum of the texture size to avoid wasting resolution; the size of texture makes a huge difference on the performance of the game too.

How the texture will be to fit well on the model.

Making art for games can be very frustrating for those who like details, but with the right technique and some creativity you can think of solutions to keep your art beautiful and make the programmers happy.

Remember to always focus on the angle of the polygon and try to play with lights and shadows applied on the texture.

If the model will be animated, how the texture will deform.

On animated model the texture will deform, like it or not, but you can use it on your advantage. Think of how the specific movement acts and draw the middle of the animation or the position that the model spends more time.

And my favorite… If the player won’t see it doesn’t have to be beautiful.

Focus just on the game screen; just because the game is 3d doesn’t mean that the player will see everything. Thinking about what the player will see helps you to choose which is the best polygon angle and resolution of the important parts of the model.

————————————————————————————————————————————————————————————

There are no secrets or pre made recipes to create the model, you just have to practice and be creative. Every little step you make changes completely the way you make 3D, so don’t be afraid to try new tips. Remember that real world sculpturing is a huge base to have a 3D mind; try to make some clay sculpture before sitting in front of the computer someday.

Low poly modeling has some difficulties, so enjoy every smart solution you make.

Written by: Augusto César 

One of the biggest problems when developing games for android is, without doubt, the immense range and variety of phones and tablets, actually at the end of last year, the number of devices running android OS was more than 1500!!

Now picture yourself, my dear developer friend, if you want to reach the maximum audience for your game/app, you must make it work on every device, that means you will have to buy all 1500 devices?!

No and yes at the same time. If your app is simple an you are sure that it can run on every device, Android devs  can rely on the emulator, which is useful only for emulating various screen sizes, resolutions, aspects, DPI and test how your app reacts on the different sizes.

Our latest game, GalaxyRush, was developed in Unity3D and was impossible, at least in our case, to test the game via android emulator. First of all, because the emulator runs really slowly, even on a top performance PC.  And then we have an issue that the emulator is not the real place to test and deeply profile a game. So what we have made, and what decisions we made, regarding the android OS, for this project is what I will try to cover here.

1) Device coverage

Decide if you want quality over quantity, or vice versa. If you chose quality, it means you have more development freedom, and your target is only high end devices that can run heavy graphics, textures and etc.

Taking Galaxy Rush as an example, we chose to target only devices with Android 2.3.3+ OS. By doing this, we automatically eliminated all low, and most of the mid range devices, that wouldn’t run galaxy rush smothlly.

2.) Graphics

Galaxy Rush is a 2D side scrolling game but all the graphics are 3d models, only the background are images, and there are many models into the game scene at same time. This means that low capacity phones and tablets cannot run this game.

If you want to target low power devices, keep the poly count of your game low, use just a few textures with low resolution. By low I mean at max a 256x256px. NEVER (I really mean never) use textures with alpha, they demand a lot of processing, and will drop the performance of the game significantly. 

3.) Code

The code itself is not the heaviest part of the games (generally), so the only things to avoid is using physics. Galaxy Rush is, again, my example. We developed in Unity3D, which has the Nvidia PhysicsX system, for physics simulation. We decided not to use it in this project. Of course, it was not necessary in this type of game, but in code speaking, the most demanding operations are the Physics.

Ok, now we finished the game, what to do?

Using Unity3D, after the game was ready to go to GooglePlay Store, we came across several issues, since building the apk, to uploading the game on Google Play. We don’t want you to have the same problems we had. Here are the Steps we made to make it work out:

First of all, you need to sign your app before uploading them to Google. If you are using Unity, I have bad news We tried for, at least, a hundred times to sign the final apk and without success so we had to sign the apk before it was builded.

Assuming that we are building the unsigned(debug) apk, your Unity3D screen on player setting should look like this:

(for security reasons I won’t be showing our public key)

First step is to choose “Unsigned(debug)” on the Alias menu, that will make the apk unsigned and the version is debug mode, useful only for testing purposes. After that, in Public Key Box, fill in with your developer public key, you obtain that key on your developer console of the Google Play.

Ok now build your APK!

After that, if you try to upload the app, google will pop you a error. It means that the apk is not Signed correctly, or saying that you musn’t upload a Debug version and you will have to correctly sign the apk.

Signing the apk is easy: you have to download the Android SDK and make your CMD on windows, or Terminal on a MAC, visible to the SDK lib, so you can use the commands from the prompt menu.

Now open your CMD.

We need to clear all sign data from the apk and remove the debug version. So use this code on prompt :

zip -d YourApkName.apk “META-INF*”

Now you have to create a valid Keystore. Open the prompt again and use this line of code

keytool -genkeypair -dname “cn=xxx, ou=xxx, o=xx, c=xx”-alias youraliasname -keypass yourpassword -keystore C:\Users\mykeystore -storepass yourstor pass -validity 1000

Now pay attention. On the field “cn”, write the name that you use on Google Play developer console, exactly that name. “ou” stands for Organizational Unit. Write your company name there. On “o”, write your organization name. After that, just change things like your password and you are done creating the key. It should be created on the path you entered before.

After that, you must sign the apk. Now for the code:

jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -yourkeystorename.keystore yourapkname.apk youraliasname

Now, get the names you have created and write them down to the correct spaces. Your apk is now signed correctly!

The last part is to ZIPALIGN the apk. To do so, use this code:

zipalign -v 4 yourapkname.apk yoursignedapkname.apk

Hit enter and there you go! Your apk is ready for deployment. Now just upload it on Google Play and wait for it to be a success!

Written by: Eliana Oda

In our last post, we talked about the creation of music for Galaxy Rush. Today, we will show how the character design for Sir Shitake evolved, from earlier drafts to the final version. We hope you’ll enjoy!

————————————————————————————————————————————————————————————

Jelly Shitake

At the beginning of this project, we weren’t too sure about the approach we would take to Sir Shitake’s design. We did know, though, that one of his main features would be his eye. Below you can see the first sketches of a more cartoonish jelly Shitake, which were soon discarded.

Tentacle alien

We later took a slightly more realistic approach to Sir Shitake (as realistic as a floating eyeball alien can be), and having abandoned the jelly idea, we opted for giving him tentacles. Galaxy Rush is a game about traveling through space, and as such, we had to create his design taking in account how he would move and push himself forward. Imagining the outer space environment to behave in a similar way to an underwater environment, the tentacles seemed like an interesting idea.

Defining the silhouette

Many factors contribute in making a character recognizable, one of them being a good silhouette. We had to keep in mind that making it simple makes it easier to remember as well. That meant removing unnecessary features such as numerous tentacles and keeping simple shapes such as the big, round head/eye thing. 

Playing with body language

The expressions mainly served to help the dev team imagine the character’s personality and backstory. 

Final Shitake

At last, we had a final version of Sir Shitake! Despite not having a mouth to express himself, his color scheme and intense gaze should tell he’s a curious little fella who may or may not know he’s a threat to the entire galaxy.

Now Sir Shitake is ready to destroy his enemies explore the universe! Shall we accompany him? :)

Written by: Henrique Fajardo

This is the first post on Breaking Fingers blog. We’ll be posting regularly about the development of our games so you all can read, comment, learn and share the knowledge on games development. Please fell free to comment. We’d love to read everything you know to improve our next posts!

————————————————————————————————————————————————————————————

Every single person likes music. Of course the music changes from person to person, and that only makes the work more difficult to the composer that has to create all music from a movie, game, animation and so on. In this post I’ll focus on the creation of music to a mobile game developed by Breaking Fingers, which I happen to be its main composer.

Let’s start with a question that I’m used to hear over and over when I’m giving my workshops: how do I start creating a song and make it sound good to my game? Unfortunately, there isn’t such thing as a “recipe” for a good game music. I found some useful steps that worked out for me, but, as I said before, these steps shouldn’t be followed blindfolded.

Step 1: Get to know your game

It sounds pretty obvious, doesn’t it? But it’s not. The most successful game composer is the one that knows exactly what your game is about, what is its core fun, appeal and pace. For the sake of exemplification I’ll use the soundtrack of Galaxy Rush as a basis.

At the very beginning of Galaxy Rush’s development, the development team – that from now on I’ll just refer as “we” – decided that this game would be a space side-scroller. First thing I did was research what other games had already done and search for good music is this genre. The pace of our game had to be frenetic, so I went to my musical background to decide what kind of music I would be composing.

I got deeply influenced by electronic and techno music, which have a very deep bass beat and good rhythm. It helped me a lot to bring the “frenetic pace” we wanted when I was composing the gameplay music.

Step 2: Overcome project obstacles

Ok, now you know everything about your game and can even go around pitching it. Great! That means that all you have to do now is the music itself, right? Wrong. Every game composer knows that you must consider the hardware, software and design limitations before getting into composition process.

These were the issues I found on Galaxy Rush:

• It’s a mobile game
• It has only one stage that would be generated dynamically
• It has tight paths that slow down the pace of the game
• The player can go through the same stage forever

So let’s see if I understood everything right. I needed a light, dynamically adaptable, triggered and endless, song. Is it right? Yes, that’s right, but there’s nothing to panic. The solution I found was to deal with this issues one by one.

First of all: the mobile game issue. Galaxy Rush was developed using the Unity3D engine so the first thing I did was look after solutions and advises in blogs and forums so I could minimize my development. I found out that the iOS system works really well with MP3 files, but for some strange reason the loop feature on iOS Unity3D doesn’t work nicely.

The solution I found was working with WAV files. The problem is that this file is way larger than the MP3. Fortunately, Unity3D 3.5 has a lot of other good features for audio, such as a good compressor. That solved my first issue.

The next three issues I figured out to solve at once. I really love to create some adaptive music. That helped me to create the music freely. I created three versions of the same music, different mixing, some tracks enabled and disabled and a couple more of experiments. That gave me a set of versions of the same music that could be played on a fast or slow pace. One last good thing is that those versions of the music were looped so they were always playing and all I had to do was enhance or get the volumes down to change what version of the music the player would listen.

Step 3: Pre-compositional process

We’re almost creating the music! Is the pre-compositional process really that important? Can’t I just press Rec and start recording everything that comes out? Yes, you can. I did it that way a couple of times. The pre-compositional process is good because you can set some aspects before focusing on composing. That saves you from that compositional nightmare: “and now, what should I do?”

One good thing to do in this phase is to think how many songs will be needed on the project. Galaxy Rush had a need of, at least, two songs. One song made for the menu and another one for the gameplay itself. The menu song didn’t demand such a complex process as an adaptive music, since the menu is almost stationary and have a relaxing and confortable mood.

There are two things that I really care about menu songs: it has to tell the player that he is safe there and shouldn’t stop playing (or, at least always come back sometime). I decided that the music would work looping (WAV, compressed) and would have a calm mood.

The gameplay song had to be frenetic. To emphasize that I decided to create some ideas on different paces, so the player would be always in a “alarm mood”. As I said before, this music had to work on a loop.

Step 4: Composition and Testing

Now you put all your skills into work! Now that everything is set and ready for your creativity to flow free you can enjoy the magic of creating music. Find the best free time (I get really creative at night/dawn) and start creating according the definitions you had preset.

After you have some piece of work (or even the whole song) put it to test. Try mixing with all kinds of headphones and speakers. When you are composing to a mobile game, try hearing with the internal speaker as well. After mixing again and again you probably will end with a version that you like and the whole team approves. The next step is to introduce the songs to the beta testers. You might have to change a couple of things before everything is neat and ready to be released.

For Galaxy Rush, we ended with two songs: Space Mall (for the menu screen) and Run Shitake, Run (for in-game). You can listen to both of them below. Please tell us what you think of this post and about its subject. Do you have something to improve this reading? Share with us!

For now, that’s all! Subscribe and follow us to receive the following posts about the Breaking Fingers’ way to create and develop games!