Developing for new consoles can be hard work. In the last 12 years, we’ve seen the release of the Nintendo 64, PlayStation, Dreamcast, PlayStation 2, Gamecube, Xbox, Xbox 360, Wii and PlayStation 3 alongside numerous hand-helds and constantly improving PC hardware – ranging from multi-core processors to graphics cards with over half a gig of RAM.
In order for games to be released on each platform, developers have to learn each system’s intricacies, build tools to make the most of their strengths and avoid their weaknesses, optimize code to run blindingly fast and ensure everything works without hiccups.
Games get better as developers become more familiar with the hardware. The PlayStation launch title Ridge Racer paled in comparison to its successor, Ridge Racer Type 4. R4 was much larger in scope than its predecessor; it had 321 cars made of more polygons with more graphical detail, Gouraud shading to improve the texture depth and improved car physics.
The improved performance for each generation of games is a direct result of the programmers’ hard work – the code monkeys who are responsible for telling the hardware what to do. But programming is hard, and it’s often overlooked and misunderstood by the public. “People don’t realize it takes about two years to write a game from start to finish, with about 80-odd people,” says Tony Albrecht, Senior Programmer at Pandemic Studios. “People are always shocked by that. It shows a real lack of knowledge as to what goes on [in game development].”
And yes, we should probably learn to understand the programmer a little more. These essential personnel are at the frontlines of every next-generation console war – the first to discover and exploit the strengths and weaknesses of the next great leap in technological advancement.
On request, Albrecht provides an example of how each next-generation console affects the way a programmer does his job, from the perspective of a graphics engine programmer.
“On the PS1, you had the challenge of transforming and rendering simple meshes in 3-D with a single texture [think of Croc‘s simplicity]. Now, given the power of the hardware at the time (33Mhz CPU), it was a challenge. Then we get the PS2 – we had two vector units that could do insane amounts of vector processing (comparably). But because we could render more things, we had to render more things. Lots more. So the challenge moved from processing individual verts to processing meshes. We had to move from just processing hundreds of verts with hand-coded assembly to processing thousands of meshes, each with hundreds of verts. We had to move from a single CPU to a main processor and two vector units and a GPU. Note that both of those vector units were rarely used to their full potential. Then, just as programmers were making the most of the PS2, the PS3 comes out and we have another half a dozen processors to manage.”
Programmers at the base level constantly have to deal with exponential increases in computing power and new, more complex architectures. They must adapt to make the best of the new, which can be a long process, considering it took seven years after the release of the PlayStation 2 before games like God of War II and Okami were able to really push the PS2 hardware to its full potential.
It might come as a shock, however, to discover that programmers are generally stubborn when it comes to learning how best to handle new technologies. “Programmers are very resistant to change,” says Albrecht. “They’re generally very intelligent people – game developers in general are very smart – but programmers just don’t like change. They like their standard environment. They like their standard compiler. They like what they’re used to, and they have a lot of momentum behind their beliefs.”
An odd thought, isn’t it, that the people that need to make the most of new technology and drive development forward are those generally less welcoming of the next evolution in tech? But Albrecht’s assertion that programmers in general are resistant to change has plenty of support.
One of the reasons programmers resist learning new technology is due to the sheer complexity of essentially relearning their job – “a change of operating system or code language is much more complicated than a change in many typical work processes,” says Ricky Ohl, Senior Lecturer of Games Programming at Qantm College in Brisbane, Australia. For instance, whereas a concept artist may continue to use PhotoShop, something with which he may have 10 years of experience, a programmer may potentially have to throw code he’s been optimizing for years out the window with each and every new console. Adapting to new technology takes time, which in turn reduces productivity. Taking this into account, it’s easy to see how a programmer might be hesitant to discard the old for the new.
Leanne Bartlett, Senior Programming Teacher at the Academy of Interactive Entertainment (AIE), offers another explanation for why programmers might actively resist change. In her experience as a teacher, she’s found that programmers are generally perfectionists, a necessary trait for the job but one that can result in programmers who “don’t like to leave something until it’s absolutely perfect.”
In an effort to break in new student programmers seeking work in the gaming industry, the AIE “tortures” their programmers by putting them on a very tight schedule and then shifting them – “we get them to swap projects with each other and get them to work on each others code,” says Bartlett. “We try to break those [resistant] habits in them.”
Qantm takes a similar approach in educating their up-and-comers by “diversifying and exposing the students to as many different environments as possible,” explains Tim Peach, a lecturer in game programming, “to equip them with not only the skills to program under different environments but also, and more importantly, the skill to teach themselves to program/problem solve under different and often new environments.”
Teaching programmers to problem solve and adapt is more important, according to Albrecht, than actually teaching programmers how to program specifically for current generation consoles. “I don’t think it’s possible to teach programming, in particular, that will be directly applicable to current-generation consoles. You can teach good programming behavior and get them to actually build a game with artists, designers and producers. You can learn a lot from that.”
Albrecht’s message is clear: “Programmers need to be able to adapt. They need to change with the times. Just because you have spent five years learning a certain flavor of shader language and are proficient in Direct3D doesn’t mean that the console you are working on will present you with that interface. The Sony consoles are a classic case of that – you have to relearn everything about the system [from each PlayStation generation to the next].
“Working on consoles is like climbing a mountain. You can climb one mountain over and over again and get really good at it (which is what a lot of programmers like and prefer) or you can challenge yourself and use what you’ve learned from climbing other mountains to help you climb new ones.”
After talking to so many programmers, I’m inclined to spare a thought not just for the artists that created the remarkable character models and envisioned the environments of the latest epic, but for the programmers behind the scenes that have worked hard to ensure the newest games are running at a blistering 60 frames per second on whatever console I choose to play. Code hard, ye’ monkeys, and let the next generation of consoles be many years away.
Daniel Purvis is an Australian gamer still praying his country will pull inline with the rest of the world and establish an adult R18+ rating for videogames. He is also Editor of www.GamingSA.com and blogs infrequently at
