Wow, looking at the syllabus, I can't imagine learning all of this in a single semester at more than a very surface level (and the course notes definitely don't seem surface level).
Take just rendering (my area of expertise): There's game programming in general, OOP and ECS, input and update loops, setting up a window, common patterns, etc, necessary prerequisite stuff.
Then there's rendering APIs and the GPU, e.g. learning about vertex/fragment shader concepts and syntax, buffers and uploading data, binding resources, making pipelines and such, etc. Then there's how to make an actual rendering _engine_, e.g. abstractions for batching entities, generating draw lists, command buffer recording for various passes, etc. Then there's lighting - analytic direct lights, many many forms of baked or realtime indirect lighting, BRDFs and PBR shaders, the pain that is shadow mapping, etc. Then on top of all that there's actually optimizing everything both from a CPU and GPU (shader) perspective.
And that's _just_ rendering. Game engines are usually way more. Asset management, physics, UI, possibly scripting, possibly networking, animations, usually some sort of scene editor, etc. All of those with many many subfields and complexities.
Well, here is the thing though: you don't need most of that rendering stuff to learn how to make a game engine - if anything it might actually be better to not focus too much on the rendering as there are many people with the misconception that a game engine is really all about its renderer when in most engines it only is a small fraction of it (i remember checking my own engine some time ago and only around 10-15% of the codebase was about the rendering, i mentioned it to some Godot developer who said that this number checked with Godot too and years ago a AAA game i worked on also had the rendering bits be around 7-10% of the codebase too, so i think on average the percentage is more or less stable) and there are a lot more things going on.
The content on the site seems to also follow, even quickly browsing from the materials there and despite using Vulkan (which is much more verbose than necessary), it still only mentions basic things like rendering sprites, meshes, some scene representation and leaves lighting and shadows (which only get a couple of paragraphs to describe the ideas behind shadow mapping) at the very end (up to that point everything is unlit/fullbright). Even lighting is only described at its basics and the page mentions some external resources to learn more if anyone wants to.
This reminds me of an upper level cs class I took in college. Can’t exactly remember the course but it was a lot of logic and terminal. We had this long syllabus and barely made it thru 2 assignments. It was a mess. Great school, great teacher too.
The next year I had another cs prof pull me aside and ask me what the hell happened in that class. And I didn’t have answer. It was an unfocused mess.
But that syllabus used in the course old. It wasn’t the first time the prof had used it. Something changed between my freshman and sophomore years, 2005-2007. When I first took cs, no one was in the class. By the following year they were adding intro cs classes. The next year a bunch of less passionate(for lack of better term) students ended up in higher level cs courses and maybe the course work was too rigorous. I still am unsure. Had some great programmers from the younger classes too.
That's exactly what I was thinking. When I read "CSC: Game Engine Programming" I was like, "oh shit, someone's offering a degree specializing in engines!?". I feel like a semester is barely enough to skim even the very basics..
The course is an overview. I think there’s space in the world for getting the big picture before zooming in to every detail.
The notes included on the site are quite complete. They make it clear that the GPU day’s project consists of modifying an existing WebGPU program. Other days like the text adventure have “higher” expectations (because the barrier to entry is lower).
Overall, it’s not what a professional might envisage, but it would definitely provide a top to bottom orientation on the workings of a game engine.
Well, these days there aren’t many good resources on the high level engine part, most gamedev focus on highlighting new and complex features or just use existing engines.
Take just rendering (my area of expertise): There's game programming in general, OOP and ECS, input and update loops, setting up a window, common patterns, etc, necessary prerequisite stuff.
Then there's rendering APIs and the GPU, e.g. learning about vertex/fragment shader concepts and syntax, buffers and uploading data, binding resources, making pipelines and such, etc. Then there's how to make an actual rendering _engine_, e.g. abstractions for batching entities, generating draw lists, command buffer recording for various passes, etc. Then there's lighting - analytic direct lights, many many forms of baked or realtime indirect lighting, BRDFs and PBR shaders, the pain that is shadow mapping, etc. Then on top of all that there's actually optimizing everything both from a CPU and GPU (shader) perspective.
And that's _just_ rendering. Game engines are usually way more. Asset management, physics, UI, possibly scripting, possibly networking, animations, usually some sort of scene editor, etc. All of those with many many subfields and complexities.