When I first learned to program, I made some nice little fun apps, compiled them to executables, ran them, and sat back. But something wasn&#x27;t right. I knew that the code I wrote was doing something, and I knew that it was doing what I told it, but I didn&#x27;t know why.<p>What is in this binary executable that makes the computer print &quot;hello world&quot;? I started digging. I found assembly. I found disassembly. I got into cracking and exploits. SoftICE. Unlimited ammo in games. Patching. Sniffing serialzz in shareware. Etc etc.<p>My point is, if I had just been happy with<p><pre><code>    printf(&quot;Hello, world!\n&quot;)
</code></pre>
and moved on, I wouldn&#x27;t have the incredible understanding I do now for what goes on under the hood. I wouldn&#x27;t know what an executable is, or how to bend it to my will. This knowledge has always been powerful for me.<p>Game programming is like this too. You can install Unity and make a basic game, hell maybe even make a few bucks off it. But what the hell is happening under the hood? What if you need to do something Unity isn&#x27;t capable of? Where does that leave you?<p>Maybe some people want to just make a game and be done with it. But I like to know why what I built is actually working. It&#x27;s worth the time it takes. OpenGL extensions, FBOs, triangulation, etc are all complicated and hard to understand, but once you know how it all works you know what&#x27;s possible and what isn&#x27;t, and you don&#x27;t need a (proprietary!!) framework making that decision for you.