While doing some research on inspiration, I watched an interesting TED talk that has me attempting to answer the question of “Why?” for my own small video game business.

How Great Leaders Inspire Action (TED – Simon Sinek)

If you have the time, follow the link above, then come back.  I’ll wait.

So I have spent a bit of time digesting the examples provided by Mr. Sinek in his talk, and I believe that there’s a lot of truth in those 18 minutes. One of the examples used in the presentation was about Apple. It’s the one that rang true with me personally; I’ve seen people join the Apple movement. In fact, I guess I’m a member of that culture myself. After all, I have an iPhone in my pocket, and not even Google has been able to pry me away.

Here’s the way Apple thinks and communicates, wrapped up in a diagram (basically the same one from the talk).


They inspire their fanbase and employees in a much better way than the big companies for whom I’ve worked (I would challenge Electronic Arts’ leadership to start thinking this way). I can’t stress enough that it’s about more than “what” we do or “how” we do it, it goes down to what can inspire everyone that makes or consumes the products. To do that effectively, the “Why?” must be answered and it must be a better answer than “We want to make dumptrucks full of cash.”

It has me working to find the right way to communicate the answers to my own “Why?” for my one-man game company. I have an intuitive understanding of why I do it, but it could do with being a concrete and well-defined answer. When I’ve figured out the proper wording for my own mission statement/creative vision, I’ll make another post about it.



I’m seriously in love with Unity Cloud Build. It’s enabled me, as a solo developer, to focus on other aspects of development and business. Anyone using Unity for Android/iOS/Web Player should examine whether it would be an asset to their development pipeline.

At each of my previous employers (even the small ones), we used build servers to do continuous integration and build mastering of our console games. While it was sometimes a fragile process, it paid off in spades. Our on-site build servers handled merging all the work together and cranked out fresh playable builds for QA or for delivery to our publishers. The only cost was setting up one or more build machines and the occasional programmer/IT time to add new hardware, update software/libraries, or add new target platforms.

Given that it’s very comfortable to work in that kind of environment, it’s one thing that I wanted to have even in my solo development. Thus it became the first thing I set out to implement when I ventured into independent development last year. It ended up being a bit more time-consuming than I imagined it would be at first.

The Hard Way, Part 1: Creating A Custom Solution

I definitely wanted to target Apple devices, so this meant that those builds had to be authored on a Mac machine. So I started off by firing up my Mac Mini and installing my CI build service of choice: Jenkins!

Jenkins.sh-600x600Jenkins is definitely worth checking out; they take care of much of the hassle and leave minimal work for the developer. Everything can be accessed via their web client: monitoring and triggering builds, tagging and archiving, sending notifications on success/failure, along with a host of other features.

A Google search for “Unity Jenkins” pointed me to a great tutorial that I started to follow.  As it turned out, there was already a Unity Jenkins Plugin.  It appeared to automate most of what I would need. I was ecstatic! In 20 minutes, I felt like I already had the tools to get continuous integration rolling for my games. Soon I had the build server pulling down all of the game content from an SVN repository and was well on my way, or so I thought.

The Hard Way, Part 2: Results of Custom Solution

Fast-forward to the next day (after a late night of frustrated attempts), and the situation was not quite so joyous.angry

No amount of arguing, bullying, or pleading would get the entire process to work correctly. I had followed all the steps from setting up provisioning profiles to configuring Xcode to creating a build slave that ran on the same machine…nothing worked perfectly. Granted, it worked beautifully for all builds that were not targeted at the Apple platforms. It should also be noted that Jenkins performed admirably and made it so I could customize things every step of the way. The biggest problem was Apple’s arcane and annoying development process.

Another long day of debugging and testing and I finally had the process working from beginning to end.  Builds for iOS and the Mac App Store were finally created and signed correctly and were properly uploaded to TestFlight to be pushed out to my devices. The whole thing was elegant in no way, and very closely resembled a Rube Goldberg machine. But it worked. God help me, it finally worked.


For the next few months, this cobbled-together CI system ran beautifully with very little maintenance required on my part. Despite being a little unhappy with it, it was a passable solution, and I resolved myself to revisit it in the future.

The Hard Way, Part 3: Disaster Strikes

One day, I got a notification that I had an OS update available on my Mac and I applied it, thinking it would be no big deal. This update wrecked everything. Nothing worked at all. The server installation was ruined, the slave wouldn’t connect, the signing was broken, Xcode was pitching a fit…but that wasn’t the worst. The worst thing was that I had not backed up my system before applying this update. I had no easy way to recover.

In all my years of programming, I’ve never been so upset that I cried over something breaking. This time was the closest; I was distraught.

As I was sitting in my chair stewing and contemplating my options, I get a notification from my e-mail client: “You are invited to try Unity Cloud Build Beta!”

I began to wonder if someone from Unity was spying on me. The timing was almost too fortuitous. Pushing aside my crazy paranoid thoughts about Unity, I decided to give it a shot. What could it hurt to try it at least?

The Easy Way, Part 1: The Clouds Part

I followed the link and did the basic setup, which went quickly. Twenty minutes later, my game was building in the cloud. I kid you not, it was that easy. I was playing a WebPlayer version of my game built on their servers just a few minutes after completing the setup. It monitored my SVN repository, sent e-mail notifications, and supported a few platforms (most importantly, iOS.)

For iOS, which had been the thorn in my side, I just had to get a couple of items for signing apps off of my Mac. They turned a process I had struggled with for three days into a simple 5 minute task. It worked right out of the gate. 10 minutes later, I was playing my game on my phone with no hiccups.happy-happy-joy-joy-o

I almost cried tears of joy. Seriously. I could simply bring up the Unity Cloud Build project in Safari on my iPhone or iPad and install from there. No TestFlight required. No yelling at my machine, no begging the ghost of Steve Jobs to take pity on me.

As an added bonus, I got back one of my Unity Pro keys since it was no longer needed on my Mac Mini. I re-purposed that key and put it on my laptop. I could now safely ignore Apple machines and the bizarre provisioning requirements entirely (sorry, Apple guys, my personal preference is PC.)

Another great bonus I discovered was that I could choose which Unity installation to use for each project in my list. No need to upgrade Unity on my build machine anymore, because the Unity Cloud Build team handles all of that stuff. I can simply tell it to use the version of Unity I have installed on my development machines, or always ask it to use the most recent published version of Unity.

The Easy Way, Part 2: The Angels sing

Since that day, I’ve exclusively been using Unity Cloud Build, and while it’s been great, it’s not quite perfect. If I could squeeze just a couple more features out of it, I don’t think I’d need to even consider a custom solution for my Unity projects. Here’s my short wishlist:

  1. Support for building on more platforms.  Ideally, it would support all of the platforms that Unity supports, especially Windows/Linux PC builds.
  2. Mercurial support. It’s the one major source control system they don’t support yet.
  3. Options to select Unity installation on a per-platform basis.

Even without those things, Unity Cloud Build will remain my go-to solution for authoring iOS/Android/Web Player builds, and I strongly recommend anyone making a Unity game for those platforms to check it out ASAP.


I’m taking part in a game jam this weekend!

It’s called “Indies vs PewDiePie“;  it’s being run by the totally awesome indie game site GameJolt and sponsored by the world-famous YouTube personality PewDiePie. The theme of the jam is “Fun to play, fun to watch!” and the top 10 games (as rated by the community) will be played on PewDiePie’s stream at some point in the (near) future.

So here are some fun and easy things anyone can do to take part:

  1. Follow the conversation with the #indiesvspewdiepie tag.
  2. Follow me (or other awesome developers) as we stream our game development live on twitch.tv.
  3. Create a GameJolt account and play some awesome indie games. Please don’t forget to rate the games you play and follow the games you like.

Wish me luck and have fun!