We’ve been implementing Git for quite a while on our HTML5 games projects and we love its code management possibilities and its collaborative features.
Using Git with the command line is too hard for us, that’s why we need a client. Until recently we were using SourceTree. SourceTree is a great product and it’s free, however there were 2 things we don’t like. First, the theme is white as siberian snow, and our tired programmer eyes really favour a dark theme. Second, SourceTree seems to work better on Mac than Windows. That’s why we’ve decided to test the free version of GitKraken.
The team of programmers developing each of our game projects usually consists just on 1 or 2 guys, so the free version is enough for our current needs.
Do you already have your own favourite Git client? Have you also suffered from white backgrounds and bleeding eyes?
Luckily we have a powerful ally called Jscrambler.
“Version 4 brings the product from a code protection solution to a platform that provides a tamper-proof environment to the application, making sure it is executed without interferences and by legitimate users only.”
We’d like to show you an example of the level of protection that Jscrambler offers, we’ll take a function of our game “Alien Kindergarten” and obfuscate it.
We can see that even after using JSbeautifier the code is quite difficult to understand. Besides site-locking they offer some interesting transformations such as dead code insertion (that’s why the obfuscated code is longer) and member enumeration.
Mission accomplished…. it looks like that doing the whole thing from scratch is much easier than attempting a reverse engineering.
Ahhhh! forgot to say that Jscrambler is optimized for games and doesn’t affect performance.
We are happy to announce we are working on a new Foot Chinko chapter.
It’s been a long time since the original game was launched and we were excited about the possibility of developing a new Foot Chinko game. During this time it seems that our little creature has been growing in popularity. Although the game was released over a year ago, enthusiastic players keep on uploading videos: Foot Chinko on youtube
We are going to release an HTML5 exclusive version of the game for Spil Games. This version will feature the Eurocup 2016 and will include a couple of new mechanics.
We are also considering a native version of the game for iOS, Android and Windows phone using Unity. By combining the old game levels with the new ones, we could have almost 150 different levels, but the truth is, in this time we’ve learned so much about level design that designing a complete new set of levels is an interesting challenge.
So, what kind of publisher do you think would be a good partner for this adventure? We would love to hear your thoughts…
We’ve been using an html5 game engine called Phaser for over a year. It’s open source and was created by a photon storm.Our experiences with Phaser have been fantastic. We’ve tried several frameworks but found Phaser the best game engine to develop our games from the usability and performance points of view.Now Richard Davey, the man behind Phaser, has started a campaign to collect money to be able to dedicate more time enhancing his incredible framework.Please check this out:
Scrum is an agile development method that allows for quick iteration and offers great adaptability to suit the needs of the project or any sudden setbacks. It mainly focuses on … getting a working game as soon as possible, and then improving upon it. As such, it can be an invaluable tool for studios wishing to save time otherwise spent redoing previous work all over.
Right now we are involved on the production of an addictive mini game in pixel art.
Creating Foot Chinko took really long for our standards, almost 3 exhausting months. This time our goal is to develop a more agile game and why not? A bit crazier.
Hopefully we won’t deceive our fans, this new title will contain high doses of humor and surrealism.
TexturePacker is available on www.codeandweb.com.
Loading time is critical on mobile html5games. Some optimizations can be achieved by reducing the size and the quantity of the assets to be uploaded without giving up quality.
We’ll describe some of the basic things that can be done to minimize loading time. They are quite standard, followed by most developers and include optimizations on these fronts:
Our game Foot Chinko contains more than 30 audio effects, that’s a lot. We wrapped them in just 1 audio file with this open source application:
Tõnis Tiigi Audio Sprite on github
The resulting file is called audio sprite. Size wasn’t reduced but the amount of assets indeed, and this helped a lot to keep loading time low.
Game Engine – code
We are currently implementing Phaser for all our html5 games. Our cute Pocahontas Slots doesn’t make use of all the capabilities of this great and robust framework. It doesn’t need the physics module, for example. Instead of referencing this file in the index.html:
we include the smaller:
Don’t forget to minimize your code too.
Choose a good and unique resolution, all assets of your game will be dependent of this initial decision. We usually work with the iPad2 resolution, that is 1024 x 768 px. Our games look alright on desktop and devices with a big display without punishing players with smaller resolution devices.
Did you know about texture atlas?
A good program to generate them is Texture Packer. Once you’ve packed all the images into a texture atlas is time to compress the resulting png. We use an online tool called tinypng for that. This is the last step before releasing the production game.
In case you need a simple background image with a color gradient, for example, let’s say for the sky, generate a bitmap procedurally.
Foot Chinko, our casual approach to football (soccer) games, has the biggest amount of levels ever seen on a Ravalmatic game (+90 levels). Editing them was a major effort per se, but then, arranging them properly wasn’t either a simple task. Without no particular literature about this specific stuff, here’s how we figured we could handle the task.
When you do level design it is key to have a tool that is visual and fast to use. The agility you have when building and testing the levels is very important to produce good stuff. If the task is a heavy and time consuming burden, the levels will consequently be designed in less iterations. That’s what happened in previous games of the studio resulting in more plain level design or an exaggerated amount of time invested on the task.
Enriqueto, had already used the Flash IDE as a visual level design layout that could be later parsed into data about items, their location and contextual level data (seconds, type of goalkeeper, etc.). Testing those levels was as easy as exporting the Shockwave file, running a json exporter, and testing the game on the browser.
Ivan then edited a huge amount of levels in several iterations, discarding some of them due to technical limitations, and getting the most out of sketched ideas and emerging game mechanics. Some of Foot Chinko’s levels felt more skill-demanding and some other had a more random development, but the general idea was to keep a wide variety of levels, offering contrasted flavors. While a random level could be more appealing for a casual player, as the game progressed, those levels should be gradually replaced by more technical ones. If the resolution of an advanced match was just in the hands of luck, the more experienced players could get frustrated. Speaking about Foot Chinko‘s difficulty, it’s really hard to keep objectivity, since your skills will probably be above the average user, so try to make some early testing during this stage of the level design process.
Finally, we printed cards of every single level we had. That helped us to have an overall look, and making groups of levels (passive/interactive, slow/dynamic, easy/hard) and then arranging them alternatively, considering the general difficulty progression during the whole game and the partial difficulty progression of each tournament. Placing the cards on sticky panels was really useful to identify visual patterns and also make agile tweaks. The final step is testing that level progression with players. With the help of metrics we’ll be able to notice if there are some particular tough levels that break the natural progression of the game.
There are probably better ways to deal with level designing and arranging, so we would be glad to hear your suggestions. Take care!