Announcing Handmade Quake
philipbuuck.com
philipbuuck.com
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.
Ramblings in Realtime: http://www.bluesnews.com/abrash/
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.
These two projects are as close to a game development masterclass as one can get.
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.
False dichotomy.
If that were true, skill and knowledge wouldn't matter.
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.
You made me curious, what do you consider a good programming style for game programming ?
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.
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.
>> 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...
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.
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.
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.
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.
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.
> 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.
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:
https://en.wikipedia.org/wiki/List_of_Frostbite_games
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.
Quake was primarily a GOOD game, and if it must be classified further, a HIGH-END game.
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 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!
Just go look at the Steam hardware survey to find out why.