Daniel Hooper

Codebook is a programming environment for javascript, written in javascript. It updates the running program in realtime each time the user makes edits. This technique lets you can see bugs appear as you write them. 

There have been several implementations of Bret's idea since his talk went viral, however mine is unique in that it is the only 3rd party implementation I am aware of that has the canvas inspection feature. This feature highlights the line of code responsible for drawing the element your mouse is hovering over. You can try it out by clicking the inspect button and hovering over the canvas. It's not the ideal UI for the feature, but, hey, I made this in less than 24 hours. 

I  put a lot of effort into making Codebook work for animated projects, such as games or moving art pieces, like the default code you see when you start Codebook. The big problem with this lies in the fact that variables, like as player position, change during runtime and recompiling would reset the variable back to its default value. To the user this would appear as if everything were jumping around the screen as they typed. The solution to this is to cache variable state before recompiling and then reinstate the values after the code has been compiled. It can be tricky to detect which variables to cache since Javascript's variables are created in the global namespace by default. I haven't seen any other implementations besides Bret's that do this; please let me know in the comments if there are others.

The Switch

Given that I wanted to release Percepto 2.0 in the spring, I wasn't sure Maya would let me work fast enough. I started to play around with Blender's rigging tools. Blender Guru's Introduction to Rigging got me started. The tools were similar enough to Maya's that I wasn't completely relearning. The mirror weights and bones tools worked like a charm and the automatic weight generation got me 90% of the way there (1). I loved Blender so much that I opted to use it for my whole 3D workflow.

Modeling

I had three goals for the character: I wanted them to look young, roughly fill out a cube and have a unique silhouette – I was able to converge on a solution by simply scaling various body parts until I found something I liked. I don't have a formal education in character design, so this was much faster than sketching. You can see the progression from tough-guy to the big headed child I ended up shipping.

Export Scripting

The choice to switch wasn't just about the rigging tools, it was the scripting interface. Since I'd have to write a script to export Percepto's proprietary file format, the scripting capability was a really significant decision point. What I saw of Maya's Mel I didn't like. I wasn't a fan of the syntax; the different between ` and ' is impossible to see. I've always loved the elegance of Python's syntax and I wanted to use Blender just for Python (2).

I had 9 animations for the character, each in an action. In order for my export script to work I placed all the actions on the NLA timeline. I used frame markers to indicate to the script what frame each animation started. The name of the marker was the frame rate I wanted the animation to use. I could've created a UI to enter this information, but the frame marker trick was much faster.

Because I had a two Blender files for the game (One for the character and the other for the game elements) I ran into the problem of the export scripts getting out of date when I changed it in one. So rather than embed the scripts in each blend file, I dynamically loaded and ran the external script:

filename = "/Users/daniel/Code/iOS/Percepto/modelExport3.py" exec(compile(open(filename).read(), filename, 'exec'))

Granted, Blender isn't flawless. The scripting API was hard to learn and hard to find resources about. The documentation isn't helpful when you don't even know where to start, like getting the coordinates of vertices after they've been modified by an armature. It was frustrating that the API mirrored the UI (3). That means since the UI is model, scripting was modal: certain functionality wouldn't work unless you switched modes. This was very frustrating.

You can check out my export script on GitHub. Let me know if you'd like the matching Obj-C import code.

More than just 3D

Once I had my workflow set up and most of the resources made, I started to branch out in the ways that I used Blender. It started with the icon. I wanted to feature the room and the 3D nature of the game; I already had the room "modeled" (It's a cube folks) and textured so I fired off a test render:

I liked it! I tweaked it a bit and then brought it into Photoshop for the final touches. This is the icon that shipped:

I ended up with a similar process for the loading screen. I wanted to try rendering with Cycles since that's the cool new toy. I ended up with a really noisy image; It was partially due to my impatience, partially Cycle's current noise issues. Since I was on a tight schedule, my solution was to blur the noise into oblivion. While technically not ideal, I think it contributes to the sleeping aesthetic I wanted. The thought bubble was added later in photoshop.

Let me know if you have any more questions in the comments, or hit me up on twitter: @danielchooper.

1. Maya has similar functionality, but the bottom line is I could work faster in blender, for whatever the reason.

2. Yes, you can script Maya with Python, but resources about that are scarce