Looking back at my professional experience so far, over the course of 8 years I have worked on 12 games (of whom 7 shipped) using 8 different engines on 5 different platforms. But all these engines were hiding the platform specificities, so having worked on Wii or PlayStation 3 means little, I have just been using “engine X”.
Of course, hardware limitations kept on showing up left and right, but it always boiled down to using the engine in a different way to take care of those. And when you work on games that do not push the hardware, you hardly ever have to dig deeper than the engine layer anyway.
So if we are not working on the middleware itself, should we still bother learning and experimenting with platform API level programming?
I think we should, and for various reasons. The first is that properly using a platform means understanding its strengths and limitations, and the low-level API gives a lot of clues about what is going on. You can really feel the hardware right under it, and get a good understanding on why things behave the way they do.
Second, engines are often cross-platform, and as they abstract the hardware, they also remove its unique features. How many games are really going beyond the two sticks, four buttons, two triggers and a D-pad approach? What about pressure sensitive buttons, motion detection, remote play and keypads? The point goes well beyond input controls, but that was the example I had in mind.
Finally, the argument for using engines usually goes like this: you would not be re-inventing the wheel every time you need one, so learn an engine once and use it everywhere. That’s true, but notice how I learned more engines than I shipped games. If you are working with a popular engine that lots of companies are using that makes sense, but if you aim at smaller scale development, chances are the ground will move a lot under your feet.
At this point, I should probably stress that I am not advocating against engines. Attempting to start a professional project from scratch would be madness. I am only suggesting to go out of the engine comfort zone as much as possible, and always question the usefulness of the abstraction layers you are presented with and/or might be tempted to introduce.
But now the question is how can one get his hands dirty? First-hand knowledge is important but the core principle being “don’t touch it unless it’s really necessary”, how should you exactly proceed?
That’s a good question and unfortunately I don’t have a practical answer. I would say “jump on every opportunity to work on the engine itself”, but that’s pretty generic. I could also suggest to play around with the devkits during breaks, but for having tried it myself, you can hardly make any progress this way (although if you manage to squeeze enough time it might be worth it, I would advise against sacrificing lunch), and it also defeats the purpose of breaks.
Having access to the hardware outside of work hours is fantastic, but I am not aware of many places allowing that. So the closest you might get maybe involves retro-computing or even soldering your own devkit, like Craig Bishop suggested in his console development post. But although that will teach you valuable stuff, it remains remote from current-gen consoles.
So this post ends with a request for suggestions. How would you do?
(my way of doing it involves teaching at a school with unrestricted access to several devkits, and that’s totally awesome, but that situation is rather exceptional)