If you are starting in game development, you may find yourself lost in some terms that you never heard before. In this post I will talk about 2 of them: Imagesheet and Sprites.

Imagesheet is simply an image file that has several independent images inside. Here is an example:

As you can see, inside of 1 image file there are several independent image files. In this case, all independent images are of a boy, but it could be any other image (like bird, lamp, boy, ... everything together in 1 file).

Why would I use an Imagesheet?

There are mainly 3 reasons.

The first reason is performance. Loading an image is an operation that access a file, so it degrades performance. One way of dealing with the performance issue is pre-loading all images when your app/game starts. You could do that by loading each image file, but imagine doing that for 50+ image files? It is much easier if all these images are inside of just 1 image file, so you do only 1 image loading. 

The second reason is optimizing file size. Having several images inside of just 1 image file allows a better use of image compression, resulting in smaller file size.

The third reason is to create animation. If you noticed, the images inside of the imagesheet above are frames of the boy walking. If you go thru these images within a certain speed, you will see the boy waking. That kind of animation using an imagesheet is what we call sprites (we talk about sprites just below).


How do I access an image inside the imagesheet?

That depends on the coding language that you are using. But the main principle is always the same: you pass the imagesheet file and some extra information about the position of the image that you want.

As mentioned above, we usually refer to sprites as set of images that together create an animation. Each image that is part of the total animation is called frame and when we pass thru the frames at a certain speed you see an animation.

Below is the animation of the boy walking. It was done using the imagesheet above using the first two images of the 3rd row, at the speed of 2 frames per second. 

You can create a imagesheet manually by putting all your images together in the same file, but doing that way is time-consuming and you will not benefit from compression improvements.

So, there are a lot of tools that you can use to create a imagesheet, These tools makes you life easier and you just need to pass the image files and it creates the imagesheet for you. One software that I like and use is the TexturePacker. It is very simple to use and it also allows you to create imagesheets directly from swf files.

If you are using Corona SDK to create your app/game and want to learn more about the code specifics, just read the links below:

[1] http://coronalabs.com/blog/2013/05/14/sprites-and-image-sheets-for-beginners/
[2] http://coronalabs.com/blog/2012/10/09/dynamically-optimized-sprite-sheets/


That is it for today. 

When developing your mobile app/game, you know that you have to keep in mind several design aspects, specially engagement (retention), acquisition and monetization.

There is a very famous framework called ARM (Acquisition, Retention, Monetization) that says that you first need to focus on acquiring users, then engage them and only for last try to monetize them. After all, does not make sense to monetize an app/game that does not have a minimum number of DAU (daily active users).

I have a problem of the ARM. At same way that it correctly poses that does not make sense to monetize before you have a "steady" user base, I don't think that makes sense to acquire users if your app/game doesn't provide them with an good experience that would makes them return to it again. So, I prefer to act in a RAM framework (not it is not the memory :)  RAM = Retention, Acquisition and Monetization).

I came across with a presentation made by Kontagent (a analytics provider) and they showed a framework that is similar to what I think should be the ideal framework to be pursued by a mobile app/games developer. Of course, if you mobile app is more like a service app, the retention would not be something as relevant to you as would be for a game developer. Here is their framework:

If you have some free time, you can watch their full presentation below.

On my next post I will talk about setting up AWS Push services so you can use it with your mobile app/game.

See you.

The infographic below has some interesting data about the mobile game industry. Hope that you find it useful.

This video shows the basic data that you need to look after you launch your game. It also provides some metrics based in the expertise of the presenter. Great video.

Great video about the common mistakes people make when developing Free-to-Play games.

Last week we released our new game: Who is the Actor ?  Now, iOS users can also download the game at App Store.

We are finishing the Kindle version, so soon Kindle users would also be able to play it.

Hi folks. 

We just released our new game for Android. Who is the Actor? is a trivia game that challenges the user to match the actor's face to his name. It appears to be simple, but believe me, it is not... As always, feedbacks are more than welcome. 

Our first game, Cut My Puzzle, is now available at Appstore and at the Amazon Store. So, now you can find Cut My Puzzle is the biggest app store available. Give it a try and let me know how you like it!

Stay tunned for the next posts where I will talk about how the game is performing in these different stores.

See u.

App Discovery is the main problem for developers in nowadays. 

I found the following article by Apptamin to be one of the most comprehensive tutorials about how to attack that problem. I highly recommend you to read it.

The iOS App Marketing Strategy Guide by Apptamin

Today we have published the Puzzle You beta version on the Google Play. You can download to your android device here.