Quarter Spiral Blog

The Tools of the Trade

Tue, 18 Jun 2013 14:50:56 -0700

With the right tools making games is fast and fun. Tools empower everyone on the team to do a quality job and help alleviate bottlenecks in content creation. Good tools set a team up for success and are one of the biggest advantages an established studio has.

Tools enable artists to put their art into the game quickly and easily. They enable designers to tweak, refine and test the game play quickly. They help developers get their code in front of people.

The Enhanced Wars Map Editor is one of the first tools we created at Quarter Spiral.

When I started creating and iterating on the art for Enhanced Wars I wanted a way to preview and test the assets in context. So I created a very basic map editor in html. It allowed me to assemble complex maps and go through several massive art iterations without having to create elaborate mock ups in photoshop.

Since our first art test, we have refined the map creation tool a great deal. We have added support for units, buildings and various terrain variations. You can now load and save maps and export them as images or raw JSON. And recently we upgraded the system so you can quickly put together a map and instantly try it out in the latest game build.

Here is one I made earlier: River Land

Tools like this are essential–even when working on a very small team. Please keep in mind that this was never intended as a stand alone product and that we may not maintain it in the long run. So use it at your own risk!

We will definitely want a better map for our next community play session!

Enhanced Wars - Community Play with Ryan Brady

Fri, 14 Jun 2013 10:11:30 -0700

Enhanced Wars - Community Play with Ryan Brady

Enhanced Wars - What players want

Wed, 12 Jun 2013 12:55:00 -0700

When we sat down to begin the design process on Enhanced Wars, we began by agreeing on 5 “first principles” that would guide the game’s development. These first principles inform both our design goals and our working style. Perhaps the most important principle is “Community is a team member.” As Enhanced Wars is a multiplayer first game and funding the game via Kickstarter is essential to bringing this game to market, we know that opening up our process to the community and involving them at every step of the way is the only possible path to victory.

Even though we are fairly early into the development of the game, we have already been soliciting feedback via a tactics game fan survey. So far the number of responses and positivity of the results has given a huge boost to the Quarter Spiral team. We wanted to share some of the early results both for our fans and for other developers who may be planning out a Kickstarter. If you are interested in shaping the future of Enhanced Wars and getting early access to the game, you too should let us know your thoughts by taking the survey.

Barking up the right tree?

The key question to answer is “Will turn based strategy (TBS) fans back a game via Kickstarter?”

Of our survey respondents, over 50% have previously funded games via Kickstarter, so we have cleared one of the biggest hurdles for at least half our fans. Not that creating a Kickstarter account is a huge barrier, but even if all of those remaining 47.5% want to back us, it is safe to assume that not all of them will end up creating accounts.

We also asked fans if they will support us on Kickstarter. This is a bit of a cheeky question for sure, to ask fans for support largely based on 1 video on IGN and a few screenshots. But over half of the survey respondents said they will back us. The 35% who gave an open ended response largely took the form of “Depends on your quality. If it is good, I will back you.” Only a very small number of fans who took the time to finish the survey flat out said they will not support us on Kickstarter.

Targeting the right platforms?

The next question to answer “Are making the game for the right platform?” We are currently developing Enhanced Wars for PC, Mac & Linux. As with most parts of the game’s development, our ability to deliver a quality experience for other platforms is largely dependent on our ability to raise enough money to port to, QA and support that platform.

For this question, we allowed fans to pick as many platforms as they desired. In our ideal world, Enhanced Wars will be a cross platform game that allows you to pick up and play your turn on any device connected to the internet.

The most desired platform is Web browser – so if these results hold over time, it is likely we will want to add browser to our initial batch of platforms. Unsurprisingly, PC is up next followed by Steam. This encourages us and validates our desire to put the game up on Steam Greenlight as well as Kickstarter. This is our ideal distribution platform for Enhanced Wars – so hopefully enough players vote for us!

iOS and Android are clearly of interest, and we ought to evaluate adding them to the stretch goal list. For all their success with crowdfunding and hype in the media (which has convinced me to pre-order both) neither Ouya or Oculus Rift have generating enough interest to make them worth putting on our roadmap at this time.

Building the right game?

Enhanced Wars is a multiplayer first game. We will build this game with a realistic feature set for our Kickstarter ask, based on years of production experience and over 35 shipped games contributed to by members of the team. Anything we can do on top of the core, multiplayer experience is contingent upon not only hitting our initial goal, but beating them with stretch goals.

This brings us to data both encouraging and troublesome. The single most requested feature is a single player campaign. Based on our experience building linear, single player content, we know that this is also the most expensive feature to implement. Creating a single player game will significantly increase our needs in terms of budget and time to market. We will need to craft a story. We will need to build more tools. We will need to develop AI that is both intelligent and fun. We will need significantly more art, sfx and game features to create a quality campaign that is worth playing.

Normally, stretch goals are at reasonable increments after the initial goal is reached. But if we truly want to build a great single player game, we will need to ask for (at minimum) $100,000 more than our base ask. It is an interesting thought experiment to imagine how players will react to a campaign with a single stretch goal that is that much higher than a relatively low project goal.

The popularity of other stretch goals was in line with our expectations based on previous work on multiplayer, TBS games. Team battles, map making tools, tournaments and more playable factions are proven hits with the community.

Giving the right incentives?

A big factor of a campaign’s success is the rewards it offers. Kickstarter is more or less a presale platform when it comes to games. In order to bring in high value contributions - or any contributions at all - we need to make sure we offering rewards that players desire.

This chart will probably be the most interesting to other game developers. Unsurprisingly, copy of the game, beta access and alpha access are the 3 most popular rewards. Next up is a custom skin for your army followed by the ability to work with the game team in designing a unit for the game.

A common lesson from successful Kickstarter campaigns is to limit the amount of physical goods you offer. It is not unheard of for campaigns to end up in the red because of unexpected costs of physical goods. Of the physical goods we asked about in the survey, 3D printed unit from the game is the most popular (and the one we think will be a limited, high value reward). After that is T-shirts, which so far are popular enough to want to include in the rewards. More complex physical goods like a printed and signed art book or printed and signed poster got a low enough response that they do not look like appealing offers.

More out of the box offerings, like access to the team’s design documents, print and play version of the original prototype, digital poster, naming a map or getting your voice in the game, all look questionable based on these early results.

Just the start

These results are early and we intend to collect a lot more survey responses before we make any hard decisions about Enhanced Wars’ future. If you are interested in shaping the future of Enhanced Wars, and getting early access to the game, there is no better way than taking the survey now. If you have already taken the survey, thank you for the support!

Enhanced Wars - multiplayer, turn based strategy for modern sensibilities

Fri, 07 Jun 2013 08:08:00 -0700

Quarter Spiral is proud to officially announce our new game, Enhanced Wars.

Our goal is to create a multiplayer first, turn-based strategy game for modern sensibilities. Although we are inspired by a number of classic games, we want to solve some genre foibles that prevent these incredible single player experiences from being truly fulfilling in multiplayer.

Specifically, we’ve targeted three areas for improvement. We find that many turn based strategy games suffer from 3 common problems. The first is that the game is much more about resource hording than tactics. As soon as one player gets a defensible resource advantage, the game is essentially over.

Which leads us to our second problem - long mop up phase. There’s nothing more annoying than when both players know the battle is won, but the game is 30 turns from finished. Even worse is the third problem - long stalemates. Nothing is more frustrating than spending weeks going back and forth over a few pieces of territory with the tide of battle never changing.

We will be sharing more details in the coming weeks about how we have designed Enhanced Wars to be a fast, fun multiplayer game that focuses on aggressive tactics and resolves quickly.

In the mean time, we need your help! If you are interested in Enhanced Wars, please take this tactics game fan survey. We are building this game with our players, not for them. Please share your thoughts and help shape Enhanced Wars, even at this early stage.

Taking the survey is the best way to get early access. But if you just want to get on our early tester list without taking the survey, you can sign up here.

I built my career on a QA job - a response to Nathan (RC) Peters

Mon, 03 Jun 2013 11:39:42 -0700

After two years I was forced to hand in my employee badge for Pandemic Studios, a broken man.

I was taking 4 vicodin a day to dull the pain of a herniated disc in my lower back. Wrist braces adorned both my arms to help control the repetitive stress injury induced by long days of playing Star Wars: Battlefront and typing. The herniated disc – acquired on a rare crunch time day off as I stood up from my couch at home – gave me a bit of a limp, and as I hobbled through the halls of Pandemic Studios you could hear the painkillers rattle in my pocket.

I was heartbroken. I was rejected. I could not fathom why I was let go from the team I had sacrificed so much for. In time, I would grow to understand the incredible gift I had been given in my two years of industry experience at Pandemic. But at the time I was too immature, too angry and too disillusioned to process my experiences clearly.

I was a student during my entire tenure at Pandemic and still had a few semesters left on my degree. I sat in class, unable to take notes without feeling a deep burn in my forearms and I seethed. I had no idea what I would do after I finished college. I could not imagine the physical pain a desk job would cause due to the herniated disk and RSI. I would be unable to do any job that involved standing up for long periods of time. My future looked hopeless.

“How can I make them pay?”

In the months following my layoff this thought popped up. A lot. It was a very soothing fantasy to imagine I could somehow extract my revenge upon Pandemic. Luckily I did not act upon this immature instinct, because my now 10 year career in the industry was built on the foundation of that first job.

I can certainly empathize with the tale of Nathan (RC) Peters and his time as a QA contractor on Halo 4. I worked at Pandemic Studios for two years. The first year I was an unpaid intern working 2-3 days a week and full time in the summer. The second year I was a paid tester, earning $10 an hour, working 3 days a week during school and 80-100 hours a week during the summer that coincided with Battlefront’s crunch. I was laid off as part of the natural team contraction after the game shipped. I walked away with a broken heart, repetitive stress injury in both arms, persistent pain in my lower back and legs and a Lead Tester credit on a massively successful Star Wars game.

Eight and a half years later the injuries have healed. My bruised ego has mended. I have worked for game developers big and small, have lectured on game design around the globe and have contributed to over 30 shipped games across every platform. I left EA and co-founded a game studio. Whether our title Enhanced Wars is or is not a success, as long as it is launched I will have accomplished a major life goal. I have a long career in videogames to look forward to.

Of course, I couldn’t see any of this when I handed over my employee badge. Or when I packed up my car, drove across the country and moved into my parent’s house in the suburbs. Or when the job working on websites with a childhood friend I moved home for collapsed. How could I see then that I would be able to make my game design dreams come true? As I stared into the void of an unknown future, fantasizing desperately about extracting revenge, all I could see was a pink slip.

I did not work at Certain Affinity. I did not work on Halo 4. I cannot speak to Mr. Peters’ personal experience. What I can do is share some things I’ve learned over the past 10 years that I wish I knew back when I was killing myself in the QA job that is the foundation of my career.

The first thing I wish I knew was EA Chief Creative Director Rich Hilleman’s “Shit in the bag” anecdote. You can hear it firsthand in this spectacular conversation and lecture between Rich and Warren Spector at about the hour and seven minute mark. I had the privilege of working for Rich and this frame of understanding the workplace is one of the most important lessons from my 4 years at EA.

In the talk, Rich explains what it’s really like for leaders on a game team to be in charge. “They have a bag of shit. You can’t smell it, you can’t see it, but it’s there. And I guarantee you they know it’s there. And for the most part, your relationship with them is defined by this bag. You’re either putting shit in the bag or you’re taking shit out of the bag.”

Rich goes on to explain that the secret to success on a game team is to make sure you are removing shit from your boss’s bag. Asking the lead designer to let you sit in on design meetings? That is putting shit in the bag. People are busy, crunch time is tense, and no one wants an unqualified QA guy wasting everyone’s time by “contributing” to a design session when he should be using that “down time” to perform unglamorous regression tests.

At Pandemic I was constantly trying to prove my worth, hoping for that moment when someone would “see my genius” and convince me to give up college and start working there full time. What I didn’t realize was that my enthusiastic attempts to impress were not helping. I spent a lot of time embarrassing myself without knowing, handing out a bunch of stinking turds to busy people with far too much shit in their bag to care about a lowly QA guy.

The second thing I wish I knew is that getting a job on a game team, especially an entry level job, is all about your portfolio of work. I thought I deserved a job on the level design team. Why? Because I worked 80+ hour weeks, hand shredded hundreds of discs, ordered and picked up team dinners, made sure new builds were waiting for people when they showed up in the morning and had some ideas for a tutorial level involving blowing up Ewoks.

The true path to that level design job I thought I deserved involved building levels. The tools of game design are cheap and plentiful. If I had any sense, I would have spent all my free time modding Dark Reign 2 (a Pandemic game) until I had a built and released a large number of multiplayer levels into the player community and had tangible proof of my ability to a) use Pandemic developed tools and b) make fun multiplayer maps that players responded to. Then, perhaps, I would have deserved that interview for an entry level design job that hundreds of others would line up for.

The period of my life after being laid off from Pandemic was one of my darkest (which alone, shows what a privileged life I have led overall and that I really shouldn’t be complaining about anything). I spent 2 years at Pandemic and am grateful every day to the many people who allowed me to be there despite all the stinky turds I’m sure I left in every corner of the office.

QA can be a shit job. QA is monotonous. QA is unglamorous. QA is thankless. But work is work; no one promised this would be easy. I owe my career to QA and the people and company who gave me that job. I only wish that back then, I had perspective instead of vicodin to help me ease the pain of one of life’s many inescapable setbacks.

IGN Developer Demo of our new game.

Thu, 23 May 2013 18:38:00 -0700

IGN Developer Demo of our new game.

A taste of what's to come...

Fri, 17 May 2013 12:49:00 -0700

Curious? Take the Weewar fan survey.

Mo' Money Fewer Problems - a practical guide to designing in-game purchases

Wed, 24 Apr 2013 05:30:18 -0700

Talk Description

In-game purchases are here to stay. Now more than ever it is clear that players are comfortable spending money in browser, mobile, and download games. But just because players are willing to pay does not mean game developers know how to give them something worth buying. This talk gives practical, hands-on guidelines and processes for designing your game’s monetization. Core loops, feature design, economy design, user interface tips, user experience flows, and forecasting tools are all covered in this actionable talk from a 10 year design veteran who has successfully made the leap from designing paid games to freemium games.

Forecast Quest

Forecast Quest, mentioned at the end of this talk, is available now on Facebook.

Game Design is Business Design - GDC 2013 Presentation

Mon, 15 Apr 2013 18:50:00 -0700

Curious about Quarter Spiral’s new game, Enhanced Wars? Sign up for early access and watch our reveal video on IGN.

Above you will find the slides and audio from “Game Design is Business Design,” a lecture presented by Quarter Spiral member Ethan Levy at the 2013 Game Developer’s Conference. Ethan mentions some tools and templates in the lecture that you can find at the following links:

Forecast Quest on Facebook
Monetization Philosophy (template)
Feature Brief (template)
Game Treatment (template)
Business Model Canvas (template)

In the template docs, anything in italics are notes for you. If you use the template, you should delete these sections.

We hope you find these tools and templates valuable. Please send any feature requests, feedback or questions to ethan@quarterspiral.com.

Game Design is Business Design

Tue, 26 Mar 2013 03:57:11 -0700

If you attended Ethan’s #GDC13 talk “Game design is business design” or #FGS5 talk “Mo’ money fewer problems”, you may be looking for links to some of the tools and template documents mentioned.

Forecast Quest on Facebook
Monetization Philosophy (template)
Feature Brief (template)
Game Treatment (template)
Business Model Canvas (template)

In the template docs, anything in italics are notes for you. If you use the template, you should delete these sections.

We hope you find these tools and templates valuable. Please send any feature requests, feedback or questions to ethan@quarterspiral.com.

Forecast Quest #FGS5

Sun, 24 Mar 2013 14:55:14 -0700

Forecast Quest #FGS5:

For those who attended Ethan Levy’s talk at #FGS5, you can access the freemium game forecasting tool he showed off at this link. It will continue to be updated over the course of the week.

Upcoming talks from the Quarter Spiral team

Wed, 13 Feb 2013 14:23:00 -0800

If you’re interested in meeting with a member of the Quarter Spiral team, you can connect with us live at one of these upcoming conference sessions:

Doing it angled - Musings with AngularJS

Presented by Thorben Schröder

Devcon Tel Aviv, Tel Aviv, Israel, February 14th

Scandanavian Developer Conference, Göteborg, Sweden, March 5th

My talk takes all the learnings we’ve had here at Quarter Spiral while building our new product with AngularJS. It covers the best-practices and anti-patterns of how to get you started on Angular, grow and deploy your app. In addition to that I will give insight on our Ruby back end infrastructure, how it is playing well along with Angular and what problems we’ve faced in their collaboration.

In a last part I will give you a rough overview on how we managed good and continuous test coverage for the whole project.

Mo Money Fewer Problems: a practical guide to designing in-game purchases

Presented by Ethan Levy

Flash Gaming Summit, San Francisco, CA, March 24th

Game Design is Business Design

Presented by Ethan Levy

Game Developers Conference, San Francisco, CA, March 25th or 26th (TBD)

The game industry has changed. A rapid shift is underway as we move from a packaged goods-dominated past to a digital, free-to-play dominated present. More players than ever enjoy the widest range of games of any time in our industry’s history. In this new world, the designer’s role has changed dramatically. The successful designers of our digital present are not only masters of fun, but also masters of business models and monetization. This lecture will talk about the changing role of game designers and present case studies of how they can successfully apply business design to their practice.

Can’t make it?

Can’t make it to one of these conferences but still interested in hearing about Quarter Spiral’s mission to change game publishing? Simply drop us a line at info@quarterspiral.com.

An Angled Mind

Mon, 04 Feb 2013 11:22:00 -0800

Do you feel that jQuery pain every now and then? That unconscious feeling that something in your front end code is not the way it ought to be? I hear you! And I might have a remedy for your tortured mind. Meet AngularJS.

Angular is a JavaScript front-end framework developed by Google in the same spirits as other JavaScript MVC/MVVM solutions as Backbone, ember, SproutCore, Knockout, batman.js, and tons more. The main difference is that if you take a look at the Angular homepage it doesn’t mention MVC, MVVM or any other buzz loaded abbreviation. It simply coins itself as: “HTML enhanced for web apps” and holds true to that promise!

Respect the HTML

In Angular, HTML is the center piece – everything else is just there to serve your HTML application. This is definitively an opinionated decision which leaves little middle ground between the lovers and haters. If you have some love for HTML left in your bones, then I strongly encourage you to check a few examples on the Angular site. Dive into it through one of the many JSFiddle code examples that are out there demonstrating Angular’s feature set. You already know Angular you say? Perfect!

If you’re still using your old jQuery plugins in AngularJS applications, then you’re not leveraging the full potential of the framework. This is ok, but it means your code is not as readable and maintainable as it could be. Let’s fix that.

AngularJS vs jQuery

The biggest difference in how I write applications with Angular, and how I did with jQuery before is demonstrated in the way I express the interface behavior. A typical jQuery thing would look like this:

$('a.select-car').on('click', function(e) {
  e.preventDefault();
  
  var box = $('.some-box');
  if (box.is('.open')) {
    $('.some-box').slideOut(500, {direction: 'right'}).removeClass('open');
  } else {
    $('.some-box').slideIn(500, {direction: 'left'}).addClass('open');
  }
});

Does that look familiar? What makes this approach so weak is that you explicitly handle your UI behavior in a procedural manner. You tell the box to slide out or in, add classes, and check for those, and so on and so on. But what if another button triggers that thing? Ok, so you move the code to a function. But you still have to call that function. If other parts of the system depend on the state of the box, then this whole thing is going to be messy. So, what if we could instead escape this procedural hell and lay out the behavior in a bit more functional way? I tell you:

<div class="some-box" ng-show="selectedCar">
  <h1>{{selectedCar.model}}</h1>
  …
  <a ng-click="$root.selectedCar = null">Close</a>
</div>
…
<li ng-repeat="car in cars">
  <a ng-click="$root.selectedCar = car">{{car.model}}</a>
</li>

So, what do we have here? First, it’s a lot of the markup the jQuery example needs anyway. But pay attention to the Angular specific ng-attributes. We have the box which should show some sort of details of a selected car. The ng-show attribute on line 1 is quite clever. When there is no selectedCar in the current scope, the box will be hidden. As soon as someone clicks on one of the links of a car, the selectedCar will be set (see line 8) and the box will be shown. Magic!

So, instead of configuring your DOM element with every single step in its behavior, you provide it with one simple rule: “When there is a selected car, be there. Otherwise: Go to hell!”.

And to close the whole thing? Easy! Look at line 4 where we delete the selectedCar from the scope when someone clicks the close link. Angular takes care of all the rest for you! Ok, it doesn’t slide in or out but that’s where it gets even more interesting. Consider the following:

<div class="some-box" ng-class="{open: $root.selectedCar}">
  <h1>{{selectedCar.model}}</h1>
  …
  <a ng-click="$root.selectedCar = null">Close</a>
</div>
…
<li ng-repeat="car in cars">
  <a ng-click="$root.selectedCar = car">{{car.model}}</a>
</li>

So now on line 1 we changed the ng-show to a ng-class. The JS object we use as a value there will add all keys as classes to the div where their value evaluates to something other than null, undefined, or false. So as soon as we click a car it will add the open class to the box and we can handle all the sliding with some nice CSS:

.some-box {
  position: absolute;
  left: -300px;
  transition: left ease-in-out 1s;
}

.some-box.open {
  left: 0px;
}

Yeehaw! Everything is now where it belongs. You setup the layout in HTML and let the stylesheets do what they are best at: The styling.

As an added benefit, you don’t have to pay attention to how the whole data wiggling is done. In jQuery you would have needed code that manages that info. You’d also have to make sure the car for the clicked link gets to the box and is displayed. With AngularJS you can just use the selectedCar property in the box and display whatever info you need.

Check out the demo of all of this in action.

Root or no Root?

For those wondering why we use $root for the selectedCar in some places but not in others, that is a bit odd. We need to do all writing operations on the root scope, but the reading will work just fine without the explicit $root as Angular will just check the parent scopes (including $root) automatically. Using $root here is not perfect but a solution to that will have to wait for my next post.

Going Further

If you want to dive deeper into Angular make sure to checkout their homepage as well as their amazing Google Group and the #angular channel on Freenode.

Why AngularJS?

Why would you use Angular instead of one of the many choices listed at the top? Well first: Trust your gut feeling. If Ember is your thing, then who am I to tell you not to use it? But for me Angular is a little bit was Rails once was. Their way of doing things feels natural. Instead of reading a lot of documentation you start to assume how things might work and most of the time you are right. Here are a few more examples:

Trust the HTML

To add a click event to your Ember code you would need a template first (straight from the guides):

{{#view App.ClickableView}}
This is a clickable area!
{{/view}}

And then some JS code to wire it up:

App.ClickableView = Ember.View.extend({
  click: function(evt) {
    alert("ClickableView was clicked!");
  }
});

Compare that to the same thing in Angular:

<span ng-click="doStuff()">
This is a clickable area!
</span>

And some controller code to show the alert:

function MyCtrl($scope) {
    $scope.alert = function() {
      alert("ClickableView was clicked!");
    }
}

I love that the click event is declared in the HTML and the controller takes care of heavy duty tasks like displaying the alert. Also as much as I can see benefits in using handlebars, why not use HTML? You can still use handlebars if you want – just pre-process it and you get HTML which Angular will happily use. Of course, that works with any HTML templating language you can think of.

For those of you screaming: “DRY YOU IDIOT! DECLARING THAT IN THE SPAN IS NOT REUSABLE!!!” Have a look at Angular’s directives which are a built-in way for reusable components.

Trust the framework

Another big win for me when using Angular is the little stuff I no longer have to care about. Angular does most of the heavy lifting so that I can focus on the app on hand. For example with Knockout this is what a model would look like (again taken straight from their tutorial):

// Overall viewmodel for this screen, along with initial state
function ReservationsViewModel() {
    var self = this;

    // Non-editable catalog data - would come from the server
    self.availableMeals = [
        { mealName: "Standard (sandwich)", price: 0 },
        { mealName: "Premium (lobster)", price: 34.95 },
        { mealName: "Ultimate (whole zebra)", price: 290 }
    ];    

    // Editable data
    self.seats = ko.observableArray([
        new SeatReservation("Steve", self.availableMeals[0]),
        new SeatReservation("Bert", self.availableMeals[0])
    ]);
}

See the call to ko.observableArray on line 12? Angular just has no notion of such explicit declarations of what is should care about and observe. Everything on the scope is observed - end of story.

Trust the benchmark

Benchmarks have to be taken with a grain of salt, but there is one comparison of Knockout, Ember and Angular on jsperf.com which you should look at if numbers are your game.

Trust the tests

Angular itself is heavily tested with unit and end-to-end tests and leverages that power for you as a user of the framework as well. You can easily run their unit testing and E2E infrastructure.

And if you are a Ruby guy like me feel free to use my adoption of the Angular seed app which besides full Coffee Script, SCSS/Less and Twitter Bootstrap integration also features nice Capybara tests using Poltergeist and PhantomJS to run integration tests against Angular applications.

Give it a Try!

I could go on for a while but you really should just try it yourself. Try out the demo and start hacking on it.

Punch Quest - Optimizing UI Flow for IAP

Wed, 16 Jan 2013 17:11:02 -0800

I’m a little late to the party, but I recently discovered the exceptional iOS game Punch Quest and was immediately hooked. This beautifully crafted mash up of Jetpack Joyride and Streets of Rage (or Final Fight if you were more SNES than Genesis) transfixed me immediately. I was addicted to the quick rounds of pick up and play simplicity, the explosions of Punchos upon completing a quest and the joy of punching a cyclops right in the eye.

Punch Quest made headlines not only for it’s high Metacritic rating, but unfortunately for its failure with the freemium model and unorthodox switch from free to paid. I only discovered the game after it started charging $0.99 and felt that the purchase was completely justified. I enjoyed playing so much that I spent additional dollars on in-app purchases (IAP). Importantly, Punch Quest fulfilled one of the most important criteria for a successful freemium game: as a player, I had more fun as a result of spending money on IAP.

Reading on their failure to monetize the over 630,000 installs to an acceptable level, I took a critical look at the game’s UI. As a game designer, it is my opinion that it is our job to ensure that game mechanics, economy design and UI/UX design all work in harmony to ensure success in a freemium game. But based on my experience working with other designers (and artists and engineers) I know that there are very few developers out there who enjoy doing UI/UX design. As a result, this critical component of a game often suffers.

As games become more browser, mobile and touch based, the importance of UI/UX will only increase as a factor of your game’s success. With that in mind, I offer some advice on how the fantastic Punch Quest can optimize its UI flow to enhance IAP and hopefully bring in more money for RocketCat.

The core loop

When designing for freemium, it is extremely important to pay close attention to the core loop of the game. What are the basic actions that the player takes over and over again with minimal deviation? Small details can make a big difference when it comes to the core loop. To illustrate the point, I am going to compare Punch Quest to Bejeweled Blitz. On a glance, these two have very similar core loops, but close inspection reveals why one has been a free to play disapointment while the other is printing money.

So, here I am in Punch Quest, happily punching away:

When my punchzerker is knocked out by one of those annoying squiddies. I am then served up the quest screen, which is key part of the core loop.

Quests give me goals in each round and keep me saying “just one more punch.” I hit the next button and am treated to a stats screen loaded with options:

And if I am following the path of least resistance, I will hit the large Retry button in the bottom right corner and start punching again. Sometimes I will visit the shop (especially if I am led there by gnomey to buy a quest item) but if I maybe visit the shop after every five or ten rounds of play.

Now let me compare this with the core loop of Bejeweled Blitz, a game that I think gets monetization design right and as proven by its distinction as 2012’s #7 top grossing game on iPhone. Here I am happily matching 3:

When I run out of time. Assuming I didn’t earn a new medal, I am immediately shown the high score screen:

This screen is very important. As one of the 20% or so to connect to Facebook on my phone, my desire to top my friend Doug’s score and prove I am better than him is what keeps pulling me in for “just one more match.” After pressing play, I am shown the boost screen:

I can spend the coins I have earned to buy boosts that will help me top Doug’s score for the next 3 rounds. I must hit play again before kicking off my next 60 second burst of matching bliss.

Now, these two games have a lot of obvious differences, but why is it that Bejeweled Blitz is raking in the cash while Punch Quest failed to meet expectations?

Making purchases present

Bejeweled Blitz and Punch Quest both follow a similar model. In each round, the player earns currency. He can spend that currency on additional items, and if he does not want to grind to earn enough currency for an in game item, he can purchase currency directly for real money.

Punch Quest features a mixture of permanent upgrades, cosmetic items and consumable boosts, whereas Bejeweled only has boosts. But the important difference is Bejeweled Blitz serves the boost screen as part of the core loop. The player is encouraged to spend currency - or at least made aware that he can spend currency - before every round of play. Purchasing is very present.

Punch Quest has boosts, but they are not very present for the player. It takes the player two taps off the main menu to reach this boosts screen. And I have to be honest, I did not use a single boost (or even visit this screen) on my first playthrough to level 50. This is a stark contrast to Bejeweled Blitz, where the player is encouraged to use several boosts every 3 rounds of play in addition to more expensive, rare gems.

Add an add coins button

It is a small detail, no doubt, but if you look at Bejeweled Blitz you will see that outside of gameplay, there is always an Add Coins button next to my coins display. The one screen without an Add Coins button is the Daily Spin slot machine, but on this screen,there is a Get Spins button which serves largely the same function.

In Punch Quest, the player does not see the Buy Punchos button as part of the core loop. He is only presented with this option when visiting the store, which as I noted above, happens once every few rounds.

I think that by combining these two elements - a Buy Consumables screen and a Buy Punchos button - and adding them to the core loop of the game, Punch Quest can increase its revenue. But I also think the game would have to add a few additional options for enticing consumable purchases.

Peer pressure

The high scores table is core to the player’s experience in Bejeweled Blitz. The peer pressure of trying to top a friend’s score each week is a big part of what motivates the player to use earned coins to purchase boosts and rare gems, and hit the Play button for just one more round. Punch Quest’s core loop features a lengthy stats screen, that from my personal experience, I’ve never paid that much attention.

Although we can expect that less than a quarter of the game’s players will sign in with Facebook, based on Bejeweled Blitz’s experience, we can also expect that those connected players are 60% more likely to be payers, as revealed by TinyCo in a June 26th blog post.

Wrapping up

These are three small suggestions, but I believe that if implemented properly the already excellent Punch Quest could boost its revenue and hopefully be in a solid financial position to keep developing updates and awesome new games. But my broader point is that when you are close to shipping your freemium game, take an extremely close look at the user’s path to spending money. A few small optimizations can be the difference between a chart topping, freemium success and a headline that calls you out as “the iPhone’s hottest game, but … a financial flop.”

5 UI/UX tricks behind CSR Racing's $12 million month

Fri, 16 Nov 2012 09:57:11 -0800

By Ethan Levy

Back in August, Natural Motion made big headlines when it was reported that their hit game, CSR Racing, had surpassed $12 million in monthly revenue. The drag racer spent most of the month of July dominating the iOS top grossing chart and enjoys a position in the top 25 on both iPhone and iPad today. Based on my model for iPhone/iPad revenue, I estimate that CSR Racing has generated a little over $5 million in worldwide sales in the past 30 days.

CSR is a fantastic, polished and fun experience, the essential foundation of developing a top grossing game. But I wanted to take a look at 5 UI/UX tricks the game utilizes to help drive its exceptional revenue.

Strong top of the funnel

When designing a freemium game, you are constantly considering “the funnel”. How many players are downloading your game each day? How many of those players even open it up? How many play for more than one day? How many spend money?

Not to dismiss the game, but the core mechanic of CSR Racing is very simple. I could code up a demo of the drag racing mechanic of revving the engine, shifting gears and hitting the nitro boost in less than a day. In CSR’s execution, not only is this mechanic well tuned but it also looks incredibly hot.

For a mechanic so simple, the quality of the experience really comes through at the top of the funnel - before the player even downloads the game. Whether he sees a friend playing it or is browsing screenshots on the iOS store, the game screams quality. This strong top of the funnel is key to attracting the large download numbers that turn into revenue at the bottom of the funnel.

Loaner cars

Very intuitively, the game sells cars for a mixture of earned and purchased currency. An issue freemium games often struggle with in motivating players to cross over the penny gap and spend money for the first time is that players don’t know the value they will be getting for their hard earned cash.

To create a sustainable business, a freemium game must enable a player to have more fun by spending money. CSR racing has a brilliant feature which allows the player to experience a taste of the fun each day.

Each day, the player can participate in a daily challenge three times. What is unique about this challenge is that the game “loans” you a car to use. Instead of using the same car that the player earned by grinding the good old fashioned way, he can experience one of the game’s many premium cars and how good it feels to smoke the competition when he wins with the help of this luxury model. The value of spending money is very clear to the player because he gets to experience it every day.

Incentivized connection

Freemium games frequently give out small amounts of purchased currency, another method of giving the player a taste of the fun they will have after spending money. CSR Racing uses this common tool to incentivize connecting to the game via Facebook.

This may seem trivial; if the player is purchasing gold in the $5 package, this represents a little less than $0.30 of value. Why is incentivizing a Facebook connection so important? According to a June 26th post on the TinyCo blog, those who have connected with Facebook are 60% more likely to pay in TinyCo games. These Facebook users are also monetizing 138% higher than normal users. If TinyCo’s findings hold true across game genres and companies, Natural Motion stands to make lots of money by encouraging players to race with friends.

Premium goods are present

When I give talks on designing for freemium, I like to hit home the importance of making sure your premium goods are present for the player. Your monetization should not be thrust in the player’s face continually, but he should see the ability spend money as part of the core loop of playing the game.

CSR Racing is all about filling your garage with sweet rides. Core to the experience is shopping for new cars, lusting after the high rez models of the same luxury brands that core players lust after in real life. CSR Racing does not ghettoize luxury cars off in a special shop that is harder to access (as some games tend to with a premium cash store), instead placing them side by side with cars purchased for earned currency.

The road to unlimited spending

Another topic I frequently highlight when speaking about the design of freemium games is my great love for consumable based economies. Not everything must be consumable, but if you design a game with only permanent goods, you are effectively putting a cap on the amount an enthusiastic player can spend in your game.

When the player loses a race in CSR, the Mechanic is there to help. He can tune the player’s engine, giving him a performance boost for a limited number of races.

Assuming the player buys the $5 currency package, a 15 race tune up means spending about $0.64. Since races tend to be 15 to 20 seconds long, the palyer is spending those 64 cents on about 4 minutes of bonus fun. In a high quality game like CSR Racing where players will come back for weeks and weeks of engagement, the amount they can spend on the Mechanic is limitless.

These are just 5 of the many little UI/UX tricks a game like CSR Racing uses to turn a fun experience into a top grossing game. If there are even better tricks the game utilizes that I haven’t highlighted here let me know on twitter or drop me an email at info@quarterspiral.com.

Simpsons Tapped Out: Why EA doesn't need new IP

Mon, 05 Nov 2012 11:08:00 -0800

By Ethan Levy

In last Tuesday’s quarterly earnings report, EA touted the success of the freemium Simpson’s Tapped Out for iOS as one of the stand out successes of the past few months. EA’s Frank Gibeau was quoted as saying “another breakout hit in the fiscal quarter was The Simpsons: Tapped Out, a free-to-play mobile title which launched in August and was the #1 grossing game on iOS for most of the last 4 weeks” (via Games Industry International).

Just how successful was the title? Using the numbers for top grossing iOS titles I reverse engineered from Supercell’s recent success, I estimate Tapped Out has generated $29.6 million in sales for EA. $20.7 million after Apple takes its cut. This represents 6.6% of EA’s reported $314 million in digital revenue for the quarter.

I have no idea what Tapped Out’s budget was, but I can guarantee a very healthy return on investment for the title, even considering that it has to shoulder some portion of a licensing deal to use The Simpsons’ brand. No doubt it is a mere sliver compared to the cost of the critical (and probable commercial) failure, Medal of Honor: Warfighter.

By my count, EA has developed or published 35 new IPs this console generation with one more on it’s way courtesy of Insomniac’s Fuse (console, handheld and PC). Hundreds of other games were released in existing brands like Battlefield and Need for Speed and licensed brands like Madden, Lord of the Rings and The Simpsons.

In September, Gibeau told Games Industry International “right now, we’re working on 3 to 5 new IPs for the next gen.” Of those games, I only know that a new IP from Mass Effect Executive Producer Casey Hudson has been teased publicly.

EA’s stated strategy is fewer, bigger brands. Of the many new IPs developed for this generation, only Army of Two, Dead Space and Dragon Age continue to see new versions. As far as I can tell from publicly facing information, creating innovative, new IPs just isn’t a priority for the organization.

Which brings us back to The Simpsons: Tapped Out and its $20.7 million in gross revenue since releasing in August. Big brands + big marketing budget + high production values = $$$. This is the EA formula. They may have been late to the mobile & tablet freemium party, but now that they are here they will outcompete the Dragon Vales and Tiny Monsters of the world. This formula may have finally run its course in the core space, where 80+ rated Lord of the Rings, James Bond and Godfather games have all fallen out of favor with gamers’ wallets.

But as Tapped Out proves, the players who enjoy the games produced by this formula have simply moved to another platform. EA’s digital future has less to do with big, risky new IPs like Mirror’s Edge or Brutal Legend and much more to do with the huge return on investment proven by The Simpsons’ $20.7 million breakout success.

19 new IPs developed by EA this generation: Army of Two, Boogie, Boom Blox, Create, Dante’s Inferno, Dead Space, Dragon Age, EA Playground, EA Sports Active, Facebreaker, Grand Slam Tennis, Henry Hatsworth, Mirror’s Edge, Ninja Reflex, Saboteur, Skate, Smarty Pants, Spore, Zubo.

16 new IPs published by EA this generation: Brutal Legend, Bulletstorm, Crysis, Death Spank, Gatling Gears, Hellgate: London, Kingdoms of Amalur: Reckoning, Left 4 Dead, Orcs & Elves, Portal 2, Rock Band, Shadows of the Damned, Shank, Spare Parts, The Secret World, Warp.

How much does the #1 game on the iOS store earn in a day? $199k (I think)

Fri, 26 Oct 2012 13:52:05 -0700

By Ethan Levy

Having a #1 grossing app on the iPhone or iPad is the dream of every game developer who ever downloaded a copy of xCode. Few games reach this lucrative goal and information on the top spot’s true value is a closely guarded secret. Even if you are lucky enough to achieve the #2 spot on the chart, there is no ceiling on what the #1 spot could possibly be worth.

My best guess? In the United States, an average day in the top grossing position for the iPhone means $199,245 in gross revenue. iPad $55,789. After Apple takes its cut, this is about $139.5k and $39.1k respectively.

How did I, who has never personally sold a game on the iOS store come to this conclusion? Follow me on an assumption laden journey as I show how I arrived at these figures.

I am probably wrong, but not that wrong

I backed into these numbers using a variety of public data sources - none of which I can personally verify - as well as a few guesses. I am certainly wrong on the exact numbers, but suspect that I am not that wrong.

Also, this estimate is very timely. I expect that total iPhone and iPad revenue will continue to grow over time as more devices are sold in the marketplace and gamers become ever more comfortable spending money in freemium games. The apex of the iOS market’s total revenue is a long way off, and the value of each of the positions in the top 100 grossing will continue to grow until a new platform comes and disrupts the iOS market.

Caveats out of the way, I will now explain my assumptions, show my work and share my estimated value of each position in the top 100 grossing chart in the US for iPhone and iPad.

Assumption #1: Supercell’s $500k days

The rosetta stone of this analysis came from a recent New York Times article on the breakout success of Finland’s Supercell. The key piece of data here is that “Supercell executives say its two games are currently grossing over $500,000 a day, which translates into about $350,000 a day in revenue for Supercell after Apple takes its 30 percent cut on transactions through its iOS App Store.”

This article was posted on Oct 8th. So, my assumption here is that Supercell’s average daily revenue worldwide was about $500,000 for the 30 day period from Sep 8th to Oct 7th.

What was extremely valuable about this data is that in the 30 day period, Supercell had two games, Clash of Clans and Hay Day, in the top 100 grossing charts for both iPhone and iPad in the US. Using App Annie, I made a table of Clash of Clan’s iPhone and iPad rankings and Hay Day’s iPhone and iPad ranking in the US top grossing chart.

Assumption #2: 42% of iOS revenue comes from the US

On Jun 20, App Annie released a very helpful infographic, Game of Phones. The key piece of data here is that 42% of iOS revenue comes from the US. I assume that this number has not changed significantly since it was published.

Assumption #3: iPad revenue is 28% of iPhone revenue

To arrive at this conclusion, I used Apple product data sourced from the website Asymco.

Using the Asymco data, the estimate is sales of 383 million iPhones and iPads split between ~274.7 million iPhones and ~108.2 million iPads. Therefore, iPads represent 28% of the total pool of devices.

I assume that spend on these devices follow the same patterns and that revenue per device category is relative to number of devices. Therefore, I assume that total revenue from iPad devices are 28% of total revenue from iPhone devices.

Assumption #4: Revenue follows a power law

In deciding on an equation to use to model the average daily revenue per US chart position, I initially tried a simple parabola. Although I was able to find numbers that felt reasonable (#1 position grosses $138k) the curve looked too round. I wanted to find a model that had a really sharp knee in it.

So, I sent this picture to my college roommate and bona fide rocket scientist Morgan Hendry:

Morgan suggested that I try out a power curve.

Revenue = Constant + (Coefficient^(100-Rank))

The idea here is that in modeling revenue, Rank 100 would represent 0 on the X axis and Rank 1 would represent 99 on the X axis. Coefficient is the assumed value of the #100 spot on either the iPhone or iPad chart.

Assumption #5: The #100 app makes $3,000 on the iPhone

For this, I have no data to back it up. Not even hearsay. I simply played around with the equation until I found a number that felt right. That number was $3,000 for the iPhone, and using the 28% ration above, $840 on the iPad.

Assumption #6: Revenue is pooled very sharply at the top

With all the other factors in place, it was time to find a Coefficient that, using my daily ranking tables for Clash of Clans and Hay Day, would give me about $500,000 in average daily revenue (worldwide) for the two Supercell games for the 30 day period cited above.

With some trial and error, I found a coefficient of 1.131. Using all my assumptions cited above, this resulted in an average daily revenue (worldwide) of $505,039.81 for the two Supercell games. Bingo!

What’s in a rank?

Given all the assumptions clearly laid out above, I generated a table for the estimated average daily value of each position in the US top grossing chart for iPhone and iPad. Here is the top 25:

I know there are many out there who are more experienced than me at math, data mining and modeling, so I expect there to be many suggestions on how to improve these estimates. Also, there are real people with real data that will help inform these estimates. The goal here was not to build a perfect model, but arrive at a reasonable ballpark given publicly available data sources and more importantly, to start a conversation. If you would like to contribute to these estimates in a meaningful way, please reach out to us @QuarterSpiral or by emailing info@quarterspiral.com.

Why I love opinionated tools for software development

Tue, 16 Oct 2012 12:55:00 -0700

By Alex Kohlhofer

The tools and services made by opinionated people can be a blessing and a curse. They are a blessing if the team is ready to fully embrace the philosophy that shaped them; they are a curse if the team is not fully bought into the tool’s approach to working and want to modify to map to the way the team is accustomed to.

When selecting tools and services to enhance your team’s productivity, there are two fundamentally different options:

The team can model its workflow around the tools they’ll love to use
The team can select/customize/hack the tools that fit their desired workflow

Option 1 can transform how you work. It is also a lot easier because people who go to the effort of creating strongly opinionated tools & services put a lot of effort into understanding and solving specific problems. Unless the primary goal of your venture is to solve those very same problems your home-brewed solution is likely inferior to the opinionated solution. And if it is not your team may want to consider a pivoting on the strength of your home-brew!

When a team tries to shoehorn a great tool into a work flow it was not intended for, the result is generating a lot of friction while extracting a fraction of the tool’s potential value. There are of course some tools that impress with seemingly infinite customization and flexibility. They try to fit every team’s needs. More often than not these Swiss Army knives leave your team confused with complexity and options no one cares to master. Tools that do anything while doing nothing well don’t increase productivity, they tax it.

What is an opinionated tool?

Simply stated, an opinionated tool is a tool that has an opinion about how a task should be done, and enforces that opinion through its interface and implmentation. For example, a Phillips head screwdriver has an opinion about how you should fasten materials together - it believes that you should use a screw with a cross indentation on its head. You of course can use the Phillips head’s handle to hammer in nails with flat heads, but you are much better off using a hammer for this purpose.

Although the idea of an opinionated tool seems obvious when looking at physical hardware, it is less obvious when applied to software development tools. Metaphorically speaking, lots of teams pick up a phillips head screwdriver and attempt to use it for hammering because hammering is what they are used to. You can generally spot an opinionated tool because:

It has few settings and these settings do not affect fundamental properties.
The creators expect your team to do things in certain ways and the tools are very vocal about it.
Your team either loves it deeply or hates it passionately.
It force your team to see and act differently than they are used to.
It not only helps your team get the job done but also make them better at what it they are doing.

At Quarter Spiral, there are two opinionated tools we have implemented in our work flow from our first sprint.

IDoneThis

IDoneThis sends you an email at the end of the day asking you what you got done. In the morning it distributes a digest of all the responses to the team. Dead simple. At Quarter Spiral these updates arrive about half an hour before the daily stand ups so that every team member shows up prepared and equipped with knowledge.

IDoneThis delivers on their promise: “Our approach is to build software that you don’t have to remember to use. We’re focused on keeping it simple and lightweight, because software should amplify what you get done, not get in the way.”

Their blog is full of productivity wisdom as well.

Pivotal Tracker

You are agile and you do some flavor of scrum. But are you actually reaping the benefits of agile methodology? Do you know your team’s velocity? Are your estimates consistent? Pivotal Tracker has the lofty goal of keeping you “on target with Tracker’s continuous, automatic prediction of milestone completion dates, based on your team’s performance.” And that is exactly what it forces on you. No excuses, no escape. Brilliant.

In conclusion

Quarter Spiral is in the business of creating services, too. We are also very opinionated about how game publishing should work. We work very hard to someday soon earn our place in your tool belt so you can create and play even better games. If you are a game developer with a strong opinion on how game publishing should work, reach out to us. We’d love to hear your opinions as we shape our service.

6 process tips for running a virtual team

Wed, 03 Oct 2012 09:07:00 -0700

By Ethan Levy

Before Alex and I decided to start Quarter Spiral, we both spent a significant amount of time as Producers leading teams at BioWare. In the San Francisco studio, he led the platform technology team and I ran the game team. Although we both have creative backgrounds as designers (he graphics, me games) we both learned to love process. As a team leader, I put down the game design document and picked up the process as my tool of quality and control.

So the very first day Alex and I met to discuss our product vision, we opened up Pivotal Tracker and wrote stories in a backlog. The first full time day for Quarter Spiral, the three co-founders met on Skype for sprint planning. Before the second day was over, Alex and I had already held an ad hoc meeting to review the process we cobbled together; dissatisfied with some kludginess we began to make changes.

Quarter Spiral has been a virtual team from day one. Being virtual is key to keeping our burn rate low and working cohesively while spanning from the west coast of California to the northern tip of Germany. As such, a strong focus on process has been key to keeping our team humming as we build product. Along the way, we’ve picked up some tips and tricks that keep our virtual team strong.

Scrum for everyone

We love scrum. It is an effective way to ship product, keep software development agile and hold team members accountable. But it is largely used in the context of programming. On our team we capture everyone’s weekly goals in the framework of user stories that drive business value. Although much of the work I do could best be described as business development, strategy or customer development, all of it is captured as user stories. For instance, I am earning 1 point by writing this post.

By viewing all stories within the context of scrum, each member of the team is involved in work outside of his discipline and held accountable for delivery. I can’t just take long coffee meetings with possible leads without delivering value. I am involved daily in the software development process just as our Rails developer is involved in the business development process.

Love the hangout

Initially, we did our daily stand ups as pure audio calls using Skype. After attending an outstanding talk from ngmoco Sweden’s Senta Jakobsen at GDC Europe, we immediately switched to doing video calls using Google Hangouts.

Group audio feel like conference calls. It’s informal. It’s easy to check out. It’s easy to feel disconnected from your team. A small change, but using video chat was the difference between feeling like another software team at EA and feeling like a scrappy band of startup co-founders.

Conflict resolution

Conflicts will happen. It is inevitable. When they do, a danger in any office environment - particularly a virtual one - is to address them over im or email. Tone of voice and nuance are gone. Instead the reader interprets based on his current mental state and can easily misread statements dramatically.

The quickest, cleanest way to resolve a conflict is to speak with the other person, and ideally to see them. If you disagree with someone, dial them up on Hangouts instead of DMing them on Hipchat.

Focus on value

A core tenet of scrum is that your activities should be focused on proving business value. This is especially critical in an early stage startup with no paychecks and no revenue. Each team member should be focused on making the right decisions based on the business value he can prove to his team. Technical debt and refactors can wait if they are not truly critical. Design specs don’t have to be written up for services that can’t be worked on for weeks or months.

It is easy to cut out parts of the scrum process either on purpose or through laziness. The part that your team cannot afford to skip is the demonstration of value at the end of each sprint. Each team member needs to be held accountable for delivering tangible results each precious week of your virtual team’s life.

Review your process

It is easy to review a product, because a product is not a person. It is easy to look at a product each week and point out what is and is not good enough.

It is harder to review a process, because what you are truly reviewing are people and their behaviors. If you do not have a strong foundation of trust or are the type of person who shies away from conflict, it can be hard to tell your only other team member that they are falling short of your expectations or they are working on the wrong tasks.

In addition to a show of value each week, we do a sprint retrospective. Sometimes these are incredibly short “Anyone have any issues from last week? No? No? Good, let’s plan our next sprint.” But sometimes we bring up issues and modify our process accordingly.

One of the best things to do is call yourself out. If you know you didn’t quite deliver last sprint, it makes a strong statement to call yourself out in a review instead of hoping that no one noticed.

Know your burn

It can be hard to talk about money matters, especially on a small, virtual team. Issues around money are typically viewed as private, especially if there are domain splits between “business guy” and a “product guy” or similar. Keeping critical information around money hidden can be disastrous, especially if money matters only come up on the brink of bankruptcy.

Among a team of co-founders, you should meet monthly to discuss money. At minimum, each member should know your burn rate (money spent each month) and runway (months solvent at anticipated burn rate).

Being transparent about money matters can help prevent disaster. For instance, if it is clear to the team that you have 3 months of runway left, it is more natural to discuss cutting salary (if you are taking any) cutting contractors (if you are paying any) or taking individual freelance work (if it is an option). Team members may suggest personal sacrifices for the sake of the shared good.

Openness and honesty around a virtual team’s financial responsibilities is key. No team member should have to guess whether or not they will have a job next month.

Devbox setup with Vagrant

Wed, 26 Sep 2012 10:14:00 -0700

By Thorben Schröder

As development work here at Quarter Spiral is heating up and more people are starting to work on the code base we needed and easy way for people to set out their development environments.

Conducting a symphony of services

If that sounds like a problem that has been solved before, that’s right. But due to the nature of Mission Kontrol we built everything as a big concert of small services from the get go. Meaning that even now we already have more than a handful of webapps that have to run and speak to each other. Starting, stopping, configuring and updating those services has become more and more painful as we add new services more often than not. While none of that work is really rocket science carrying it out took up larger and larger amounts of our precious time.

Laziness driving goodness

With many small tasks that had to be carried out repeatedly by every single team member it seemed best to automate those steps so that we could spend our time solving actual problems instead. Queue our new Vagrant box.

The basic idea behind Vagrant is to put together virtual machines that can be used as encapsulated development environments that just works everywhere. So instead of setting up all the dependencies (e.g. databases, caches, …) for every developer you only have to install Virtual Box and Vagrant itself and boot up a machine that comes with everything configured and enabled so you can start hacking right away. As a pretty lazy bunch we opted against building the whole thing from scratch and just used the official box used to test Rails patches (rails-dev-box) as a foundation.

The benefits of laziness

In addition to all the dependencies we need for development our box also pulls off a few other neat tricks.

1) Never miss a new repo

As mentioned above it happens that we add a new Git repository to our Github account more often than not. To initially setup the box and also stay up to date we included a script that runs on startup and queries Github for all our repos. If it detects one that has not yet been cloned it will do so.

2) Manage services with ease

The whole idea behind the box was to not care about managing all the services any more. So we built metaserver. Metaserver is our development dashboard and allows us to easily get an overview of our services, start/stop them, browse their logs etc etc.

We can start that dashboard with a single command and let it take over from there. Behind the scenes metaserver manages the server processes of all the services via plain Unix processes and as all of them are configured by environment variables it will also expose the URLs of the services to their respective processes. This way we ended up with a really dead simple development environment that saves us a ton of time every day!

In summary:

As a new developer you simply: clone the devbox, boot it up, run the metaserver and you are ready to go. Piece of cake.