Wednesday, July 26, 2006
Wednesday, July 19, 2006
- 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.
Thursday, July 13, 2006
I’ve eluded to this in earlier posts, but once you’ve written a demo or two, why not put them on a web page?
- It shows you have the technical skills involved in building a web page.
- It shows off your communication and presentation skills.
- It makes your resume stand out, and be more memorable.
- It increases the likelihood that you’ll spend your interview talking about your demos, which is better than answering questions you’ve never heard before.
Here are a couple of tips to bear in mind while making your site.
- Keep it reasonably professional. We don’t need to know your 100 top films, see your family album, or follow links to your favourite comics.
- Some words are good, but avoid big essays. Pictures and a few words are enough. We can ask for more details during the interview.
- Use screen grabs and video as appropriate. It’s a lot easier for people to look at pictures or a video, than to download executables and struggle to get things to run. That said, if it’s a good demo, why not offer both pictures and a download.
- Get your friends or perhaps teachers to look at the site and give feedback. As with your resume, it’s good to have a few people proof read it.
Thursday, July 06, 2006
Using Copernic, you can key in a couple of keywords, and in a couple of seconds – bam – you’ve got a list of every email and file containing those words. You can then refine the search by being more specific about the sender or the type of file. If you’ve ever searched for email using the search feature in Outlook, you’ll never use it again.
If you get a lot of email and you don’t already have a desktop search program, drop everything and install Copernic now. It’s free, and you’ll start raving about it too.