A Lot Can Happen in Two Years

This post is my first attempt to reflect on the whole process of making it. As I often say in the Lean into Art podcasts, the process of reflection carries with it so much value.  We learn from the process of doing but also from the process of reflection.  Much of the story of This Panda is in my notes here and there, in my Day One journal, source control commits, task tracking, change log, and my brain-noggin. Now it’ll be in my blog too.

What follows is my attempt to capture the essence of the development process,  a little bit of why I made some of the choices I made, and how I went about crafting the game.This post is also about the life I’ve lived while making the game. It’s context for when I look back and ask “how the hell did making this game take me two years?”

Let’s start there.

Got a new job.

At the beginning of This Panda I was working for a design agency.  Within a few weeks of starting the game development I learned about an intriguing and exciting job that combined most all of my interests. Even with this exciting new game project on my plate in the evenings (it’s a side project after all) I decided to pursue the new job and I’m still there.

Father of my second daughter

My wife and I both feel super fortunate to be parents. We wanted a second child which we didn’t think would happen, and had come close to giving up. Then to our surprise mid-way through my first summer working on This Panda, it did happen - my wife became pregnant and here we are now with a 5 year old and a 1 year old.

Juggling Side-Projects

Working on This Panda was only one of many side-projects that I worked on through the past two years.  Of course not all projects are juggle-able, finished, or successful. I have some neglected Arduinos, Raspberry Pi’s, and a barely used soldering iron for proof.

Some that did turn out to be juggle-able:

• I Published a book + open source game learning project called Game Construction Kit: Underwater Tomato Ninja Edition.

• I continued podcasting: Lean Into Art, Extra Lean, and the Polytechnicast.

• I joined the UXPA, volunteered and was selected to be a UX mentor.

• I stayed active on the speaking circuit, giving talks at events such as Kids Read Comics, The Society of Concurrent Product Development, Agile Day Twin Cities, UX Professionals Association of Minnesota, among others.

• And finally, I did a number of art challenges: 30 Characters in 30 Days, Art Soundoff, and Lean Into Art Quests.

Two Years Ago, The Beginning of the Project

At the beginning of making This Panda Needs You I had just wrapped up a big teaching project, a class on Web Design for the FAIR School at MCAD. I was really as hoping to land another teaching assignment, this time about making video games. I didn’t get that video game teaching gig, so I felt I had some project time available. It didn’t feel like the right time for another update to Guitar Fretter, I’d recently published the custom-tuning update and wanted to branch out to something new. I decided it was time to make a game where I could apply the things I learned making Guitar Fretter. But many questions remained. What game? How long will it take?

Two years, evidently.

Yep, Definitely Going to Make a Game

But, what game should I make? Not Guitar Fretter 2. Not yet. One of the concepts collected in my notebooks? Something else?

What would be the right sort of project for me for where I’m at now?

Then - my wife, Kate, came up with a game concept. Trying to recall exactly how that came about. I’ll ask and either update this post or capture it in a new post.

Kate’s Concept: A Block Stacking Game

Kate’s background is in child development and she really wanted to make a game that even the youngest technology savy child could play.  Kate’s concept was a focused, simple game that would be easy to start playing if you’re old enough to pick up and use an iPad. It would be about a Panda and how the panda needs to stack blocks in order to move to the next set of blocks. Kids can learn pattern recognition and decision making via shape and color matching.

Sold on the concept, it was time to plan the rest of the game design and how I’d build it.

What Materials and Techniques?

With a game concept in-hand I had a set of design constraints to help me plan the features and tools to build the game. Based on Kate’s concept I had the core features , the learning and experience goals I needed to accomplish. They included:   

• Easy to play

  • Keep things minimalist as possible while still feeling like a game.

• Cute and playful experience

  • Approachable, high contrast characters and backgrounds.

• Stack blocks to match a given pattern of stacked blocks

  • Touching, moving the blocks needs to feel good.

I knew I wanted to have production quality and polish beyond what I did for Guitar Fretter. Two things in particular: background music that provides feedback to the player as they progress through stacking the blocks. For visual feedback I wanted to add multi frame animations for the Panda which would be more expressive and hopefully more delightful to interact with than a set of still panda images.

Making the Game

What was it like to make This Panda? I wore many hats throughout the process. Game Designer, Visual Artist, Animator, Musician, Tester, Project Manager, and so on. I’ll probably add a credits screen in the game or on the game’s web site, though it’ll only have two names on it, mine and Kate’s.  When working alone, planning the game and making the game blend together. The process was not a simple sequence of design > build > test > publish.

Design

How did we capture the design? For the game concept, Kate created some slides in Apple Keynote to convey the essence of the game. From there I would sketch and explore ideas for the game in my notes, sketching on paper.

• Keynote

• Paper (later scanned into Evernote)

Prototyping

The early prototypes of the game began in the Corona SDK, the same technology I used to create Guitar Fretter. Initially, my focus was to play with the shape stacking, discover what about it felt fun. I made a shape stacking scene, played with it, evolved it, and learned I wanted to make it physics-based. Gravity and stuff falling over was part of the fun.

Over the course of the first year, I build a full basic working prototype using the Corona SDK.

When I prototype at my day job, I use Javascript. At the start of my second year on the project I experimented with porting the game from Lua and it showed great potential. When I started Guitar Fretter I went the opposite path. Started in Javascript, then switched to Lua.

Eventually - as the This Panda matured and I switched to Javascript.

I also set-up additional experimental projects, where I’d test one feature at time. For example, when I was exploring new particle animations, I found it easier to make a simple thing to test only the animations instead of exploring both that and integrating it into the full game in a particular place and time.

The focus of prototyping changed over time, yet I continued to use prototyping as a way to experiment throughout the entire development cycle:

• Initially: explore and find the fun and playful interactions.

• Expanding: get the basic elements working together

  • game logic

  • frame based animation

  • sound effects

  • tweens

• Improving: get the flow and structure of the game working, the “level progression”

• Finishing: get the refinements in place, polish the game

Art Assets

To accomplish the design and features of This Panda, I knew the effort to create the art assets would be greater than what it took for me to produce the art for Guitar Fretter. Some notes about what went into the art assets:

Screen Elements and Layouts

Most elements in the game started as blue or red pencil sketches which I inked over, scanned, and vectorized using Cocopotrace. I colored and composed the elements further in Photoshop.

To layout the screens I used an approach similar to Guitar Fretter - use a 2d art tool to compose scenes, then export both the elements AND the data about the elements’ positions. I used Photoshop’s Javascript extensibility to get that layout data. Back in the Guitar Fretter days I used the same approach yet with Adobe Fireworks.

Animations

To make the panda more emotive and relatable - I wanted to give her personality via movement. I’d experimented with frame by frame animations before, but had forgotten much, and needed to learn how to use them in a game.

First I studied how PhaserJS supports sprite sheet animations. Each frame of an animation is on a grid of pixels, along with a JSON file “texture atlas” that describes and groups the frames and animations.

Once I learned what PhaserJS needed, I learned how to export sprite sheet animations using Adobe Flash.

To create the panda animations I used two approaches. The panda character is a set of movie clips within Adobe Flash. Conceptually - it’s a doll made of movable parts: Head, body, arms, legs. For some of the animations I’d create frames directly using the panda  doll movie clip in Flash and move the parts, test, repeat.

For others, I first made a “pencil test” using an iPad animation app called Animation Creator HD. Then would use each frame of the pencil test as a layout guide to position the panda’s parts, rotate, stretch, squish as needed.

Then there’s the procedural animations: Tweens and Particles. Procedural animations move and change things over time without needing separately drawn frames.

• Tweens: I made a few pre-set Tweens to use in the game, including new versions of my favorites “breathe” and “wobble”.

• Particles: I made a few simple particle systems to add life and excitement.  Like the burst of stars that happen when you finish stacking a set of blocks or the puffs of wind that appear when cloud kid is blowing over the panda’s blocks at the beginning of a level.

Physics

I knew that playing with the blocks needed to feel ‘real’ and be fun.  To give the block shapes an underlying structure, I used Physics editor. It’s an app that lets you load an image, then draw a shape within which will provide structure for the physics engine within the game to react with the environment and other shapes.

Art and Sound

I frequently use placeholders as a way to keep moving toward working code. Placeholders help me focus on a primary coding task instead of all the minutiae surrounding the task.

As my game development progresses I reuse things within the game as placeholders. For instance, instead of laying out a new screen in Photoshop every time, I’d get the basics working by reusing another screen’s layout. Or instead of producing all the sound effects, I’d reuse one sound effect as a placeholder.  Hearing the same sound over and over again can drive me a bit crazy but overall it keeps my development moving forward.

During the two years of making This Panda - I also wrote a book about learning to make games using HTML and Javascript.  The Game Construction Kit book I wrote included  a library of placeholder art and sounds. As a result, early builds of This Panda Needs You looked and sounded more like Underwater Tomato Ninja from the Game Construction Kit book.

Platform

When  I make a comic,  I make it for a given form and size. That’s true for all creative effort - the form will affect how I go about building. When I build a game,  I build it with a platform - a base of hardware and software needed to create it and expect others to have to play it. This Panda was built to work primarily with touch input with a tablet sized screen in mind.

The software part of the platform changed. I mentioned part of this in the prototyping section, though to recap:

• Started working with the same platform I use for Guitar Fretter - the Corona SDK.

• A great ecosystem and community, yet I was growing frustrated with switching between working in Javascript for my day job and Lua Script for my games.

As part of the switch to Javascript, I sought another piece of software on top of the platform: a game engine. I knew that I wanted to build upon a more complete game engine than I used in The Game Construction Kit book - the book advocated for learning game development in a very bare bones way, which is great for becoming familiar with the parts of a game engine. I want to start with a whole basic engine I could build a game around.

Early in my exploration I came across PhaserJS. It’s an amazing base of technology to build games on top of with great help toward managing your game events, game loop, sound, asset loading, tweens, particles, physics and tons more. I’m a huge fan of PhaserJS.

One more piece beyond the game engine, what to use to wrap the game in a launching application. Something that holds all the game parts together and makes it feel and launch like any other application. For that, I chose CocoonJS by Ludei. It’s something I could have chosen to build myself, yet I’ve found it immensely time saving and convenient to focus on making the game instead of making the thing that wraps and launches the game.

Shipping the Game

Once all the art, code, sound, features, testing, and built package for This Panda was ready, I began the final major threshold to cross: shipping it via an app store.

It’s super important to present the game in a way that connects with its intended audience. And it’s critical to pass any tests and standards necessary to help it be approved and allowed into the market place.

The shipping machine

• I needed to pass the tests of an app store/market place, including:

  • App icons of various sizes

  • Screenshots of the game

  • Screen video + audio of game play

  • Build file size

  • Build settings (what privileges does the app need, code signing, etc.)

  • Description text to inform the potential buyers about the game

• I needed to provide a web site

  • Thankfully, the game has many assets that helped to  quickly design and build the site.

  • I was able to Reuse the description text for both the web and App Store

  • I chose to use Macaw to design and build the site using a rapid prototyping approach

• Of course I needed a Privacy Policy

  • I chose a legally re-usable template via Docracy.com

Keeping it a Secret

Secrets can be tough when you have a big team, yet you at least have one another to collaborate with and talk about what you’re making. I am regularly a part of teams in my UX and software work where we’re designing and building something secret. It’s a common, understandable situation. Secrets help a business create something that surprises competitors.

Secrets are tougher if you’re working on a small team or solo. The first release of a game is a moment. A threshold. I wanted that moment to be a fun surprise and wanted to not be haunted that I’d published my game’s design while not knowing when I could bring it to market.

I mentioned the project publicly in a general way from time to time. I leaked a tiny bit of info about the game on my portfolio site, though not much. Not enough to satisfy my urge to share what I’m doing. This Panda was a well kept secret for two years.

New releases of TPNY feel less urgent to keep secret. I’m looking forward to blogging about work in progress on this game.

Will I keep my next project secret? Not sure. There are other ways to connect with an audience besides having a product ready for sale, perhaps there’s a Patreon approach that would work. Kickstarter is an option as well. Each has a huge strength in that it creates a deeper connection between artist and audience. Worth considering, yet I’ll probably keep the next totally new game I make a secret too.

Keeping it a surprise wasn’t easy - though now things may get difficult because I don’t want to stop talking about the game.

And that Was About Two Years

So glad it’s not a secret anymore. This Panda Needs You is out and available. Now it’s time to grow the game, help it find its audience.