What Went Right

1. Brainstorm to living room in one easy step.

We only have twelve people on staff, and we all work in one big room. Our original business plan said nothing about the creative dynamics of large versus small teams, but this is probably the single best result of our model. Granted, the acoustics of our wood-floored, brick-walled loft space stink because I’m too cheap to buy rugs, but we have a comfortable, casual, light, and quick workflow that allows anyone to blurt out ideas and have them propped or chopped on the spot. A small team doesn’t need a lot of hierarchy, management, team meetings, strike teams, and a lot of organizational overhead, so we can focus our energies on being creative. It’s hard to believe we didn’t consciously plan this, but our emergent culture turned out to be a great side effect of our model.

For example, substantive, creative conversations often began when someone cracked a joke and the rest of us riffed on it. Unlike at a big company, where authority is always out of earshot, at Wideload we put those gems straight into the game! The dance battle in Stubbs emerged this way.

2. Freedom from the publisher’s shackles.

Because we’re small and our overhead is low, we were able to spend nine months working on various game ideas, mechanics, and story elements before we signed a publishing deal. This allowed us to take our time and experiment. It also gave us the power to say no to a few deals that weren’t consistent with our commandments. We actually came within a few feet of signing a publishing deal early on with a major publisher, but it would have required us to give the publisher final say on creative decisions. We thought the deal could have been a disaster in a worst-case scenario, so ultimately we passed on it. Being able to reject a publishing deal could be considered having leverage, and for independent developers that’s pretty rare.

We also had the ability to miss milestones. We didn’t want to miss milestones, but because we could effectively manage our cash flow without having to live hand-to-mouth with each milestone payment, we avoided the situation of our publisher using money to take control of our project.

3. Cost structure.

A big problem facing game developers is the budgeting process. In order to secure project funding, you need to estimate cost and schedule on day one. Developers don’t have a constant development platform (hardware and software are always changing) so making this projection requires a little voodoo science. Publishers tend to expect developers to stick to their budget and schedule, and often times that doesn’t work.
Stubbs shipped four months behind our initial plan, but two circumstances made our lateness workable. First, our overhead was low because our staff is small, and second, our contractors deliver specific assets to us for specific fixed prices, so if scheduling failed, the asset price did not increase like it would have if it were being developed by a full-time employee. As a result (to a certain degree) our contractors assumed schedule risk on our behalf.

The table below shows how much money the Wideload method saves per schedule slip, compared to the costs incurred by a fully staffed team.

There were also points in the development of the game when we needed a little time to design something before opening the asset floodgates. We were able to prototype animation ideas for feel and gameplay without having a bunch of animators waiting around for us to get the plan together. Once our animation system and mocap list was ready, we pulled the trigger and got it done quickly.