I've been coding for a long time, and have long since wanted to make games. Nowadays the problem is creating a code base that runs on most platforms, is flexible and performant and not a nightmare to debug.

I love this series. I think it's great Casey is sharing his knowledge with us. But because he is making a specific game (and not showing how to make ANY game) there is a lot in there I won't need.

The game I'm trying to make with a friend is not tile-based. So it's hard to cut out which elements I need and skipping ahead to the ones I do.

Also, multiplatform is important. The first dozen videos are excellent since they show you how to do that, splitting out code for the windows platform and the game code, but it doesn't show how to go to the other platforms (linux, mac, android, ios).

I guess what I'm saying is - there is a lot of incredible knowledge in this series but it's hard for someone who wants to learn how to make games to use it for their own purposes. The first few weeks are brilliant and all new game coders should watch them, but then the series becomes specific since the aim is "this is how you can make A GAME" and not "these are the issues for making GAMES".

Anyway. I don't know if others have the same sense when going through these videos. I'm incredibly appreciative of Casey for doing this. I'd love to sort of be able to summarise everything, break it down into layers, and give people a piece-meal way of writing THEIR games from scratch with all the various things Casey shows us ...

Just a thought.

I'm not sure what do you mean when you say he is not showing "these are the issues for making GAMES". Because to me it looks that he is doing exactly that. He is showing many issues you encounter when you are making games. Memory organization issues; how to operate on assets; how to create flexible debug system, various issues with performance and how to troubleshoot, etc.. These all are very reasonable issues that any game developer encounters.

Yes I agree. There is a lot of great information.

I think maybe what I'm trying to get at is organization. There are nearly 1000 hours of videos and they sort of go along this specific path. What would be great is if everything was built up in a way that gets people understanding things in layers.

Let me explain. As far as I can see so far (I'm only on video 8 - direct sound) Casey reckons games only really need 5 or so parts - graphics, audio, memory, files, input, and networking (6). And to design a platform-independent game you have each part written in a way that can be implemented in windows or linux but tied together so the game code stays the same.

It would be great to see just how this is done - how each part needs to be built up, all the things to consider for each platform. Casey has basically done this for Windows but with some gaps - no networking, the files is just debug at first, graphics is only buffered at first - only later does he get to opengl ...

I'd love to see him describing these things. Like "Ok, to be a cross-platform games programmer (from scratch) these are the things you have to build" and talking about how basically all platforms implement sound as a buffer (for example) and what it would take to go and learn how each platform works and making an api that can be implemented on any.

I feel like once I have those things down then, well, I have the base 'layer' done - I will understand how to, at least basically, implement the 6 core components for any game that can be ported.

Then you mentioned all the other things Casey has done - Memory, Assets, Debugging ... Again, it's incredible the information is all there but you sort of have to sit through and listen to all of it. It would be great if it was organised, as a list. And a secondary layer. Like "Once you have this done (the 6 platform layer functions) then you can start to think about these (assets, memory layout, debugging), and these are the situations you will need them in (giving context to what types of games they would be important in)".

This could all be covered in an hour. Sort of like a tellescopic choose-your-own-adventure.

I guess what I'm saying is there is so much great information in this stream but it's been frustrating seeing how long it will take to get to the parts that are relevant to me. And also just getting a sense as to WHAT is relevant to me ... I must have gone through the episode list a dozen times trying to figure out how I was going to get the information I needed without missing things.

Sorry if this is a ramble. Honestly, what I really should do is sit and go through these videos and organise the information in the way I'm thinking about. But if I do one a day (which is a big part of my day!) it will take over a year !

There are playlists on youtube to see videos on specific topics and the episode guide to help you find specific information. There are also community ports (of the platform layer) to other platform (linux, mac, android) but I don't know if they are up to date. I believe they are on the git repository if you pre-order the game (there was a resources page but it was lost in the switch to handmade.network). And you can ask questions here if you need help.

One of the reason for not showing how to make something work on several platforms at the same time is to avoid doing work on something you may discard later. You don't know for sure what you'll need for the complete game and time you spend on thing you don't need is wasted. So the reasoning is to say: "Build the complete game on one platform so we know exactly what we need, then port it to other platforms". We want to focus on making a good game before making it run on several platforms. Maintaining several platforms while the game architecture/api is still changing will probably cost you lots of time, and again, on thing that may not be in the final game. Relative to the game code, the platform code is small so, unless there is something specific about multi-platform in your game, it can probably wait near the end of development.

In my opinion handmade hero uses a specific game as an example, but the show is not about that specific game. It shows how to reason about problems. There isn't one way to make things and there is no "right" way. If you try to build things before you need them, you could be making something that doesn't fit the problem when it appears. For example there are game with no graphics, game with no sound, game that don't need files. And there are games with advanced rendering techniques, low latency audio and file streaming. Each problem is specific to the game and we need to make the game to find the problems and solutions.

mrmixer
I believe they are on the git repository if you pre-order the game (there was a resources page but it was lost in the switch to handmade.network).

The team is making changes to the site to incorporate markdown (instead of bbcode) for the upcoming Handmade lessons. As part of this, we're clearing any pending work, including adding AsafGartner's Episode Guide Searcher for Handmade Hero. Another thing we're doing is making a static pages editor, allowing us to reinstate the HMH Resources page without it being a hack. Indeed that page is the one dear thing we lost when moving to Handmade Network.

I think searching Miblo's episode guide is extremely useful in organizing the topics you want to learn about from Casey.

mrmixer
And you can ask questions here if you need help.

This is essential to realize. We're a niche but impressively active group of individuals, following a reasonable set of guidelines (meaning no one should worry about being ridiculed), and willing to give our time to answer many programming questions.

kewp
Also, multiplatform is important. The first dozen videos are excellent since they show you how to do that, splitting out code for the windows platform and the game code, but it doesn't show how to go to the other platforms (linux, mac, android, ios).

FYI, I am somewhere in the 30's (10% complete whoo), and I am writing in pure C for two platforms:
mingw-gcc for WINE on Linux
gcc for SDL on Linux

neither of which is exactly like Casey's or anyone else's for that matter. One reason for that is that I think I will assimilate the problem solving methodology more effectively by having to actively use it every step of the way, not just mimick or pantomime. The other preserves my preferred development environment, at the cost of no functional debugger for the WINE build, yet. So far printf and some imagination has gone a long way.

On the other hand, after completing debug platform layers, I haven't bothered writing code just to reproduce the same exact things Casey is doing on the screen. I stopped watching day-at-a-time, and try to watch a week's worth of streams to rapidly ingest as much material as possible, reduce the entire set to its essential ideas, with occasional review. Like the school classes in my youth, Casey's streams usually cover a larger basic idea over the course of a week, with lots of coding and smaller points along the way. The week-at-a-time method I'm using for HMH is exactly the same method I used to complete Algebra I and II in 10 weeks apiece.

Although I may test more than one simple game type along the way, the game I want to make is a 2D Puzzle Platformer, also not tiled-based as I think of tiles. Nonetheless, the way that game world maps to memory in HMH is going to be very usable in my game, since some of the mechanics revolve combat triggered audio effects, beat matching, entity to entity distance relationships, movement, and velocities. The concept of tiles simply may mutate into some other, more efficient mathematical structure for those mechanics.

Thanks for the replies. The playlists helps as well (am busy trying to get OpenGL working in a cross-platform manner ...).

I suppose my reaction is based on starting the stream so late. Casey starts off talking about his over-arching philosophy, making everything "from scratch" and why we need a new generation of game programmers to learn how things actually work.

I agree with him. And I love the idea that it makes making games more tangible and enjoyable. So I'm trying to do that with a game idea I have with a friend. But I'm getting stuck. I can't figure out how to setup a platform layer for Android. And we definitely want to have an iOS version. And I think for debugging it will be great having something live-reloadable on Windows.

I'm busy scratching together solutions from various sources, but it's this slow process and what I miss the most is someone with Casey's straight-forwardness and experience saying things like "This is what you need to worry about in a situation like _x_". What I liked most about the stream is this definitiveness. I sort-of trust him since he clearly has a lot of industry experience and yet doesn't hide what he doesn't know. And I wish I could get that kind of feedback when working on the problems in my domain, without having to have worked 10 years on it in production ...

Does anything I'm saying make sense ? Essentially I'm saying that what Casey does cover is like a God-send - a shortcut through years of trial and error. But he unfortunately doesn't go through everything (obviously), but doesn't even really show how to cover all the bases like the most common platforms (or what kinds of things you need to know / read about when porting to a platform). It's great he's showing a specific game, but there is so much I wish I could ask that would help with basically ANY problem I'd face when developing ...

And I think perhaps the platform layers are the toughest... ? Perhaps it is they that are so specific and finicky. Once you sort of have that down everything else is more theoretical ... I think ?

I get that I might seem ungrateful ... But I hope what I'm saying makes sense - That, seeing how direct and useful this stream is, if it were layed out in terms of "the issues game makers face" instead of "the process of making one game" (or maybe in tandem with it?) would help with the original mission - to show newcomers that you can do it all yourself.

His decades of experience is from what I gathered mostly in console and win32. So one can't really expect him to know how to do the android or IOS platform layer without some serious research and experimentation. The platform layers for console he most likely can't show because NDA not to mention it wouldn't be the current generation.

Then there is the fact that he's still just a human with his own biases and prejudices. Taking whatever he says as gospel would be a mistake. A lot of what he says makes sense but there are things on which I disagree with him.

I think it's important to understand that Casey is not exactly a "game developer" in the classic, broad sense of the word. Casey makes middleware, game tools, (engines) and such. That's his background.
And within that context what Casey does on stream sort of makes sense.

On the other hand, if you're primarily interested in "making games", most of the stuff on stream will appear like constant sidetracking, always opting to work on mainly irrelevant* technical stuff instead of doing gameplay programming or moving game to a more shippable state.

kewp
Nowadays the problem is creating a code base that runs on most platforms, is flexible and performant and not a nightmare to debug.

I believe neither of these things have been a real problem for gamedevs for at least a decade.

SDL, glfw and similar cross platform libs and tools have been out for a long time now.
Combine that with a conservative version of openGL and you are ready to go.

Dragging performance below 10ms per frame takes real talent irregardless if you use C/C++ or C# or Java or any other language.
And if you get a real performance hit, it's probably swaying to far off the "fast-path" of OpenGL.

Java with libgdx (LWJGL), or C# with MonoGame/OpenTK makes cross platform gamedev effortless. Neither are they engines which push upon you their abstractions or workflows.

It's never been this easy to make games as it is now. At least from a technical point of view.

It's the point of handmade hero in order to learn to do things yourself ?

I get that these issues have been solved, that you can make a game using SDL that's cross platform. But it's more fun, and empowering to see how these libraries are made.