7 tips for a successful dev project

7 tips for a successful dev project

By Rob Crossley

July 16th 2009 at 4:39PM

Develop â??09: Krome Studiosâ?? Robert Walsh offers his advice on game development

Stakes may be at an all-time high, demands on game quality may be sitting above what’s practical, and even feasible, but there are still a few things that can make the game design process run more swimmingly.

And, at the fourth annual Develop conference in Brighton, UK, Krome Studios CEO and co-founder Robert Walsh offered seven tips for success in a well-received session speech.

Those seven tips can be found below.

1) Be realistic
It’s easy to over-promise, especially in today’s nervy economic times when publishers want bang for buck. But take tremendous care with what you allow to be expected of you and your work, don’t comply to promises you cannot keep.

If you dig yourself deep into a promise, it will take so much more work to dig yourself out. People will respect and trust you more if you remain realistic and honest with your publisher.

And whatever you do, avoid the ‘little’ suicide jobs; there’s no such thing as a little game project.

2) Communicate
Strong publisher communication is a key virtue for any project.

Don’t try and hide stuff from publishers. They’re not as stupid as you think they are. You will be found out. It’s far better to be upfront with them. |

The ‘us’ and ‘them’ mentality needs to die.

Even if it’s ten minutes long, have lead meetings as much as you can. Aim for one every day, and don’t keep the management out of the loop.

3) Leverage
Stick to what you know, and the games you’ve worked on. The more you work on a game series, your iterations will get better, faster, and finished quicker.

Don’t build one offs: if you’re designing a platform game, and are looking to add a driving level, the standard of that driving component needs to be as high as the platforming itself. Dropping your standards for this one component is essentially wasting player and developer time.

But if you manage to keep high standards for the driving component, don’t waste all that work on a single level. Implement it as many ways as you can. Be cost-effective.

4) Track, track, track
There are so many ways in which a project get killed; bugs, human errors, miscommunications, system errors… If you effectively plan out your work, you can absorb the shock of unforeseen problems.

As much as we all love spending publisher’s money, in today’s times developers are scrutinised far more for how they’re being cost-effective, this is why you have to track your budget and processes.

You should always measure what you planned to do against what you’re actually doing. Tracking progress, and making internal deadlines, is vital in helping you achieve this.

Krome Studios has six people, working full time, tracking progress of processes and systems and objectives.

5) Hitting your dates
There’s no escaping the importance of money. Publishers need to be profitable. Miss your forecasts, and you’ll get beat up by the press, beat up by the board, beat up by your shareholders.

Publishers spend a lot of time evenly spreading their portfolio of games across the year, measured meticulously in between the releases of competitors and placed inside the volume of genres. Delaying a game can move it into a time not planned for it; delay your shooter by three months and it could end up competing at retail with the next Halo.

6) Prove out high risk early
If you’re embarking on a big challenge, prepare accordingly: Get the tech, middleware, and core features done as soon as possible. You need to know that these central features will work. 

“Retrofitting middleware is not something that I would like to wish upon anyone else,” says Walsh.

7) QA
Quality Assurance is invaluable; time it correctly. “A build rarely comes through at lunch time, it comes through in the evening,” says Walsh, adding that this is why he has a night shift of QA staff.

Don’t just rely on the publisher for QA. You probably won’ get any publisher QA until Alpha; and so much could have been addressed before that. QA teams need to test things the moment they are ready.