Shippable Win32 Layer

I recently started following the Handmade Hero series and I'm currently on day 24, but there is one thing I really want to know; what does a "shippable" Win32 layer look like?

Casey keeps on referring to the fact that the Win32 layer so far is just for prototyping purposes and isn't something you would want to actually ship for a finished game, but my only guess as to what this actually means is that the code is a bit of a mess right now and may have some compatibility problems.

Other than cleaning up the existing code a bit (at the day 24 point), what else would need to be done to make the Win32 layer "shippable"?

I assume making it "shippable" is just in reference to compatibility concerns or something like that, but as someone who has never written a program with the Windows C API before I have no idea what making the Win32 layer "shippable" actually entails.

If anyone could shed some light on this for me it would be greatly appreciated! :)

Edit: I should also add that I did see Casey's partial list of things that need to be done, like getting keyboard layouts, raw input, threading, proper function for things like file I/O etc, but since that was a partial list I still wonder what the other things might be.

Edited by SpicyLemon on
In a shipping game you aren't going to have live looped code editing.

Also various workarounds for odd bugs that may crop up in certain versions of windows/graphicss driver.
I think what Casey means by "shippable" platform layer here is that he wants to put a lot more stuff there. In beginning he just wants something simple that works and does stuff he wants to show in game layer. But that doesn't mean its finished and will be like that in final release. In later days he was modifying platform layer a lot. Like adding multi threading for software rendering and asset loading, dynamic asset loading (load/unload), hardware rendering using OpenGL, and probably more things I already forgot.

Edited by Mārtiņš Možeiko on
Has there been any regular testing of the game across different hardware, besides the people following along on their own computers? Its plausible there could be hardware specific bugs to address in the final layer that the community could help make short work of if they haven't already.
Thanks for all of the replies everyone.

So it sounds like the platform layer not being "shippable" in this case just means that there may be compatibility concerns to iron out, be it hardware or software concerns, and there are things missing or things that could be made much more efficient (threading, file I/O etc). Would you say that's a fair description?

I'm sure I'll understand more as I go on in the series, but since I've only ever worked in languages where a platform layer has never really been much of a concern I just couldn't help but wonder what a "shippable" platform layer might look like.

I really enjoy the series, but sometimes the things that Casey leaves out of his explanations drive me crazy because I want to know everything :P

Edited by SpicyLemon on
Yes, in this case by "shippable" I just mean that we have not focused on things that the end user might care about, we've only focused on things _we_ care about for development. So we have not tested on different GPUs, we haven't stress-tested the audio, we only support XInput, we do state recording by default with no way to turn it off, we don't log failures, etc., etc.

Granted, you certainly _could_ ship a game with the layer we have, but you'd be putting yourself in a bad position to deal with compatibility issues and you would potentially make your customers unhappy with unnecessary bugs or problems that would be prevented with something that has been ironed out and tested with the _user_ in mind rather than the developer.

The reason we didn't do that yet is because it is usually better done toward the end of the project, when you have the APIs worked out exactly as you want them, so you don't spend time fine-tuning a platform layer for the wrong API and then have to undo some of it or spend time making changes to the API and re-testing/tuning.

- Casey
Thanks for the reply Casey.

I completely understand why you left the platform layer how it is for the series so far, after all, the series is about game development and while the platform layer is important, it wouldn't be all that interesting to spend a couple of hundred episodes in the Win32 API.

Do you (or anyone else for that matter) have any recommendations on where to begin learning about the things needed to make (in your opinion) an acceptable platform layer? Or would you say a lot of it just comes down to experience and just knowing what to do?

I'll try looking around myself of course but I've only ever programmed for the server-side of web applications so I've never had to deal with the problems a game would face if it were distributed to many people with a wide range in hardware etc.