1. A window into a coordinate system plane populated by “objects”…
2. that smoothly moves through it by remapping how its borders map to that underlying plane…
3. and loads the objects to be displayed as they are needed, while keeping memory requirements in check.

So let’s explain how to do that with Core Animation, and as a bonus we will do parallax scrolling, talk about some graphic optimizations, and show you flying cupcakes.

Recycling

Point 3 above requires some explanation. The last thing you want to do in the middle of your game loop is allocate memory, since it will totally kill performance. We also need to use the minimum amount of memory possible, since iOS devices don’t have much. To do just that we initialize the tiles that make up our background at the beginning of the game. We will use a separate CALayer for each tile and put them in an array. How many do you need?

Example of scrolling to the right.

In this image the red line is the view in the screen, slowly moving over a grid of tiles making up the world (grey lines). Only the blue and green tiles are in memory at any time though. We used as many as needed to cover the whole screen, plus a 1-tile wide border around the whole thing so we always have tiles under our view during the scroll (depending on the scrolling speed you may need more than 1).

When the view scrolls to a point where it needs to show more tiles to continue, the farthest tiles (in green) are moved to the required new position, and their contents recalculated by looking up in the world map what graphic tile goes with that position (or similar). If you have ever used UITableViews and dequeueReusableCellWithIdentifier:, is the same concept but in two dimensions instead of just one.

No Core Animation

If our game was an infinite scroller, say something like Jetpack Joyride, we could use Core Animation to create a CABasicAnimation at the beginning of the game, set a speed, and let it run indefinitely. The problem is that, as I explained in the latest article, getting notifications when the tiles need to be refreshed is not easy. But usually you will need more control over the scrolling anyway, modifying its direction or speed according to user interaction, events during play like the player dying or being stuck on an obstacle, difficulty increasing with time, etc. What we need is a more traditional game loop, in which at every frame we can modify the view position in the world.

That’s a basic CADisplayLink loop, except for the CATransaction part. Since we don’t want any of those pesky implicit animations when we change the properties of the CALayers, we wrap everything into a transaction and disable them. This has two side-effects though.

First the positive one. When we need to read the current state of a layer, say its position, we usually do the following to get what’s on the screen (instead of what an animation started or will end with):

However, since we are skipping animations the changes to properties are way faster, so after the transaction is committed we will have the same value in the layer properties than what we see on the screen. Ergo, we can do this instead.

Why is this any good? Every time you call presentationLayer a new copy of the layer is created. Every time you call that method, a new object is allocated¹ and returned. And as we said before, allocating memory mid-loop is a Very Bad Thing™. That’s why in other cases, when you really need to use the presentation layer, it is probably better you do this…

rather than this:

The second side-effect is not that good. When Core Animation is in charge it runs its calculations and updates properties on a different thread, then it shows the results on the screen at the next screen refresh. This, unless you run lots of simultaneous animations or other calculations, gives you a smooth 60 Hz refresh rate. But by making changes to layer properties by hand we are basically bypassing all that. The CADisplayLayer will call your code at a multiple of the refresh rate on the main thread (again, unless you are limited by other calculations). Then you will update the properties of the layers, but is not until the [CATransaction commit] that those numbers actually change in the presentation layer or the private render-tree. The next time around the runloop, whenever that happens, the new values should be visible, but they still may need to wait for the screen to refresh. When before we had a smooth 60Hz animation now we are limited by the CADisplayLink’s frameInterval, and by whatever else we are doing on the main thread. Performance is going to suffer because we are fighting, rather than using, Core Animation. Why use Core Animation at all then? I guess I will have to talk about that in the next article in the series.

Apple Land of Flying Cupcakes

Now that we know what we are doing, why we are doing it, and what are the consequences, let‘s jump into some sample code. We are going to be modeling the following:

Don’t know what I had for breakfast the day I drew this :/

We have, from front to back:

1. A floor of dirt with grass.
2. Some yellow blocks, in a repeating pattern for the example.
3. Some kind of robot head.
4. Apple-shaped hills.
5. Clouds.
6. A flying cupcake.
7. And the sky.

Of all those only the apples, blocks, and grass are going to be separate tiled layers moving at different speeds. The sky is just a fixed background, and since they are more like individual elements, we will deal with the clouds, cupcake, and robot head later.

We are going to create a CALayer subclass to take care of all our tiling needs. You can check the MCParallaxLayer class in the sample code at the end of the article. As part of its initialization we pass the size (in points) of the tiles (they need to be all the same size). Then we can calculate how many tiles we need like this:

So each tile (the ones in memory, the blue ones in the diagram), is a separate CALayer that we save in an array. We need enough tiles to cover the whole bounds of our MCParallaxLayer plus one more at each side. If we make this layer the size of our view, we would be covering the whole thing (what you will do for the terrain of an RPG, for example). But if we make it smaller that our view we can restrict the drawing area and save some memory. For example, instead of needing this many tiles for our yellow blocks…

…we only need this many doing it this way. Notice how, since we are never going to scroll vertically (horizontal == YES), we are not creating extra rows of tiles on top and bottom.

Once we have allocated memory for our array of tiles we need to initialize them:

We just allocate and initialize some CALayers, set their size, the anchor point to make them easier to position, and assign the image atlas. Then we add them as a child of our MCParallaxLayer. Notice there are two things missing there: we are not setting the correct position of each tile, and we are not setting the contentsRect (that would identify what part of the atlas to show).

Scrolling and Blurry Pixels

There are a couple things I added to MCParallaxLayer to make things a bit easier. The first one is the TileCoords type, to measure position in tiles (integers) instead of points (floats). A couple methods convert between CGPoints and TileCoords and back using the tileSize.

The second is a provider, that works as kind of a delegate supplying what section of the atlas to draw for a specific tile coordinate. Usually it will be an object that has access to the level’s layout, and can answer questions like ‘what do I draw in tile (13, 24)?’. In our sample code, we are just using the view controller as the provider for all our layers.

So with that said, this is how we calculate the position and contentsRect of the initial tiles.

How do we scroll then? The same way CAScrollLayer does, by changing the bounds of the MCParallaxLayer. We have to do it carefully though.

What’s with all thosee floorf() and scrollLeftovers? The thing is if we just add any decimal amount to the bounds position, the tiles will not be rendered aligned to pixels. They will be antialiased, and performance will suffer (there is a reason the Core Animation Instrument has an option to warn you about ‘Misaligned Images’). So the floorf() helps with that. But what happens if, for example, we scroll 0.6 points every frame. If we don’t keep track of the remainder we will be scrolling 0 pixels every frame! So that’s why we do, so 2 frames moving 0.6 actually scrolls 1 point.

You may have noticed that I keep talking about points, not pixels. This method could actually be improved to take into account double resolution devices like the iPhone 4, since those would actually accept scrolling in half points (half a point * 2 point per pixel = 1 pixel). The truth is those are some really small pixels and, at least for me, the difference is minimal.

Recycling Implemented

This is already running really long, so let’s get to the meat of the scrolling, the implementation of the recycling method shown in the first figure. Almost the most important question is, where do we implement this? What gets called every time we change the layer’s bounds even when needsDisplayOnBoundsChange is NO? Since we have all our tiles as sublayers, layoutSublayers does.

The code is pretty self explanatory. We figure out what are the tile coordinates of our most upper left tile by checking the bounds origin and if we are only scrolling horizontally. Then we compare it with the previous value, that we had stored in the prevOriginTileCoords ivar. If the coordinates are the same, we don’t need to recycle anything yet, so we return.

If the coordinates are not the same, we find what row and/or column is going to be recycled. Then we loop through all our tiles (since at this point they can be in the array in any order), and we move each one that matches an affected column and/or row to the other side of grid; horizontally for matching columns, vertically for matching rows. Then we ask our provider for the new section of our atlas (contentsRect) for the new tile coordinate. That’s it. Tiled layer with infinite scrolling without spending extra memory.

Odds and Ends

So what do we need to extend this and make it into a parallax scrolling example? Not much. Basically we can create multiple MCParallaxLayers with different tile sizes and images, add them all to the same view, and then scroll them at different speeds. To make things easier, I just added a multiplier ivar to use in the first lines of the scrollTiles: method.

So what about the clouds, and the rest? The three clouds are not the same size, and there is lots of blank space in-between, so they don’t really fit our MCParallaxLayer. The thing is our class is still a normal CALayer, so we can add individual sublayers to them and they will scroll along with the rest when we change its bounds. Check the sample code to see how we use that for the clouds, the robot head, and the flying cupcake.

Opaque or not Opaque

The moment you start to pile layers one on top of another, performance is going to take a hit, specially so if they have transparent or translucent pixels that need to be combined. That’s why UIViews and CALayers have the opaque property, so you can signal UIKit that it is OK to forget about what’s underneath, because you are covering that whole section of the screen.

What I didn’t knew though, is that the opaque property is completely ignored if the image being rendered has an alpha channel (like, you know, if you have that Transparency checkbox checked when exporting PNGs from Photoshop), even if all the pixels inside the layer are actually solid. That’s the reason the sample code uses two different atlases, one with an alpha channel for clouds, the robot head or the grass, the other one without for the sky or the apples. This improves performance a tad, so remember to use solid images whenever possible.

¹ To be honest, I don’t know if it is allocated or it comes from a pool or what happens behind the scenes. A new object is initialized and returned each time, so the advice still stands.

But not today. Today you are so smug you are fogging the windows, because an hour ago your email pinged and you were happy to read that ‘Your Application is now In Review’. So happy indeed that you had to make sexy Fiona, Lion’s Scottish Standard English voice (and the only girl you have talked with for weeks), read the whole damn thing, including the legal text, 2 or 3 times. How long has this latest endeavor taken anyway? It was an update after all, not even a whole new game!

Casey’s Contraptions came out for iPad only in May. Since then, you and your partner in crime have been working on making it run on the iPhone. That’s 3 months for those of you counting. So what has taken this long? Wasn’t it a straight port? Lots of shared code? Just shrink the images and go? Well…

Reducing the Number of Choices

People nowadays are not that much into reading, and to tell the truth, I had to create a whole support group just to get myself in the mood of writing, so let’s just cut to the chase and show you some graphic examples (click on the iPad screens to see them at full resolution):

Casey’s Contraptions Main Menu on the iPad.

Casey’s Contraptions Main Menu from the iPad, reduced to iPhone size.

So that’s not looking so bad… oh wait, I forgot to show you the finger. Sorry about that.

Oops. And that’s a small hand right there.

So not so great. The thing is on the iPad screen there are plenty of actions that the user can take, but they are all big, spread out, and graphically different enough, that they don’t compete with each other (too much) for the user’s attention. Let’s count how many actions are possible in this screen. The user can:

1. Play the Classroom tutorial levels.
2. Play the Backyard levels.
3. Play the Bedroom levels.
4. Play the new Tree House levels.
5. Go to the Sandbox.
6. Scroll the locations to have better access to the Sandbox, Tree House, and beyond.
7. Open the credits screen.
8. Check the game news.
9. Or open the game settings.

When we cram all that info into a smaller space, we are changing the mood from a relaxed exploration of possibilities, to a much more stressful one of trying to identify what is what. But really, how do we get rid of options here? Everything seems pretty much necessary, unless we rearrange screens and put access to the credits in some other place. Guess what? Doing that we will just be cramming some other screen, and I can tell you they are already as busy as the main menu.

There is one thing we can do though. The normal action for a user on this screen is to continue playing where he left. If he is playing the Classroom levels, that’s the button that should be more prominent, in the middle of the screen. You should still be able to scroll to the other locations, and with a paged scroll view they can all snap to the middle of the screen as you do it. We just converted those five first actions in our list to only one. The result:

Sizing issues

An iPad’s screen is 1024×768 pixels, or a ratio of 4:3. An iPhone 3GS is 480×320, and an iPhone 4 is double that or 960×640. That’s a screen ratio of 3:2. So to make the iPad game area fit the iPhone screen we needed to either fit it vertically and have vertical bands on the sides, or horizontally and crop top and/or bottom. Luckily for us not all the screen is used in the game when the simulation is running; there is a nice chunk underneath the floor level that is just decorative.

The red line represents what we can show in the iPhone when fitting the location background to the width of the screen.

That was convenient… but what goes there on the iPad again? Ah yes, the toolbox with all the items you get to solve each level!

Yeah, I think we may need that…

Noel already wrote about all the details that went into implementing a retractable toolbox, something that seems easy enough until you try to use it and implement it. The result looks like this:

Closed…

…and open.

What happens when you get an object, let’s say the soccer ball, out of the toolbox? The toolbox not only closes so you have access to the bottom of the screen, all the buttons fade out while you drag the object so you have a clear view of the whole play area.

Details, details…

Too many fingers

On the iPad we use gestures that feel pretty natural for interacting with the objects. You can drag them, double-tap to flip them, and rotate them with 2 fingers. Rotating was the gesture that gave us the most trouble on the iPad; we went through many refinements to take into account how different people put the fingers on the screen. On the iPhone, as Noel has said more than once before, you need to make your game playable with just your thumbs, even only with one hand. But unless you have evolved more fingers than the average person, holding the phone and rotating with 2 fingers of the same hand is going to be tricky.

As a staunch supporter of direct manipulation in games I was totally against selection widgets, those things with buttons that appear around an object and that you tap or drag to interact with it indirectly, on the iPad. Rotation on the iPhone was a different beast though, so this is what happens when you either tap, or finish dragging an object.

By touching anywhere in the blue arrows (that rock back and forth in the game) you can rotate the object with only one finger. Does that mean we got rid of all 2-finger gestures? No, we needed one that everybody is going to try when they see how small the 8-balls are on that screen!

Just like a Mazda Miata.

About Features

We put lots of effort into having the iPhone version of Casey be as feature-full as the iPad one. One of the things we talked about removing from the very beginning was the level editor, but as you can see in the screenshots above that finally made it! Yes, is nicer on the bigger screen of the iPad; but you will be surprised how well the editor works even in the small screen.

The only feature that didn’t actually made the cut was another case of too many options in the screen. Take a look:

The multiple player profiles were one of the most requested features from families with kids (mind you, not because the kids wanted it, but because the parents didn’t wanted to play through the already unlocked levels of their mentally superior offspring. But when trying to pack all this info into the iPhone it became apparent we would need to divide it into multiple screens and create some kind of navigation between them. Then we realized iPhones and iPods are a more personal item. Is far more common for a family to have only one iPad, and multiple iPods, than to share an iPhone between everybody. So we got rid of it, and the result is a simplified Settings screen.

Many other screens had to be divided in two though, and I was not too happy about that at first. Take a look at the sandbox menu, for example:

One, …

… two.

But at the end it helped make things more clear. Again, less options on each screen means less confusion. And the nice sliding animations between them help know what’s going on.

Anyway, I am sure you are sick of reading all the ridiculous details, so that’s it. It took 3 months, but we are sure the result will shine. Look for it on the App Store in a couple weeks!

Have I then decided to finally get rid of iDev? Not at all. I am excited to announce a new phase for it has started that will hopefully boldly bring iDevBlogADay where no BlogADay has gone before… well, except for AltDevBlogADay, whose awesomeness we are going to shameless copy as much as necessary.

To that effect, I have created an iDevAuthors Google Group where we are currently discussing the upcoming changes. You should join if you want to write for iDevBlogADay in the future (and yes, that includes current iDev authors and people in the waiting list; if you don’t join the group, you will be skipped when we roll out the changes).

Some of the proposed changes are:

• No waiting list. We divide everybody in the normal 2 weeks, so we will have as many posts per day as necessary instead of just two.
• Since there is no waiting list, we will not kick out anybody, even if they forget to post in their day. We will still remove anybody that continuously skips his turn though.
• More information about each author.
• Archive of past posts, and search.

If you have additional ideas you want to see, and want to help making it happen, join the Google Group. Cheers!

In any case what better way to talk about the last 5 months than to do a quick recap of my old list of evil projects.

The Ones That Got Done

You are looking at one of the projects that I got (kind of) done: the new design for the site.

In case you are wondering how it used to be, here you have a couple screenshots:

There were a few things I wanted to attain with the redesign, but the important ones were improving readability (too many people complained about the white text on dark background), and featuring the multiple apps and projects I am involved in. That it took me this long to have a site that actually supports multiple projects just goes to show how confident I was on finishing more than one.

In any case, I made it live today with some parts missing. I will be adding stuff as time passes and, even through is not my turn in #iDevBlogADay, I mean to write more often in this blog; maybe I should go for the old ‘every Wednesday’.

Of course the big (and old, since it happened more than a month ago) news is we finished Casey’s Contraptions, it was featured by Apple as Game of the Week across the world on its first week, got fantastic reviews, and shoot up all the way to number 2 in the US apps chart. Some articles:

• Games From Within: Casey’s Contraptions on the Media
• Pocket Gamer: The Making of Casey’s Contraptions
• Gamasutra: Postmortem: Llopis & Friginal’s Casey’s Contraptions
• IGN: Casey’s Contraptions Review
• Kill Screen: Review: Casey’s Contraptions

Since then it has maintained a pretty good position in the charts, although sales have slowed down considerably. We have been working on the next version for a while now. The plan is to convert the current iPad-only game into a Universal version, and also sell an iPhone-only cheaper one. Is taking a while since we are recreating each one of the screens so it’s usable on a small screen, and boy, we have lots of UI.

The whole surreal experience of having success in the App Store requires its own post, and Noel also wants me to write about the specific changes we are doing to the iPhone UI, so maybe next week.

The third one that got kind of done is the #iDevBlogADay redesign. Let’s talk briefly about the kind of part.

As you can read here, I changed the rules slightly and made the new design live last February. Since then, I have not touched the site even once, except for adding people to the waiting list. And to tell the truth, I am growing more dissatisfied with its evolution. For one, doing it every 2 weeks doesn’t seem to help with the intended purpose of getting in the habit of writing; lots of people drop from the main list because they forgot about it, and I have read one too many “is going to be short this week because I didn’t have the time” posts.

I have also come to realize the new design is too cold. It was done that way so as to not impose a particular style to the blend of authors and blogs. But after following the #AltDevBlogADay design revisions, I recognize they make a way better job of representing their authors, with photos, bios, links, featured authors, and more.

Problem is I have not even created a basic Join Us form, or even an About page after 5 months. I have not had the time, and I finally didn’t recruit anybody else to help. So not sure what’s next. I think I would like to get closer to the #AltDevBlogADay spirit and support our authors and content better in the future. But maybe is time to point everybody to #AltDevBlogADay and close the doors here. As always, your thoughts on what’s working, what’s not, and how to fix it are very welcomed.

The Ones That Didn’t Get Done

So now for the downers, the other four projects that I did not have time for. iDevTracker, Notedo, and The Legend of Robin Hood received no attention at all. Pretty sad, but lets be serious… didn’t I write before about the reasons things get shelved around here? The first two enter straight into the “boring” category, and the game, although it really pains me, into the “scope creep” one. I should just pay more attention to what I write!

So what’s left? Well, the Elephant Run game! Since the last disgruntled post about Core Animation games I have not touched the prototype again. I still think is a pretty good, small, and doable game idea, so this one is not getting canned for sure. Also I promised to explain how to do a scrolling game with CALayers without wasting memory, I just need to get to it.

More?

You didn’t think I was going to be happy getting rid of projects without adding some more to the queue, did you? Some weekends ago I worked on a quick prototype for a different game after watching The Librarian TV movies and then Raiders of the Lost Ark a couple times back to back. Still no title, but I leave you with a screenshot of what I got done:

As we did with the first version, I decided to make the new design live early, get some feedback, and improve it with your suggestions. Better to have something out, even with imperfections, than to make you wait forever for it, then never release it.

It has been kind of a hectic week. Next week I am attending the Game Developers Conference in San Francisco, a first time for me. It should be fun, and I promise to write about it when I come back. Of course, since I was doing this, I had to get off my ass and design some business cards! Designing something for yourself is always the most difficult thing, but nothing better than a deadline to make it happen. I am pretty happy with how they turned out (thanks Owen for recommending moo.com!).

Noel and I have also been preparing the beta release for Casey’s Contraptions. If you are interested and have an iPad lying around, I think you are still in time; just send Noel a note. To top it off, I got a cold that is making the fan of my computer sound like elephants running around my ears. By the way, one of those nights I could not sleep I also finish the scrolling background for the elephants, including randomly generated tiled paths…

So anyway, that is my excuse in case the whole iDevBlogADay site goes down in flames while I am partying. Why did I have to do it this week??? Heck if I know :) But let me give you the rundown of the changes.

The New Rules

Although I got some pretty good suggestions last week about other possible changes, I finally decided to go with my initial plan. That meant basically two things:

• Each author gets 2 weeks between posts. This means 14 new authors from the waiting list will join starting next week to cover the gap.
• 10 consecutive posts, or 20 weeks, as a limit. Once an author reaches its 10th post, he will be automatically moved to the end of the waiting list, and the first person in the list will take his place.

I was already keeping track of the date each person currently in the main list had started, so counting back I found 4 people had already been longer than 10 posts. I gave them this week to say their goodbyes, and they will be replaced in 2 weeks. Thanks Gareth, Simon, Nicolas and Alfred for being so understanding.

Starting this coming Sunday new authors will have their turn. I already assigned days to the people that were in the top of the waiting list. Check the site to see when is your turn, and if you don’t like it, since you all are starting at the same time, maybe you can trade with some other person. Just let me know.

As a result of all this, we have reduced the waiting list from 60 something to around 45. In just a few weeks there will be more empty spots (mine included!), and even when all this movement is kind of nice we will see if it solves anything at the end. I have been thinking that maybe starting everybody on the same week is a bad idea, especially if nobody drops before their 10 weeks; but I am playing it by ear, we will see how it looks in a couple months.

The New Design

As you can see I changed the horizontal layout to a vertical one. The top of the page will always contain the posts for today, and I ordered the rest in inverse chronological order, so yesterday is just bellow. For each day, apart from the 2 blogs that either wrote or have to write this week, you will also see the 2 that blog in alternating weeks in smaller type over a grey background.

I didn’t find an appropriate place for the usual NEW badge, so instead I just turned the whole title block red. Not too happy with that, so suggestions are welcomed.

For each blog you will also see a bar representing how many posts the author has left to write. The week the bar is full is the last post for that author. The following week, the first person in the waiting list at the time will take its place, although he will not have to write anything until one week later (so you guys will have at least a week notice for sure). I was thinking maybe I should add some kind of email notification, but for now you will have to check the site.

As you can see the design is pretty dry, but legible. Since iDevBlogADay represents a multitude of authors, and I don’t want to impose them any particular style, I suppose is better this way. I didn’t use any fancy javascript this time, so I hope it works in all devices and (modern) browsers without problems.

The Missing Parts

Things that were present in the previous design and are nowhere in this one:

• The list of “Other posts by this author”: I omitted it so you will not have to scroll forever to go to the next day. I am not sure many people used those links, since probably you all use RSS readers and not the site itself. If you guys see the point in having them back, please tell me and I will see if I can fit them there somehow.
• The “about” blurb, and RSS link: I still need to add a page with information about what the site is about, how to use it, how to participate, etc. I am thinking I will add a menu at the top by the logo with these links. Since they were not essential, I probably will not get to that until after I come back from San Francisco.
• The day navigation: the links to jump directly to a certain day didn’t seem as important with the vertical layout. Any opinions?

And stuff still in my to-do list:

• Sign-up page for getting into the waiting list. I am probably going to use Google login for this, no need to create yet another user login system.
• Admin to give up your spot in the main list, move to the end of the waiting list if you are getting towards the top and you are not ready, or remove yourself all together from the list.
• Archive of previous articles. I get this request now and then, so maybe having a searchable archive of posts is a good idea? There is some cases of previous blogs disappearing all together from the internet, but I am not sure I want to duplicate the content of participant blogs if I can avoid it.

I think that’s about it. As always, send me your feedback and ideas about anything you would like changed. Now if you excuse me, I have to get rid of this cold in the next 4 days (BTW, if your doctor ever tells you to sniff salt up your nostrils, take note that 1/4 of a teaspoon is not the same as 1/4 of a tablespoon. Damn abbreviations :)

As you can see the rules cannot be simpler. That’s how it was intended from the beginning, mainly because if there was more rules somebody would have to enforce them. Take for example the “you can write about whatever you want” rule. If it was instead “write about this particular subject”, it could be totally open to interpretation; what is good for me may not be good enough for you. I would then become more of an editor, and iDevBlogADay more of an online publication, with schedules, style guides, and who knows what else. At the end it would be less successful in what it really is all about: to make people write. So it was determined that less rules meant less ways things can be unfair. The “you don’t post, you are out” is the kind of cut-and-dried rule that makes it all work with the least possible friction.

But iDevBlogADay has been evolving. With almost 500 posts under its banner, and more than 60 people waiting their turn, is clear that it cannot go any longer without some changes. And those changes, whether I like it or not, are going to require some new rules.

One of my main concerns has always been the people waiting in line. For starters, the more people on the waiting list, the less attractive it is to join the group. What’s the point if you know is going to take forever for it to be your turn? The system was built thinking a dozen people at most would ever be waiting, and the drop rate was expected to be higher, given everybody involved previous experience.

But there are only 2 ways to get people out of the waiting list: either we have more people writing per day, or we impose a time limit after which posters are automatically rotated.

Time Limits & Other Ways to Get Rid of People

Time limits have been proposed in the past to help increase the drop rate. Sometimes this is proposed as a way to get rid of people whose posts are growing stale, or that don’t contribute interesting posts in general. A similar method proposed a number of times is voting each week for the best/worst posts, and kicking whoever gets the less votes.

The reason I don’t like this much is twofold. First, it totally goes against the main goal. The thing is that goal is all about the writers, not so much about the readers. Yes, iDevBlogADay provides a bigger stage than our individual blogs had to start with (well, with exceptions), and we all strive to give readers reasons to come back. But the same way the rules are not about the subject of what you write, they are not about the quality. This is in some aspects the path of less friction for me; I could try the voting system as a way to not only write more, but also write better. And that’s the other reason I don’t care much for this; implementing and managing it seems like a nightmare. Until now I was glad to leave everything as is and trust the old adage of practice makes perfect.

At the same time, time limits can be a boom, if not for getting rid of writers, at least for getting people out of the waiting list; that is the only reason I am even considering it.

More People Per Day

Having 3 or 4 people per day instead of 2 has also been a constant suggestion. Let’s say we started tomorrow with 4 people per day. That would be 14 more people going from the waiting list into the main list, so only… 49 people will be left in the waiting list. That’s only until more join in, of course. I realize this is not a long-term solution either (I don’t think there is actually one). But what I find more interesting is the other reader complain about this: that would make too many post to read every day!

And on this case I am on the reader’s side. I don’t know about you, but I am not gaining spare hours every day. I am not even able to read all is published in iDevBlogADay right now. I would probably care less about the whole thing if there was even more to read, independent of how good the content.

AltDevBlogADay Solution

The “other” blog a day site doesn’t seem to have any of these problems (or at least I have not seen them voiced). They also work slightly different: every participant gets a turn, and when everybody that signed up has written a post they start over from the beginning. Some people asked me why we don’t use the same system then, but it all goes back to the main reason of the existence of iDevBlogADay. If is all about getting in the habit of writing, you need to do it often. In that sense AltDevBlogADay is more about the content, and less about habit formation.

But their system also got me thinking… is a week a good enough time between posts? What about two weeks instead? I immediately liked this solution because it solved a number of problems.

Take the last post from Chris Adamson before handling over his day to the waiting list as an example:

My original plan for being featured on the iDevBlogADay blogroll was to be able to share some of the work I’m doing on the Core Audio book. I figured that as I worked through new material, that would translate into blog entries that could then get the word out about the book.

Unfortunately, I think what’s happening is that I’ve been working on iDevBlogADay entries instead of working on the book.

The thing is a week is not that much time for having something new worth writing about for somebody whose main job is not writing. It happens to me all the time, wondering what the heck to write about, then having to put away my work to do it! And if I had more time to expend on my work, I probably would get more interesting things to write about, no?

So what would be the consequence of having 2 week periods then?

• For starters, 14 people will get from the waiting list into the main list.
• I would have way more to manage. It doesn’t happen often, but I am doing the whole getting into or off the list manually. I would have 14 more people to check on.
• Given that authors will have two full weeks to write their posts, pressure is off. If drop rates were already low, there would be even less reason for anybody to lose its spot.

Future

The plan I have decided to go with is to have both 2 week periods, and a time limit. The 2 weeks will help with having more people in without having more to read per day, and the time limit will help with making the waiting list move faster. My first thought is the limit will be around 10 posts. That’s 20 weeks, or 5 months per author. We will see if that’s not fast enough.

Having to manage more people also makes my need to implement some automatic tools in the backend even more obviously. On my todo list I have:

• Automatic list handling. If you miss your day or the time limit is up, next person gets your spot, you go to the end of the list. Should have been like that from the very beginning, but since the code was done in a day and has not been touched much since…
• A “how it works” page. I don’t know how many times I have to explain the rules to new people over Twitter.
• A sign-up form. Same thing, getting the info from new authors on Twitter is getting old.
• Multiple admins. It has all been me until now, but I am thinking of recruiting some more individuals that don’t mind solving problems with the site if any appear. If you are a participant with minimal PHP knowledge and don’t mind spending a few minutes now and then (hopefully not many once all the automatic tools are in place), ping me.

Lastly, this also means the new design is not valid anymore. I am probably going to simplify it, get rid of the horizontal scrolling and all the javascript, and have info not only about the 2 authors writing every day, but also about the 2 writing the previous week.

So when? I am planning on next week having the same authors as this one, then introduce the new ones. New authors will start posting then two weeks from now. I will get in contact with whoever is past the time limit too (that may include me now that I think about it). As you can see, the whole thing is a mess of conflicting goals. So my plan for the future may hurt some in favor of others. Hopefully it will all be for the better.

If you have any other ideas, please share.

Screw-up Update #1

To demonstrate once more how on top of my game I am, Mr. Acton points AltDevBlogADay doesn’t work at all as I described! Instead everyone posts every 15 days. The more people they get, the more posts per day. He says:

mike_acton

(Mike Acton)

@mysterycoconut For me (as well), it's about the writers first. The readers can read at any speed they want. It's not live-TV.

On 17-2-2011 04:17:19 from web in reply to Miguel Á. Friginal

He has a point. Maybe we should do that instead.

I still have plenty to do before Friday, so you will have to tune in some other day for part 3 of the Designing Casey’s Contraptions series (if you have not read the previous posts, they are here, and here). While the more artsy readers wait, the coders will have another (small) ration of… Core Animation (I bet you were not expecting it, given the title of the post and everything).

The Story So Far

As you may remember I started working on the Elephant Run game with the intention of doing it all with Core Animation, and so demonstrate what I called Thesis A:

Thesis A: Core Animation is just fine for most 2D games…

But giving the last few weeks, let me present you with Postulate B:

Postulate B: …but you will suffer if you try.

To explain this postulate, I will present you with the latest in layer scrolling! And some other issues. Yes, that’s the noise of my teeth grinding, shut up.

Scrolling is easy! Cannot you just use…

Let’s start by defining what I was looking for:

1. a window into a coordinate system plane populated by objects…
2. that smoothly changes how its borders map to that underlying coordinate system…
3. and loads the objects to be displayed as they are needed, while keeping memory requirements in check.

If you were just idly browsing the documentation, you have probably seen a few CA classes that look pretty promising: there is a CAScrollLayer that looks exactly right, and even a fancy CATiledLayer that can make you think of something like this the first time you read about it:

Sadly, it is actually more like this:

CATiledLayer

What does the documentation say about tiled layers?

CATiledLayer is a subclass of CALayer providing a way to asynchronously provide tiles of the layer’s content, potentially cached at multiple levels of detail.

As more data is required by the renderer, the layer’s drawLayer:inContext: method is called on one or more background threads to supply the drawing operations to fill in one tile of data.

That sounds pretty promising to take care of point 3, and since it lets you create tiles of the content you would say 1 can be covered too.

When you start messing with it though, the first impression is that is slow. Like really slow. You may even notice that slow fade of tiles and think “hey! Is just my old friends, the damn implicit animations trying to make it look cool when what I need is to make it appear NOW! Let’s just disable those pesky animations!”. But I am going to save you the effort by editing the docs for you so they are a bit more useful.

CATiledLayer is a subclass of CALayer providing a way to asynchronously provide tiles of the layer’s content, potentially cached at multiple levels of detail.

As more data is required by the renderer, the layer’s drawLayer:inContext: method is called on one or more background threads to supply the drawing operations to fill in one tile of data.

Don’t ask me why I didn’t see that the first time around. Or the 20th. But anyway, CATiledLayer good for photo galleries and zooming into big images… for games, not so much.

CAScrollLayer

CAScrollLayer has no problems providing both points 1 and 2. To make it work, you create a layer, give it the bounds size of your “window”, then add sublayers to it. The moment you send either scrollToPoint: or scrollToRect: to the scroll layer, its sublayers will scroll by. (Note the layer doesn’t have scroll bars, and will not do a thing when you touch it; you need a UIScrollView for that).

You can also send a scrollPoint: or scrollRectToVisible: to any CALayer, and it will look through its superlayers for a CAScrollLayer to forward these messages to after the proper adjustment of coordinates.

The way CAScrollLayer accomplishes scrolling is pretty straightforward. It just animates changes to its bounds origin (that as we saw in a previous post determines the origin of coordinates for all the sublayers), and by default masks contents to its bounds (maskToBounds property is NO for any other type of layer). To adjust the speed at which the layer scrolls, you can use a transaction to override the duration around your scrolling messages.

All this is great, but point 3 is the tricky one. To be able to add and remove sublayers on the fly, change their contents, or any other dynamic behavior to happen while scrolling, we need notifications. And you see, the bounds property never sends letters while being animated. Instead of a nice “Hey, I am scrolling! I am at (1.0, 1.0)! Now (1.01, 1.0)! Guess what? Now is (1.03, 1.0)!”, it just tells you something like “You want me to go to (20.0, 1.0)? OK, ciao!”. Some properties are just not sociable.

By the way, if you know how to get the bounds to behave, please tell me. But beware, have a running program to show me, because I cannot tell you how many times I was like “this trickery SHOULD do it! It SHOULD work!”, just to find it didn’t.

Anyway, practical solutions to this? Only 2 I can think of. Either scroll in grid sized chunks that allow you to swap pieces at the end of the scrolling, or create your own animatable CGPoint property to take care of the notifications while scrolling (your own properties, as seen previously, can send nice display and drawInContext: messages periodically while animating).

Next Core Animation article I will go about creating a custom scroll layer that does all this, but that will be another day. Until then, don’t be like me and have fun creating games with OpenGL or freaking Cocos2D!

Tools

All the drawings you have seen, from the first sketch I sent Noel to the later interface designs, were created in Adobe Illustrator. Vector graphics allow me to scale assets without losing quality, adjust shapes, and change colors easily. I know plenty of iOS artists use Flash, but I am way more used to the Illustrator tools.

From time to time people ask on Twitter if there are cheaper alternatives to Illustrator. The truth is there is nothing out there that comes even close to the power and flexibility of Adobe’s tools. Since I have to be cheap (life of the indie :P) what I do is not buy every release (I am still using CS3 right now). If you have an old version of their products the upgrade price is usually more affordable. Educational discounts are also really nice if you are a student.

I also use a Wacom tablet, a 6×11″ Intuos 3 I got a while ago and had not seen much use until recently. The usual question I get about buying one of these is how big it needs to be. I feel more comfortable with something around letter size, that allows for some arm movement. There is a world of difference between even the smaller tablets and using the mouse though.

That’s not my arm. My arm is way hairier.
But my Wacom is like that one.

Some people like to sketch first on paper, scan, and then clean up and color with Illustrator or Photoshop. I did that at the beginning, but the more used I get to the Wacom, the easier it is to just start from scratch directly on a blank document on the screen. I still draw doodles on paper any time I can; even if you don’t think you have any artistic abilities, all you really need to get better is lots of practice, and drawing a variety of subjects so you expand your visual vocabulary (by the way, Aaron Diaz’s blog is worth its word count in gold for any aspiring illustrator, bookmark it!).

In Illustrator I use both the Brush and the Pen tools extensively. I have a variety of brushes I created for Casey’s look, but they are all basic calligraphic brushes of different sizes, with size dependent upon how much pressure I exert with the Wacom’s pen.

Normally I use the Brush to draw the outlines, then the Pen to both simplify lines that got too many points and create color areas. I will get to coloring in a bit.

Necessary and Unnecessary Detail

I will show you how I created a RC monster truck this past week. The idea was simple: we needed both a truck and a controller with a button. The 2 objects can be placed separately on the screen. When something hits the button, the truck moves forward.

When creating objects for the game the first thing I usually do, even for the simplest objects, is get some documentation. In the past illustrators used to collect photographs and magazine clippings to use as reference in what they called their morgue file, but as you can imagine Google Images is the way to go nowadays. I try to look for real-world photos of the object in question and select the ones that seem more representative, the ones closer to the “ideal” of the object.

A couple RC monster trucks found with Google Images.

After that I try to divide the object features into 3 groups: the parts that are fundamental to make it recognizable, the parts that are necessary details that make it believable, and the parts that are mere noise. In the case above is clear the giant wheels are the most important part, plus the general shape of the chassis and bed. The door, windows, decals on the side, and the lights add some necessary detail. At first I thought that I could also include the springs used for the suspension, and the motor and cables underneath, but all that ended up being unnecessary.

Yep, that looks like the bare minimum for a truck.
Soccer ball is there for size comparison.

When I have difficulties deciding what parts of the object are important and what ones are not, I look for how other illustrators have drawn the object in question. I am looking for a stereotyped version of the object in this case, so the most simplified the style the better. That way I can see what is the minimum needed to make something still recognizable.

As you can see above I do a really quick sketch to begin with. I am only looking for the right shapes and sizes. I try to make the drawing as close to the size is going to show in the game as possible. The scale is by no means exact; if it was, our tennis ball would be almost half the size, and lets not talk about the pinball or the scissors! They would be way too small for any practical use. So, as happens in comics, I am just looking for close enough to be believable.

Then I start adding some of the details. You can see below I try to use thiner lines for the interior of the object and a thicker outline for the outside. This makes shapes less jumbled.

After showing Noel this draft we decided the bed needed to be bigger so we could put stuff inside, not on top. The truck should also be able to tow stuff, so it was missing an attachment point in the back. I made some changes to the shape to get a bigger bed, open on the back so it was easier to insert objects there; I figured I could add a rope hook later for the attachment point.

Wheels, Step by Step

As the wheels seem the most important part of the object, I started with those. Nothing fancy, just a couple circles, taking a bit more care of line widths this time. I draw the circles by hand, so they didn’t look too perfect. Since this object is going to rotate in the game, big differences from a perfect circle are quite obvious, but I think small ones give it a bit more character.

Then, looking at my sample photos, I saw how important the tire tread pattern was to the overall feeling, so I draw a simple shape for it and duplicated it a few times. I kept looking at this at 100%; I didn’t wanted too many lines making it a confusing mess. I think I got just enough there to convey the shape without it looking too messy.

The pattern is three dimensional, so I added some extra shapes to obscure parts of the white circle creating that effect. At 100% this is only a couple pixel difference, so you can say it is unnecessary. However without it the wheel looked way too perfect, so they stayed. This is the kind of little detail I like to add to make shapes more realistic, but I try not to overdo it.

Next I added the center of the wheel. I liked the yellow wheels of the toy truck on this photo I found, so I decided to go with a similar color motive. Notice though that what I draw as a dark blue line is going to be light yellow color, and the space in between the lines is going to be the darker holes; it was just easier to draw the separating lines than to draw the pizza shapes in between.

Color

That was looking pretty good, so I started adding color. If you have ever painted miniatures, this is basically the same.

You start with a base color. My advice is to always use the HSB (hue, saturation, brightness) selector in the color palette, and not go crazy with saturated colors. Everybody’s first impulse is to use nice bright saturated colors for everything. But then nothing can be made to stand out, because everything is visually yelling at you! There are so many nice colors with low saturations that you are missing out if you don’t use them. The color of the tire here is a mere 14% saturation, and even the bright yellow is 70%; it just looks brighter cause of the surrounding color.

Something I have found really useful when choosing colors is sampling them from real photographs. Just get them in Photoshop and sample the wide variety of colors that make up the image. Even on the parts where you only notice bright saturated reds, you will find multitude of less intrusive colors.

Why isn’t the tire black instead of this weird violet? Same reason. Black and white are the most powerful colors. Their intensity is stronger than even the most saturated reds, so you need to reserve them for when you really need them. I could have used a gray for the wheel instead, but the lack of color would still draw too much attention when staged with everything else in the game.

After the base color, I add shadows to the parts of the wheel that recede, so we gain a bit of depth. This are drawn normally with the Pen so I can control better the position of each point, and moved behind the outlines but in front of the base color. In this particular case I was not too worried about the direction the light comes from, since the wheel is going to be moving pretty fast most of the time.

Usually I just decrement the brightness of the base color (not too much!), and maybe adjust the hue a little bit so the colors mix harmoniously (e.g., here I moved the darker yellow a bit more towards the orange).

Finally I add the highlights. Although I try to keep things logical, I don’t really worry too much about shadows or highlights not being in the correct place for a specific light source. You will notice that even in the truck body they are mere approximations. You have to play with it and see how you like it, but the secret again is not to overdo it. The moment that something looks good enough, I stop.

Other details (or lack thereof)

The process for creating the truck body was more or less the same. You can see the steps I went through in the animated GIF below.

I did try to draw more detail under the chassis and have those cables, the motor, and the springs as shown in some of the photographs, but it soon became apparent that at 100% it was just becoming a mess of lines that didn’t add anything to the design. At the end I just added some simple shadows and call it good.

For the highlights I used white this time to get that metallic shine look, and I even add a few darker lines to the brake lights, and some translucency to the window. At that point I considered it done and I posted it to Twitter in case I had forgotten something (the more eyes the better). Just a couple minutes passed before Craig from Little White Bear reminded me I was missing the antenna! And of course, I was also missing the hook for tying the rope so I added both. All in all, a pretty simple design, that looks pretty good in game.

That’s basically how I do it for Casey’s Contraptions. As you can see, is not that complicated. Different games and graphics styles will need a different approach, but I hope this helps you in your own process. As always, feel free to ask if you have any questions!

Today I wanted to review a few of my own “failed” designs for Casey’s Contraptions. And I quote failed because these are a normal byproduct of development; to know what works, you need to create, analyze, and finally discard lots of things that don’t. Discarding is hard, but is also going to help me explaining another pet peeve of mine: the widely accepted concept that design is all about the looks. You will notice that some of the discarded designs are prettier than the final ones, and I will try to explain why they were still a failure.

A final disclaimer: Casey’s Contraptions is still pretty much in development. Whenever I say “final”, read it as “current” :)

Theme

Noel and I started talking about collaborating back in August last year. After some iPhone tech prototypes Noel had decided to go iPad-only to start with, and had a specific setting for the game: a 10-year old kid making these crazy machines to do things kids care about; open the cookie jar, reach for the pie on the top shelf, break the piggie bank, etc. He had been asking a number of artists to try drawing a few of the game objects, but he was not entirely happy with the results. He wanted something very distinctive, that you could look at and say “Oh, that’s a screen from Casey’s Contraptions!”.

The moment I heard the theme I started thinking cartoony characters, but cartoons cover a wide range of styles. On one side of the spectrum we had the totally crazy Warner Bros. style, or the misshaped objects and expressionist perspectives of Maniac Mansion, Day of the Tentacle. On the other the more realistic looking Sunday strips, like Peanuts, or Calvin & Hobbes, with suburban landscapes and mostly realistic depictions of everyday objects.

We talked for a bit about this; the first style would give us more freedom to introduce weird objects; anything from TNT to shrinking ray guns would feel at home. But it also would have complicated gameplay by introducing cartoon physics, and way more unpredictability for the player when things started squishing and stretching, etc.

So we decided for the later; objects could still be slightly deformed, lines didn’t need to be totally straight, but we were not getting too crazy. Something like this image from Calvin and Hobbes was my goal.

Some advice for designers of any kind: the more you know about a project and what is expected of you, the better the result. Never start without enough information. If you are not sure about something, ask. Is not going to upset your client/partner that you show interest in their product. And all this going back and forth with Noel not only helped me create an appropriate theme for the game, it also helped him better define what he wanted to make.

Casey

This was my first try at a few game objects. At first I was just going to draw a few objects, but then decided to try sketching Casey too (at that time he didn’t even had a name).

The objects were solid (that soccer ball even appears in the final game almost untouched!), and the general style of colored outlines, flat colors, and simple shades was set. Casey didn’t feel right though. He looked too much like an anime character, and way too naive and lacking personality. I didn’t want a modern Japanese-style cartoon, but one more grounded in the 50s, the golden age of American animated cartoons.

After quite a few tries, I started getting into something I liked better, with more of a Hanna-Barbera style.

Notice my ridiculous annotations to remember how to draw it?

The more I draw him, the more of a personality it started to show. He was a hands-on smart geeky kid. And all those contraptions to get to cookie jars and pies had result in a bit of a belly.

I reused the pencil from a previous sketch there. Don’t trash anything!
Spent some time deciding if I wanted 6 or 8 fingers too. Is that his mom?

Fonts

One of the first things I got into after the character design was deciding on fonts. You see, I love typography. The difference between using the default fonts or the freely available ones in any platform, and using professional fonts is like… well, like this.

Arial to the left, Sqweash to the right. Difference? $20

Quality fonts are not expensive taking into account how much they influence the style of your game. You can find single-user licenses for as low as $20. Take into account that those licenses don’t allow you to include the font file as part of your binary, only to use it in textures or static images (yes, this includes texture atlases with all the glyphs at a certain size; but rendering non-monospaced fonts is not easy if you have to implement all the metrics from scratch). Although you should contact each foundry, you can assume a license to include a font in your binary and let UIFont render it for you, will be around 10 times as expensive as a normal one.

After choosing fonts, I worked a bit on a logo, then on the first drafts for a level selection screen. You will notice that all these pieces were of no relevance to getting content into the game itself. I attacked them first to build on the theme and get a better sense of where we were heading.

Don’t use fonts in your logo you use anywhere else, it cheapens it.

Every piece you add changes how you perceive the game, even if is not gameplay related, and every part has to pull in the same direction. Some people like to leave this for last, add it as the last layer of cream on the pie, because having final art too soon kills opportunities for experimentation. On the other side, having all these can strengthen your initial concept, let you discover what is important and focus on it.

Location Screen

From the beginning we wanted levels separated into different locations. This was the first try at creating a level selection menu (click the screenshots to see them full size). You can see there is not much worth saving there: the colors are kind of depressing, and my first idea of having all the locations in the same screen scrolling vertically, with rows of levels that scrolled individually in the horizontal was pretty confusing.

I did like the outlined titles though, and the thumbnails with details of the levels, and you will see I maintained both in later designs.

Second try was more in line with the theme, with brighter colors. Each location got its own screen, and I decided to style them as a page in a sticker book that you complete as you solve the levels (in this screen all the stickers are the same piggy bank image just because I was lazy). You can see here we were already working on having stars representing degrees of success for each level. The blue info buttons didn’t pass the first beta tests: nobody ever understood they were actual 2 things you could touch, the center of the sticker to enter the level, and the “i” to get info about the level without entering. It was confusing cause of the overlapping hot-areas, but also because of something that has haunted me for the whole process: making interface elements stand on their own without blending with their surroundings. You will see more of this later.

This was the level info screen that the “i” button opened (it was supposed to be the back of the level stamp, and we were going to transition to it with a fancy animation from the previous screen). The plan was to have all this information about goals, how your friends had done in that level, and if they had shared any solutions, that you could check before loading the level itself.

When we got rid of the blue “i”, we had to put this info in different places inside the level itself. My assumption was that it was better to check all this info before deciding if you wanted to play the level, but tests showed that people just liked to see the level at full size, and since it opens instantly (no “loading” progress bars) and you can exit at any moment, there was no catch.

There are other interesting things in this screen I decided to reuse later: the white outlines that appear around different elements, the first use of a normal looking capsule button, the green background colors, the tape and shadows in the thumbnail pics… You can also see something we didn’t changed until way later: three different goals for each level, each giving different amounts of stars.

Level Intro

That simple thing, three goals per level, gave me lots of trouble. When you first start a level, you were supposed to get a short blurb by Casey of what to do, but also the level title, and what extra goals you can complete to get 2 and 3 stars. I hated this screen because it was so plain, so I tried to make it more interesting.

To the right is one I particularly liked. But you see, I was trying to solve the wrong problem. I tried to add more stuff to it (the item rewarded for the sandbox if you finished the level, your current star rating…), and make elements bigger and more attractive. But people would either dismiss this screen as fast as possible so they could see the level, then wondered what they were supposed to do, or get confused about the multiple goals, or always try to go for the quite complicated 3-star goal without even considering the simpler ones.

What we needed here was not to get fancy, but being straightforward. To the left is the final iteration: title, goal, and you can see almost the whole level, without even the translucent yellow overlay.

That of course also pushed the two other goal descriptions some other place. We figured we could have a menu inside the level with a screen showing these, and that of course caused more trouble. But since this post is already running long, you will have to wait for part 2 to know how we solved that one :)

As always, feel free to ask any questions in the comments below or on Twitter!

I also finished the design of the “Goal Completed” screen! This is a big one for me, mainly because the damn thing has changed so many times during the life of the project I got like a dozen different designs archived! That may require its own post, but here is the final one (as of this week):

Since obviously I am not involved in enough projects already, I decided to promote yet another Twitter community project: #iSketchADay is an original idea by Craig Sharpe (the artistic half of Retro Dreamer) to promote more doodling. Join with your own sketches on the Twittverse.

I also continued working on Evil Project #7. After some more Twitter voting it even got a name: Elephant Run!. Owen‘s suggestion, “Elephant Run: A Banana Bonanza” was my favorite by far.

Head Over Heels

In the few hours I could spend on this I got the elephant sprite to walk. You may think this was solved last week, but there was a little problem with the previous sprite: the head and the body were stuck together in the same graphic, making it impossible to swing the trunk in the direction of the bait while walking.

After a few tweaks in Illustrator I ended up with this:

Now I just needed to position the trunk with respect to the body so the whole thing moved together. Since the body was already one of my sprite layers, the idea was to make the trunk a sublayer of it. That guarantees that moving the body would make the trunk follow. If only it had been that easy…

Origin of Space

Just a few lines later I had my first WTF.

Let me explain you what’s going on there.

My main problem was that each of the frames in my animation had a different size, so every frame the sprite bounds where changing (red rectangle). The bounds change with respect to the layer’s position, that by default is in the center (the point in the center of the red rectangle that doesn’t move).

Now, the easy way out of this was to just make all the frames the same size. But there are two things on this diagram I wanted to talk about first.

How a layer’s content draws around its position

The reason the bounds grow out from the center point is because of the layer’s anchorPoint property. You can check the docs here for a long explanation of what the anchorPoint represents. But basically is a CGPoint in the range {0.0, 0.0}-{1.0, 1.0} that indicates where inside the bounds rectangle the layer’s position is. Or in this case the other way around, how the bounds (and the layer’s content) are drawn with respect to the position point. The default value is {0.5, 0.5}, and that’s the reason our red rectangle above grows a few pixels both on the top and the bottom when its size changes. If we change it, this is what will happen:

Anchor point at {0.5, 0} on the left with bounds growing down, {0.5, 1} on the right with bounds growing up.

As you can see neither option will help with our original problem; the one on the left creates a gap between the body and the trunk, and the one on the right inserts the trunk further than necessary into the body.

How a layer is positioned with respect to its superlayer

The question is, why the position vector of the trunk (the blue arrow) starts where it does? I was half expecting it to go from the body’s anchor point, to the trunk’s anchor point, but instead it starts in the upper left corner of the body’s bounds. Can we change that point, start in a more convenient place?

The answer is yes. This line in the documentation tip me off:

The bounds property is a CGRect that provides the size of the layer (bounds.size) and the origin (bounds.origin). The bounds origin is used as the origin of the graphics context when you override a layer’s drawing methods

As I show you last week when changing the bounds of the layer I was setting them like this:

If you change the bounds.origin the origin of coordinates for all its sublayers change to that point. For some reason, negative numbers (in points) move it right and down, so doing this…

…and changing the anchor points for the head to waggle, finally got me here:

Origin of Time

After that I decided to embark in another easy one: have different speeds for your elephant. I am going for just 3 speeds in the game, slow, normal, and fast, plus completely stopped (with some idle animation). For now I was just going to run the animation I have at different speeds (later on I will probably create different images for each, so I can give a bit more personality to running like crazy vs trotting vs pacing around).

Both CALayer and CAAnimation objects depend on the Media Timing Protocol for time related tasks. You can set duration for your animations, how many times they repeat, or if they autoreverse through properties in this protocol, and yes, there is even a speed property.

The thing is, as with the spatial properties the time properties are also organized hierarchically. This means that changing the speed of the elephant’s body would also change the speed of any other animations applied to its sublayers. Say we set the body’s animation speed to 2; animations applied to the trunk will proceed now at double the frame rate! Even worse, if we set the speed to 0, the trunk will not be able to move at all. I could apply the inverse speed to all the layer’s children, but since we will eventually end with the rider, bananas in the baskets, bait, and who knows what else, that can get messy fast.

So the plan was to create a new animation each time there was a speed change; same parameters except for the duration, that would depend on the required speed.

A couple minutes later I had my second WTF.

This time the problem was that recreating the animation was resetting it, so each time I changed speeds it started from the first frame, instead of continuing along with whatever frame was next. Note also that at the moment the animation stops, we only know what frame we are in (through our sampleIndex property), but not if we were going towards the next frame or towards the previous.

How long since the animation started?

There are 2 properties in the Media Timing Protocol that allow us to start an animation not from the beginning, but some time into it: beginTime and timeOffset. The main difference between them is that the first one is scaled to the timespace of the animation’s layer, and the second one is not. What does that mean? Remember our animation is part of that time hierarchy created by the differences between the layers’ speeds. 4 seconds in beginTime applied to a layer with speed 2 is equal to 2 seconds in timeOffset.

What I needed to do was:

1. Calculate how long the animation had been running by substracting the current time from the time when it started (dt).
2. Create the new animation with the new duration.
3. Set beginTime so the new animation starts in the same relative point (dt * newDuration / previousDuration).

So how do I know when the animation started without keeping track of it on my own. A non-documented fact about the beginTime property is that if you don’t set it to something different, it is internally populated with the animation start time timestamp.

Remember though that beginTime is scaled by the time hierarchy, so some transformation is required. At least the Media Timing Protocol gives us methods to do this; by passing nil as the 2nd parameter to convertTime:fromLayer: and convertTime:toLayer: you can convert to and from the layer’s timeframe to the standard one.

Notice we also subtract the timeOffset from the starting time (without converting, since timeOffset is not scaled). If the offset is used, it needs to be taken into account.

Finally we can set the new animation beginTime, making sure to set it to a timestamp for the code above to continue working:

As I said at the beginning not much progress overall, but at least it helped me understand a bit better how everything works together. Hope it is helpful to you too!