Metal Fish Eggs

I’ve been invited to speak to about creating apps for kids at Nook – a work and event space for artists and illustrators here in Toronto. I’m expecting it to be a pretty free-wheeling discussion about all the practicalities of the process. I’ve hand picked a number of articles and links to get people started and thought I would share them here.

Apple iOS Developer Program: If you want to publish your own apps to the App Store this is where it all starts.

Apple’s iOS Human Interface Guidelines: Read them. And then read them again. Even though they are geared a bit more toward productivity and utility apps for adults, there are lots of insights on how to design effective interfaces for mobile.

Overview of iOS Game Frameworks: A good introduction to the variety of frameworks available to take some of the pain out of creating your own apps.

Do I need to know how to program to do game design? An excellent response to a frequently asked question.

Inventing (Playful) Invention: Great overview of the process of creating digital play experiences for kids from the creators of Toontastic.

User testing at zinc Roe: Notes on how we approach user testing with kids. Some important considerations here to ensure you get useful feedback.

App Licensing: An excellent blog post from Night and Day studios on how they went about entering into licensing deals. Moms with apps is a loosely-organized group of (mostly) indie developers building apps for kids. Their forums are a great place for creators who are just starting out.

There are a lot of good kid app developers out there, here are a few of my favourites:
Toca Boca
Launchpad Toys
Kidoodle Apps
Duck Duck Moose
Night and Day Studios
Crab Hill Press
Nosy Crow
Gareth Lancaster
Matt Hammill

We have two desks coming available in January. The space includes internet connection and shared use of our kitchen, printer and boardroom. Ideal for a freelance designer, developer or other creative professional who wants a bit of work/life separation but not the headaches and cost involved in renting a full office. Cost is $300/m. We’re located in downtown Toronto at the corner of Adelaide and Portland with easy access to Jimmy’s Coffee. If you’d like to find out more just drop us a line.

Here’s a problem that often crops up in our iOS projects – how do we get assets originally created as vector artwork in Flash onto an iPhone or iPad?

The simple solution is to export the assets as bitmaps, but this approach has a number of issues. First, it means making and exporting multiple versions of each asset for different resolutions and aspect ratios (iPhone, iPhone retina display, iPad). Keeping track of that many assets is labour-intensive and makes maintaining and updating the apps difficult. Second, there’s a pretty hard limit on how much stuff you can actually load into memory on a device, especially when there’s frame-based animation involved. We always have to simplify and compromise on the amount of artwork and animation compared to the Flash version. And sometimes, it’s just not possible.

Wouldn’t it be great if we could just load a SWF?

In the process of porting a Flash game we’re working on to iOS, it seemed like we’d run into one of those “just not possible” situations. I started looking around for alternatives to the whole export bitmaps song and dance and came across MonkSWF by Micah Pearlman, a project on GitHub that claimed to be able to do just that – read a SWF file and display it in vector format (using OpenGL) on iOS.

Sure. And pigs can fly.

Except… it actually works! Note that MonkSWF isn’t “Flash on the iPhone”, it’s just reading the vector data for the shapes on each frame (so no ActionScript or anything), like you could read the vector data from an SVG file (strangely enough, there’s also MonkSVG, which I haven’t tried). It’s great for simple animation SWFs, but probably not anything more complicated than that.

There’s not much documentation, so it took a bit of work to get it to compile (well hello, Xcode workspaces!). And, since we use cocos2d-iphone for pretty much everything these days, I wrote a quick CCNode subclass that displays a SWF file and put it all together in one Xcode workspace.

Here it is:
cocos2d_iphone_monkswf_ios.zip

Just run setup.sh to checkout MonkSWF, MonkVG and cocos2d-iphone. Then, open MySampleApp.xcworkspace in Xcode 4.

Enjoy!

How do you take a classic platform game and adapt it for 4 year olds? This was the challenge we faced in designing Justin Time Online, a joint production with Guru studios.

Goal
In classical platformers, like Super Mario Bros., the goal is to get to the end of each level without dying.  For our pre-school audience it’s the immediate goals that are most important. The real payoff is in all the little animations, actions and treasure found as you explore. Trigger a tune as you run past Aztec sculptures, pop the bubbles floating through Japan, or fall on your bum when you slip on a puddle in Venice.

Multiple Paths through the World
We built a more guided game experience for younger kids, so that players, if they so wish, could press and hold in one direction and still manage to get to the end.  Along the way, they would still be able to ride a boat, slide down hills, or pop into the clouds.  More skilled players however could be more adventurous, breaking away from this path, and find those hidden areas, filled with treasure.

Creating an amusement park feel
In each of the worlds, we tried to create a series of moments.  These moments could be sliding down a mountain, steering a raft, riding a Ferris wheel, or even just triggering a series of musical notes.  For children, these moments are what made the games fun, and like an amusement park, kids would want to re-play these moments over and over again.  For each of these sections, we had to make sure there was always something that could take you back to the top of the slide, or allow for the animations/sounds to be re-triggered.

Context is King: Driving Animations
Justin can perform around ten unique actions.  Unfortunately we needed to keep the controls simple for our pre-schoolers.  Unlike AAA console games, where the player has a button for each of the character’s actions, we had two; run and jump.  To accomplish the feeling of mastery over the character, we triggered appropriate actions when they contextually made sense.  For example, when running down a steep hill, we would make Justin automatically slide, or when crossing a clothesline, make him automatically shimmy or zipline across.  To the player, they would still just press the one directional button, but the context would trigger the visual variety.

A few weeks ago Justin Time Online launched on DisneyJunior.ca/fr, coinciding with the french premier of the amazing television series created and produced by GURU studios.  The centrepiece of the online property is a platformer adventure game, that allows kids to play as Justin, as they explore the vivid worlds of Venice, Japan, and the Aztec jungle.  Kids are given complete control of the character and are able to run, jump, slide, and swing through these worlds as they collect unique treasures.  Speaking on the show’s themes of teamwork and friendship, Justin is accompanied by his trusty sidekick Squidgy, who helps him get to those hard to reach places, and Olive, who acts as a guide throughout these worlds.

zinc Roe is looking for freelance developers to work with us on upcoming projects. We develop websites, games and apps for children. We build things that we are happy to share with our kids, nieces, nephews and neighbours. Our developers are very talented and enjoy applying these talents to build games and activities that delight, engage, entertain and – once in a while – educate. If you’re passionate about coding and are looking for new and interesting challenges we want to hear from you.

The zinc Roe team comes from a very diverse background in terms of education and work experience. We value portfolio and personality above all other considerations. Show us what you’ve built. Tell us how you built it and why.

From the outset we knew we wanted our Stella and Sam Apps to fully support English and French and be built in such a way that we could accommodate additional languages in the future. Colin promptly dug into Apple’s docs on how to support localization and did a survey to see how other app developers were handling the issue. What we found left us with a series of three not-quite-perfect options. I wanted to share what we learned and hear from parents and developers about their thoughts.

There are two things that make localization of children’s apps different than typical apps. First – including assets for multiple languages in a single app means each additional language can result in much bigger app files sizes. This is because children’s apps often include a lot of voice over. Second – users may want to switch back and forth between languages frequently. In traditional apps users are more likely to use the app in their native language and stick with that. With children’s apps parents often want to have their little ones play in multiple languages as a way of improving their language skills.

1. Publish two separate apps

The advantage here is that the apps are smaller in size (no need to include localized versions of all the assets. Also, everything about the app from the search-engine-friendly URL in the app store to the app name and content is in the native language making it fairly clear when promoting the app in different languages. Even if their device is set up in English you can send them to a URL where you can be sure they will see the French app name and description in the app store. The downside is that families who want their kids to play in both languages have to buy the app twice. It also means maintaining two apps so QA and updates can take a bit longer.

2. Publish one app and build a language setting into the app

The advantage here is that parents and kids can fairly easily switch back and forth between languages. File sizes grow because you need to include assets for both languages. In apps like Stella and Sam that means duplicate copies of audio files as well as all the graphics used in menus. The big disadvantage though is there is no way to localize the app name on the device. The books and the tv show have a significant audience in France and French Canada and Stella and Sam is actually Stella et Sacha in French. So promoting a ‘Stella and Sam App’ and then relying on native French speakers to navigate to the appropriate setting is less than ideal.

3. Publish one app and rely on the device’s language setting

Apple’s development tools include a fairly elegant method for supporting multiple languages within a single app. File sizes are still big but following this approach means that everything from the app’s name on the device right down to the graphics assets are set based on the language setting on the device. This is the method that Apple recommends but it’s designed more for localizing an app like Safari than it is for a kid’s game or storybook. For native French users this gives the same advantages as #1, namely that the entire experience from end-to-end is in French. The big downside is that users who want to switch back and forth need to navigate away from the app to the Settings App to switch languages and then come back to the app.

The File Size Issue

As I’ve mentioned, embedding assets for more than one language can result in very large file sizes. The Stella and Sam Apps include 2.5 minutes of high-quality video and two sets of videos would have pushed our file sizes from about 60MB to around 100MB. Based on a suggestion from an Apple engineer at WWDC we looked into building an app that would download these large assets on the first run. But after looking into this we opted against the idea for three reasons: extra development and QA time to build a thoroughly-tested system for managing the download process, a long delay when the app is first launched and the assets load, and frustration and disappointment if parents first launch the app while offline. Although we embedded all the assets, we were able cut down on file size by separating out the audio tracks from the video. Since only the audio is different we embed one video track and two audio tracks. Based on the language settings we play the appropriate audio track and sync it up with the video.

Conclusion

As a parent, I love the idea that kids can hear the story and play the activities in both languages as a way to re-inforce their language skills. As someone who has worked with software for non-English users I also understand how important a seamless native-language experience is to having legitimacy in these markets. Making the decision was difficult but in the end we chose #3. It allowed us to publish a single app while offering a completely French experience right down to the app names. Also, following Apple’s recommendations generally means fewer surprises down the road.

So far I’ve had one support email asking about how to switch languages and one bad review from a user who was clearly unaware of how to switch languages. As we anticipated, this solution is not ideal for parents who want to switch between the languages frequently. However, for native speakers it has worked tremendously well. Apple featured the Stella and Sam Apps in both the Great Canadian Apps and Apps en Français sections.

Final Tip

One issue we ran into was how to link French-Canadian users to the App in iTunes without displaying the preview page in English. If we used the link as provided from Apple it would display the English preview page. Unable to turn up anything in Apple’s docs I started playing with the URL and discovered that adding a ‘&l=fr’ to the end of the URL forces the display of the French app details on the preview page.

The Flash IDE has many short-comings as a code editor, but for the most part the pain is limited to the person actually using it. If, however, you’re editing ActionScript files in the Flash IDE on a Mac and then committing them to Subversion (you are using version control, right?), then you’re foisting the pain on your co-contributors.

When you edit an ActionScript file in the Mac version of the Flash IDE, it converts the file to CR format line endings – you know, like the ones used by the Commodore 64, the Apple II and Mac OS 9. Since Subversion’s diff tool (svn diff) doesn’t understand line endings from the 80′s, you (or your co-contributors) get something like this when you then try to diff the file:

Not. Pretty. Subversion thinks every line in the file has changed (and it has, because Flash changed all the line endings) and there’s no way to tell which part of the code you meaningfully changed. While there is no way to make Flash smarter, we can help Subversion out a little bit by telling it to automatically convert the line endings to the native style used by the OS.

From the command line, find your problem file and run the following command:
svn propset svn:eol-style native LineEndingTest.as

If you diff the file again, you get something like this:

Much better! Subversion automatically converted the line endings to LF format (the native line ending format for OS X) and the diff tool works again.

To avoid having to run svn propset on every ActionScript file you create, you can use subversion’s auto-props feature to do it automatically when you add or import ActionScript files to subversion.

Open ~/.subversion/config in your text editor and turn on auto-props by uncommenting the enable-auto-props line. Then, add a svn:eol-style entry for .as files at the bottom of the auto-props section.

Unfortunately, auto-props won’t fix files that are already in Subversion – you’ll have to fix those ones manually or write a script to do it for you.

There you have it. Flash, Subversion and line ending bliss.

This week I gave a quick talk on user testing with kids based on our experience here at zinc Roe. I am a firm believer that good games come from good game designers. User testing helps these designers empathize with their audience by virtue of spending time with them. It is also crucial to making the refinements that make a good game great. But no amount of user testing will save a poorly designed or built game. If you’d like to learn more about the do’s and don’t of user testing here are the slides:

SLIDES – Jason Krogh on User Testing with Kids

What do you think? Is user testing always worth the effort? Can really bad user testing be worse than no user testing at all?

By the way, we are always looking for kids ages 3-12 to help test our work. If you live in the Toronto area and would like to get involved please get in touch!

Are you a freelancer looking for a nice workspace to call your own? We have two desks coming available to rent to the right people. The space includes internet connection and shared use of our kitchen and boardroom. Ideal for a designer or developer who wants a bit of work/life separation but not the headaches and cost involved in renting a full office. We’re located at Adelaide and Portland with easy access to Jimmy’s Coffee. If you’d like to find out more just drop us a line.