Spread the word!
Sophie’s Drawings and its Lite version are now available on the iOS App Store.
More info here.
Spread the word!
Sophie’s Drawings and its Lite version are now available on the iOS App Store.
More info here.
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.
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.
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”…
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.
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.
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…
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:
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.
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.
This one should be known by every developer out there… It’s not the most important one either.
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.
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.
I really thought that I’d have this game running in two months… hahahahahaha.
So far it’s been a truly unique experience that I wouldn’t change for anything.
More to come, perhaps in a new post.
I love FlashDevelop, I do.
I love it so much that I even installed a Windows virtual machine just to be able to use it on my macbook pro. It seems insane, but none of the other IDEs that I tried (free or commercial, though there are great ones out there) made me feel as comfortable at coding as FlashDevelop does.
So when I started using it for mobile development, I found out that by using project templates I could save a lot of time setting up new projects, testing and publishing. All you need to do is copy a project template into your FlashDevelop installation folder and then you are almost ready to start coding.
The coolest thing is that you can modify those templates to fit your needs. For instance, I took a template for AIR 2.7 for iPhone and adapted it for AIR 3.0. Later I created a new template that enables you to publish your mobile App to both iOS and Android.
I created a gitHub repository for all my FlashDevelop templates (created or modified by myself), so not only you can download or fork them but also suggest modifications or improvements.
In order to have this templates running, you’ll need to have the following:
If you need some guidance on how to install the SDKs and to understand how the templates work, I highly recommend this series of tutorials by codeandvisual.com. Everything there points to AIR 2.7, but almost everything applies for AIR 3. In fact, I adapted my templates from the one that I found there, so thank you codeandvisual
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?
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.
Use the static method DynamicAtlas.fromMovieClipContainer:
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:
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.