Our latest book is available now: the iOS Swift Game Development Cookbook has all the recipes you need to make amazing iOS games. All you need is some Swift (and a little Objective-C) knowledge. Grab it now! (also on Amazon!)
We had a total blast at Unite Australia today in Melbourne. It's the first time that Unite has been run in Australia, and the Unity team was clearly really excited to be here. While much of the content was stuff thats already been announced at the main Unite conference, the Australian satellite conference was a great opportunity to get info straight from the developers.
The big announcement at the keynote was the availability of the first public beta of Unity 5. Unity 5 is looking huge, and is packed with very cool features and improvements to the workflow. One of the most interesting things, from our largely technical-artist-focused perspective, is the inclusion of an incremental workflow for global illumination. Global illumination makes for some fantastic looking scenes, but the main drawback has always been the problem of waiting for the system to finish baking the lights when you make a change.
Another huge new feature mentioned in the keynote is a brand new audio mixing system. This system is extremely configurable, and easy to tie into the scripting system. It looks like sound designers are going to have a much easier time designing really immersive environments, and we can't wait to get to play with it.
The single biggest new feature, our opinion, is already available. The new GUI system, which has been long-promised and became available in the betas of 4.6. The new GUI has to solve a lot of different problems, and be applicable on both desktop, mobile and console environments; additionally, the fact that there are a billion and one different screen resolutions out there can make a UI designer's life distinctly unpleasant. We're particularly taken with their approach to scaling UIs to meet this problem: design everything based on a "reference resolution", like 800x600, and give the system a fuzzy hint that it should try to prefer to preserve the width or height when the aspect ratio changes.
Another great new feature that's landing with Unity 5.0 is the WebGL deployment target. WebGL has become a lot more available over the last few years, and a plugin free method of getting games into the browser is totally awesome. We spent some time going through benchmarks, and the performance looks great. Expect web-based demos from us, and may other game developers, in the future.
Things mostly wrapped up with a session on the future roadmap of Unity. The biggest takeaway that we got was their intent to make a larger number of their high-level features available as open source libraries. Both the new GUI layer and the new networking system are intended to go open source, and the team on stage made it very clear that this was a pattern that they plan to follow for more features.
We're really looking forward to playing with the 5.0 beta, and can't wait to pull it apart for inclusion into our upcoming O'Reilly Media book, Mobile Game Development with Unity. The next few months are going to be a lot of fun. Follow us here, and on Twitter @thesecretlab for updates.
Our new book is finally out, in early release unedited ebook form! Today Swift Development with Cocoa was released by O'Reilly Media.
We're really proud of this book (which we wrote with our friend and frequent collaborator Tim Nugent), and now's a great time to grab it – O'Reilly is running a 50% off promotion on all the great new iOS 8-related books until 5AM PDT on 25 September 24!
The code samples for Swift Development with Cocoa are available on GitHub too, if you'd like to play with some Swift.
While you're at it, check out our friend Tony Gray's new book, Swift Pocket Reference – Secret Lab wouldn't exist without his encouragement and support, and he's written a damn fine pocket reference for Swift!
Stay tuned for more books, as well as the final release of these Swift books. Let us know if you have any comments on the early release editions!
This is the third in a trilogy of posts about animation basics by Rex Smeal, animator, and friend to cephalopod and amphibia alike.
Welcome back! If you haven’t read the first and second parts of our animation basics trilogy, you should check it out! This third article is about Spatial Distortion!
Spatial Distortion
Distorting objects to accentuate their motion is something that animators have been playing around with since before they were animators – painters, comicbook artists, even sculptors to a lesser degree have all distorted reality to give a greater impression of motion. Speedlines, blurs, extreme perspective, stretching, various repeating-image techniques. Some of these transfer well to animation, others tend to get in the way.
Blurring
Blurring occurs in the “real world” when something is moving fast through a photograph exposure (or frame of film) and light reflects off of it into the camera through a range of motion, rather than creating a single image. Remember those oldschool cameras where people were asked to sit still for a minute? That was to avoid blurring across a much longer exposure.
Of course, in animation we don’t have to worry so much about this happening by accident, but it can be a useful technique for avoiding obvious afterimages (see Part 1: Spacing) and creating a greater sense of speed. Blurring can be slight, or the entire object can vanish into a dramatic blur until it slows down! The important thing to remember is that blurs will make everything smudgy if used too often, over too great an area, or on objects moving too slowly, and will not blend well with certain graphic styles. They can also be processor expensive if generated procedurally.
Smearing
Smearing is a kind of deliberately symbolised blur, and in many cases looks much cleaner where a blur would be out of place. For example, if there are a lot of high-contrast areas, as in a kid’s cartoon, or on simple interfaces, a blur will be a strange smudge in a world of hard lines and contrasting colours. So the various techniques of smearing help maintain visual style while performing much the same function as a blur would otherwise.
Smearing has become a bit of an art form in itself, decades of economising children’s animation led to all sorts of interesting methods for cheap motion that didn’t require many complex drawings.
Squash/Stretch
This is perhaps the most well-known animation technique, Squash and Stretch, put simply, is the distortion of an object to reflect forces being applied to it (which would normally be invisible/too fast to see). If you imagine a bouncing rubber ball’s motion broken down:
- Moving quickly through the air, it’s sides taper against air resistance.
- As it hits the floor, all the parts of the ball want to keep moving forward so the sides of the ball distort flat to push themselves up against the surface – this is obviously dependant on the angle of impact.
- The elasticity of the ball cause it to snap back into shape as Newton’s third law forces the ball from the floor at near-equal speed to it’s arrival, which means we almost immediately regain the elongated look, though now rising instead of falling.
- As the ball rises, gravity reduces its velocity, and the air resistance against it decreases; so the ball returns to it’s natural shape, only to repeat the process as passes the bounce’s apex and falls anew.
Without a slight squash/stretch effect during fast motion, your objects will appear rigid and lifeless (sometimes a desirable effect), but too much squash/stretch and they’ll appear cartoony or overly bouncy. Getting the perfect level of distortion actually makes objects appear to move more realistically!
General Advice
The techniques outlined in our Animation Basics trilogy are really just the very top layer of what is possible when you’re creating motion, particularly in the digital realm. They provide a starting point for many basic effects, but they can and should be combined, modified, used across three dimensions rather than two, even actively ignored or opposed. So long as you’re thinking about what you’re doing, about physics in the real world as they apply to gravity and momentum, and learning from failed experiments, there’s no end to the complexity of motion you can explore.
Finally, I’ll leave you with an old rule amongst artists (and animators in particular) that goes something like:
“If it looks right, it is right, even if it’s wrong.”
And the inverse of that might be:
“If it looks wrong, make it look right, even if you have to break the rules to do it.”
So the trick is not to look for hard and fast rules in animation, instead look at your result, and make judgements on your next step to take based on how it feels to you- because that’s how it’ll feel to your viewers/users.
Miscellaneous
“What framespeed should I use?”
It depends. There are a lot of factors to consider. 24fps is traditional disney animation speed- but that’s for animating complex figures, and is usually performed by teams of full-time animators. With the invention of procedural animation techniques like tweening, you should be able to apply most of these techniques smoothly to even something crazy like 200fps very easily. As a general rule, anything around 30fps will be much smoother and less likely to leave afterimages, but depending on how you’re making your animation, and what sort of device you’re displaying it on, it may not be economical or practical to work at this speed!
“I’m a developer making interfaces, do i really need to take these techniques into account? Will people even notice them?”
People will notice if they’re missing. Two apps on the subject of pizza restaurants perform the same task with similar graphics, but one moves through it’s frames with the squashing and stretching motion of strands of mozzarella cheese? It’s a distinct advantage.
“I’m a developer, and this was interesting, but I don’t think Disney will be hiring me just yet. What can I do myself/in-house, and what should I hire a dedicated animator for?”
Assuming the programming knowhow is present, with a little practice and experimentation (literally an hour or two of messing around), the techniques in this blog can be effectively applied to simple interface components and very simple objects like falling rocks or bouncing balls at a passable level by anyone. But for characters, handdrawn animation, complex elements like flags, water and fire, explosions, lightning, complex composite objects, depicting weight, emotions, reactions, and for making unique interfaces that move with real flair- and animating all of these well: requires a kind of mental library of natural motion, as well as an experienced animator’s eye for mistakes and improvements. Someone without a few years on the clock won’t be able to make complex animation move well.
“Okay, so I need an animator. What should I look for in my new hire?”
Ideally, as usual for any position, you want to see referrals from previous clients and examples of relevant work, but if you want something weird, that might not always be possible. Most animation students are more interested in character animation than interfaces or other “inanimate” elements- and particularly in terms of developing software, often you may be better off seeking out a graphic designer who dabbles in animation than a “traditional animation” school-trained Animator.
“I’ve decided that I want to be an expert animator, but I’ve no idea where to start. What’s next for me?”
If you’re lucky enough to live near a good animation school (the quality of which you will learn by contacting previous students about the courses there, and remember to ask to see examples of their work)- that’s your next port of call. If not, you’ll be joining me in a never-ending self-taught quest to study and replicate the natural motion of the world. Animators love dissecting each other’s work, and there’s no shortage of amateur critical analysis communities online. If all else fails, let Richard William’s ‘Animator’s Survival Kit’ be your guiding star!
Jargon
Spacing: The placement of frames throughout a set (or open) timeframe, usually between defined keyframes. This can be thought of as animation at the micro level.
Timing: Choosing timeframes for objects, particularly choices in terms of different objects interacting throughout time. This can be thought of as animation planning, defining constraints for spacing.
Easing: Spacing that favours smooth transitions from a keyframe- Usually expressed as slowing into a key, or slowing out of a key.
Frame: A single image or exposure- will be displayed for a predetermined time based on framespeed, which is expressed in the number of frames per second (fps).
Keyframe: An “important” frame usually with a specified time- The start and end positions of an object’s animation might be considered keyframes. Additionally, if an object must move from A to C through B- there might be keyframes at A, B and C, with inbetweens (see below) between them. Defining keyframes first as a Timing element can simplify the inbetweening process.
Inbetween: The frames that sit between keyframes- their placement is known as “Spacing”.
Tweening/A Tween: A software assisted technique for placing inbetweens- will often allow for automation of some basic spacing techniques such as easing in or out.
Cycle: A sequence of animation that repeats the motion of an object seamlessly.
Loop: A sequence of animation that repeats.
Further Reading
We just finished another fantastic week at OSCON 2014 – this was our fourth year attending and speaking at O'Reilly's Open Source Convention, and we (as usual) had an absolutely amazing time. It's rapidly becoming one of our favourite conferences.
We presented twice at OSCON this year: a session version of our How Do I Game Design? workshop, and our three-hour Android-focused mobile design tutorial (along with Chris Neugebauer, as usual).
The slides for How Do I Game Design? are available now on Speaker Deck. Interesting and related links for attendees are:
- Squire, 2006. From Content to Context: Videogames as Designed Experience
- Schell, 2008. The Art of Game Design
- LeBlanc, Hunicke and Zubek, 2004: MDA: A Formal Approach to Game Design and Game Research
- Koster, 2004. A Theory of Fun for Game Design
- Game Definitions: gamedefinitions.com
- 8KindsOfFun – Marc LeBlanc: 8kindsoffun.com
The games we mentioned in the talk are:
The slides for our mobile design tutorial Unfortunately Design Tutorial Has Stopped ... and other ways to infuriate people with mobile apps are available now on Speaker Deck. Interesting and related links for attendees are:
- Google's Creative Vision for Android
- Google's Material Design
- Google's Company Philosophy
- Action Bar Icon Pack
Please don't hesitate to get in touch if you have any questions!
Some quick thoughts from Secret Lab on the mind-blowing collection of WWDC 2014 announcements from Apple.
OS X Yosemite
Pretty! Made simpler. Not super sold on translucency, though.
Handoffs and Continuity is awesome. Will be super useful. Devs get access to this too. Reminds us of the excellent “Send to Chrome” feature in Android. Only really polished.
iOS 8
Not a huge amount of new stuff, visuals wise; however, there are some awesome behind the scenes changes.
Custom Actions, Photo Editing, Sharing Options can all be provided by apps. You can make your app provide services to other apps. This is AWESOME - it’s going to make the app ecosystem quite a bit richer.
Android’s had this for some time, and it’s great to see it in iOS.
The ability to put widgets in the notification center is also great, lots of devs are going to make some great stuff with this.
Being able to share documents between apps without having to copy them is going to be Super Nifty. This has been a real weakness of iOS until now.
Swift
WOW. Apple developed an entire language, wrote all the docs, and wrote all the supporting tools for it, without it leaking. This is really impressive.Can’t wait to use this.
The language is very modern. Its syntax feels like a mashup of Python, Haskell and Ruby.
Interoperation with Obj-C is rather nicely handled. They’ve directly translated ObjC’s arguments-are-embedded-into-method names approach into named parameters. The goal was clearly to make it as painless as possible to work with both languages in a single project.
Something that’s interesting is it’s completely opposed to Objective-C’s way of doing things is that, while ObjC allows sending messages to nil (thereby making it safe to not have to do null checks), Swift instead guarantees that all values that are not Optionals are non-null. Optionals are a very cool feature: in other languages, the concept of “nothing” is usually represented by a special value (for example, Lua’s ‘nil’ value), or by convention (for example, in C, the value 0 means ‘nothing’). This creates its own problems; if you use a special value, comparing it to other objects means you have to do type conversions, and if you instead use the convention of zero meaning null, you have to do checks. Objective-C goes some of the way towards helping with this: it defines ‘nil’ as a special value that’s represented a zero pointer, but calling methods on it is safe because the runtime automatically returns if it notices you’re trying to call methods on nil.
This is nicer than crashing, but it can lead to problems, since if an object you’re trying to work with is unexpectedly nil, you’ll get bugs. Not crashing bugs, but weird behaviour bugs.
The Optionals system is nicer. In Swift, a value is either guaranteed to be a valid one, or else is explicitly known to sometimes be nil.
For example: if you’re converting strings to integers, your code looks like this:
let theString = "123" let theInt = theString.toInt()
In most languages, the ‘toInt()’ method would return a value that represents ‘not valid’, such as 0. But in Swift, it returns an optional int - that is, a value that MIGHT represent nothing, but if it doesn’t represent nothing, then it’s GUARANTEED to be an integer and nothing else.
This makes things quite a bit safer, since the compiler’s able to do more checking, and is able to reason about your code better.
Swift is filled with this kind of thing. Another example: in C and similar langauges, the assignment operator (=) returns a value, like this:
a = b = 3 // sets both a and b to 3
In Swift, that doesn’t apply. This means that the following is actually a compiler error (it’s just a warning in ObjC):
if x = y { … }
We’re not huge fans of the range operators: a...b means “range from a to b, including b” and a..b means “range from a to b, not including b”. Notice that they only differ by a single period. That’s going to lead to bugs, due to typos.
The mutability of variables depends on whether or not the variable is declared as a constant or not. This is nicer than Objective-C, which has two different classes for each type based on whether it’s mutable or not (ie NSString vs NSMutableString)
This only applies to strings, arrays, dictionaries, and other low-level things. We’re still going to be stuck with NSURL vs NSMutableURL for a while.
Playground is super cool. Reminds us of IPython, in that you can figure out your code without it having to be run inside a larger app. This is going to make development a lot faster.
App Store
Being able to show videos and make app bundles (with discount) is going to be neat. Not a huge game changer for us, but any increase in app store functionality is good.