Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Vector Unit's Hydro Thunder Hurricane
arrowPress Releases
November 28, 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

DeNA
DeNA — San Francisco, California, United States
[11.28.14]

Senior Build and Release Engineer
Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States
[11.28.14]

Game Engineer
The Workshop
The Workshop — Marina del Rey, California, United States
[11.28.14]

Programmer
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[11.28.14]

Mobile Developer C++ (m/f)





Loading Comments

loader image