Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Vector Unit's Hydro Thunder Hurricane
View All     RSS
October 24, 2014
arrowPress Releases
October 24, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Postmortem: Vector Unit's Hydro Thunder Hurricane

October 27, 2010 Article Start Page 1 of 4 Next

[EA and Stormfront Studios veteran Matt Small shares successes and defeats in his small team's transition from large studio to small startup while developing Hydro Thunder Hurricane for Xbox Live Arcade.]

"So I've been having these thoughts... about quitting and doing the small games thing."

That line popped up in my chat window on a night in the summer of 2007. My pal Ralf Knoesel and I had been working on a little side game project, just for kicks. Or at least we'd been talking about working on it. The problem was we had regular paying jobs. And what we liked to think of as lives. Progress was achingly slow.

Every developer I know daydreams about breaking away at some point to work on their own game. Ralf and I had put over 12 years apiece into established companies, most recently me as an art lead at EA Redwood Shores and Ralf as a programming lead at Stormfront Studios. We had a little money saved up, and we were tired of working for The Man. Ralf's revelation was all the push I needed.

By January 2008 we'd quit our jobs, liquidated every personal asset we could live without, upgraded our PCs, and incorporated a new company -- Vector Unit. We absorbed details we'd never had to think about as employees: the nuts and bolts of small business management, contract negotiation, group health plans.

The game we set out to make was designed from the start to be a small-scale but big-attitude water racing game for XBLA or PSN, a throwback to classic arcade racers like SF Rush, and of course, Hydro Thunder.

We went with water because we love the emergence you get from the dynamic surface, and aside from minigames in titles like Wii Sports there hadn't been a decent water racing game in about 10 years. Plus we'd worked together years before on the boat combat title Blood Wake for the first Xbox. We figured we'd start with something we knew we could make.

Six months later we had a game engine, a playable PC prototype, and a PowerPoint pitch that we'd practiced in front of friends so many times I could recite it in my sleep. We shopped it up and down the West Coast publishing gauntlet, and eventually caught the interest of Microsoft Game Studios.

It was through our conversations with Microsoft that the idea of tweaking our design to fit the Hydro Thunder license first came up. We believed in our prototype, but we also knew that a known license would bring much-needed publicity to our first title as a new studio.

MGS acquired the distribution rights from Warner Brothers, who had just purchased the license from the recently defunct Midway Games. We rewrote our design docs, increased our scope threefold, and lawyered our way through the contract negotiations.

In April 2008 we finally signed the deal and received our kickoff funding and our first 360 dev kits. Hydro Thunder Hurricane was off and running.

Well, "running" might be an overstatement. We still had to hire a team, find an office, prove out our new design in an updated prototype, and get our PC engine running on the 360.

When we started Vector Unit, we figured the experience we had as leads managing large teams at established game development studios would scale smoothly to the development of a smaller game project. If anything, we thought, it would be easier -- fewer moving parts. To some extent that ended up being true. What we didn't count on were the countless small surprises that small game development had in store for us.

What Went Right

1. In the beginning there were Tools

When we began working on our original prototype, the very first technical task -- before the game engine itself -- was a suite of production tools. We knew that content creation would be our critical path, and our plan was to keep our core team small and outsource the bulk of the art.

We needed a pipeline that would be easy for contractors to pick up and learn, allow for rapid iteration with minimum build times, and be adaptable enough that we could add features as needed without having to rebuild existing assets.

We researched a number of third-party game development suites but decided against them. Engines like Unreal were way out of our price range and delivered more power than we really needed. And the indie suites like XNA and Torque didn't give us the low-level control that we figured we'd need. We decided early on to roll our own, and it proved to be one of our best decisions.

(click for full size)

The base art asset pipeline came first. Ralf developed a data-driven shader system that integrated into Maya with a shader plugin supporting full-featured hardware rendering in the shaded viewport using the game shader code. Artists could add shader layers like normal or detail mapping and see the results of their tweaks immediately, iterating freely without having to export into game. Over the course of development this simple feature saved us weeks of development time, as our artists could work in a way that felt immediately natural to them.

The game editor, PFX editor, and other tools all export to a common format (xml or json), which the game itself builds at runtime, baking updated assets on demand. For the artists, this means that even for our most poly-heavy and texture-rich assets, the time it takes from hitting the export button in Maya to flying around the assets in game was never more than 30 seconds and usually much less. The tools also support live telemetry, which reduces the need to re-build when tweaking any parameters.

Finally, throughout development we maintained a working PC build of the game. Although final assets were always tested on the 360 and evaluated on TVs, the PC build freed us up from having to provide dev or debug kits for outsourcers, and also made it easy for team members to work at home and maintain flexible hours.

I should mention also that we didn't build everything ourselves: We used FMOD for audio, Bullet for collisions and rigid body physics, and the truly wonderful Subversion (specifically TortoiseSVN) for version control.

Article Start Page 1 of 4 Next

Related Jobs

Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer
Activision Publishing
Activision Publishing — Santa Monica, California, United States

Tools Programmer-Central Team
Bluepoint Games, Inc.
Bluepoint Games, Inc. — Austin, Texas, United States

Senior Graphics (or Generalist) Engineer
Intel — Folsom, California, United States

Senior Graphics Software Engineer


Megan Fox
profile image
I wonder about this line: "We researched a number of third-party game development suites but decided against them. Engines like Unreal were way out of our price range and delivered more power than we really needed."

I can totally get it being way, way overkill, but there are other examples of studios of your scale using UE3 and fitting it within what I imagine are equivalent budgets. Is this a case where you contacted them and were quoted an astronomical price up front that was unaffordable, a case where the terms ended up with what you felt was too much back-end being spent on the license, or was it more that you just rejected it first thing because it really was overkill / didn't even seem worth considering / etc?

(I realize any price/deal offered would be under NDA, but hopefully my question is in general enough terms)

Matt Small
profile image
Megan - Well, our price range was pretty low :-). And at the time (two years ago) our understanding was that UE3 was not offering substantially scaled-down licenses for small games. We didn't negotiate directly with them however. Since that time, particulary in the last year, they've been much more aggressively going after the small games market, so I wouldn't be surprised if they have some attractive licenses for indie devs.

I should have also mentioned that the more we talked about designing our own suite of tools, the more it felt like an important strategic goal for our studio. We were able to retain ownership of all our tools and technology for HTH, and so now we are able to move fowrard on new projects with an established engine and pipeline already in place....and one we don't have to pay for.

sean lindskog
profile image
Thanks for sharing your thoughts, and congrats on making it all work. :)

Regarding tech:

I lean strongly towards using as much middleware as possible (I use PhysX, FMOD, Ogre3D, CEGUI, and several other 3rd party libs, tools, and exporters). But I understand your point about making good production tools, especially when working with external contractors. I don't think it's universally true,l but in your case perhaps writing your own tech was the best approach.

Cullen Waters
profile image

This is the best post-mortem I've ever read, thanks so much for sharing your team's experiences.

Robert Sanchez
profile image

As one who has hit #2 on the HTH leaderboards... (heh) and also one who has over 12 years at a major software company... this hit home. This is an awesome postmort and all I can do is say thank you and your now on my Hero list. :-)


David Wessman
profile image
This postmortem is now required reading for my students. Thank you for sharing your experience and insight!