[In this reprinted #altdevblogaday-opinion piece, freelance programmer Fabrice Lete shares why you should be learning and experimenting with platform API-level programming even when you're not working on the middleware itself.] Looking back at my professional experience so far, over the course of eight years, I have worked on 12 games (of which seven shipped) using eight different engines on five 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 their 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 after 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 it? (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) [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]