CSCI 181G PO: Game Engine Programming | Hacker News Reader

CSCI 181G PO: Game Engine Programming

cs.pomona.edu

127 pointsmemkit20 comments

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.

There's also this great book for designing a game engine. It is quite thorough: https://www.gameenginebook.com/

> 15. You Mean There’s More?

heh, every book should end with just such a chapter

It's quite pricey for a "casual" purchase but I found that my public library offers the ebook for checkout, so one may wish to check their local library to see if it's similarly available

I've just finished reading it. It's quite a brick of a book (over 1000 pages!), but I thoroughly enjoyed it. The author is Lead Programmer at Naughty Dog so he definitely knows what he is talking about.

Rust and Unity are interesting picks. I feel like everyone used to use C++ to teach game engine development.

I imagine this course is more theoretical than practical? And maybe the students already have exposure to rust in other courses? I hope so, anyway. If not, it would be like teaching an introductory web dev course in Elixir. Students would learn a lot, but it sure wouldn't help them get their foot in the door at their first jobs. I've definitely taken classes that were clearly intended to be practical in which the teacher either taught it through their weirdly specific lens of familiarity, or had pet concepts about the "correct" way to do things that weren't in accordance with the rest of the world, or assume that the weird circuitous way they learned something was somehow superior because they're just so dang smart. The worst.

I've found most academics to be like this

I've been lucky enough to go to schools in which the curriculum was set by someone that that understood what the students needed to get out of the program rather than using their students as a vector to convince the world that they really needed something else.

Back in my day most 3D tutorials were in Turbo Pascal.

Also they weren't written by college professors but by demoscene teenagers :-P.

Fashion trends tend to change over the years :-)

Back in my day it was all 6510 assembly, written by engineers, hackers and hobbyists.

I followed a game engine minor in c++, all I could think was "I wish I was writing in Rust".

Our end result was cool though, we got a Guitar hero guitar working on it and remade clone hero. Fun times.

Rust makes sense because it is Open Source and a growing language in the gaming world. Unity, on the other hand, is a proprietary, legacy engine which is on the way out. I would have selected Rust and Godot instead.

Alternatively, if you prefer to watch over a 1000 videos featuring a non-standard programming approach and that end up going nowhere, you could go over to youtube and consume the Handmade Hero series...

Sarcasm aside, there's still lots to learn from the series although it does look like Casey's promise of "writing a complete game [...]" might not actually become a reality in the foreseeable future.

At the very least the first 10 or so videos teach you a bunch of stuff about win32, loading dlls dynamically, ring buffers (for sound), etc.

Yes, I actually found lots of interesting stuff (for me personally) even in later videos. Just recently I watched the ones where he introduces OpenGL, and found that quite informative.

Reply on news.ycombinator.com