3 ms·

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 ma

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.

derefr 12y ago
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.
- krig 12y ago
  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.
- ANTSANTS 12y ago
  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.
  - tonyarkles 12y ago
    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 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.
Keyframe 12y ago
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).
- Kurtz79 12y ago
  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).
- bjg 12y ago
  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.
- pjc50 12y ago
  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.

derefr 12y ago

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.

krig 12y ago
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.
ANTSANTS 12y ago
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.
- tonyarkles 12y ago
  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 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.

Keyframe 12y ago

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).

Kurtz79 12y ago
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).
bjg 12y ago
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.
pjc50 12y ago
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.