|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Lessons We Learned Create a Linux version of your game (assuming that it’s a client/server architecture game) as you develop. This is an important factor, and is now one that is almost assumed for all games. In the same way that a game suffers if there is no multiplayer option, a game will suffer from no Linux version. You don’t have to go all the way — just developing a dedicated server is enough. We messed up in this regard, and simply didn’t recognize the demand there would be for Linux. We won’t make this mistake again. Keep in touch with your publisher’s marketing department. It is paramount that the folks marketing your game understand all of its nuances, and understand what the game means to you, the developer. Communication is of the essence here, and it will pay off big when launch time comes around. Limit the number of programmers involved in the project. Throwing bodies at a project with a looming deadline is not necessarily the way to get it done on time. If you use contractual programmers, or programmers from another project, be sure you have clearly defined the code that they need to write, and that you have broken the coding work into modules. This may sound obvious, but it often isn’t.
Have a good project lead. Often the difference between an amazing game and an okay one is the ability of the project lead to describe the vision in his head to you, the developer. We were lucky that we had a damn good one. The concept art helped a lot too. Don’t hand out demo dates. Another mistake we and Activision made was in announcing a date for the demo. We were two days late, but to the frothing masses out there, two days can be an eternity. When the demo for Hexen II was late, Brian Raffel received over 400 mails in an hour demanding to know why it was late. Some even included death threats. Scary, eh? Don’t go out of your way to create extra code for upcoming demos. E3 is important, but it's not the be-all and end-all of whipping up interest in an upcoming game, and quite often creating a demo for E3 can be a drag on real development. The only exception to this is if you have new technology to show and you are looking for a producer — if you don’t already have a delivery date, then it doesn’t much matter. It is possible to get games done in a realistic time frame. Having a "when it's done" mentality may work for id, but then they are, well, id. Most of us aren’t. Having a deadline and sticking to it shows discipline, and helps focus you when something is due a month away. One big plus to actually making a delivery date is that all your marketing will be right on track.
A private Beta test can shake your code tree in ways you never imagined. This is not to attack any QA group, but it can act as a great precursor to the actual quality assurance process. QA-ing almost always costs you, the developer, money. Private beta tests out on the wilds of the internet cost nothing, and you end up with a legion of loyal fans that will beat your game better than anyone that’s paid for it. It was a great experience of "real world" testing that we will most certainly be repeating. Supporting and being available to your community can bring rewards that are indefinable. We made a point of making sure we perused the message boards daily, answering all questions and mail as much as we could. This makes the community feel that you care, and that they can approach you. In some ways this backfire too, because there are always some fans that will cause you trouble, and by being responsive you open yourself up to abuse by them. But by and large, communicating with your fan base is almost always a positive thing to do. You will be exposed to suggestions that you would never have heard before.
Jake Simpson worked on C64, Amstrad, and Sinclair Spectrum games back in the early eighties, then ducked out of gaming computing into the corporate world (after being on the receiving end of a bad situation between a UK publisher that shall remain nameless, and a software house that shall also remain nameless). After trying his luck out in the world of Big American cars and McDonalds, he hit it lucky and ended up working at Midway for six years, helping out such arcade projects as NBA JAM (Nani Edition), WWF Wrestlemania, Revolution X, and even doing a bit of work on Mortal Kombat 3. His most recent post is at Raven Software, developing first- and third-person shooters using id ‘s Quake technology. If you feel the need for feedback, he can be contacted at jsimpson@mail.ravensoft.com. |
|
|
Features
