Wednesday, July 19, 2006

Why is coding for consoles different than coding for PC?

I sometimes ask people questions of the format, “If you’re coding on a console, why would you blah blah blah?”. The blah blah part is confusing enough, but also a lot of people don’t know what the differences are between coding for consoles and PC’s. Here’s my little run down of most of the main ones. First, the main technical differences:

  • Consoles (at least if you’re just developing for one type of console) have fixed hardware. You don’t have to worry about grossly different processors, graphics cards, hard drive speed, memory or controllers.
  • PC’s have ‘virtual memory’ as part of the operating system. In simple terms this shifts things from physical memory onto the hard disk when they’re not being used. No current consoles have this feature, and so the program has to use only the physical memory available. This is good for performance, but means that you really have to keep a close eye on memory usage in your game.
  • Consoles have custom hardware like DSP’s, DMAs, SPUs, and areas of memory which are faster/slower than others. Making use of these features often requires low level coding which can get pretty complex.
  • Next generation consoles like Xbox 360 and PS3 have multiple processors. If you want to get the best performance out of the hardware, you have to architect your engine to utilize all the processors as fully as possible. This is a complex task.
  • Consoles can have a different endianness than PC or other consoles. This means you've got to be careful when coding, and sometimes need to 'swap the bytes' when writing data files.

And also some less technical ones:

  • There’s usually no mouse or keyboard. These are often helpful when developing PC games.
  • The machine is just running your game. Your game isn’t running ‘infront’ of windows. When your game crashes the console just sits there doing nothing.
  • If you start by just using the libraries which come with the system, you often start coding with very little support. You start by writing lots of code to do simple things like render debug text, load files, do vector math etc.
  • As mentioned in an earlier article, STL may not be natively supported.
  • The compiler may not support all the language features you are used to using.
  • You are often required to use an IDE other than the one you are used to. This can mean learning different shortcuts, and using a debugger which is less usable than the one you are used to.
  • Console development is a fast paced industry. If you start developing on a system close to when it comes out, you can expect to use very clunky hardware, API’s with bugs in, and compilers which sometimes generate bad output for valid code.
  • Developing a game for a single console means that you can spend time making use of all the features available, and squeezing all the performance you can from the machine. As opposed to basing your decisions on what ‘lowest common denominator’ hardware you will have available, or spending time on feature/performance scalability.
  • You don’t have to worry about writing install/uninstall scripts.
  • You do have to worry about a big list of technical requirements. For example, all the text messages about memory cards need to use the proper terminology, you have to supply an icon for the save card, the on screen text can’t be too close to the edge of the screen, etc. All these things (and more) need to be checked and approved by the console manufacturer before you are allowed to ship.
  • You’re not allowed to patch the game after it ships. On PC it seems that you can ship the game from half way through production and then release patches. J
  • Testing of PC games requires testing on a broad range of hardware. Testing for consoles is a lot simpler in this area.

If you’re looking for how to get some experience with console coding, a good way to get started is to search for homebrew sites and write your own console code. You can use free compilers and emulators, and even buy hardware which allows you to run your code on the console. For fun I wrote some Gameboy code a few years ago. It was a great feeling to see it running on the proper kit.

Note: Using emulators and homebrew development is generally not approved of by the console makers. Personally, if you’re doing it to build knowledge and experience, then I don’t see the harm. Some people use the same tools for piracy – that’s not cool.

3 comments:

Anonymous said...

Does Sony/MS/Nintendo maintain the same interfaces for their API's from one console generation to the next? Such as going from PSX, PS2, to PS3, or even to PSP, to minimize the learning curve? And when buggy API's are discovered, does the dev team (i.e. 3rd party software developers) switch to the new API or just work around them? I guess that would depend on which one introduces more risk into the ship date--particularly with regression testing if you decide to switch to the updated API versus ease of implementing a workaround, among many other considerations.

You mention that these compilers sometimes generate bad output for valid code; it's a bit unnerving, I'd like to think it's my fault 99.9% of the time, not the compiler. Have you seen this mostly for optimized compiles or also for unoptimized compiles?

Here are a couple more things unique to console development...

- For PC games, the developer has no control over hard disk fragmentation on a user's computer. Fragmented files can cause streaming audio/video hiccups, can tank frame rates to the point of making a game temporarily unplayable, and to some degree extend loading time. Console games that are stored on optical discs and run off of them have their data arranged very carefully to minimize seek time to avoid these hiccups. Also, because optical discs are written starting from the inside portion to the outter portion (where transfer rates are highest), developers exploit this property for shorter load times. Even games that don't fill up the disc to the outter edge can benefit by filling the inner portion with dummy/filler data. Recently, top executives from MS and Sony have commented that they believe hi-def DVDs (HD DVD and Blu Ray) will be the last optical format, i.e. no more discs, because people will be tired of discs. In that case, hard disk fragmentation might become an issue for console developers. Or maybe, the consoles 5 to 10 years from now will have a very large flash drive instead of a DVD drive, making fragmentation moot, and use an external hard drive to store a collection of games downloaded through an online distribution system when consumers start to move toward fiber speed broadband.

- Console development is done on developer kits ("dev kits") and Test units. The Xbox dev kit for example, can run the game off a hard disk using a virtual DVD drive. Test units look similar to retail consoles and are similar to modded consoles in that they can play burned copies, which is what the QA department uses to test and developers can use as a sanity check.

- In addition to the technical requirements required by console manufacturers you mentioned, there are some interesting ones like "Test the game to see if it crashes when the user ejects the disc while it is loading a level." or "Do not write data to a memory card while a level is loading." Some of these requirements sound unreasonable but start to make sense when you consider that children also play console games and as a result may increase calls to tech support by parents, costing the company money.

Mark Pope said...

API's do tend to change between consoles. With Microsoft, the Xbox/360 sdk is quite similar to DirectX, which keeps things pretty simple. I'm less directly familiar with the Sony API's, but they tend to involve quite a lot of low level work, and this is more susceptible to change when the hardware changes. If a bug is found, it's most often an internal problem in the implementation of the API, and a subsequent version will fix it. Sometimes there can be small changes in the API too. I don't want to blow it out of proportion though, generally the API's (I'm using API and SDK interchangably here) are pretty good with only occasional issues.

99.9% of the time it is us, rather than the compiler. When tracking down a tricky bug, it's not uncommon to start thinking "this must be a compiler bug", but then you almost always find that it's your own. I'd say you'd normally get under one per year. A common way it happens will be that we upgrade to the latest compiler, the game starts getting wierd occasional crashes that we can't track down, and we revert back until another new version comes out.

On PC HDD fragmentation, yes. I like to keep my HDD defragged, but I can't say I've ever noticed a huge difference after defragging a heavily fragmented drive. I think that other considerations like the HDD speed, connection type and cache will likely play a bigger role.

Another difference that this reminds me of is that all the different PC hardware requires drivers. So there's a ton of different pieces of hardware, each with multiple versions of the driver. These days I don't see a lot of driver problems, but in the early days of DirectX (8ish years ago) it was a nightmare. Despite having the uniformity of the DX API, you'd end up putting in wierd little hacks that detected the name of the card and then did things a little differently. And some cards had such poor driver support that we just gave up.

Thanks Tom!
Mark.

Mark Pope said...

That would have been clearer if I'd started with "API's do tend to change between different consoles from one manufacturer."