|
- Contents |
|
By Matt "Thraka" Gilbert
"I am the
beat of your pulse. The computer word made flesh"
Now, questions: people ask them, and I encourage that. The more questions asked of me, the more topics I have to write about! A lot of people were interested in how developing for consoles differs from developing games for the PC, and that’s what we’re going to rap about this time. So let’s get on with it! It’s tempting to say, on first thought, that making games for the PC is simply easier, but that’s not precisely the truth. Nothing about this business is easy. The chief difficulty of console development is the life span of the machine. In the six years I have been involved in this biz, I have programmed three consoles: the Genesis, the Saturn, and the PlayStation. Even now, the next generation looms on the horizon, and developers clamor to begin work on them. Let’s do it this way: first, I’ll run you through the process of creating a game for a new console system. Then we’ll talk about how things change for a console that’s already established, and finally, the differences for a console system nearing the end of its reign. Obviously, this is a lot of material, so I am going to break this into two parts, and concentrate on the birth of a console system for this issue. Now, consoles are a strange breed. It’s like this: the console manufacturer wants to make a machine that will sell, and to do that, he has to cope with several issues. First, he has to have a machine that does more whiz things than the current crop. Easy enough, but of course, price is inevitably the bottom line. Console manufacturers must produce these whiz features on a shoestring budget, because, in the end, they have to sell the thing at rock bottom prices, maybe even at a loss. The reasoning is simple here: console manufacturers take a chunk of money from the games that get made for their platforms. The more consoles they can put into the hands of the public, the larger the target market for games on their system. Obviously, publishers want to sell lots of games, so they are more inclined to produce games for the system that has the most market penetration. They sell more copies, and make more money, which translates to more money for the hardware manufacturer. The manufacturer must make the machine as cheap as possible. And the way he does this is to pick and choose from a variety of chips that will do the job, with the cost being a paramount issue. He cannot afford, for example, always to choose the top of the line chip for 3D; instead, he must find the best balance of price versus performance. Not surprisingly, this combination means mix and match, rather than integrated suite of devices. How does this all shake out? Often, it means that the console is a rag tag piece of hardware, one capable of the task, but only after being coaxed and teased into doing so. This doesn’t mean that hardware manufacturers are slack, or trying to rip people off. Quite the opposite: they’re making the best machine they can with the budget at hand, and it’s up to the programmers to understand and cope with the limitations of the system. However, the job of the hardware manufacturer is not yet done. Next, he must make certain that tools exist for developers to use in creating games for the system. As you might expect, these tools are rushed, because that is the nature of things in this business, and come out as serviceable, but with their own set of quirks. And, finally, he has to have some means of communicating to the developer just what the hell the machine can do and how it can be done.
. |
ust
a brief note before I get started on the central issue: I’d like to
thank those of you who took the time to drop me a line and let me know
you liked the column. I received mail from a number of people, from
aspiring developers to old hands in the field, including a few I have
worked with before. To the new, nice ta meetcha. To the old, hope we
meet again soon.