It’s classic software architecture patterns, only seen through the lens of performance and design iteration speed, which is the way I see the world even though I don’t make what most people would consider games.
Google search “design pattern book”. Right, now take any of those books.
If you want game related stuff try “game programming gems”.
This book is free... that’s literally all it has going for it. Wikipedia has better stuff that you know... actually compiles, etc.
If you got any value out of Game Programming Patterns, I cannot strongly enough recommend you go and read an actually good book on design patterns; you’ve probably been mislead by its vague hand waving and incoherent discussion of the various topics.
...but once again I recommend anyone who reads this post go browse wikipedia’s design patterns section. Its pretty neat:
If you’re going to recommend a book, then why not just recommend Design Patterns?
That’s actually a good book; and, if you read it, you will extract exactly zero value from this one, which gives only the most trivial coverage of a handful of the patterns from the former.
I feel like people who 5 star review this on amazon didn’t read Design Patterns becuase it looked to scary, and liked it because this was cute and simple and easy.
...unfortunately, the reality is that cute simple explanations are usually trivialising the content (as this book does; seriously go read a few game programming gems if you think game programming is as trivial as a singleton...), so given a choice of a universally acclaimed coverage of the topic, and some hand drawn pictures, why the heck would you recommend the latter to anyone other than a student?
I don’t get it, and I see no value in the content of this book ...but, I guess different things for different people.
I really like this book.
It teaches abstraction and techniques like streams and recursion. In that respect HtPD is very similar to Winston & Horn's Lisp.
One of my favorite tricks I picked up was to write the header comment for a function before writing any of the code. Once you've written down what the function is meant to do, it's often almost trivial to actually implement. (This is especially helpful when first learning recursion, as I was when I took the class.)
I'd like to see a HtDP/Racket attempt at Cleanroom to see what differences or similarities there would be. SPARK Ada and miniKanren, too. It's already closer to them with its algebraic style of specification of programs that use only a few primitives for easier analysis. Edit to add that what DonaldPShimoda describes is exactly what Cleanroom required with its "intended functions."
I've done some work (in projects, not academia) on trying to create low-defect software - by informal methods, not formal verification, so the paper was interesting.
In comparison to SICP, HtDP is slower paced and more basic in terms of Computer Science. Not surprising since the intended audience of SICP was MIT undergrads rather than those more toward the middle of the high school academic Bell Curve. The other major difference is that HtDP is a specific methodology utilizing specifications, tests, stubs, and other techniques for writing programs.
In terms of Books as Books, SICP is better written. It has far better type-setting and binding. It is a pleasure to read. And to hold. HtDP has a poor physical format and below average typesetting for a textbook, it's just ugly and awkward all around. HtDP doesn't reflect a Knuthian concern with typesetting and the experience is closer to a bound website than TAoCP.
TeX is a technology. In the context of my literary criticism, citing TeX and MIT press is analogous to "styled with CSS and hosted on GoDaddy" in regards to a website. TeX is a tool. MIT Press is a good publishing house and its catalog contains quality, but some of its books are still better than others in terms of typesetting (in the sense described). The differences can reflect authors' goals; publishing economics; and just the times (HtDP came about in the era of the commercial web).
Personally, I find the unconventional physical format of HtDP (8" x 9") awkward. It's unbalanced. The pages are too wide. The compensating increase in font size makes the lines so tall that there is low information density on each page. As a reader, the amount of head/eye movement for a disrupts my concentration. The gutters are far too wide.
I suppose that the wide gutters were to accommodate the Lambda icon, but these peter out in the first quarter of the book. Because these could be taken away with little effect their inclusion is a decision that could have been revisited and a more conventional layout considered.
The typography is haphazard. Code on page 191 uses san-serif. Code on page 322 is set in four faces; a mix of serif and san-serif, bold, and italics; and boxes. Page 299 has its own notation. Often its complexity obscures the big ideas: on page 278 the unimportant ideas are in bold (local is irrelevant to the local point of f's referent)  and the diagram's arrows connect the thinnest term and the thinnest term is typeset in italic.
Please don't take my remarks personally except in so far as I think HtDP is a book worth owning and reading and that the world is better for it existing in its current form. It's useful and supports an important project that I like. Thanks.
 Page 279 uses nested boxes to express locality. These have semantics distinct from boxes on page 322.
Nor does being published by a reputed publisher guarantee good typesetting. The story of TeX is itself a good example: TeX came into existence because Addison-Wesley, whom Knuth had chosen specifically for their great typesetting, was compromising on their typesetting for the 2nd edition of TAOCP vol 2 as they moved away from hot-metal typesetting. I'd expect that things are even worse today.
In the case of HtDP specifically, just opening the print edition of the book and flipping through the pages, I can see how its typesetting is indeed below average for a textbook. Look at the ugly table on page 21 (and throughout the book), the uneven typographic “color” on pages like 23 and 31, and just the whole mishmash of mismatched fonts on most pages. The book also has a lot of short paragraphs (two or three lines long), so the choice of indentation for paragraphs in the book is an odd one. A good book designer would have changed a lot of this.
Overall it's perfectly readable, and sure, all typographic subtleties fade away once a reader gets sufficiently engrossed in the content (which is what ultimately matters), but the book is not a delight to hold in one's hands even before that, as in the case of TAOCP. (Probably unfair to compare with something well above average (TAOCP), so compare with SICP which is probably at about the average for a textbook from MIT Press.)
Taking a look at the contents, once a person has read through SICP and understood it, they may find most of HtDP to be boring. It would be much better to read HtDP before SICP than the other way around.
I guess it might be a bit strange to think that we don't encounter iteration until the latter part of our second semester but it does make student get really familiar with recursion.
Not sure how I would have handled it if I had to work through it alone but I would at least recommend people to give the book a look.
Even with my past experience, I still needed a ton of help from professors and other students. It's kinda daunting to think about doing it alone, without much help.
Not aware of a PDF, but this version (just click "How to Design Programs") has a UI where you can go to each chapter and subsection with the sidebar. Pretty nifty.