Our 12th app, Jack and the Beanstalk, was released at the end of January, and I thought I’d share some of the design and art development of the project with you.
In the beginning
We had decided that Jack was going to be our next fairytale adventure. We’ve focused on fairytales for our biggest apps as they are well known and well loved stories and that gives us a little more exposure in the App Store, which is never a bad thing.
The first thing we did was churn through ideas. Noting down the ones we thought would fit into the story and most importantly be fun. That’s another thing about using traditional stories; they can take a certain amount of alteration and tweaking without breaking and it’s very important to us that the gaming elements we have become part of the story and are not just bolted on for the sake of it.
As the pages of post-its grew bigger, I started to filter them; things that were directly to do with the story and stuff that was more “engine level”, like adding shadows on characters.
We wanted Jack to have a element of non-linearity in it, so depending on how a child read/played you’d get a slightly different story. We looked at what locations we could have inside the castle and what activities would be fun and what features of the devices we could make use of. Having lots of characters to meet was also important to push the story forward.
Direct Interaction
Something we had learned from the previous fairytale app (Little Red Riding Hood) was that direct interaction with the story resonated with children interacting with the world inside the iPad rather than acting through a character; we wanted you to chop down the beanstalk at the end!
Keep it simple, stupid
Another part of this design process was to always trying to simplify things. Which is easier said than done. I try to look at it like you should be able to explain, in a single sentence how something is going to work. If you can’t do that then it might still be too complicated, or you don’t understand it yourself. So … for us, the plan with the castle was to have Jack earn keys by helping other characters he meets. For every two characters you help, you get to unlock one of the giant’s treasure rooms and get a chance to steal the treasure back. If you wake him, then it’s a chase back down the beanstalk. The end of the story changes depending on the amount treasure you managed to get back.
Lesson – Simplify! At the beginning of a project you never think you’ve got enough, then at the end you look back on this massive thing you’ve made.
Prototyping
I made good use of an app called POP-Prototyping on Paper which lets you take photos on your iPod then link them using hot boxes. It’s easy to use and you’re able to get a feel of how the story fits together before any code or art assets were started.
Lesson – Understand how you think the thing is going to work then try and find the problems early. You can’t plan everything, but you need somewhere to start.
Illustrating away
My usual way of working is to doodle on paper, then bring those into Photoshop and cut and paste the bits I like and redraw the parts I don’t until I get the look I’m after. Then, I colour it all in.
I take my sketches and understanding of how the games are going to work and fit the background art to that. Something I’ve learned is to let the design of the game dictate what’s needed rather than draw something wonderful that fails to leave room for the characters, or has so much going on in the background that it’s hard to see what’s what.
I put all the artwork together so you get a sense of how everything fits as a whole, and to ensure it’s all looks consistent. When I was happy with the flat art, I took it all to pieces and arranged it onto textures ready to use in the building of the 3D environments.
Lesson – don’t overwork the art. If I spend too long trying to make things perfect, I end up losing the special something that was in the original sketches.
3D or not 3D
The environments where the story takes place have always had this depth to them, like theatre sets in many ways, built from layered meshes. Something we wanted to try with Jack was to introduce more 3D into the scenes. The reasons for this were two-fold. Firstly we wanted to show that we could have more 3D without compromising the picture-book-like illustration look of the story. Secondly, having proper 3D meshes rather than the pseudo-3D billboards makes moving characters around the scenes and drawing them more robust. Both of these things are important if we want to continue to develop the kind of play ideas we want to do in the stories.
The biggest scene where 3D was going to be used more was the castle halls where Jack explores and unlocks doors to the different parts of the story. Early on I did a test model to show that using the artwork in this way would look okay and also iron out any problems that working like this highlighted.
Something else I wanted to do this time round was to use some computer generated art in the story. Luckily Jack is a story that has high cloud potential, so I got to work with Maya’s fluid rendering tech and made some really, rather nice, clouds.
And the beanstalk itself was a good candidate for a bit of 3D-ness too.I kept the meshes very simple and you end up with something that looks a bit like you’ve built it from folded card.
I think one worry of using the solid meshes is that they would look odd against the illustrated art, but I think that once it’s all together it looks fine. And when you add the rendered clouds, you get a very nice looking finished scene.
Most of the other 3D sets are quite primitive really, though places like the kitchen and the well room had a bit more 3D than others; the pot of stew on the stove needed to be solid enough so you could stir it nicely with the spoon.
And in the well room, you’re fishing for the frog prince’s lost golden ball, so the scene needed to be deep enough to have a dark dingy bottom to the well.
To save memory and keep our apps compatible with as many older devices as possible, we try and reuse textures where we can, for example some of the outside scenes have the same background elements used again and again and vertex colour is applied quite a bit too, to add some variety. We even managed to get some ambient occlusion in the main castle hall.
Lesson – Find ways to make repetitive tasks go away. We do a lot of this, especially in Maya. Things like model exporting, shader creation and automatic UV mapping are all things that can be sped up using scripts. AJ does the bulk of this and tends to use python now.
Characters and Animation
When the 2D character illustration was ready, it’s split up onto textures and brought into Maya so it can be mapped onto meshes and then be animated. We have quite a simple animation rig, nothing too complicated; IK on arms and a bit of stretchy IK on the legs and lots of driven keys. Sometimes we use dynamic curves; for example, on the beanstalk, to make the leaves shake when you chop it down.
Once each animation is done, they are baked to TRAX clips and imported into the character model, and we end up with a single asset that has the model and all it’s animation together that is exported to the app.
We use different mouth meshes for when the characters are talking. Typically each character has happy, sad, E, O and M shapes. Sometimes more is required, like with the Giant; he had a lot of joints in his mouth so I could animate his mouth properly when he wasn’t talking.
Iteration, Iteration, Iteration
One great thing about making Jack was the amount of time spent iterating. Nothing beats having something, however rough, that you can play around with and make improvements to over time. It’s not easy, especially with only one engineer, and you have to balance actually getting the thing finished at the same time, but it gives you the freedom to refine and adjust rather than attempt to design it all on paper first and hope it all works okay in the end. Another positive outcome is that often we had ideas whilst prototyping and iterating, like the button game in the dungeon (originally you were going to feed the dragon the right foods to get him to give you the magic key). It’s the best way to work.
Lesson – You can’t design everything at the start. Iterate and improve!
User Testing
We’d been putting the app in front of children whilst building Jack to see how they reacted. I’m an advocate of the let-them-play-and-watch-what-happens kind of user testing. See what players struggle with and watch how they do things. Usually, it’s not how you thought! We fined tuned things like the hits on the axe (kids kept dropping it by swinging it too fast), took out the giant being woken by too much noise (kids make too much noise) and added a tap gesture to making Jack jump (we liked the swipe-to-jump, but most children just kept trying to tap).
The biggest thing we changed was swapping the dragon-in-the-dungeon scene around so the dragon was on the left, because we found that too many children would rest their right hand on the tablet, thus hiding the cell bars and the dragon so they couldn’t see what effect the buttons in the wall were having.
Lesson – Get real players playing as soon as you can. Now, more than ever I want to watch and learn about how kids use the apps we make. Even though I think it’s important you have a good idea at the start about how you think something should be, you have be ready to revise that thinking if all your feedback tells you otherwise.
Bug fixing.
We use good old pen and paper and Bughost to log and track bugs and we typically find and fix about 600 bugs per app. Luckily for us all our apps share the same code base so over the last three years the stability of the apps has got better and better.
For Jack, I think we had forgotten how many bugs you can get when you let the player move around an environment. Up until now this hadn’t really been a problem, but with Jack, you could walk him around, move the camera, and have him run up and down stairs. All this happening at once resulted in Jack sometimes getting stuck on the stairs or the camera freezing; two bugs that took a while to repro, then fix.
Lesson – it’s time consuming but vital and you’ve got to do it on multiple devices and you’ve got to try and play in a way that tries to break things; is too easy to go through the game in a predictable way. Find outside testers; we used our children for this job!
The End
One of the last things we did was shoot the trailer for Jack. This time round we wanted something short and snappy. We ended up on AJ’s kitchen worktop, with a length of lining paper and his Dad’s fancy camera.
I think we did a good job, though you can’t underestimate how long it takes to get half-decent video; either the reflections are too visible, or you forget to take your watch off, or the iPad would fall over. We spent a couple of mornings getting what we hoped was enough footage, then I cut the trailer together in iMovie. Cheap and cheerful!
Lesson – Use the best camera you can get your hands on, find somewhere with loads of natural light and use a retina iPad. Shoot more than you think you need and just double check everything’s in focus and framed properly!
The End
And I think that’s covers about everything. We had a few last minute requests from Apple for artwork for the App Store (which is always nice) and Jack went on sale on the 30th January and it’s onto our next story…
Jack and the Beanstalk is available on the App Store now – if you enjoy the app, please consider leaving a review! If you’d like to stay up-to-date with all our upcoming apps, you can sign up to our Apps Mailing List here.
