Handmade Hero's new lessons about old-school game programming | Hacker News Reader

Handmade Hero's new lessons about old-school game programming

gamasutra.com

95 pointsgws20 comments

I've been watching this religiously since it started. I manage to catch almost all the episodes live, and there's a great set of people on the Twitch/IRC chat as well. (I'm "nxsy" on there.)

I also wrote a Linux platform layer for it for fun [1] and for those who were skeptical about Casey's approach to portability (and there are a few people who pitch up who are/were aggressive about his choice of starting platform and/or his approach).

[1]: https://github.com/nxsy/xcb_handmade

Impressive. Have you worked with xcb in the past? I think the lack of good tutorials and documentation makes me always choose to start new projects with xlib. How would you compare working with xlib vs xcb?

Nope, this is my first use of XCB, and I've never used Xlib before either.

As you say, the documentation is barely to entirely non-existent.

I've been following his stream and it's fantastic. I wouldn't say it's just about old-school game programming; It's more like full stack game development. No math libraries or pre-built components are used. Everything is done from scratch, in C.

Some of the architecture patterns are actually quite relevant for web development, especially the earlier lessons on decoupling the game layer from the platform layer.

I think the first thing I'd do if told to "write a game from scratch, in C" is to write a bytecode interpreter for a higher-level language. Actually, it'd be kind of fun to start from a machine that only has a machine-code assembler, and bootstrap your way up to something like a Smalltalk GUI.

It's interesting that one of the first things he does is to effectively build a REPL - the executable is a shim and the actual game code is kept in a shared library which is recompiled and reloaded on the fly. Together with manually laying out memory instead of relying on the runtime malloc/free mechanism for allocations, it seems to work pretty well. Make a code change, compile, the game updates immediately. Thanks to sticking to C the compile times are short enough to make the reload cycle near instantaneous as well.

One of the points Casey is trying to make with this series is that, at least in games, dynamic languages aren't quite the silver bullet for productivity that people make them out to be, and you can write your gameplay code just fine in C or C++. It might even work out to be a net productivity win, because native code debuggers are far superior to "managed" language debuggers (most of which don't handle the boundary between managed and native code at all), and because even moderately well written C or C++ is much less likely to cause performance problems down the line than anything garbage collected.

This is totally tangential to this discussion, but I thought I'd throw it out there in case it helps anyone.

The python-gdb macros are fantastic for debugging those painful managed-native problems one occasionally encounters. https://wiki.python.org/moin/DebuggingWithGdb I've used it to debug some really gnarly issues over the years. They're not perfect, but they're good enough to solve all of the problems I've encountered and used them with.

I glanced over several episodes on youtube. It seems like he is building core around windows/winmain and plans to port or something later. Some guys on forum ported it over sdl to osx and linux. Kind of a shame for what I expected. I was looking forward to seeing a C crossplatform setup from the start without sdl, sfml, glfw whatnots. It doesn't even look loke it's straight C either, but more c in c++ world. Game stuff is probably ok, as people say good things about it - haven't checked it all (yet).

As someone said, he is keeping the platform layer and game layer separated, the game layer is meant to be platform independent.

The idea is to write in real time every single line of code, and if he had tried to set up multiple platforms from the start he would have spent months in mostly boring and repetitive tasks, while he wanted to get to game programming as soon as possible, and get back to support more platforms later.

After the first few weeks setting up the windows code, the focus has been on the game layer mostly.

He is using mostly straight C (stating several times that he loathes C++) using a small subset of C++ features (function and operator overloading).

I've been casually watching these, might be able to clear some stuff up...

He started out with a widows platform layer, which implements generic services (input, sound, rendering, memory allocation) to get the system boot strapped. Since then he's mostly been writing generic game code (player movement, world rendering, time management, etc) which consumes the abstracted services and is cleanly separated from his windows platform layer. He architected it in such a way that it can be easily ported to other platforms once they have a game (he's brought up the raspberry pie a bunch a possible target platform).

The other people doing the ports have ported the "lessons" to other platforms so that people who don't run windows can (mostly) follow along, they are just viewers of the stream.

As for language choice, it is mostly C, the only C++ feature he uses (and why he compiles with a C++ compiler) is function overloading.

Graphics rendering and loading a UI is inherently linked to a platform. Some platforms you can just write to the hardware, but if you want crossplatform graphics you need to pick a library.

I have been enjoying the stream a lot, thanks to HN community since I learned about it here when it was starting.

Aside from the game development angle, the host has his own strong opinions on programming in general that are quite unconventional, I do not agree with some but they are interesting nonetheless.

And in general, it's fascinating seeing programmer with 20 years of experience and which obviously loves his work teaching his craft.

This stream is fantastic even if you're not, or do not aspire to be, a game programmer. I find it interesting to watch someone's thought process as they flesh out their ideas and make something out of nothing.

"If everyone in the next generation of game developers decides to use a pre-fab engine, who will be left to make the new engines?"

Implementing low-level systems yourself is a valuable exercise for games as much as for any other software. You gain new appreciation for the things you took for granted, and pre-made abstractions become even more intuitive because you feel more in control of what's (probably) going on under the hood. One of my pet projects is implementing graphics primitives in software - you'd be surprised at the amount of tuning and iterations needed to make them fast, clear, and correct.

I've been working with UE4 since april on a personal project of mine (fps).

While there are layers of abstraction over all of this that I enjoy, I debate really how important it is for me as a game developer to worry about them.

In the old-school days the role of engine developer and game developer were the same.

Now I see there are two disciplines. Those that enjoy making video games and those that enjoy making video game engines.

It is a good tutorial. But do take it with a pinch of salt, b/c I have already seen some zealots defending this as religion of writing games from scratch as something easy and achievable in short time. It is time consuming and takes lots of practice and tweaking even for seasoned game developer.

And most importantly, if you want to deliver a complete game as single developer/designer, doing it from scratch is probably the wrong path to take. You would have to wear so many other hats besides just game programming.

But if you want to build renderers and learn the craft of rendering stuff in low level. Or you are doing as a hobby without intention to deliver a complete game with rich content, then this tutorial is good for ya!

I just discovered this about a week ago, and am only a few videos into it (Day 006), but it's been great so far. Like a some people have pointed out, Casey has some strong opinions about things that I don't completely agree with, but I've already learned a lot, and it's really cool to see the thought process of someone who is clearly very smart and has a lot of experience doing this sort of thing.

On a side note, it's also pretty cool just watching him work in emacs. I just started learning emacs myself and he's wicked fast!

I hadn't seen this before, but now I've subscribed to the youtube channel so I can watch the videos as I get time. This entire project sounds amazing :).

When i think of old school game programming I think of programming in assembly directly onto a ROM chip.

Reply on news.ycombinator.com