Cocos2D State Machine Wish List

I'm a big fan of Cocos2D for iOS and Android game development.  You only have to read the last 2-3 years of this blog to see that.  Cocos2D is tightly integrated with SpriteBuilder which is an excellent visual tool for creating levels, mapping out game objects, setting up animations and many parts of a game.  As of writing this it just keeps getting better with the advent of V4 road-map and SpriteBuilder's partnership with Apportable we see some great new features.

Right now you can easily integrate, animate and setup your assets in scenes, and then switch back to code in Swift or Objective-C to manipulate your game objects with a nice separation of responsibilities between the SpriteBuilder data files and the Cocos2D code.  

There is only one thing missing, a decent State Machine implementation.

PlayMaker by Hutong Games - http://www.hutonggames.com

UPDATE: I have started hacking around to get a sense of how much work there is and what sort of stuff there is in SpriteBuilder's code base to help.  On Github:

• Initial proof of concept for the state machine & bindings as a SpriteBuilder game
• Includes some performance testing
• Fork of the Cocos2D project with the state machine & bindings from the PoC
• Fork of SpriteBuilder with some new State Machine node types

Screenshot of the SpriteBuilder state machine fork

There's already some support for this from SpriteBuilder and Cocos2D folks which is awesome.  The executive summary is:

• we can have a better state machine that suits Cocos2D games
• we can have it visually designable in SpriteBuilder

My goal is to get something very humble that might not represent the best UI idiom up and working in the next 2-3 weeks, and this will go back to the community for some early feedback.

---

The gold standard for State Machine implementations at present in game development is surely Hutong Games PlayMaker for the Unity 3D game development system.  Of course PlayMaker is not available for Cocos2D, and even if it was PlayMaker's tight integration with Unity's component system would mean that Cocos2D would have to be re-architected to work with it.  There's no way that a "port" of PlayMaker to Cocos2D makes sense, as far as I can tell.  Nonetheless if you ask what is the premier experience for game developers using state machines in their work, I'd have to point out PlayMaker.

Unreal Engine's State Machine editing - http://www.unrealengine.com

Unreal Engine's editing tools also include a State Machine editor, but its very tightly bound to the skeletal animation system.  I have never built a game using Unreal but I suspect that despite the apparent power and sophistication of Unreal's editing tools you'd be hard pressed to use the State Machine to do the kind of complete visual game development that Hutong promises with PlayMaker. I know that realistically if you create a game with Unity and PlayMaker you are going to have to write some code, but if you can for example do great swathes of your game logic in PlayMaker that is very powerful as the less technically savvy members of your team can then get in and work on play without having to know C# or how to script & code Unity.

What Can We Learn?

So we don't have PlayMaker in Cocos2D, but we have an opportunity to learn from the state machine implementations of others, and make something great for 2D game development in our favourite toolkit.

Given a port of these tools is not the right thing, what can we take from PlayMaker?  Of the many things that PlayMaker gets right with respect to its visual editor would have to also be gotten right for a decent State Machine implementation for Cocos2D:

• tight integration with the visual level editor
• preview states and actions in the visual level editor
• states, events and transitions can be stored inside objects/components
• on publish, state machine data is integrated with the game object files
• tight integration with object animations to easily do common things
• can be used for many parts of gameplay, not just animations

Obviously in the case of Cocos2D the editor is the SpriteBuilder tool, which already handles animations and visual editing of many object properties.  We could in theory make a separate State Editor but it would have to be able to be docked in Sprite Builder in order to achieve these things.

What is there Already for Cocos2D?

At present Cocos2D has many of the things needed to profit from a great State Machine implementation, but there are no pro-grade State Machine tools around as far as I know.

There are a few open source implementations around for State Machines in code.  I used Blake Watter's Transition Kit in my game Space Bot Alpha.  Its a nice project, well set up with CocoaPods, unit-testing and so on, so as a piece of Software Engineering its nicely done.  But for game development for me it really failed on the count of making my job easier.  I wound up doing more work for it that it did for me.

A big part of why that was the case is that there is no tooling integration.  I cannot create a State Machine visually with Transition Kit, or any of the other current offerings - it all has to be done in code.  First off this has the problem that its very difficult to do this with a nice separation of concerns and a clean interface.  You wind up embedding the State Machine setup into the objects initialisers and then calling the transitions from various places scattered throughout the code.  Secondly its time consuming and confusing to layout the State Machine in code - with the best syntax and API in the world any useful state machine quickly becomes cumbersome and difficult to maintain.

A second problem is that there is no tight integration between the Cocos2D objects and the State Machines.  You would have to write a whole binding system, but that is work over and above writing the game I needed to write.

Think about Chipmunk as it is bound in Cocos2D right now.  Just turning on Physics and having Cocos2D node objects under a Physics node in SpriteBuilder enables it for physics.  Then once I have checked the enable physics box, the Chipmunk system can change the x and y position of my Cocos2D nodes in response to the physics simulation all without me having to write any code.  Nice!

That's how it should be for a State Machine.  I should be able to hook up a State Machine to my object and have transitions drive changes in the objects properties.  Even if that had to be done in code, having some sort of binding system would save a lot of work.  As it is the code to alter properties in response to state changes gets messy and its easy to circumvent the state machine by mistake and get unexpected results.

Another interesting project is hsm-statechart which is written in C, and is scriptable in Lua.  In theory this should be easy enough to integrate into a Cocos2D project.  However despite some attractive extra features (discussed below) relating to Hierarchical State Machines, and C performance, I tried Transition Kit first as it had an Objective-C API already.

Also worth understanding is the Apache SCXML project which provides an XML format for describing HSM's like those you can build with hsm-statechart.

Memory and Performance

Another problem I see with some State Machine implementations - and Transition Kit is not too bad here but it could be better - is object proliferation.  Its should be possible to create states and destroy them without doing a lot of allocation and destroying of objects off the heap.  Let's imagine we have a zombie game with 40 zombies, and a hero firing hundreds of bullets - we don't want to have an NSObject for every state in every machine for each of those.  But that's how some FSM's are set up.

Instead you need some sort of manager class that can create a unique state machine "pointer" record without duplicating the state objects for each entity using that machine.  Its like a set of CPU registers for a process or thread referencing a copy of a binary program file without making a copy of it for each process or thread.

Also for performance the management of updates on the machine would have to be done well - tightly integrated with the game objects own update mechanism where timers were needed; or designed so that it does not unnecessarily get updated.  String dispatch would be ideal, as long as it does not impact on performance, and it should be used where it can reduce coupling of the objects in the program - we don't want to create circular pointer chains that could result in ARC retain cycles.

Blending and Animation Integration

Check this video on setting up an animated door in Unity using PlayMaker.  Of particular interest is the blending of the open to the closed state & animation which comes for free.  Here you have an animation for the "closed" door, which specifies certain XYZ positions for the door model, and similarly XYZ positions for the "open" animation.  Creating a transition between open and closed gives you a smooth blending from one set of XYZ to the other, similarly as setting keyframes for a Cocos2D animation would.

In a game getting the State Machine to work well with the animation and actions system is vital.  If a whole lot of extra code has to be written to get this to happen the you wind up doing more work for the State Machine than it does for you.  Blending is part of the story - here you are getting basic animations for free just for using the State Machine.  But where you want to have an animation play as an object transitions from one state to the next you need extra care.

Sub-States: A Hierarchical State Machine

How do you handle the fact that during an animation from open to closed, you are not really in either of those states but in fact you're in some in-between animation state??

One option is to have a 4-state model for your door: open, closing, closed and opening and then you can have the animation complete handler for the closing animation cause the transition from closing to closed.  The problem with this is when you have some other game logic that depends on checking the state of the door.  Lets say you have some poison gas in the room - it can escape into the adjoining room if the state of the door is one of open, closing, and opening - but if an NPC character wants to walk through the door they can only do so in the open state.

A more complex State Machine implementation is to use State Charts to solve the problem.  These add hierarchies of states, and also variables & guards to the system.  Variables are like game objects values, except they only exist within the framework of the State Machine.  Heierarchies mean that you can take the animation states which are visual effects that depict and implement an object; and place them inside a semantic (or meaning related) concept of a state.  So you could have two high-level states of Closed and Open; with Open having as sub-states Opening, Closing and and Completely-Open animation states.  This way you can have the Open high-level state trigger the release of the gas, and the NPC only get access when the low-level state Completely-Open is triggered.

Effectively what you are doing is grouping your states.  You need to specify which of the sub-states is entered when the superstate is entered, and there are some other details, but basically they're an extension of the simpler FSM concept.

So here's the remainder of the items, which would apply to a State Machine implementation regardless of the game level editor question.  Here's part 2 on my wish list:

• the FSM must have simple bindings to objects (like Chipmunk)
• transitions can be configured to drive changes in objects properties
• blending of property changes should come for free (see video)
• load states, transitions and events by reading some kind of data file
• can also create states, transitions and events in code if needed (rarely)
• state machines can be serialised for use in save/load-game and other cases
• small memory footprint/CPU usage
• ability to specify variables and guards as for HSMs (nice to have)

When?  Why?

I think having a solid State Machine implementation with editor support would get new comers to game development much more excited, productive and involved in game development.  It could give existing experienced developers relief from some tedious, detail-focused coding tasks and make those things accessible to the level designers.  And it could make complex bug-prone parts of a game project into data-driven cleanly-seperated modules.  I think it would have huge value.

I'd like to see this happen, so I might be interested in pitching in on such a project.  But it would need broad adoption by the core SpriteBuilder/Cocos2D team.  Let's see if we can get them to have a think about it.  :-)

More progress with Spine

I've been working on importing Erin into Spine so that she can do all the things I need her to do in the game, like reaching for things and climbing on things.

Update: adding in the front-quarter walk-cycle animation.  There are 5 different spritesheets: front, rear, side, front-quarter, and back-quarter.

The quarter and side ones are flipped in X to give a full 8-way facing character.

Here's a GIF export straight from Spine showing the walk cycle from the front.

I find the front walk cycle particularly hard because instead of just being able to use just limb rotations, you need to do a lot of image switching and scaling.  Scaling is used to make the rear-ward leg in the walk have that limb and foot appear to go back and up.

Notice also the feet:  as the leg extends towards you the bottom of the foot becomes visible.  This does not come for free.  It is done by swapping the foot image from a top down one, to one where the foot is viewed from below.  Its a different sprite altogether and I tell Spine to switch one sprite for the other at just the right moment so that it looks completely natural for the walk.

The image switching is also used for the eye-blink that happens as Erin's right foot hits the ground.

I am pretty impressed by Spine so far - it really is a pro bit of software.  Just wish it had been around a year ago.  :-)

This video published recently on my YouTube channel explains some of the thinking behind the move to Spine, and also compares the previous tech stack's deliverables with that of Spine.

I didn't show it in that video but here below is the Spine sprite sheet:

...amazingly compact, hey?  Especially when you consider that with this set of sprites I can use Spine to create any animation I want, for example Erin reaching down, scratching her head - that is to say an "idle animation" - or anything else I need.

Room to Room

This new progress update video shows a bit of a milestone with our animated door sliding open and our heroine able to move to a new room.

I did all the room background artwork for the apartment a few weeks ago and I have been coding like a demon since then ironing out all the issues with moving from room to room and persisting the game state across view and room changes.

For those of you who are coders you might be interested in this aspect of CocosBuilder and Cocos itself - since it is scene based, and your scene is effectively your entire user-interface, moving to a new room basically tears down the whole UI, and it has to be rebuilt again from the CCB file for the next room or view.

This makes for some fun and games when an item has been modified in one view and you need it to reflect those modifications in a new view on the "same item".  Like wise with items that have been added to the inventory, and which to not appear in the next view.

Lastly of course the actual opening of doors and the logic with the character having to wait for the door to slide open before walking through had to be done.

This is done with action queueing which also took quite a while to get working properly.  So for example the sequence to go through to the walk-in-wardrobe is

• player taps the door to the wardrobe and says "Go"
• queue a GoTo  action to the wardrobe room
• that requires the door to be opened first so...
• queue a GoTo the door
• queue a Open of the door
• when the door open occurs it plays an animation of it sliding open
• finally execute the action to go to the wardrobe

This is all now working.  Whew!

Progress update video

A thing or two dropped into place today so I thought I'd upload this progress update video showing where things are at with my game, EthEx2080.

Apologies for my halting voice-over - I am a bit weary but I get there in the end.  :-)

All constructive criticism is gratefully received.

Please bear in mind that nothing is carven in stone at present, especially the character look and animation.  I am looking at changing over to Spine for that which will give me an opportunity to redo the vector art from my original Anime Studio work.

I want to give our heroine a slightly softer look - she's kind of a hard-nosed type at present!  Also the way the vector art came out trying to allow for the face animations and neck movement made the line around the face heavier than I wanted.  Anyway - you get the idea.

By the way - if anyone followed my presentation on Lua scripting you can see a bit of that coming through here in how the game text is generated from the state of in-game items.

Let me know what you think.

Exporting layers from Gimp as PNG files

Gimp for MacOSX is now a "native" (-ish) application, and is a great graphics tool for game developers - especially those who can't afford Photoshop.  I've always used it and wouldn't go for PhotoShop as I know GiMP so well now.

You can create animations in layers and Gimp allows you to preview your animations when you've done them as a bunch of layers, by simply invoking the handy "Animation" option in the menu:  "Filters" > "Animation" > "Playback..." - very nice.

But now how do you export those layers as a collection of separate PNG's so you can import them via TexturePacker into your game?

It turns out there is a handy Gimp plug-in to help you - but installing it is not for the faint-hearted.

Installing Plug-ins for GiMP on Mac OSX

On Windows or Linux the process is comparatively easy and is described in a nice tutorial.  If that article happens to be unavailable the GiMP registry lists a number of others.  On MacOSX where normally things "just work" for some reason its a lot more obscure.

The first insight is to know how to find your plugin folders.  Use the Preferences menu in GiMP to find the Folders item and choose "Plugins":

I didn't use the one for just my user name because I wanted the changes in GiMP to be available to anyone using the GiMP install on this computer.  Also it saves me a step as I don't have to create that folder.  I used the GiMP internal folders.  It also has the advantage that if I copy that GiMP to another machine, its plugins go with it.  Nice.

The second thing to know is that there is a laundry list of different types of things that you can install into GiMP, and this makes things more complex for the GiMP automation newbie.  You have "scripts" which are small helpers that can automate what GiMP already knows how to do.  Then you have "plugins" which are larger actual programs which extend GiMP's functionality.  And then there is modules, brushes and the list goes on.

Confusingly enough scripts are written in scheme, but if you want to write a script in python, that is considered a plugin.  Why?  Because the GiMP authors decided it would be so.  In any case if you want to install the export_layers Python script, you have to install it in the plugins folder.

Also since it is a plugin, it has to "look" like the other plugins which maybe complied C program binaries and so on - in other words it has to be executable.  If it isn't then it won't show up when you restart GiMP.  And also - note - restarting GiMP is required, since this is a "plugin": you cannot get it to show up by selecting the "Refresh" option from the script-fu menu in GiMP.

So first step - shut down GiMP.

On MacOSX using the Terminal its then an easy 3 step process:

cd ~/Desktop
curl -O http://gimp-registry.fargonauten.de/files/export_layers-0.6.py.txt
chmod a+x export_layers-0.6.py.txt
mv export_layers-0.6.py.txt /Applications/Gimp.app/Contents/Resources/lib/gimp/2.0/plug-ins/export_layers

If you have problems using the Terminal I really strongly suggest that you start getting over them.  Seriously.  You're missing out on a lot of what Mac has to offer - all the power of Unix just a few keystrokes away.  It's much faster and much easier to capture the process to repeat or modify it.  In some cases the Terminal is the only way to do things.

I use a mixture of UI dragging-and-dropping and always have the Terminal handy to do things that the Terminal is great for.  If your Terminal is not already running, type <cmd>-<space> in Finder and then type "Term" to get hold of it with Spotlight, then press Enter.  With your fingers on the keyboard you're ready for the Terminal to do your bidding.

Let me demystify the above a bit for those of you not keen on the Terminal:

• First I change directory to the Mac desktop - we're going to temporarily store the downloaded plug-in there. 
• Next we use the curl command that downloads stuff
• I use the -O (that's a capital Oh) to say that the output file should be named 
• curl will call it after what ever it was on the server I got it from.  
• Try typing "man curl" to find out more about curl - its a handy tool
• Then the script has to be made executable with the chmod command
• if you've managed to get the Python script in the right folder but it still does not appear in GiMP - you probably missed this step.
• Finally copy the script into place.

To do most of all this graphically is possible, but its a pain.  You'll need to

• Go to the export_layers plugin web page and right-click on the link to download it to your Desktop.
• Now you'll need to make the file executable
• I know of no way to do that apart from the command line - so you'll need to open the Terminal for that.  
• See the above "chmod" command, and first cd to wherever you downloaded the file to.
• Click on the downloaded file and rename it to export_layers
• Now go back to Finder and open two windows.
• In one, navigate to your Gimp program in the Applications folder, right-click and
• choose "Show Package Contents"
• the Finder window will change to a view of the inside of the GiMP application bundle.
• Navigate down to through these folders
• Contents > Resources > lib > gimp > 2.0 > plug-ins
• In the other window navigate to your desktop
• Drag-n-drop the executable export_layers into place in the plug-ins folder in the other Finder window

Now when you restart GiMP you will find that you have a new menu option under the "File" menu with "Export Layers" > "as PNG" which will do what you need. Note you may find some oddness/bugginess with where it drops the generated files. If that happens, use Spotlight to find them - in my case they were dropped into my home folder.

Bonus Content

There are a bunch of Mac file name changer apps out there. If you're a Terminal master you don't need 'em.

After running the file export my original sprite sheet called "process-working.xcf" had resulted in a bunch of weirdly named files as a result of the Export Layers command. The names were like "process-working_xcf-working-1.png" - where the first part was the file name and the second parts were all the layer names.

for f in *; do g=${f#process-working_xcf-}; do mv -v $f $g; done

This command will strip off the leading characters "process-working_xcf-" part and just leave the layer names. The -v just gives verbose output so you can see what it's doing. You'll need to cd into the directory where the files are located before running it.

This is using the Terminal (well, the Bash shell's) ability to do substring mangling. To find out more at the Terminal, type "man bash" and then a forward slash "/" and then "substr". Press enter a few times until it gets to the stuff with the curly braces. As explained there you can use the % instead of # do strip stuff off the end of the string instead of the beginning. For more complex things you can go from just using to f and g, to h and j as well - and so on - successively picking apart the string as you go.

When experimenting with this stuff it pays to preview your command before you run it. You can do that by prefixing it with "echo" like this:

for f in *; do g=${f#process-working_xcf-}; do echo mv -v $f $g; done

Then you'll get a nice listing of all the "mv" commands that would be run, and you can inspect them to make sure your substring mangling did what you expected. Have fun!

Rushy Anim Tut for Walk-cycles

Update: most of what is contained in this video is still valid as far as it goes, however I have now moved to Spine for my in-game animations.  I will still be using AS9 for cut-scenes.

Check the post I wrote about Spine character animation for more details on that amazing tech.

---

This is a very quick export of first walk-cycle animations, showing a bit of how I work.  I'm still in the middle of working on this so its rough, but I thought I would take this moment to cover what I have learned for my in-game character animations.

First can I say that AS9 Pro is very good for this job.  Combined with TexturePacker this process gives you a set of sprites in a sprite sheet that you can drop right into your Cocos2D game.

The horizontal lines show my method for getting the walk correct.  I recommend this excellent tutorial on the fundamentals of the walk-cycle at AngryAnimator.com - refer there for the meaning of the pose names and to explain the lines.  That tut is for pencil-and-paper cel animation but its by far the best of any tutorial I have seen yet.  The best insight it has that you need to base your cycle around the contact pose, which is when the legs are at their farthest apart.

There are some differences taking Angry Animator's method to the 2d-bone animation technique, but most of it is the same.  In the computer-animation your big bug-bear is skating/sliding.  To fix this I do the animation with a translation (so the character moves across the room as well as pumping his/her legs) and this allows me to mark the foot-falls and retro fit the feet to the marks.  This seems to fix skating quite nicely.

To get my sprites the right size I use one of my game rooms as a background and then I can position the character at the largest size it will need to be against that room.  Then when I do the export the Anime Studio camera is set at the same size as the background, so the PNG's that are exported have the character sprites at the correct size.  Because I use TexturePacker I don't have to worry about the vast amounts of transparent pixels all around each PNG frame exported: TP will remove that and pack the actual sprite into the sheet.  (Note, I have made a terrible job of this part in the sample files shown here -   but they are just for illustration only).

Having the game background also allows me to do the sprite sheets for other animations such as sitting down on the bed, reaching for the window and so on.  Here I'm just talking about the walk animation.

Here is my process:  I do my animations as a walk with translation by:

• Set the animation marker to frame 0
• Draw and rig the character
• Draw the guide lines on a seperate layer based off your character
• Pose the bones to the contact pose; left-leg in front
• This counts as your first step/foot-fall
• Mark its position on the guide line layer
• Measure out 3 more strides to find the foot-fall points on the guide lines
• Temporarily translate the character in its contact pose
• Using legs & feet like a pair of dividers
• Mark each foot-fall positioning the back foot at a mark
• Then do mark a new foot-fall at the front foot
• To mark I use Anime Studio's "note" feature
• Translate the whole character so that the 4 strides take 48 frames by
• Move the animation marker to frame 48
• Translate to the final marked position at 4 strides completed (4 steps/foot-falls)
• Don't use bone translate for this - use whole-character-layer translate
• Go back to frame 0 (contact pose; left-leg in front)
• Copy the contact pose at frame 0 to 24 and 48
• Create the opposite contact poses at frames 12 and copy to frame 36
• See Angry Animator's tutorial
• Use the Z move bone tool to switch the legs over
• Keep the character at the same height
• Now add the recoil poses at 2 and copy to 26
• Use the translate bone  on the root bone (not the whole character) tool
• move the character down to the lower guide mark for the head
• The recoil is the lowest pose so head-height  should be checked carefully
• Adjust the feet to the foot-fall marks so they don't skate or slide
• Adjust the legs to the "sink" pose so the feet are still on the lines despite the lowering
• Copy the recoil pose to 14 (and dup to 38)
• Copying key frames makes sure you get the height & attitude right
• Switch the legs front-for-back to get the correct opposite pose
• Make sure you don't change the height of the recoil when doing this
• Do the high-point at 8 (and copy to 32)
• As for the recoil use translate bone on the root bone to move character up
• Copy these forward as for the recoil and switch to get the opposites at 20 & 44
• Do the passing pose at 6 (and copy to 30)
• Do the opposite passing poses at 18 & 42
• Add in hand-arm swing, bending the elbows
• Add in some head bob, and other movements
• I did ponytail up in the recoil and down in the highpoint

Once complete, run the animation through on loop mode over and over, looking for timing issues, mistakes and unevenness.  Tweak as necessary.

I find its impossible to do this without the translation in the animation (as above) especially with respect to removing/reducing skating, where the characters feet slide or "moon-walk" across the ground.  Also, even though technically you could do all the above in 24 frames instead of 48 I find it much easier to have the extra framing so I can see what I'm doing.

Once everything is golden, you're ready to create game art.

Choose the key frame channel for whole-of-character translation (not bone translation) and delete it.  This will remove the character animation that does the travel across the room, and leave all of the bone translations and rotations done for the walk-cycle itself.  If this somehow removes your height adjustments done for the recoil or high-point poses (because you used whole of character translate instead of bone translate) then undo the delete, and go back - carefully remove the bad keys and replace with bone translate keys.  See the above.

At this point playing the animation should show your character doing a 48 frame in place walk-cycle, with nothing else on the screen.  Now to export game ready art, hide the guide lines, any background images used for scale and go ahead and choose "Export Animation".

Select the PNG exporter from the drop-down.

You only need to select 25 frames of the above animation.  I do a full 48 frames so I can select the part that looks good, and because I find its easier to check the animation for errors.

If you go with the passing pose as your start frame then it works well with a standing character moving into a walk because the feet are together, and then one picks up and starts walking.  To do that, in the export dialog choose 18 as the start frame and 42 as the end frame.

At this point you also have the choice to export at half-frame rate by checking "Render at half frame-rate" on the export dialog.  This will give you 13 frames when exporting frames 18 to 42, and 12 frames per-second is probably OK for most games.  If you need 24 frames a second leave this box unchecked and you'll get 25 frames.

Run the export, choosing a folder (use create folder if needed) to put the frames into.  Don't worry about background colour - PNG export by default will alpha out all the background for you.

Now you can use Texture Packer to put the frames into a sprite sheet, by dragging and dropping the folder you exported the PNG files to.  Follow Ray Wenderlich's excellent tutorial for this - I won't repeat the details here.

The sort of result you get is as here (although this is a PNG sheet).  

Note that I have done a power-of-two sheet with my crazily large sprites.  This sheet is 2048x2048 (fine for desktop but bloated for mobile).  You can (and should) do a non-power-of-two (NPOT) sheet if you know that your platform supports it.  Most new platforms do.  Also using the pvr.ccz compressed PVR format will give a good result in sprite sheet size with fast loading times as well on mobile - check the Wenderlich tutorial for more details.

Character rushes

Rushes from the studio floor.  This is a still frame from my current work, animating the main character Erin.  She looks a bit grim, but I suppose you would be if you woke up with the headache she has in the game.  :-)

I use Anime Studio Pro which uses vector art in layers; and the above is actually around 30 different layers, one for each of the moveable parts of the body, and another one in some cases (switch layers) for parts of the body that have different appearances.  The hands for example have a "grasp" position as well as the above relaxed position; and the feet can either be straight on (as the left foot) or aside (as in the right one).

When the camera zooms in the vectors scale nicely which gives a good result.  The shading is done with a single polygon defined by another unstroked vector.

Anime studio lets me export to PNG sequences, which I then texture packer down into sprite sheets for use with Cocos2D.

Now to work, doing the walk cycle, idle animations (scratch eyebrow, twitch feet to different stance) and a few others.

Update: mov export of first walk-cycle animations.  Going to refactor this a bit.

Animation begins

Screen grab of the Neural Probe character that I'm working on currently in Anime Studio.  This is for the title sequence of the game which is non-interactive (basically a movie that rolls while the game title and intro is being displayed).  This little guy is so much with the lamprey and menace vibe that I just have to find other places for him to show up now.

I'm going to try to do a bit of animation every week I think, so I don't have a huge pile to do at the end. It's really intense work, and so different from coding.  I will pretty much need to mix it up, or my spine will be a pretzel from all the concentrated tablet work.

This is a part (can't give everything away at once) of the scene the cute little guy above appears in.