Archives for category: Game Development

It took a lot more time than expected (other projects, other problems) but finally Sophie’s Drawings will be available on the iOS App Store next wednesday 12/12/2012!!!!!

In case you haven’t seen it, here’s a teaser trailer of the game in action:

Right now all my energy is being used for marketing purposes. Any developer that has had to put the marketing guy hat will understand the amount of energy it demands.

For ramblings and lessons learned along the way you can check my latest post.

Splash screen

Sophies Drawings splash screen

Inspired by my 3 year-old child, I’m making a Learn to draw App for children. It’s a step by step (or stroke by stroke) guiding App that will actually compare the original drawing against what the child is drawing, with a nice reward at the end.

This post will make an introduction to the game that I’ve been working in for almost a year (part time), and the lessons I’ve learned in that time.

The concept

There are lots of Learn-to-draw apps in the iOS App store, but not many that can detect what the player is drawing, help to improve the drawing, and at the same time allow certain levels of creative freedom.
I wanted to make a game that can really help my daughter learn to draw, not just some “Watch, then draw, and I don’t care what you did”.

So I took my daughter, Sofía, and told her I was going to make a game for her. And she said “ok”…

Meet Sophie and her magic drawings

Sophie in an early stage

Sophie in color

Sophie is the little girl that will be helping us draw things which, if well drawn, will come alive.
It’s pretty simple: Each drawing is a group of individual strokes. Each stroke will be shown and compared to the original version when drawn, and the resulting drawing will be animated with predefined actions.
There will also be a magic wand to help us draw those very difficult parts, if we don’t overuse it.

So, what’s taking you so long?

Well… let’s say that I discovered that being indie turned to be a little harder than I expected.
First of all, I discovered that I couldn’t stop my main income stream and commit to making this game without succumbing to anxiety and despair, so a part-time modality is what’s working best for me so far. There goes half of my available time, but I’m not panicking anymore thinking that I may fail and end up without money, job, dignity, and a number of other dreadful thoughts that used to come to my mind at the difficult times.
And there are always difficult times…

Happily I’m now working doing what I enjoy the most, both at home and at my part time job. And I also enjoy a balanced mixture of doing what I want and fulfilling other people’s requirements or following some rules.

That said, I also did spend some time contributing to the developer community. Proof of that in my Starling Dynamic Atlas Generator extension and my NME native extensions for iOS.

And then, I dedicated some time to find the idea, the inspiration, the true concept of what I wanted to make.
That took a lot more than expected…

Drawing selection - work in progress

Then some prototypes, some failed attempts when I almost threw the towel, and finally the phoenix coming from its ashes, and if all goes well I’ll be launching this game by the end of July.

This is a little bit of what I’ve learned so far:

Indie Lessons

Do it for yourself (or do it for her)

I’m making a game that I’ll enjoy to play, and that my daughter will enjoy as well (and hopefully learn something along the way). I’m not doing it just for the money, and monetization isn’t the first thing in mind when designing it. Of course that money matters, but if it was the most important thing I wouldn’t be making a game in the first place.

If you don’t love it, don’t bother

I think that this one is the most important of all. If I didn’t love not only the game I’m doing, but also the whole process of making it, this would be another abandoned project.
Seriously, you should take some of your ideas and imagine that you spend a considerable amount of your time, month after month, without earning a dime, and without knowing if what you’re making will be accepted, and then think if it’s worth bothering.

Coding isn’t the hardest part

This one should be known by every developer out there… It’s not the most important one either.

Learn to delegate (or If you’re thinking that you can do everything by yourself, think again)

My first idea when I started this project was to do everything myself: Game design, Code, Graphics, Music…
Soon I discovered that my artistic abilities weren’t helping me get what I wanted to have for this game, and that I would be better if I destined my time and energy to what I’m most suited at the time (coding and game design) and tell an artist what I want my game to have as graphics and music. It will cost me money, but it will be worth it and also will buy me more time to focus on the code and on the game as a whole.

Don’t compromise on the concept

For my last game, FingerSlice!, my main motivation was to see if I could take my skills as a Flash(AS) developer and make a decent game for the iOS platform using the technology available back then (At the time it was AIR 2.5 and the Packager for iPhone), and then publishing and Android and a BlackBerry version. It was a challenging task to find the right performance optimization techniques in order to have some decent frame rate in my iPhone 3G (that was my target device at the time). But is was also very time consuming to optimize and optimize, and devoting so much energy to that task made me neglect other areas as important (or more) as optimization, such as game play design, concept or promoting the app. So at the time I published the first version of the game I realized that it wasn’t what I originally planned to be. It was just my best effort to make something work using a technology that was not ready for the task. It’s a nice game, but it’s not what I really intended to make in the first place. So I didn’t even bother to publish it for Android or any other platform, despite being able to do so “easily”. Nor I didn’t update it to the newer AIR versions that came after 2.5. I was very tired and very frustrated to do it.
The concept had been compromised, and that was what affected the result.

The path I’d take now would be to be inflexible about the concept and core functionality, and if the technology doesn’t support it, then find another or cancel the project.
And that’s why I’m now using NME, which I think is the technology that suits me best for this kind of project.

There are lots of things that I can compromise, and most of those will be added to the game in newer versions through updates, but the core will remain.

Patience, it does take time

I really thought that I’d have this game running in two months… hahahahahaha.

Wait. Hahahahahahahaha!

Drawing screen - still polishing

So far it’s been a truly unique experience that I wouldn’t change for anything.

More to come, perhaps in a new post.

Or should I say: My first contribution to the Open Source Flash community? Both are true.

In case you don’t know what Starling is, it’s a open source 2D GPU Hardware accelerated Framework for Flash that may allow you to take advantage of the benefits that come with the Stage3D class, but for making 2D content.

Enough with the Starling introduction, what I did was to add a little extension that I think will be greatly appreciated, specially by mobile developers.

As you know, GPU acceleration is possible only if you upload textures (bitmaps) to the GPU, so no vectorized content is allowed (no traditional flash display list here).

Let’s say you are developing a game. You want to publish it as an iOS game for iPhone, iPad, and also as an Android App and as a BlackBerry playbook as well. You’ll have to handle a lot of screen sizes. What you want to do is to have only on version of the code and assets and publish it for every device without having to maintain different versions.

If you develop the game using the most common approach (using Sprite Sheets and Texture Atlasses) you’ll have to make your sprite sheets taking the biggest resolution of your target devices (for instance the iPad) and scale it down on the rest of the devices at runtime. That is a good approach but it would require more memory than it would need for most of the devices that it will be running in. And if in the future a new device with a bigger screen hit the market, you’ll have to make bigger assets recompile the game.

Starling lets you create Texture Atlasses at runtime by using bitmap textures. So why can’t you take advantage of your vectorized assets by having then as vectors (Using regular Sprites and MovieClips), scaling them to the size you really want (including filters), and then creating a Texture Atlas?

Introducing the Dynamic Texture Atlas Generator

This tool will convert any MovieClip containing other MovieClips, Sprites or Graphics into a starling Texture Atlas, all in runtime. By using it, you won’t have to statically create your spritesheets. Just take a regular MovieClip containing all the display objects you wish to put into your Atlas, and convert everything from vectors to bitmap textures. This could save you a lot of time specially if you’ll be coding mobile apps with the starling framework.

I’m planning to add the same functionality for converting system or embedded fonts into bitmap fonts as well.

Where can you find it?

How to use

Use the static method DynamicAtlas.fromMovieClipContainer:

DynamicAtlas.fromMovieClipContainer(swf:flash.display.MovieClip, scaleFactor:Number = 1, margin:uint=0, preserveColor:Boolean = true):starling.textures.TextureAtlas


  • swf:flash.display.MovieClip – The MovieClip sprite sheet you wish to convert into a TextureAtlas. It should contain named instances of all the MovieClips that will become the subtextures of your Atlas.
  • scaleFactor:Number – The scaling factor to apply to every object. Default value is 1 (no scaling).
  • margin:uint – The amount of pixels that should be used as the resulting image margin (for each side of the image). Default value is 0 (no margin).
  • preserveColor:Boolean – A Flag which indicates if the color transforms should be captured or not. Default value is true (capture color transform).

As you can see, the only required parameter is the first one: The sprite sheet Movie Clip. Inside of it (in a single frame) you should put every one of the MovieClips you wish to upload to the GPU, naming every instance. At the end of the process you’ll have a Starling Texture Atlas containing every asset as a texture.

Take a look at this example:

// Assuming that you have a MovieClip Sprite sheet named "mc" with all your assets inside
// Enclose inside a try/catch for error handling:
try {
var atlas:TextureAtlas = DynamicAtlas.fromMovieClipContainer(mc);
} catch (e:Error) {
trace("There was an error in the creation of the texture Atlas. Please check if the dimensions of your clip exceeded the maximun allowed texture size. -", e.message);

Some credits

This little project was only possible thanks to the inspiration (and code) I got from:

I really hope that this tiny contribution may help flash developers to easily enter the GPU accelerated world without having to stop using the display list and the Flash authoring IDE for asset creation. Vector content is still really useful for a lot of things.