7. June 2015


In the previous tutorial we covered Sprite Animation, although to be honest it was more about creating animation ready sprites.  The actual way we performed animation wasn’t ideal.  Fortunately we are about to cover a way that is very much ideal… and capable of a great deal more than just animating sprites!


As always, there is an HD video of the this tutorial available right here or embedded below.  It’s important to have followed the previous tutorial, as we will be building directly on top of it.


Keyframes Explained


Before we get to far into this tutorial I think it’s pretty critical to cover a key concept in animation, keyframing.  Essentially you animate by setting a number of “key” frames in the animations timeline, then let the computer take care of the rest.  You can set a keyframe on just about any property available in Godot as we will soon see.  For example you can create a key on the position value of a sprite.  Then advance the timeline, set another key at a different position.  The computer will then interpolate the position over time between those two keys.  This interpolation between key frames is often referred to as a “tweening” as in “inbetween”.  Don’t worry, it will make a lot more sense when we jump in shortly.




In the previous tutorial, we created a simple animation using code to increment the current frame at a fixed play rate.  Now we are going to accomplish the same thing using the built in animation system in Godot. 

Start by opening up the previous project and remove the code from our AnimatedSprite.  Now add a AnimationPlayer node under the root of your scene, like so:



With the AnimationPlayer selected, you will notice a new editor across the bottom of the 2D window:



This is your animation timeline control.  Let’s create a new animation named “walkcycle”

Click the New Animation icon



Name your animation and click Ok



Click the Edit icon



This will extend the animation options even more.



First let’s set the duration of our animation to 2 seconds:



You can then adjust the resolution of the animation timeline using the Zoom slider:



Here we’ve zoomed in slightly to show just over 2 seconds:



Now that we are in edit mode with our AnimationPlayer selected, in the 2D view, you will notice there are new options available across the top



This is a quick way to set keys for a nodes positioning information.  You can toggle on or off whether the key will store location, rotation and/or scale data.  You set a key by pressing the Key icon.  The first time you press the key icon you will be prompted if you want to create a new track of animation.

Select your sprite, make sure the timeline is at 0 and create a key. Advance the timeline to 2secconds, then move the sprite to the right slighly, then hit the key icon again to create another key frame.



Press the play icon in the AnimationPlayer to see the animation you just created:



Well that’s certainly movement, but pretty crap as far as animations go eh?  How about we add some frame animation to our mix.  Here is where you start to see the power of animation in Godot.


With the AnimationPlayer selected, rewind the timeline back to zero, make sure you select your AnimatedSprite, then in the Details panel you will notice that all of the properties have a little key beside them:



This is because you can keyframe just about any value in Godot.  We are now going to do it with the Frame value.  This is the value we programmatically increased to create our animation before.  Now we will instead do it using keyframes.  With the timeline at 0, set Frame to 0 then click the Key icon to it’s right.  Click Create when it prompts you if you wish to create a new track.  Then move the timeline to the end, increase Frame to the final frame (21 in my case), then click the Key again.  This will create a new track of animation:



You can see the different track names across the left.  The blue dots represent each key frame in the animation.  There is one final change we have to make.  Drop down the icon to the right of the animation track and change the type to Continuous, like so:



Now when you press play, you should see:



Playing Your Animation


While your animation appears properly if you press Play in the AnimationPlayer interface, if you press Play on your game, nothing happens.  Why is this?


Well simply put, you need to start your animation.  There are two approaches to starting an animation.


Play Animation Automatically

You can set the animation to play automatically.  This means when the animation player is created it will automatically start the selected animation.  You can toggle if an animation will play automatically using this icon in the Animation Player controls.



Play an Animation Using Code

Of course, AnimationPlayer also has a programmatic interface.  The following code can be used from the scene root to play an animation:

extends Node

func _ready():


Scripting the AnimationPlayer


Say you want to add a bit of logic to your keyframed animation…  with AnimationPlayer you have a couple options we can explore.


First there are the events that are built into the AnimationPlayer itself:


For simple actions like running a script when an animation changes or ends, using AnimationPlayer connections should be more than enough.


What about if you wanted to execute some code as part of your animation sequence?  Well that is possible too.  In your Animation editor window, click the Tracks button to add a new animation track:



Select Add Call Func Track:



Another track will appear in your animation.  Click the green + to add a new keyframe.



Now left click and drag the new key to about the halfway (1 second) mark.  Switch to edit mode by clicking the pen over a dot icon, then click your keyframe to edit it.  In the name field enter halfway.  This is the name of the method we are going to call:



Add a method to your root scene named halfway:

extends Node

func _ready():

func halfway():
   print("Halfway there")


When the keyframe is hit, the halfway method will be called.  Adding more function calls is as simple as adding more keys, or complete Call Func tracks.  As you may have noticed in the video above, you have the ability to pass parameters to the called function:



Finally, you can also access animations, tracks and even keys directly using code.  The following example changes the destination of our pos track.  This script was attached to the AnimationPlayer object:

extends AnimationPlayer

func _ready():
   var animation = self.get_animation("walkcycle")


Now when you run the code you should see:



The Video

Programming , , ,

blog comments powered by Disqus

Month List


What's different between versions?

Home > Design >

25. April 2011


So, in its relatively short lifespan Android has seen a 1.0, 1.5, 1.6, 2.0/2.1, 2.2, 2.3 and most recently 3.0 release.  As a developer, you need to decided which of these to target and which of these to ignore.  In many ways, if you are using Unity or another engine it makes the decision easier, as they set a minimum level and abstract away the details in their own code.  For the record, the minimum Android version supported by Unity is 2.0.


One of the most obvious factors in deciding what version to support is market penetration.  Luckily, Google provides such information.  This chart shows the OS version of devices that have connected to the market in the past 14 days.


Hmmm, pretty simple really when you look at it.  Support Android 2.1 and higher and you are good to go.


From a developer perspective this is pretty true too.  There were vast numbers of changes between 1.5 and 1.6, things you would think would be a no brainer like multi resolution support, but due to such small market numbers in the first place, I think we can simply ignore 1.5 and earlier.  Trust me, they aren’t worth developing for.

Android 2.0/2.1

From a game developer perspective Android 2.0 really isn’t all that different from Android 1.6 but there are a few giant gotchas, not to mention the various “undocumented” features.

First off, due to a move towards virtual buttons, HOME, MENU, BACK and SEARCH buttons now execute on key up, instead of down.  These little changes cause all kinds of nightmares moving between platform versions.

Perhaps of the most importance to game developers, MotionEvent can now report multiple simultaneous touches ( aka, multitouch ).  Also, if you are using the NDK ( C native code ), OpenGL ES 2.0 is now supported.

Really, that’s about it.  There are other changes of course, support for bluetooth 2.1 profiles, better thumbnail generation, etc… but to a game programmer, not much else of consequence changed between 1.6 and 2.0.


Android 2.2

This was the big daddy of all updates.  First of all, they enabled JIT in the Dalvik VM, resulting in 2x-5x performance increase CPUwise over Android 2.1.  Personally, I never experienced anywhere near that level of increase, but the improvement in speed is extremely noticeable.  So first and foremost, your code is going to be faster running on Android 2.2.  If CPU bound, in some cases then, your code is going to be MUCH faster on Android 2.2.

Besides enabling JIT there were a number of other changes of note to a game developer.  One exceedingly big one is the ability for Apps to install to SD card instead of into the devices memory.

Perhaps biggest of all is that OpenGL ES 2.0 support is now available to Java based apps.  The media framework also gained a few new abilities that are quite useful, like the ability to detect the completion of a sound loading in a SoundPool.

That’s about it, but then again… a massive increase in speed, the ability to load to an SD card and OpenGL 2.0 ES support…  that’s a pretty substantial upgrade.


Android 2.3

Android 2.3 is one of the first versions that actually looked at gaming as a priority.  They improved the garbage collector to minimize pauses, which are killer to immersion.  Nothing like having a 30fps shooter slow to a crawl because the garbage collector kicked in.  They also increased the performance of touch and keyboard events and used a 3rd party OpenGL ES video driver to increase 3D performance.

In the feature perhaps most called for, they implemented OpenSL ES for native audio support.  Up until 2.3, audio support has been at best weak on Android.  Now expect to see a lot of audio applications from the iPhone show up on Android because frankly until now, they were impossible to implement.

For the very few games that require it, if you want to use a front facing camera, Android 2.3 is where support was added.  Also added support for a slew of new sensors to enable Wii-esque actions, if of course the device has said sensors installed.

Really, in the end, the audio changes are the main event in the 2.3 release.

Unless of course you are doing Native Development using the NDK.  If that’s the case, this release was huge.  Until 2.3, you basically used the NDK to develop libraries that you called from a Java code.  All your UI and event management code had to be done in Java.  With 2.3, they added the NativeActivity class which pretty much allows you to work 100% in NDK/C++ code and kiss java goodbye. 

This should result in a performance improvement and make porting to Android easier.  My question is, will it fragment the market even more?


Android 3.0

And this brings us to the most current release as of writing, 3.0.  3.0 was mostly about adding tablet and tablet UI support to Android, but from a developers perspective there were a few new additions that are handy.  Lets go with the biggy first, Android 3.0 is the first OS release to support multicore processors.  So I suppose you want to target that shiny new Tegra2, 3.0 is where you are going.

They also added new animation support, but that’s not really animation support in a way that a game developer would care, that’s more for flying bouncing windows and other annoying and overly abused eye candy.

They did however add hardware acceleration for 3D graphics.  I am kind of surprised it took this long, but is definitely a welcome feature.

They also added something called Renderscript, which due to my ignorance may or may not be of use to game developers.  I really need to look into it further, but for now I will let Tim Bray @ Google explain it.

Renderscript is a new API targeted at high-performance 3D rendering and compute operations. The goal of Renderscript is to bring a lower level, higher performance API to Android developers. The target audience is the set of developers looking to maximize the performance of their applications and are comfortable working closer to the metal to achieve this. It provides the developer three primary tools: A simple 3D rendering API on top of hardware acceleration, a developer friendly compute API similar to CUDA, and a familiar language in C99.

Renderscript has been used in the creation of the new visually-rich YouTube and Books apps. It is the API used in the live wallpapers shipping with the first Honeycomb tablets.

The performance gain comes from executing native code on the device. However, unlike the existing NDK, this solution is cross-platform. The development language for Renderscript is C99 with extensions, which is compiled to a device-agnostic intermediate format during the development process and placed into the application package. When the app is run, the scripts are compiled to machine code and optimized on the device. This eliminates the problem of needing to target a specific machine architecture during the development process.

Renderscript is not intended to replace the existing high-level rendering APIs or languages on the platform. The target use is for performance-critical code segments where the needs exceed the abilities of the existing APIs.

When I get the chance I will look into this Renderscript a bit closer, but it does sound interesting.  3.0 is such a niche of installed devices however that it really isn’t a feasible minimum level to target at this point.



So in summary, 1.5 and earlier are so ancient and decrepit you are just as well as ignoring them.  1.6 is pretty much the “core” of the current API, but a large portion of the 1.6 install base will be running on old hardware where the resolutions simply may not be worth supporting ( like 320x480 ) in a game, so this generation may be skippable on that merit alone.  Multi-touch and ES2.0 native support are the big draw to 2.0/2.1, while 2.2 offered a fair number of advantages.  Simply put, 2.3 and 3.0 currently don’t have a big enough install base to bother supporting as your minimum target.

Therefore, and this is purely opinion, if I were starting a game today… which I suppose I am, I would look at 2.0 as my baseline target unless I really needed one of the new features or the performance gains that 2.2 offers.  Luckily in my case, the developers at Unity already came to the same conclusion I have.

One last word of warning.  In my brief time working with Android, I found version bugs to be a major pain in the ass, especially in code dealing with media.  I had code that wouldn’t work in the emulator, that would only work in the emulator, that would work in 1.6, and 2.2 but not in 2.1.  Put simply, Google have done a pretty terrible job at times in the forward/backward support category.  With your code, make sure you test on as many devices and as many OS versions as you can.  This single handedly is the reason I am not developing directly for Android any more.  I spent more time, by a large magnitude, dealing with crap like this than I actually did developing.  Of course, your mileage may vary!


blog comments powered by Disqus

Month List