Watching the first couple videos, it looks like his claim, of building Quake from scratch, is not at all what he's actually doing in these videos, which is walking through the existing Quake source.
The 0.x videos are a walkthrough of getting the Quake source to compile and run. He goes on to mention that afterwards there'll be a couple of videos on C programming and then the main series will begin after that.
compared to youtube, twitch is a streaming experience with subscribers can comment on chat instantly.
I think, allowing subscribers to ask or comment instantly in what the caster does atm is an amazing opportunity.
And not suggesting the streaming twitch over youtube because of same time follow up (as told in another reply), agreed that it would be really hard to simultaneously replicate him.
I would not recommend game dev on twitch, example: handmade hero, awesome project, super great guy, but it is nearly impossible to follow what is going on.
I feel compelled to link to Michael Abrash's amazing and inspiring series of articles written when Quake was developed (don't know if there is a better link):
I read this while I was in high-school and worked on my own 3D engine in parallel (inspired by Abrash's articles).
As this was written while quake was under development, you get the reel feeling of the challenges they went through during development. Through "beam trees", z-buffer, to finally end at the PVS and sorted edge rasterization and mip-mapping technique that made the whole thing wrong smooth enough in the end.
There is a similarly lengthy description of the considerations they had regarding shadow maps vs. e.g. gouraud shading.
Carmack and Abrash's experience is very much trial-and-error and that's inspiring, because you realize that they went down many dead ends in order to find the right way to solve the problems. It's not some sort of divine stroke of genius, but far more their determination that solves the problems in the end.
Of course Abrash also mentions some of the uglier hacks.
Another very interesting exploration of the Quake source is Fabien Sanglard'[1]. He has done reviews of several of the Id games that have been released.
This looks to be similar to the Handmade Hero project (https://handmadehero.org/) which I love, but rather than building a modern RPG in the case of HH, Handmade Quake seems to be focused on rebuilding that familiar classic shoot-em-up, step-by-step, one line of code (and presumably one concept) at a time.
I'm sure the folks at id would be pleased, as they routinely opensource their games to share knowledge with others.
These two projects are as close to a game development masterclass as one can get.
I really think it's great that experienced game devs are willing to put so much effort into these things. I loved the idea behind the Handmade Hero series. Do you know anyone who has the time to step through all the lessons for such a thing though?
It's a great resource to have out there, I'm just doubtful all but a few dedicated individuals will have the patience and commitment to go through something like Handmade Hero fully, spending many many hours and days essentially making what someone else made.
Speaking for myself, I would find more motivation in learning how to build something I wanted to make, with guidance from a master of the trade. I couldn't see myself spending a year of evenings after work building what someone else already made to try to learn the skill. Some degree of synthesis should be included. Perhaps some will use the information as a template to build what they really would love to create. If that's the case, I think these resources are even more awesome.
If your goal is to learn about game development, I would avoid Handmade Hero. Over 200+ days into the project, and he still has a rats nest of a 90's era style Windows code base. It's clear he didn't put any pedagogical thought into the project. Masterclass is the wrong word to describe HH.
I've learned a lot of useful stuff watching the Handmade Hero feed on Youtube - but I stopped trying to follow along directly after the second week or so. Casey seems to harbor grudges against C++ and object oriented programming (both of which he will expound upon at length) that lead him to pile obfuscations and abstractions into his code that make it difficult to approach as a student, and difficult to separate what should be best practice from "stuff Casey does because anything other than raw C is a big dumb stupid."
And now that the series is 200~ days in, I know it would be futile to start again from the beginning (assuming I only do one "day" per day) because by the end of the year I still wouldn't know how to make a basic game. So I've gotten into the habit of just watching the particular parts i'm interested in (such as tiling, or fonts) and implementing them with SDL so maybe I can finish something decent within my lifetime (although I should probably just use Unity.)
That said, it is still a very good series, as long as you accept that Casey Muratori and his methods are very opinionated.
Yeah... if you disagree with his objections to object-oriented programming and design-by-abstraction you're going to have a hard time getting through the series.
If design patterns are comfortable and understandable for you then check out Game Programming Patterns[0]. It's a decent book.
However I agree with Casey's philosophy and the wider data-oriented design approach to programming. C++ is not a great language. Zero-cost abstractions are a myth. We should be thinking about the data and not about how to write clever, abstract code.
You are as wrong as you could get, the Handmade Hero project has about 200 hours and not 200 days as in 200 working days. Everything is coded live and recorded, so for 200 hours of work he is doing quite well.
The Windows specific code is localized in the platform code and this could be swapped with something Linux or OS X specific at any time.
Come one, don't do a strawman. Parent is factually correct that HH project has been going on for 200 days. Nowhere was even implied that 200 working days were put into the project.
It's not exactly 200 hours as Casey regularly goes well into the Q&A session and adds things past the first hour. But that's not really the point the OP was making, I guess. I really enjoy watching HH and I have nothing but respect for Casey and the way he's doing these videos, but you can't possibly maintain that the code he's writing should be taken as an example by anyone.
The HH code is just plain bad, dangerous, unnecessarily 'optimized' (read: taking ugly shortcuts or incomplete simplifications) in places where it doesn't matter, while super-inefficient in places where it does, it's untested, full of TODO's, does not use any modern language/compile features, it's basically just a lot of lines of code thrown together with minimal design (I do like his seperation between the platform layer and the game layer though). I've watched and enjoyed over 100 hours of HH, and the process the game is going through is very interesting, but in terms of code quality and suitability to 'learn game programming' I would not recommend it.
While I don't 100% agree with how Casey codes I wouldn't get as far as saying that The HH code is just plain bad, dangerous. He defined a problem space (implement a game like in the 90's with a software renderer) and decided to use the common parts of C and C++ for the actual implementation.
You made me curious, what do you consider a good programming style for game programming ?
>> While I don't 100% agree with how Casey codes I wouldn't get as far as saying that The HH code is just plain bad, dangerous. He defined a problem space (implement a game like in the 90's with a software renderer) and decided to use the common parts of C and C++ for the actual implementation.
Well, I would ;-). I think the quality of the code he writes for the game scores low on almost any objective measure of quality except pragmatism.
>> You made me curious, what do you consider a good programming style for game programming ?
I don't think there is a single 'good programming style' for games, it all depends on the game, the development environment (language, tools) the third-party components you use, the target platform, etc. I think there's a lot of best practices you could apply to any game though. Applying abstraction in those parts where it matters and doesn't negatively impact performance, for example. Defining the components of your game and keeping clear boundaries between them. Making good use of the language features at your disposal. Not obsessing over constant factor performance 'optimisations' before you know where the bottlenecks are. Thinking about and preferring efficient algorithms and data structures, over quick & dirty 'handmade' data structures, just because you feel STL or boost are 'not efficient' (it doesn't matter for 99% of your game code, especially not for something simple as HH). Not passing around naked pointers everywhere. I could go on for a while...
If you watch Casey work on HH, most of the time he's fiddling with and rewriting the same things over and over again, because he feels that he always needs to program everything 'in the simplest possible way' first, and then rewrite when necessary. I don't disagree with throwaway code at all, and not everything always needs to be 'designed upfront', but he's taking these things to the extreme, which results in an entangled mess of spaghetti code full of bugs (which you'll have seen he runs into in almost every episode of his stream). He basically disregards all the advances we've had in programming since the 90's, and keeps hammering in C-style code that happens to be compiled by a C++ compiler, but doesn't use any of the advantages C++ provides.
I still like to watch him do it though because there's definitely educational value to his videos, and he does solve some interesting problems along the way. And because I've been working on a simple game myself for a while. In my earlier comment I refrained from plugging my own little side-project but now you've asked you could take a look here [1] if you wanted to see how I like to program games. It's about an equal amount of hours in as HH but it already has some actual gameplay, is fully scriptable using Lua, Box2D physics, a sprite-based OpenGL rendering backend, persistency (freeze/unfreeze), action replays with live code updates (inspired by HH, but done 'the right way'), texture-mapped truetype font rendering, some interesting 'handmade' algorithms (complex polygon triangulation, sprite packing), motion controls, etc. I realise it's not the same thing as HH as I prefer not to re-invent the wheel for everything and use libraries and frameworks, but I still feel it's much closer to how you would program a 'real' game using modern technologies.
I think you missed the philosophical justification at the beginning of the series. This is Handmade Hero we're talking about where we build every system of the game with no help from libraries, frameworks, or engines. The whole point is to show people how it all works from soup to nuts.
Using libraries, even the STL in C++, would be cheating.
In the bigger picture of things these abstractions have costs. They're not free despite the C++ propaganda machine telling us otherwise. It's important to know what those costs are in order to make effective decisions about whether to include them in your project.
And finally the golden rule: if it looks right it is right. We're not here to write pretty, elegant code. Your pretty abstractions don't matter to the hardware. The target platform your system runs on is likely a highly-optimized piece of circuitry with real, physical constraints. Casey is the first programmer I've seen teaching people to keep the Intel manual handy and how to implement data-structures for cache-efficiency instead of pretty abstractions and virtual machines and template meta-programming.
It may not be a style of programming that agrees with you but it's one that has a growing number of proponents from Casey to Mike Acton, Jonathan Blow, and others. It's not a new idea either... but it certainly distinguishes itself as a reaction to the normative notion of programming by abstraction. It's a philosophy that proscribes programming by mechanical sympathy; using machines to manipulate data to get the results you desire.
I haven't missed it, I know the idea is to do everything by hand, which I think definitely has educational value but does not necessarily lead to better or more efficient code (to the contrary, even). Not using STL or Boost on the one hand, but using many of the available OS frameworks on the other hand, seems a bit arbitrary, I don't see why 'handmade' should mean 'reinventing the wheel' even on basic tools and building blocks like data structures etc.
>> In the bigger picture of things these abstractions have costs. They're not free despite the C++ propaganda machine telling us otherwise. It's important to know what those costs are in order to make effective decisions about whether to include them in your project.
Based on years of writing all kinds of software I can only disagree with this. Even in games there's such a tiny amount of code that would really benefit from going all the way down to the bare metal to avoid some constant-factor overhead of higher-level abstractions, that it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'.
>> It may not be a style of programming that agrees with you but it's one that has a growing number of proponents from Casey to Mike Acton, Jonathan Blow, and others. It's not a new idea either... but it certainly distinguishes itself as a reaction to the normative notion of programming by abstraction. It's a philosophy that proscribes programming by mechanical sympathy; using machines to manipulate data to get the results you desire.
Philosophically, that's all nice and dandy. Practically speaking, it doesn't make much sense though, except for educational purposes (and even then, only up to the point of showing how things work, then moving on and settling on a proven, battle-tested version of the same thing that you don't need to maintain and debug yourself. At least that's my opinion...
> it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'.
There is a circularity to this logic that you should address.
On the one hand, you shouldn't write your own abstractions because someone else did a good-enough one already.
On the other hand, you shouldn't try to write more appropriate abstractions because you should have working code first.
Well, which is it? If you intend to write appropriate abstractions(and that's a goal of HH), you have to start off being a bit too crude and slow so that you have a working test case; then you can gradually improve that with better algorithms as you uncover the performance profile.
Jumping to "use someone else's code" introduces a dependency and a guess about average-case behavior. That is okay if we're making "Premade Hero", but it teaches nothing about algorithm design.
And w/r to your own project, there are a lot of guesses about what will be useful or helpful - the specifications boil down to "it would be fun to add more physics and scripting to Thrust" which, as a game design goal, is quite impoverished. HH also lacks for design right now, but everything in it is built on direct experience and isn't going to box in Casey later. It is motions he is going through to show to the crowd how it all works if you were going to do it yourself.
I get that... but Handmade Hero is an educational effort. It is trying to show people how to implement their own data structures. How to read the manuals for your OS and hardware and how to program that hardware.
There is no "battle-tested" single data-structure that is going to fit into every program ever written. Different data, different platform, different problem. The philosophy chosen by STL and Boost, etc, panders to the lowest-common denominator or some idealized use-case. That might be useful for certain applications but making an educated decision on whether to include it takes knowing the cost of memory access and how your cache is being utilized (or not as is often the case with STL bloat-ware). The "zero-cost abstraction" promise is a myth.
Any significant game engine or system will end up considering, carefully, it's memory allocation strategy and access patterns. You will end up writing specialized data structures for your particular data challenges to best use the hardware and operating system running your program.
The more abstractions you add the more difficult it becomes to manage the complexity in your programs and you end up writing more abstractions to solve the problems with your other abstractions. Soon your program takes tens of thousands of cycles access the data it needs in your loop and you end up cutting out all of the abstractions anyway.
And there's nothing wrong with teaching people to think this way. If we want to call ourselves engineers it's time to stop thinking that only a certain elite is allowed to write the data structures we mere mortals are blessed to use. Everything has a cost. You can't add features and incur no cost. Every instruction, memory access, page to disk -- it all takes electricity and time. We should be able to think about our systems holistically and consider each aspect of our system.
I'm not saying we should write every program from scratch every time. However we should be able to if it's required by the problem we're trying to solve. Our job is to solve data problems. We take data in and transform it to perform some task. Everything else from the bottom up introduces a cost to the system. Maybe 90% of the time you do need a garbage collector -- you've considered your access patterns and object life-times and know that the particular algorithm and its costs align with the goals of your system.
What I find a bit disappointing is that this won't be a remake in the sense of writing the code in modern C99/C11, but rather a copy/paste with comments of the original code according to https://www.reddit.com/r/programming/comments/3xy110/announc... .
> It is named Handmade Quake thanks to the inspiration of the Handmade Dev community, and following the spirit of their manifesto, we will be starting with a blank Visual Studio project, nothing pre-written at all, and file by file, will turn it into the source code that id Software released to the world in late 1999.
> The main goal for this project is to show you how full video games are actually built.
Modern AAA games always seem to be written around a pre-written engine. Yes, the engine had to be written at some point, but it was likely a modified form of a pre-existing engine, and so on, iteratively, until you end up with a blank project you're writing in Turbo C or something similar which existed for MS-DOS in the later 1980s, pre-dating Quake.
My point is, modern AAA game development isn't clean slate. It's modification of existing code, which is a topic that seems rather under-emphasized in the introductory programming literature. It would be interesting to see some series of videos which were all about making a non-trivial change to some large codebase which has evolved for a few decades.
If you're trying to argue "pre-built" on the basis that they started with some existing code, that defines almost all software, so does not seems like a useful definition.
I think most commenters here would generally associate "pre-built" with the licensing of an existing engine available on the open market. Such as Unity, UE4, etc.
The very top AAA game studio actually use their own proprietary engines. For example, EA uses the Frostbite Engine in many titles:
Even if I were to accept the strict definition you proposed,
many of the upcoming titles on PlayStation 4, such as Dreams and Tomorrow's Children are essentially completely new game engines.
They're breaking new ground in rendering and gameplay technology and are as reasonably close to "from scratch" as you're going to get at this point.
True but we're not done building game engines. It's not a solved problem. New hardware, new problems. New code.
The point of the Handmade Hero series is to show people how every system is done. It exists because almost all literature and media on how to make games is presented from such a high level that there aren't enough people in this world who know how sound works or how the graphics pipeline works from a holistic perspective. It's all too much a black box and we're told to program with these high-level abstractions without understanding how it all works.
This series is for people who literally want to see what's involved in building a system from nothing. It's not necessarily about designing and making a game. It's about building game engines.
Presumably it will give the next generation of programmers a foundation on which to build the next UE, Unity, etc.
I don't find the "AAA" nomenclature worthwhile. So-called AAA development can be akin to factory farming and deliver garbage come release day. It's not necessarily doing anything right or wrong.
Quake was primarily a GOOD game, and if it must be classified further, a HIGH-END game.
"The series will likely be starting right around the beginning of 2016"
I really hope you do this. I also suspect you have underestimated the incredible workload this will be, and this shouldn't receive any hype until you start delivering. It will likely take 1-2 days to edit and produce 1 hour of video, and making a full game along with making full, good quality videos, will take, well...good luck!
So this is another Handmade series that you need to extrapolate knowledge if you want to follow on Linux, right? Nothing against it, of course, but, since I'm new to game programming, trying to learn SDL as I learned this stuff back in Handmade Hero was a huge pain, I couldn't get past the 14th episode or so.
The port to Linux will happen later. I forget the exact episode Casey justifies this but basically the problem for game developers is that every other platform other than Window is not a good target platform if you want to stay in business. So he's showing people how to target Windows first and will show us how to port later.
Just go look at the Steam hardware survey to find out why.
