Studio transition – start up to going concern

A friend linked me this the other day.

A blog about the difference between start up “get it done” mode and on going development in terms of scalability and maintenance

It’s quite an interesting read, and it puts into words some stuff that I’ve seen over the years in personality types.

The basic jist is that those people who are good at startups – getting stuff built, working and out there in the world, who can cut the right corners that need to be cut to get something shipped are NOT the right people who can do stability development, who refactor things so they are more flexible, modular, scaleable and testable. Once you’ve switched from scrappy start up doing something new to established going concern, those people who started the company need to step back and let other people actually run it.

There’s definitely some truth to that – in video game development we’ve traditionally attracted people who are good at start ups – hackers, people who get things done fast not always in the best or right way, but who can be relied on to get *something* done.

We’ve also traditionally had a very large disposable codebase attitude too – game code is written for Game X and then thrown away and we start from scratch, maybe using some elements of Game X but generally refactoring it fairly largely when doing Game Y.

If the next game is a new genre (ie you just did an FPS but now you are doing an RTS then large amounts of the codebase does need to be refactored – that’s incidentally an AWESOME coding interview question – what needs to be touched and why?) then this is somewhat understandable, although with this generation of games we are starting to get to the position where it’s cost prohibitive to do that. Game budgets are such that re-writing the Matrix class yet again is just a waste of time and money.

So we *are* starting to move into situations and positions where what this blog is talking about *is* actually going to be relevant to use as an industry.

It’s worth reiterating the genre thing by the way. Dev Studios like Infinity Ward get great stock out of reusing their past codebases because effectively what they are doing is iterating on an established genre (and very well they do it too). They don’t start from a blank page every time they start something new because that makes no sense from them. Building on whats there makes perfect sense, as it does for the Madden Team and most iterative sport franchise games.

So how do you do it? How do you use both kinds of people in a game development environment?

Well, I don’t believe (as the article says) that boot strap mentality and Do It Right mentality are mutually exclusive. It’s entirely possible to have both – it’s just very very difficult to hire people with those skills because a) they are a commodity and b) testing that ability in an interview situation is very very hard.

I’ve always said that the best skill a lead programmer needs to have is the understanding of the right way to do something, an understanding of the quickest and hackiest way to do something and the wisdom and experience to know when each needs to be applied.

There are some personalities that definitely lean more to either maintenance / scalability and some that lean towards fire fighting and Get It Done attitudes to be sure, but that doesn’t mean one can’t do the other.

I’ve long advocated for a new position to start emerging in the video games industry – that the of the prototyping engineer. This position is half designer and half engineer. They are hackers of the knarly-est type and just get stuff done really fast in ways that are totally non flexible or ‘right’ – they write code that no one else will ever see and will never see the light of day, but they get it done fast.

The idea being that while in pre-pro your team has a small group of these that essentially define what the game is going to be, how it plays, and basically remove the risk from a mechanic “is this fun?” point of view, with a bunch of prototypes that demonstrate what the game *is*.

Then, when the full team falls on this project they already know it’s going to be fun, that the mechanics are thought out and that the nastiest risks – that of “This isn’t fun, what do we do now?” are eliminated.

That still doesn’t stop there being technical risks because a hacked together prototype doesn’t really demonstrate whether streaming an open world from the Xbox 360′s DVD is possible or not, but it *does* remove certain other risks.

And this is where I see the differentiation of the two development types in terms of video game development – to start with you are in startup mode – just ‘getting stuff done’ and on screen. Then the second production team comes along and actually write the code correctly, scalably, with modularity so these modules can be used again should the need be. The pre-pro development team then goes off and tries to start building the next game.

So despite the title of this blog post, it’s more about how to use the two approaches together per project than it is about an inherent switch of a studio from one approach to another, which is generally what happens.

Thats how I see it anyway.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>