« Posts tagged unity3d

How Many Pages of Code in an Indie Game?

October 1, 2014 / posted in behind the scenes, flutterfly / No Comments

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.

So: HOW MANY PAGES OF CODE IN AN INDIE GAME?

The answer?

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

(SCROLL DOWN TO SEE ALL THE PAGES!)

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!

code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
WindManager

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!

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

July 12, 2014 / posted in behind the scenes, flutterfly / No Comments

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:

set01

set02

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

glowboxset

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:

tooldemo

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

EditorUtility.SetDirty(yourObject);

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.

How Many Pages of Code in an Indie App?

September 25, 2013 / posted in behind the scenes, spider prank / No Comments

I was curious! So I just finished my iphone/ipad app: Spider Prank. How much work had I actually done? I know I’d worked like a dog for almost a YEAR on nights and weekends. But how much code had I actually written?

Well, there was only one way to find out. I saved all my code as pdfs, then opened in photoshop and saved each page as a tif. Then using some neat Photoshop actions, I shrank the images down and tiled them. I basically made sprite sheets out of them.

The result?

424 PAGES of C# code that I had personally written.

A friend joked that I had written the Great American Spider Prank novel. She wasn’t far from the truth. When you’re deep in development it’s hard to tell how much work you’re actually doing. There’s no such thing as ‘page count’ in scripting. And all your work is broken up into different classes of differing lengths.

But that’s a lot of writing!

Now granted, every page isn’t totally filled in. And it’s at least double spaced I’d say. But as a former screenwriter, I can safely say that I wrote the equivalent of at least 3 movies.

A few other notes– this is all the code that I wrote personally. But there’s a TON of other code in the app in the form of plugins I bought, cool license-free snippets I found online, and of course the huge C# and Unity3d libraries I built the whole thing on. So my code that you see below is just the tip of the iceberg when it comes to the bits in the game (gfx & sound aside).

Also I thought it’d be neat to highlight portions of the code to get a sense of how much code it took to create a specific result. In my app, I have a semi-intelligent spider that crawls around and reacts to swipes, gravity, taps etc. So in the code below, I’ve highlighted in RED all the portions that control the spider alone. All the rest is UI, photo import, saving/loading, localization etc etc etc. But the spider is quite a large chunk. Almost feels like peeking at a decrypted genome.

If you ever wanted a look at how much code goes into a little app, check out the code below and make sure to keep scrolling! If you’re a developer, how much code did you write for your game? I bet it’s more than you think!

code01

code02

code03

code04

code05

code06

code07

code08

code09

Localization

January 20, 2013 / posted in behind the scenes, spider prank / No Comments
korean

Is this amazing or what? Thanks to the very simple and easy to use localization plugin for Unity3d, I can localize the text in my app at the click of a button.

localization

It’s all automated through google docs– including the translations. Here are some blurbs from my app in French, Spanish, German, Chinese, Russian, Japanese, Korean and Thai– the list goes on and on.

spider prank in korean

Spider Prank in Korean

I love living in the future. (PS– anyone know how to say ‘swipes’ in Korean??)

Procedural Logo

January 13, 2013 / posted in behind the scenes, spider prank / No Comments

In my latest app, I came up with what I thought was a cool look for the logo. I created the following in After Effects. My initial thought was to render out the still frames and have them run in the app as an animated sprite:


However, rendering out all the frames led to over 200mb or so of raw assets. Granted, this number would drop after combining onto sprite sheets and compressing, but it was still far too much bandwith for a simple logo. Moreover, I’m not a fan of the aesthetics of compressed still imagery. I needed a different solution.

sprite sheet

A handful of the 90 odd images that would have gone into a sprite sheet for the animation.

I created a single god ray sprite in Photoshop (seen here).
godray

I also created two logo sprites (one normal, one glowing). So instead of 90 images, I was down to 3. In Unity3D, I duplicated the god rays several times and added a Box Collider to each one. Then I wrote a godray script. The script told each god ray object to fade up and scale depending on its relative intersection with a trigger object. I also gave each ray a little wiggle. Finally I told the glowing logo to fade up when it intersected with the trigger to boost the overall glow effect.

The last step was to write a simple script to make the trigger object move back and forth over the logo. Because it’s procedural, I got the added benefit of being able to randomize the speed and the direction of the trigger from pass to pass. Here you can see the trigger object (the longer box) and the god ray objects at work in Unity3D:


And the final result below. Since the three sprites fit on the same sprite sheet, this version of the animated logo only takes a single draw call and costs 322 KB (uncompressed).

Not quite as pretty as the original After Effects version, but worth the extra work to get the size down. Now users won’t have to wait an extra several minutes for a heavy sprite logo to download. Instead this streamlined version should load fairly instantly.