- 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.