Differences between console and PC development, Part 1
- Fixed console hardware vs. endlessly variable PC configurations.
- Minimal or no operating system on console vs. large and general purpose OS on PC.
- Hard memory limits on consoles vs. disk backed virtual memory on PC.
- Relatively stable and robust tool chains on PC vs. less mature tools on consoles.
- Running games directly from read only media on console vs. hard drive on PC.
- Specialized hardware on consoles vs. more general purpose hardware on PC.
- Cross compiling on consoles - targeting a different CPU architecture.
I'll cover each of these areas in turn and discuss some of the implications of these differences on the way developers must approach the task of programming for the platforms.
Fixed console hardware vs. endlessly variable PC configurations
One of the most obvious and most important differences between console and PC development is that console hardware is fixed whereas PCs are very variable in what CPU, graphics hardware and memory they have. With console hardware being fixed and developers being covered by NDAs with the console manufacturers, developers will usually have much more direct hardware access and much more detailed information on the low level design of the hardware than on the PC.
Targeting a fixed, known hardware platform makes life easier for programmers in some respects. If the game runs well on the development kits then it should run just as well on every customer's box. This is in contrast to the PC where the different performance characteristics of different CPUs and graphics cards and the varying amounts and speeds of memory on different systems mean that developers must test many different configurations and provide options for performance scaling and sometimes entirely different code paths for different hardware.
On the other hand, in order to deliver the quality of experience consumers expect on a console, programmers must be comfortable with low level hardware details that developers on the PC don't have to deal with (even if sometimes they wish they could!). In order to compete with other titles on the market, console programmers will need intimate knowledge of the hardware at a level which is generally not even available to PC developers. Not every programmer on the team will need to be a low level hardware expert but a successful console team will need some programmers who are very knowledgeable about the hardware.
I'll have more to say about some of the specific technical implications of fixed console hardware in future posts.
Minimal or no operating system on console vs. large and general purpose OS on PC
Modern consoles generally have a minimal OS that provides low level system services but this OS is extremely cut down and special purpose compared to an OS on a PC. Older consoles often had no OS at all - everything was done through direct hardware access or through a minimal set of libraries provided by the console vendor.
The minimal nature of the OS on a console makes a game developer's life easier in many respects. On the PC a heavyweight, multi-tasking OS allows users to run multiple applications simultaneously which means that even discounting the variable hardware configurations discussed above, PC developers will never have full control over the performance of their game. At any time the OS can take resources away from the game for its own use or for the use of another running application. This is one of the reasons why PC games rarely attempt to target a fixed frame rate of 30 or 60 FPS the way many console games do.
On older consoles it was not uncommon for games to depend on very specific details of timing - something only practical when there is no risk of a multi-tasking OS interrupting at any time. As games have got larger and more complex and consoles have introduced OSs that may perform some background tasks not directly under the game's control, console games have come to rely less on very precise timing of sections of code. It is still much more feasible to aim for a fixed frame rate on a console than on a PC however.
Hard memory limits on consoles vs. disk backed virtual memory on PC
This is perhaps the most important difference between console and PC development and the one that typically causes the most pain for developers transitioning to console development from the PC. On the PC the only hard memory limit is determined by the amount of virtual address space available to an application. On 32 bit Windows this is generally 2GB and until recently few games had to worry about exceeding this limit unless they had a serious memory leak. Although running out of virtual address space is now a concern for some PC games on a 32 bit OS, with 64 bit OSs becoming common the 2GB limit increases to 4GB for 32 bit apps and a generous 8TB for 64 bit apps (8TB should be enough for anybody...). On a console on the other hand, the hard memory limit is just the amount of physical memory available on the system - this ranges from 32MB to 512MB for current consoles. A console game that doesn't take a much stricter approach to managing memory than is typical for a PC game will soon run into problems.
The only penalty for exceeding the amount of physical memory available to your game on PC is a performance penalty as memory accesses start page faulting and hitting the page file on the hard drive. While this performance penalty can be severe (as anyone who has experienced disk thrashing while playing a game on a PC can attest) it will not result in a crash. On a console on the other hand, once you've filled physical memory you simply won't be able to allocate any more until you free up some space yourself. A discussion of some of the approaches to managing memory on consoles is easily a post in itself and I will go into more detail on this topic in a future post.
In Part 2 of this post I will cover the rest of the differences listed above.

1 Comments:
Hey, I just stumbled across this. I wanted to let you know I thought your two posts were extremely informative and interesting. I used to think console programmers had it easy, but now I see I was wrong. Thanks!
Post a Comment
<< Home