« Posts under flutterfly

How Many Pages of Code in an Indie Game?

FLUTTERFLY is done and launches for iOS this week! And after almost nine months of non stop work, it’s time to reflect. How much work did I actually do? With an app it’s tough to tell sometimes. You bang on your keyboard typing code at the prompt… then you compile… and then an app appears as a single icon on a device you can put in your pocket.

Unlike a novel, you can’t flip through it and feel the pages. Unlike a movie, you can’t scroll through the timeline to get a sense for every frame. It’s a game! It has no real physical mass, as it were.

So I decided to convert EVERY PAGE of code I personally wrote into a pdf, then in photoshop, shrink them down into little jpegs and line them all up. It’s a fascinating way to get a sense of the over all work involved in an indie game.


The answer?

An astonishing 1,266 PAGES OF CODE in Flutterfly that I wrote myself.


A few big caveats:

1. There is obviously WAY more code in the app than just the stuff I wrote myself. There are tons of amazing plugins that I bought and used. And of course the Unity3d game engine which the whole thing is built on probably has enough bits to fill a library. But for this experiment, I think the page count of the stuff I wrote personally is a pretty cool metric.

2. Pages of code are generously spaced. It’s not like this stuff is packed in there. You’ll see from the images below that code, in this case C#, is not very dense when it comes to the amount of space it takes up. So take those 1,266 pages with a grain of wide-margined salt.

3. Code is repetitive. There’s a lot of code that repeats. For instance, almost every class I wrote starts with
using UnityEngine;
using System.Collections;

It’s part of the lexicon. So it’s not like every line of code is completely unique necessarily.

4. A lot of code gets deleted. The game evolved a lot over nine months. So entire sections were ultimately zapped. I’d estimate that at least a good 10-15% of the final product were axed and aren’t pictured below.

5. There is a lot of work that goes into a game that is NOT CODE. There’s animation and sprite sheets and models and sound and camera work. So the code is maybe half of the whole story. At most.

6. A lot of programmers pride themselves on writing super condensed, tight and streamlined code. The less code the better! I’m not one of those guys! I’m more from the literate school: lots of comments and notes to myself. Just fyi.

7. I’m seeing now that a couple blank pages snuck in there. Whoops. Converting over a thousand pages of code into little thumbnails is no easy task unto itself. I highly recommend this little photoshop script if you’re interested in trying the same for your game!

So without further ado, here are the 1,266 pages of code I wrote for FLUTTERFLY over the last nine months. I’ve colored some of it RED and have annotated those sections. Figured it’d be interesting to get a sense of how much of the code did what exactly. Who knew powerups were so complicated?

See you after the long scroll!


Whew! I feel exhausted just looking at all of that.

And sometimes writing code is like creating music– it just flows out of you. But more often than not it can be a very exacting and painstaking process where you battle through mazes of logic to just write a single line.

Mostly though, I’m excited about starting the next project! Time to open up a new blank page one.

PS: I did a similar experiment with my previous, smaller app SPIDER PRANK. If you’re curious, you can check it out here!

Leveling Up Your App: 3 Lessons I Learned the Hard Way

So I’m about to launch FLUTTERFLY — a brand new side-scrolling color matching game. Guide colored butterflies as they migrate and match colored blocks.

For those of you who’ve been following this blog or who follow me on twitter, you might know that FLUTTERFLY actually started as FLUTTER. Flutter was a previous incarnation that was a simple endless game. There were no levels. No powerups. No stages. Just one endless side-scroller that went on and on.

I started work on the original Flutter in Feb 2014, and working in Unity3D, quickly got something up and running. The original core concept was to take a fun color-matching / tetrisy mechanic and make it a side-scroller. Could I combine two genres to make the whole greater than the sum of its parts?

It took another few months to polish the game into something I considered finished. And I uploaded Flutter to the app store in mid-May 2014 to (drumroll)… the sound of crickets! Flutter opened with a whimper. Despite some nice feedback from some folks in the community, sales were pretty non-existent. So… game over??

But I still believed there was something great at the core of Flutter. I thought the gameplay was original and fun. The app, however, had a long way to go. For the past five months I’ve been working non stop to make Flutter better. In fact the new version has evolved so much that it’s really an entirely new game. So goodbye Flutter and hello FLUTTERFLY!

In the meantime, here are THREE LESSONS I learned the hard way that I’ve worked very hard to fix.



I created Flutter originally as an endless side-scroller mainly because I wanted to finish an app quickly and not spend five years on it. Why design 100 levels when you can design 1, amIright? And of course the endless platformer/flappy/runner is a tried and true genre all unto itself. But there’s just one problem. You never win. It’s not a problem for games like Flappy Bird. I think the frustration of dying repeatedly is what spurs players on in a game like Flappy. It’s addictive masochism.

flappy fun

But that sort of hardcore die, die, die experience flew in the face of my app. I discovered too late that people really liked these butterflies. They didn’t want them to die! And when they died, they felt bummed and didn’t want to play anymore. I needed to let people win. So I’ve spent a big part of the last several months developing levels.  I added a FLOWER object that served as a goal for players to reach.  Now players could actually win!

Now players can WIN

Now players can WIN

It has been a lot of extra work, but I think the results have been worth it. Playtesters are experiencing joy with the app finally. Saving butterflies is compelling. Winning is compelling. And it keeps people playing. Besides, I don’t want to be the guy forcing people to kill all their butterflies, right? Because that’s what an endless game is. It’s inevitable death. The lesson for me is that I had a happy game on my hands—not the casual equivalent of Team Fortress 2 (God, but I do love me some Team Fortress 2).

LESSON #1: If losing your game isn’t fun, players better be able to win it.



FLUTTER 1.0 looks great in motion. I made a trailer that I think showcases it nicely. But stills? Not so much. I had this idea I’d be Jony Ive and use this minimalist solid color approach. Helvetica everywhere. The problem is this makes for really, really boring screenshots. So I’ve gotten to work adding particles, flares, glow effects and a nice handwritten font. It makes a world of difference. The game is much more beautiful, both in playmode and in a still screenshot.

Which game would you rather play?

Which game would you rather play?

When you’re an indiedev and no one’s heard of you or your game, screenshots are THE first thing people will look at. I’ve learned the hard way that your screens gotta be amazing. There’s a chance no one will watch your video, not least of all give your game a try.

LESSON #2: If no one wants to play your screenshot, no one will want to play your game.



At its heart, Flutter is a pretty simple game. Or so I thought. Match butterflies with colored blocks. What’s so hard about that?

But sometimes as a dev it’s hard to see your own game clearly. If I’d been honest with myself I’d have admitted that there are actually many different kinds of blocks to match: avoid black ones, match identically colored ones, and hit the correct side of a dual colored block. In Flutter I’d spent a good deal of time on a lengthy tutorial hoping this would be enough to get players comfortable. But it wasn’t and they weren’t. They were confused.

I failed to realize that my game really had more than one mechanic. In a way it’s semantics, but I think it’s helpful to think of a mechanic as any one thing a player does that gets a unique result. Matching a black block is DIFFERENT than matching a colored block: it’s a different mechanic. As a result, people were confused playing Flutter. There were too many mechanics thrown at them all at once.

Flappy Bird can get away without a tutorial and without levels. Press the screen once and the bird goes up. That is the ONLY mechanic in the game. But even an ostensibly simple game like Angry Birds has several mechanics happening. If you think about it, the game is more than just a slingshot. Tap the yellow bird and it goes quicker. Tap the blue bird it splits apart. Hit ice and it shatters. Hit wood and it breaks. Pigs with helmets are harder to kill than pigs without. Etc. And the player has to learn and master each one of those new elements. And if you don’t want a frustrated player, introduce new mechanics ONE AT A TIME.

In FLUTTERFLY, what was once a one shot tutorial is now a series of 15 levels (There are over 70 levels in Flutterfly, but the first 15 probably cover what was in the original Flutter tutorial).

Learning is now spread out over many levels

Learning is now spread out over many levels

The player learns the same tutorial content, but it’s spread out over time. Now the player is engaged and having fun as they learn. Moreover they have time to master each new mechanic before moving on to the next. It’s no fun trying to learn to ride a bike and swim at the same time. (For more on this, see Daniel Cook’s amazing presentation on feedback loops.)

LESSON #3: Players can only master one mechanic at a time.*

* notable exception being if the mechanic is so well known it’s part of the vernacular—like running and shooting in an FPS. WASD. We all know that.

FLUTTERFLY launches in a matter of days and so far reactions have been extremely positive. It’s also just super fun and rewarding to see an app you’ve put a lot of love into get better and better! Mainly though, it’s a reminder to me that sometimes you gotta just keep grinding to level up.

Make an App to Make an App (plus how to get Dirty in Unity)

Sometimes you end up making code that no one will ever see. Case in point: FLUTTERFLY has a bunch of different levels made up of different colored boxes. Several boxes put together make what I’ve dubbed a ‘Glow Box Set.’

A picture speaks a thousand words so here’s what the glow box sets look like in-game:



And here’s a glimpse at the Unity3D inspector window for everything that goes into one set:


There are a ton of parameters to keep track of: position variables for all the boxes, what type of box each one is, are we raining? Is this the last set in the level? etc. etc.

For a while I was tweaking all this manually. Now you can imagine that for a game with over 100 levels, where each level consists of 6-20 sets, the work becomes unmanageable real quick.

So I took a few days to design an app for my app. I created a new blank scene and set up a tool for level creation.

It seemed like a big pain in the arse at first, but it honestly went quicker than expected. And now that the tool is done, designing levels is a breeze– and even fun!

Here’s a look at my nifty new tool at work:


Much, much better than manually entering Vector3 position values one at a time.

Getting Dirty in Unity3D

So here’s a bonus PRO TIP for you Unity guys/gals out there. So you have your awesome level editor working and you make your tweaks in playmode, hit stop and WAIT! Where’d all my changes go?

As every Unity dev knows, changes made in Editor in playmode are not persistent. It has to do with serialization which is a huge topic unto itself. But I don’t want a seminar in serialization– I have a game to make! To get my level editor working I just needed to know one thing: How do you programmatically change prefab parameter values in Editor during runtime and have them stick around when you hit stop?

Easier than you might at first think. You just have to GET DIRTY.:)

Add a

using UnityEditor;

to the top of your class, and then call


to save changes to values you tweak in Editor playmode. With my tool, I call SetDirty when I press the ‘Save’ button (shown above).

Now you can write a ton of values quickly and procedurally at the click of a button (ie– where should all these boxes go? well here’s 100 Vector3’s generated by code). Just be sure to comment the above two lines out before building, because as far as I can tell Unity won’t build if any of your scripts have a UnityEditor ref.

With the tool, now at least I have a fighting chance to finish this thing! Plus it has made level design quite enjoyable– a nice change from the torturous process of manual tweaking.