2020-05-09
in
4 min read
Yesterday I was following a Twitter thread John Carmack where he was talking about optimizations. Someone suggested he do some sort of a series on how to build game code et cetera. His response was to point to something I’ve never heard of before Handmade Hero . This is a project started by a small group of developers back in 2014. Their goal is to produce the whole game as live coding so people can see how they, professional developers, build a game. I’ve watched previous live coding videos before and enjoyed them. My first was this person writing a vim-like program for CP/M in assembly language, link here . Sounds very dry but I actually get a kick out of seeing how other coders work. I’m just through the first video and am pretty fascinated.
The thing which fascinated me the most was the developer’s choice of development environment. This appears to be a Windows native game that will run under x64 mode. When he stated he was going to setup the development environment I assumed it was going to be how to use one of the Visual Studio wizards to start the new project. Instead it’s actually taken a very atypical path. Their preferred build environment setup is to not use IDEs at all except for debugging. Instead they do their coding in a regular text editor, in their case emacs, and write their own build scripts. By “write their own build scripts” I mean that they literally write a batch file to manually invoke the build commands, create directories etc. In the commentary they state that even for their large projects they find that the build time of this path is still just a couple of seconds compared to all of the complexity of scripts like CMake. Watching this it occurred to me that I have always had an IDE of some sort when writing Pascal, C/C++, or Java code on Mac and Windows. My first Mac programming environment was Think Pascal. My first Windows work used Borland Turbo Pascal and Borland C. The only times I’ve used just a pure text editor for C was on Unix back in the 1990s. At that time I also didn’t really want to mess with Makefiles and such so I too wrote my own shell scripts to do my builds for me. So for several years back then, on Unix only, that was my build system too. Otherwise though it’s been all IDEs and build systems. So there is a bit of nostalgia watching this for me and fascinating to see how their build script evolves.
I know they are targeting new developers, there is even a series of videos covering C code fundamentals, but I found some new nuggets of information. There are a lot of nuances of the lower level C parts of Windows and how it’s assembled that have long left my brain from when I did this sort of coding on a daily basis. There are also a bunch of nuances about Windows shell that I never knew existed. For example I never heard of pushd or popd for shell scripts, and I’m scratching my head as to why. I’ve done this sort of thing manually which is now totally insane to me. I also like how he shows users how to navigate through MSDN, explaining the nuances of what the compiler, linker, and debugger are doing etc. Since I’ve never coded a real game I’m also looking forward to seeing the step by step development as it unfolds with a real developer at the helm. Yeah, I could just read a book or maybe even meander my way through it with my own past experiences. For me there is something more appealing to me doing it this way.
It’s a very long video series covering hundreds of episodes going back to 2014. However I recommend at least skimming some of the episodes to see parts of development or game development fundamentals. Yes, I’m making that recommendation after just one episode, but I have high hopes for it.
It also has me wondering if live streaming my own coding may be helpful to myself. Internal exposition would become external exposition. My penchant for getting distracted would disappear. It’s an interesting premise…