i_c_b

There are a lot of properties that game mechanics can have that make people invest in games. Legible rules, clear feedback, deterministic and discrete cause and effect, clearly understandable win conditions and game states, being relatively simple to implement in code, having properties that make discrete variations and permutations of gameplay situations easy to build and easy to parse for players, setting rules up in ways that can be structured with real-time pressure, often embedded in large spatial structures to organically pace an experience...

Shooting (and combat more generally) has proven to be pretty easy to make satisfy most of these criteria. There are other core styles of actions that do as well (say, 2d Platforming, or clean puzzle mechanics like in games like Tetris).

These mechnical factors matter, because it's often the case that people who don't like violence in games would prefer games to focus on other kinds of challenges that they find more socially good in terms of morality or ideology. But then they stomp all over the mechanical styles of issues I was just listing above, and the results is predictably game designs broad masses of players don't want to play.

I've worked on both AAA hyperviolent games, as well as with educators on learning games with what they saw as pro-social game play, so this is a divide I've had front row seats to.

And to make what I hope is a productive contrast, one of the really great things about Undertale is that the designer didn't make being peaceful in the game lame. It is (or was for me) actively fun to try to figure out how to not kill enemies, because you still have to engage in bullet hell dodging while you try to psychoanalyze your opponents, and that dodging (for players who like those kinds of mechanics) still maintained a lot of the properties I just listed above.

To make a more real-world comparison, my father-in-law was an extremely successful junior college tennis coach, and he has noted in passing that he couldn't personally see how anyone could invest in Olympic sports like figure skating, just on the level of taking the competition that seriously. And his argument (he wasn't being universalizing, particularly, just tying it to his experience as an award winning coach) was that the extreme subjectivity of judge ratings was really offputting to him, as a competitor. Obviously tennis can have bad line calls and other controversial judge issues, too - all human sports can. But I think his argument ties in with my original one here; a lot of game players really like clean, legible rules with clear good and bad states so they can invest in getting good at games and take pleasure in their good play. And, as I say, shooting and combat at this point often fulfills that well.

(I'm a game designer, so I can't help but respond to this as a designer first, and not primarily a player)

I wonder how much of the issue here is the rise of the abstraction of "gameplay loop" itself as a lens that shapes what gets made.

One of the things that can keep a game fresh is players being unclear on where the border of play is, or what the range of the possible is. When I was playing Mario 64, say, I really wasn't clear on what was possible in the game, and so one of the main pleasures of playing the game was encountering new kinds of interactions and new kinds of activities embedded in specific space that I didn't know would be in the game. Same experience with Legend of Zelda: Ocarina of Time. As a matter of fact, this was true for me when I was first playing through the original Half-Life and the original Metal Gear Solid as well, or Castlevania: Symphony of the Night. The boundaries of the possible were not clear, and I had to play to tease them out. There was something like an implicit promise (because those games were violating my expectations early) that I might see and do stuff I hadn't seen and done yet if I stuck with the game.

Refined gameplay loops with variation are certainly cool and a great and an important tool, and many games I love do rely heavily on them (like, say, Slay the Spire, or the original Doom deathmatch as a kind of competitive play, or Street Fighter 3). But my general sense is that the more designers think in terms of game play loops, the earlier the edges of a game design and limits on the realm of the possible become clear for a player in a subconscious way. In a way, this is similar to a player noticing early that they seem to have heard all the music a game is going to provide, or seem to have seen all the enemies or weapons early - they recognize they've found all the novel stuff they're going to find, and everything going forward is going to be re-combinations and permutations. But I think it's a little harder to reason about when it comes to a player discerning the limitations of what kinds of play they will ultimately encounter, because it's a bit more subtle of an issue.

There's something here about the aesthetics of open-ended discovery versus the pleasures of achievement, I think, perhaps in something like a fractal sense.

I think there's a lurking development tension here, too. Constrained variations within game play loops can often help constrain arbitrary interactions in game play code, and arbitrary interactions in game play code make systems harder to reason about, and balance, and ensure stability, and modularly farm out different tasks to different developers. So I suspect there are development reasons for preferring these kinds of designs as well.

I worked on a couple of high profile FPS games during the era when designers really started trying to make these Potemkin village spaces off in the distance of levels to suggest larger realities (especially the 2000 shooter Soldier of Fortune).

I don't have anything interesting to say about how the backrooms phenomenon has evolved in recent years, but I do find it mildly amusing that I have a very different, but equally horror-themed, reaction to seeing "players" poking around in the original backrooms. Because it immediately gives me flashbacks to the feeling that players have found spots where collusion detection has had a nasty issue (because of bad geometry, or floating point precision errors in the physics system or a NaN, or players abusing the physic system to climb to areas they weren't supposed to), and now there's some awful-to-track-down bug to be fixed during a death march crunch time... all of which actually was a somewhat common occurrence during development at the time, of course.

Obviously, that makes me a lousy target audience for this art movement. But it's been vaguely fascinating watching people enchant, essentially, spaces that were experienced, from our side, as an very brittle (but useful!) optimization hack that we were all too aware could be easily broken.

Back in the late 90s, when I first entered the video game industry to work (when it was quite scruffy, countercultural, and populated by some pretty odd people), one of the first things I encountered was a new co-worker who, next to his giant tower of used Mountain Dew cans, had a black and white TV in his cubicle. This struck me as very odd at that moment in time - as I understood things, obviously the point of work was supposed to be that it was a place where you worked, not a place where you watched TV. (Now, granted, everyone else was playing the recently released Diablo on their work PCs during lunch in network mode, and we were a game studio after all, so my reaction wasn't totally coherent). Still, no one else had a TV, and that guy was young and single with no work-life balance, he was a recent transplant, and it still seemed unusual at the time.

Fast forward 28 years later, and now everyone has an amazing TV in their pocket at all times when they commute, sit in their work space, go out for coffee or lunch, or go sit down in the bathroom, all with a near infinite collection of video via youtube, netflix, and even massive amounts of porn. How little did I know. And that's to say nothing of texting and twitter and reddit and instant messaging and discord and ...

Several years ago, I was working on a college campus, and there were giant corporate-flavored murals beside some of the city blocks students walked, full of happy multicultural clip art people and exciting innovative technological innovation, and adorned with the message, "Imagine a borderless world!" Clearly that message was meant to be rhetorical, not a call to reflection, critique, or reevaluation. There did not seem to be the suggestion that one might imagine the borderless world and then, having done so, decide it was a problem to be corrected.

I wonder a lot, these days, if we're not deep into a Chesterton's Fence situation, where we have to rediscover the hard way the older wisdom about having separate spheres with separate hard constraints and boundaries on behaviors, communities, and communication pathways to facilitate all sorts of important activities that simply don't happen otherwise - something like borders and boundaries as a crucial social technology, specifically about directing attention productively. Phones and tablets are, in their own Turing complete way, portals to a borderless world that pierces the older intentional classroom boundaries.

I really try to avoid anything about politics here, but I recall there already being a controversy about this back in May of 2024. Specifically, there were public comments from the new CEO to investors about Cracker Barrel needing to change the demographics of the customers who ate at Cracker Barrel, and, depending on your point of view, some people interpreted the way the comments were said as suggesting that there was something morally suspect about how non-diverse, non-inclusive, old-and-white-and-straight the current dining demographics at Cracker Barrel were. There was a small right-of-center online public outrage du jour about it at the time. I'm not interested in litigating what the CEO said or how justified the outrage was, just noting precedent.

I can't find any of that discussion online, because it has been totally overshadowed by the more recent logo drama, but you can see a bloodless summary of the event here from the time: https://www.nrn.com/family-dining/cracker-barrel-unveils-str...

So there already was a pre-existing history here for people who are sympathetic to this point of view, particularly coming as it did shortly after some similar Bud Light and Target controversies.

"But that's not how real life works at all, right?"

How real life works is always a plausible interesting goal, but it's very often at odds with a bunch of other valuable goals for players.

A particular sharp example of this is sports video games. It might well be interesting (and certainly realistic) to simulate bad referees in a sports game. Horrible blown calls by tennis line judges, or missed calls by basketball refs, or bad umpire calls on pitches. Real-life soccer makes working the refs and their inability to see everything an art form, as far as I can tell.

Perhaps that's interesting, but the irony here is that real life refs are actually bad simulations of the original perfect game code in the first place, from a certain point of view. I think debates about the use of instant replay in sports gets at the heart of this, and one could imagine using real-time AI to help refs taking this conversation much further.

I think the sports case is a particularly sharp example, but it definitely holds with all sorts of choices in games.

For Animal Crossing in particular, I remember when I finally played it, it struck me after a while how much it had in common with recent MMOs (Everquest and World of Warcraft) that I had had fellow game developer friends have their lives severely disrupted by. And when I played the original Animal Crossing, I remember noticing specifically how careful the designers were in having players use up every bit of interesting content in a day after 45 minutes or an hour, so that eventually you'd run out of things to do, and that was the game's signal to put it down and pick it up again the next day. And I remember being struck by how intentional it was, and how humane it was... particularly given their goal of wanting to make a game that was asynchronously coop (where different family members could play in the same shared space at different times of day and interact asynchronously). As a game designer myself, I really respected the care they put into that.

Anyway, that's my immediate thought on seeing this (fascinating, valuable) experiment with LLM dialogue in Animal Crossing. The actual way NPCs work in these games as they are has been honed over time to serve a very specific function. It's very similar to personal testimonials by paid actors in commercials; a human expressing an idea in personal dialogue form triggers all sorts natural human attention and reception in us as audience members, and so it's a lot more sticky... but getting across the information quickly and concisely is still the primary point. Even dialogue trees in games are often not used because of their inefficiency.

I totally think that there will be fascinating innovations from the current crop of AI in games, and I'm really looking forward to seeing and trying them. I just think it's unlikely they will be drop-in replacements for a lot of the techniques that game developers have already honed for cases like informational NPC dialogue.

A few years ago, I was feeling dispirited about being middle-aged and had come around to the conclusion that, at least when playing games, my general dissatisfaction and "meh" response to the games I was playing was probably a function of my age rather than anything about the games themselves. I was enjoying some games to an extent, but I wasn't being really grabbed by anything, and I was having a hard time sticking with much that I was playing. It seemed like a reasonable just-so story, and a particular exhausting one if you make games and theoretically are supposed to like them.

And then I picked up Hollow Knight, was utterly sucked into it in a deep way, couldn't put it down, and came out the other side doing the Principle Skinner meme - "Am I so out of touch? No, it's all those other games that have been wrong..."

So thank you Team Cherry, for helping remind me that 1) I really can love games deeply, even in my tired middle-aged-ness, and 2) sometimes the problem isn't that a person is being too judgmental, the problem is that the the lofty potential of their ideals really is, perhaps, justified, and other creative people (for a variety of understandable reasons, really - making games is a hard and costly business) mostly aren't even really aiming for such things.

I'm probably saying something obvious here, but it seems like there's this pre-existing binary going on ("AI will drive amazing advances and change everything!" "You are wrong and a utopian / grifter!") that takes up a lot of oxygen, and it really distracts from the broader question of "given the current state of AI and its current trajectory, how can it be fruitfully used to advance research, and to what's the best way to harness it?"

This is the sort of thing I mean, I guess, by way of close parallel in a pre-AI context. For a while now, I've been doing a lot of private math research. Whether or not I've wasted my time, one thing I've found utterly invaluable has been the OEIS.org website, where you can just enter sequence of numbers and then search for it to see what contexts it shows up in. It's basically a search engine for numerical sequences. And the reason it has been invaluable is that I will often encounter some sequence of integers, I'll be exploring it, and then when I search for it on OEIS, I'll discover that that sequence shows up in much different mathematical contexts. And that will give me an opening to 1) learn some new things and recontextualize what I'm already exploring and 2) give me raw material to ask new questions. Likewise, Wolfram Mathematica has been a godsend. And it's for similar reasons - if I encounter some strange or tricky or complicated integral or infinite sum, it is frequently handy to just toss it into Mathematica, apply some combination of parameter constraints and Expands and FullSimplify's, and see if whatever it is I'm exploring connects, surprisingly, to some unexpected closed form or special function. And, once again, 1) I've learned a ton this way and gotten survey exposure to other fields of math I know much less well, and 2) it's been really helpful in iteratively helping me ask new, pointed questions. Neither OEIS nor Mathematica can just take my hard problems and solve them for me. A lot of this process has been about me identifying and evolving what sorts of problems I even find compelling in the first place. But these resources have been invaluable in helping me broaden what questions I can productively ask, and it's through something more like a high powered, extremely broad, extremely fast search. There's a way that my engagement with these tools has made me a lot smarter and a lot broader-minded, and it's changed the kinds of questions I can productively ask. To make a shaky analogy, books represent a deeply important frozen search of different fields of knowledge, and these tools represent a different style of search, reorganizing knowledge around whatever my current questions are - and acting in a very complementary fashion to books, too, as a way to direct me to books and articles once I have enough context.

Although I haven't spent nearly as much time with it, what I've just described about these other tools certainly is similar to what I've found with AI so far, only AI promises to deliver even more so. As a tool for focused search and reorganization of survey knowledge about an astonishingly broad range of knowledge, it's incredible. I guess I'm trying to name a "broad" rather than "deep" stance here, concerning the obvious benefits I'm finding with AI in the context of certain kinds of research. Or maybe I'm pushing on what I've seen called, over in the land of chess and chess AI, a centaur model - a human still driving, but deeply integrating the AI at all steps of that process.

I've spent a lot of my career as a programmer and game designer working closely with research professors in R1 university settings (in both education and computer science), and I've particularly worked in contexts that required researchers to engage in interdisciplinary work. And they're all smart people (of course), but the silofication of various academic disciplines and specialties is obviously real and pragmatically unavoidable, and it clearly casts a long shadow on what kind of research gets done. No one can know everything, and no one can really even know too much of anything out of their own specialties within their own disciplines - there's simply too much to know. There are a lot of contexts where "deep" is emphasized over "broad" for good reasons. But I think the potential for researchers to cheaply and quickly and silently ask questions outside of their own specializations, to get fast survey level understandings of domains outside of their own expertise, is potentially a huge deal for the kinds of questions they can productively ask.

But, insofar as any of this is true, it's a very different way of harnessing of AI than just taking AI and trying to see if it will produce new solutions to existing, hard, well-defined problems. But who knows, maybe I'm wrong in all of this.

I was in the game industry when we originally transitioned from C to C++, and here's my recollection of the conversations at the time, more or less.

In C++, inheritance of data is efficient because the memory layout of base class members stays the same in different derived classes, so fields don't cost any more to access.

And construction is (relatively fast, compared to alternatives) because setting a single vtable pointer is faster than filling in a bunch of variable fields.

And non-virtual functions were fast because, again, static memory layouts and access and inlining.

Virtual functions were a bit slower, but ultimately that just raised the larger question of when and where a codebase was using function pointers more broadly - virtual functions were just one way of corralling that issue.

And the fact that there were idiomatic ways to use classes in C++ without dynamically allocating memory was crucial to selling game developers on the idea, too.

So at least from my time when this was happening, the general sense was that, of all the ways OO could be implemented, C++ style OO seemed to be by far the most performant, for the concerns of game developers in the late 90's / early 2000's.

I've been out of the industry for a while, so I haven't followed the subsequent conversations since too closely. But I do think, even when I was there, the actual reality of OO class hierarchies were starting to rear their ugly heads. Giant base classes are indeed drastically bad for caches, for example, because they do tend to produce giant, bloated data structures. And deep class hierarchies turn out to be highly sub-optimal, in a lot of cases, for information hiding and evolving code bases (especially for game code, which was one of my specialties). As a practical matter, as you evolve code, you don't get the benefits of information hiding that were advertised on the tin (hence the current boosting of composition over inheritance). I think you can better, smart discussions about those issues in this thread, so I won't cover them.

But that was a snapshot of those early experiences - the specific ways C++ implemented inheritance for performance reasons were definitely, originally, much of the draw to game programmers.

Hey, thanks! I ran myself ragged on that project, so that's nice to hear. And yeah, I think we really did nail a particularly kind of visceral experience.

I was knee-deep working as a technical game designer + engine programmer on Soldier of Fortune when Half-Life came out. I can't put into words the impression that the opening that game left on me; I still remember very distinctly experiencing the tram ride, just being utterly entranced, and then being deeply irritated when an artist walked over to my cubicle, saw the game, and jokily asked what was going on, pulling me out of the experience. For me, it was one of those singular experiences you only have a very, very rarely in gaming.

It's funny, though - I would say in retrospect that Half-Life had the typical vexed impact of a truly revolutionary game made by a truly revolutionary team. In terms of design, the Half-Life team was asking and exploring a hundred different interesting questions about first person gaming and design, very close to the transition from 2d to 3d. And their influence, a few years later, often reduced down to a small handful of big ideas for later games influenced by them. After Half-Life, because of the impact of their scripted sequences, FPS games shifted to much more linear level designs to support that kind of roller coaster experience (despite many of Half-Life's levels actually harkening back to older, less linear FPS design). The role of Barneys and other AI character also really marked the shift to AI buddies being a focus in shooters. And the aesthetic experience of the aggressive AI from the marines as enemies also cast a long shadow, too, highlighting the idea of enemy AI being a priority in single player FPS games.

Certainly, those were the biggest features of Half-Life that impacted our design in Soldier of Fortune, which did go on to shift to much more linear levels, much more focus on scripted events, and would have resulted in much more emphasis on AI buddies too if I hadn't really put my foot down as a game programmer (and in my defense, if you go back to FPS games from that era, poorly implemented AI buddies are often, by a wide margin, the most frustrating aspect of that era of games, along with forced poorly done stealth missions or poorly implemented drivable vehicles - the fact that Barneys were non-essential is why they worked well in the original Half-Life). You can see this shadow pretty clearly if you compare Half-Life to, afterwards, the single player aspects of Call of Duty and Halo. Both are series that, in their single player form, are a lot more focused and a lot less varied than Half-Life was, but they clearly emphasize those aspects of Half-Life I just mentioned. And in practice, those were the single player FPS games that were in practice actually copied for quite a while.

I went to college in 1995, and my very first week of school, I was introduced to the internet, usenet, ftp, and netscape navigator. A few months later, I was downloading cool .mod files and .xm files from aminet and learning to write tracker music in Fast Tracker 2, downloading and playing all sorts of cool Doom wads, installing DJGPP and pouring over the source code for Allegro and picking up more game programming chops, and getting incredibly caught up in following the Doom community and .plan files for the release of Quake.

Then Quake came out, and the community that grew up around it (both for multiplayer deathmatch and for QuakeC mods) were incredible. I remember following several guys putting up all sorts of cool experiments on their personal webpage, and then being really surprised when they got hired by some random company that hadn't done anything yet, Valve.

There was really just this incredible, amateur-in-the-best-sense energy to all those communities I had discovered, and it didn't seem like many people (at least to my recollection) in those communities had any inkling that all that effort was monetizable, yet... which would shortly change, of course. But everything had a loose, thrown off quality, and it was all largely pseudo-anonymous. It felt very set apart from the real world, in a very counter cultural way. Or at least that's how I experienced it.

This was all, needless to say, disastrous to my college career. But it was an incredible launching pad for me to get in the game industry and ship Quake engine games 2 years later, in many cases with other people pulled from those same online communities.

I miss that time too. But I think there's something like a lightning in a bottle aspect to it all - like, lots of really new, really exciting things were happening, but it took some time for all the social machinery of legible value creation / maximization to catch up because some of those things were really so new and hard to understand if you weren't in at the ground floor (and, often, young, particularly receptive to it all, and comfortable messing around with amateur stuff that looked, from the outside, kind of pointless).

I never loved the original Far Cry as a player, but I did deeply appreciate it as a game designer.

I was working as a game programmer and technical designer on a big budget FPS back when the original Half-Life was released, and immediately "AI AI AI!!!!!" became a stifling buzzword and thought-terminating (ironically) slogan, heavily reorienting how people thought about shooter design and, essentially, ending boomer shooters as a thing for a good long while and ushering in the era of Halo, Call of Duty, cover-based shooters, and so on.

I happened to adore boomer shooters and have good taste for their rhythms and making them, so the transition is not one I personally enjoyed at all.

But worse in a way, Half-Life ALSO ushered in much more linearity in level design because of their awesome interactive set pieces and the particular interactive way they got across their story. Certainly that was the way its release was experienced in the studio I was in, anyway. Less sprawling, unfolding, and backtracking like in Doom (where the space unfolds over the course of a level in something like a fractal way), more following a string of pearls and hitting all the scripted events, like a haunted house ride. You didn't want the players getting lost, you didn't want them to get bored backtracking, and you didn't want them to miss any of the cool one-off scripted content you'd made for them.

(I love Half-Life, so I don't blame it for any of this - it's a vastly more interesting game than many of the games it inspired, which I think is typical of highly innovative games)

At the time, I wasn't quite yet a thoughtful enough, perceptive enough game designer to recognize how deeply in tension those two changes ended up being with each other. And so I spent a miserable year of eventual burnout trying to make "good enemy AI that players actively notice" as a programmer for a game whose levels kept getting progressively tighter, more linear, and more constrained to support the haunted house ride of scripted events.

As a point of contrast, games like Thief and Thief 2 were magnificently structured for good, cool AI that players could notice, and it was specifically because of the non-linear ways the levels were built, the slow speed of the game, the focus on overtly drawing attention to both player and enemy sense information, and the relationship between the amount of space available to players at any given point to the amount of enemies they faced, as well as the often longer length of time players engaged with any particular set of enemies... and of course, despite all these cool features, poor, poor Thief was released to store shelves just 11 or 12 days after the original Half-Life. Business advice 101 is don't release your first person game 11 or 12 days after Half-Life.

Anyway, that all leads in to my admiration for Far Cry's design. Their outdoor levels actually steered their game design in a direction that could let enemy AI breathe and be an interesting feature of their design, in turn giving players higher level choices about when, where, and how to make initiate fights. In that sense, it reminded me of where Thief had already gone previously, but in the context of a high profile shooter. But doing that required actively relinquishing the control of the haunted house ride-style of pacing, which I think was kind of brave at the time.

Ah, yeah. If you go through the code there, Bryan had to change that file in quite a few places to implement crouch sliding.

Nick Maggoire is an animator. Super nice guy. No inside voice at all. I shared an office with him for a while :) I haven't kept up with him, but after Q4 he left for Valve where he's been ever since, it seems.

That comment strongly suggests to me that Nick did the animations for players crouch sliding. Or, that's my hunch anyway.

Thanks! That's really cool to hear, 20+ years later.

I actually did all the effects work on the weapons (muzzleflashes, smoke, explosions, bullet holes and surface sprays, and all the extensions to Quake2's particle systems to make that content possible) and all the single player weapons system game balancing, as a matter of fact. Both the sound design and animation / modelling on the weapons went through a number of iterations to get them really over-the-top and delightfully powerful / ridiculous, too - I was lucky to work closely with a great sound designer and a really talented animator on that.

Thanks! I've been thinking a lot recently about maybe getting some of my own stories down. The late 90's were a really fascinating time to be in games.

And I loved Masters of Doom, too, although it was weird reading it and occasionally seeing people I knew show up in it, briefly.

I ... hmm. My memory is really, really dusty on that.

I remember I had a handful of conversations with Bryan Dube during development about Q4 deathmatch. He was a super sharp game programmer / technical designer who had done a ton of the work on Soldier of Fortune 2 deathmatch previously, and had worked on the Urban Terror mod for Quake 3 before that. And he was much more focused on multiplayer than I was.

We talked a lot about weapons (as I had done most of the code side work on weapons in Soldier of Fortune), but I'm now remembering him being really keen at the time on adding more high skill play to Q4 deathmatch. We all loved rocket jumping, and I remember him really wanting to add other kinds of high skill movement.

So that much I definitely remember. More than that and my memory is kind of fuzzy. To be honest, lots of team members loved deathmatch and Quake, and all of us were of course talking about gameplay possibilities all the time, so it's possible the idea originated somewhere else on the team.

Well, as I say, I'd been meaning to look into this in more detail because it's something I'd been long curious about. But I don't think I have time right now to dig into it.

Wow. This post gave me emotional whiplash.

I opened the collection of links, which is quite good if a bit old. But then I had a subconscious mental itch, and thought, wait... where had I heard the name mrelusive before? That sounds _really_ familiar.

And then I remembered - oh, right, mrelusive, JP-what's-his-name. I've read a huge amount of his code. When I was working on Quake4 as a game programmer and technical designer, he was writing a truly prodigious amount of code in Doom 3 that we kept getting in code updates that I was downstream of.

And he was obviously a terrifically smart guy, that was clear.

But I had cut my teeth on Carmack's style of game code while working in earlier engines. Carmack's style of game code did, and still does, heavily resonate with my personal sensibilities as a game maker. I'm not sure if that particular style of code was influenced by id's time working with Objective-C and NeXTStep in their earlier editors, but I've long suspected it might have been - writing this comment reminds me I'd been meaning to explore that history.

Anyway, idTech4's actual game (non-rendering) code was much less influenced by Carmack, and was written in a distinctly MFC-style of C++, with a giant, brittle, scope-bleeding inheritance hierarchy. And my experience with it was pretty vexed compared to earlier engines. I ultimately left the team for a bunch of different reasons a while before Quake4 shipped, and it's the AAA game I had the least impact on by a wide margin.

I was thinking about all this as I was poking over the website, toying with the idea of writing something longer about the general topics. Might make a good HN comment, I thought...

But then I noticed that everything on his site was frozen in amber sometime around 2015... which made me uneasy. And sure enough, J.M.P. van Waveren died of cancer back in 2017 at age 39. He was a month younger than me.

I didn't really know him except through his code and forwards from other team members who were interacting with id more directly at the time. But what an incredible loss.

I'm not exactly up-to-date on current techniques (I've been out of AAA game making for a while now), but here are some general observations that might be useful.

Way back during the transition from Doom to Quake, which in some ways really marked the transition from 2D to 3D, Quake's particle systems also relied overwhelmingly on small flat colored particles and their motions, rather than larger textured sprites and their silhouettes. (Quake did use a few sprites, but it was few and far between).

And I think the reasoning was pretty straight forward even back then; in a 3d game world, there are a lot of conceptual and architectural benefits to only working with truly 3d primitives - and point sprites often can be treated like nearly infinitely small 3d objects.

Whereas putting 2d sprites into a 3d scene introduces a bunch of kludges. In particular, 2d sprites with any partial transparency need to be sorted back to front in a scene for certain major blend modes, which gets really troublesome as there are more and more of them. They don't play nice with zbuffers. And because they need to be sorted, they don't always play nice with the more natural order you might prefer to batch drawing to keep the GPU happy. And likewise, they have a habit of clipping into 3d surfaces in ways that reveal their 2d-ness. There's probably more things I'm forgetting.

These are all issues that have had lots of technical workarounds and compromises thrown at them over time, because 2d transparent textures have been so important for things like effects and grass and trees. Screen door transparency. Shaders to change how sprites are written into zbuffers. Alpha testing. Alpha to coverage. Various follow-on techniques to sand down the rough edges of these things and deal with aliasing in shaders. And so on.

And then there's the issue of VR (or so a cursory skim suggests). I haven't spent time doing VR development myself, but a quick refresher skim of articles and forum posts suggests that 2d image based rendering in 3d scenes tends to stick out a lot more, in a bad way, in VR than on a single screen. The fact that they're flat billboards is much more noticeable... which is roughly what I had guessed before I started writing this comment up.

All of those reasons taken together suggest why people would be happy to move on from effects based on 2d texture sprites in 3d scenes, to say nothing of the other benefits that come from using masses of point sprites specifically themselves (especially in terms of physics simulations and such).

Andre LaMothe's prior book, Tricks of the Game Programming Gurus, was literally life changing for me.

I was in my late junior or early senior year of high school when it came out. My stepfather had a 386/20 and then later a 486/33, a Borland C compiler, and a generic 700 page "Learn C" book at home, and I had worked all the way through the book. But I couldn't for the life of me figure how in the world to bridge the gap between the extremely slow, "high res" 16 color graphics libraries that came with the compiler, on the one hand, and what Wolfenstein and Doom were doing, on the other, both of which I was utterly entranced by.

And then I saw LaMothe's book on a random shopping trip to... Software Etc, I think? I'd never seen anything like it. And I knew I had to have it, immediately.

After getting that book, I was diving headlong into relatively fast VGA C programming in mode 13h (320x200x256 color). I spent the afternoons of my senior year of high school writing relatively fast texture mapping routines and trying to get full screen 30+ fps interactive scenes and levels running, which I think I mostly did. I had to write my own paint program, too, for 256 color palettized textures. It was thrilling.

Thanks largely to my time with that book, later when I was introduced to the internet the first week I started a Computer Science program at college, I was primed to dive into all the awesome C open source game libraries and tools (like Allegro and DJGPP) that I found online, and I was making commercial games and working in the guts of the Quake and Quake 2 code bases two short years later. (The book and then the internet were not, however, great for my college career)

I know there are corny parts of the book, and maybe things that weren't as cutting edge as they claimed to be. It doesn't teach you how to actually write actual Doom, of course.

But prior to the widespread roll out of the internet, it's hard to get across just how inaccessible most of the knowledge in the book was, at least for a high school kid like me. It really was like turning on a light switch when I got it. Sometimes something is just at the right place at the right time for someone, and that's what that book was for me.

For anyone who wants to give LOGO a try, there's a really nice browser-based, javascript-implementation live at https://calormen.com/jslogo/ . Source for it can be found at https://github.com/inexorabletash/jslogo .

LOGO's great. It was my first introduction to programming back in 3rd grade in the 80s and definitely helped shape my eventual arc as a programmer. And honestly, it's just lots of fun to play with and explore.

I think there's a couple of orthogonal issues here.

One of them is the nature of interactivity in the levels themselves. There's a spectrum between having a game grammar made of distinct discrete interactive reusable objects and then building unique situations by assembling them in interesting ways, versus having (essentially) unique scripted traps or interactive things or set pieces that only show up in one place. Older action games that inspired Doom tend to draw from that former tradition; a lot of FPS games that came after Quake tended to go more down that second road. Quake's trigger system specifically opened up the door to a rudimentary kind of visual scripting that made the latter style of design more possible in a way that wasn't possible in Doom (although it was possible in Hexen via HexenC(?)). I think you could say that that style of design really came more into its own with Half-Life, which foregrounded unique interactivity grounded in very specific, themed levels much more clearly. Doom at its best seems like it's much more in the design space of, say, Robotron and old Mario games. Fewer unique set pieces, much more focus on discrete interactive toys to be recombined... and given id's background with Commander Keen and their earlier recreation of the first level of Mario 3, this design influence shouldn't be a surprise. Anyway, Quake feels like it is at the intersection of these two styles of design.

I think it is true that Peterson did try to go more down that second road of design in the episode 4 maps in a way that there was less of in other maps, and that it interesting.

But the other thing that sticks out to me more so, in terms of level design, is about the way the space is shaped. A lot of the very best Doom and Quake levels have a tendency of having different parts of levels intersect and interact in interesting, playful ways. The order that you see areas is different from the order that you hear areas is different from the order that you can attack into or interact with areas is different from the order you can move through areas is different from the order that different kinds of enemies can move through areas or attack areas. And that changes as you progress through a level, get keys, and activate switches. There's a tendency for levels to start somewhat linear and movement constrained but give information about later areas in a somewhat more non-linear, tantalizing way, and then as a player progresses, for the player's movement in a level to become more like a multiply connected graph as switches, keys, and activated lifts make a lot of one-way paths become two-way. And that style of design plays to the strengths of Doom and Quake using BSPs for levels as their fundamental data structure - BSPs specifically make these kinds of weird and surprising visual and physical intersections between areas manageable in terms of computational performance on 90's era hardware.

Whether or not someone considers the design approaches I just outlined appealing is fundamentally an aesthetic issue, obviously - there's no one right way to enjoy a game. But my general sense is that the Sandy Peterson maps in Doom and Quake tend to explore these approaches to play much less than the maps made by other designers.

You can read Carmack's .plan archive from 1996 here, if you're so inclined:

https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

It's a _fascinating_ snapshot into Quake's development.

I have no idea if his .plan is a record of what he, specifically, was doing, or if he was just capturing what the programming team was doing, but at the very least, it makes clear that he was aware of huge amounts of very highly specific game code issues as they were being worked on and was almost certainly deeply involved.

That's sort of how things ended up, but I don't think it was the intention. Doom and Doom2 were (and are) magnificent single player and co-op games, if you like that sort of thing, which I do (Doom was my lode star when I was working as a gameplay programmer / designer on Soldier of Fortune).

The better single player levels in Quake are actually really intricate and well-designed single player levels too, in exactly the way that Doom levels were great.

Some of the enemy design in Quake is actually pretty good, too, with sharply distinguished silhouettes between enemies, and good discrete gameplay property differentiation between them - well, at least for the zombies, the fiends, and the shamblers. Some of the others are fine, too (scraggs, grunts).

I think the bigger issue is they bit off way more than they could chew.

Specifically, Doom's single player mechanics thrive on having hordes of enemies interacting with highly interconnected levels in interesting ways, making space management a big part of the single player game play. Trying to figure out where you're safe to pick a fight, or how to steer the hordes around to create a space where it's safe to fight, is a big part of the draw. But, because rendering 3d monsters was so expensive compared to 2d sprites, Quake couldn't do hordes when it shipped, and fighting just a few enemies at a time (with their health highly jacked up) was a totally different experience. It could have been made to work, but they would have had to stray a lot further from the Doom gameplay recipe than they did.

And they also would have needed, I think, a lot more monster variety. A single player game with 30 different enemy types that were interesting and differentiated would have been much stronger.

That's my two cents, anyway.

"You can even tell that from the quality of Quake's levels which start with beautifully crafted and intricate levels, and as you approach the end, progress into "whatever, let's just ship it, this is gonna sell" kind of levels that were mostly just boring repetitive filler to pad the play time."

IIRC (this is well-documented if you want to double check), Tim Willits made most of the Episode 1 maps, John Romero made most of the episode 2 maps, American McGee made most of the Episode 3 maps, Sandy Peterson made most of the episode 4 maps, and John Romero made most of the level 1, military base themed maps in each episode.

The episode 4 maps are often barren, lacking in details, and missing much of the beautiful interconnections of earlier maps... but this is also true of Peterson's maps from Doom (he did a lot of episode 3 in the original Doom, IIRC). So I think it's more of "this guy might be a strong game designer in a lot of other contexts, but the specific needs of making cutting edge Doom/Quake style maps isn't a great fit for him".

I was at Raven Software at the transition from the Doom engine and other 2.5D engines to Quake (and then Quake 2, and then Quake 3, and then Doom 3), and there were a number of existing designers who were fine game designers in earlier, 2d contexts who found their skills severely out of sync with the changing demands of 3d map making, and most of them eventually had to transition to other roles or leave the industry.

This isn't even the first legitimately interesting video game connection to McDonalds, weirdly.

Treasure is an influential game development studio that did a lot of really interesting work in the mid to late 90s, responsible for games like Gunstar Heroes, Radiant Silvergun, Ikaruga, Bangai-o, Silhouette Mirage, Dynamite Headdy, Mischief Makers, Alien Soldier, and others. They were a bunch of ex-Konami developers (who had worked on games like Contra 3, Axelay, Super Castlevania 4, the arcade Simpsons) who were tired of making license games and wanted to make their own original games. A few of their games did well in the market, but they and their particular approach to innovation in action game rule systems has had a much, much bigger impact on other action game developers since.

And their very first game when they left Konami and started their own studio, the game they had to make to stay afloat to make Gunstar Heroes, was... a Sega Genesis McDonalds game, the 1993 "McDonald's Treasure Land Adventure".

Longplay here: https://www.youtube.com/watch?v=LNbmJyL872c

I've never played it, but it looks really solid and vastly better than it has any right to be.

There are serious aesthetic ramifications for running with the idea of games (and especially game rules) as being primarily composed of databases.

Specifically, at least in my experience, foregrounding database thinking when making game rules tends to make it easier for designers to add more rules and rule variations, or a lot more "content" generally, that tends to be more shallow and less novel in terms of surprising interactivity.

Now, that can be a desired kind of game design! If you look at something like, say, Gran Tourismo, where the pleasure is in having hundreds of real cars modelled, that can be really enjoyable to a certain kind of player. And of course most static level data is just a giant collection of non-interactive data variations as well. There are certainly other examples.

But if you sit down with, say, the original NES Legend of Zelda, with a paper notebook in your lap, and every time you encounter a new enemy, you write down the enemy's name, what is interesting about them, and what you might have to do to implement them, what you're going to notice is that the lion's share of enemies have custom behavior and interactivity that will need to be special cased, and that that is all the meaningful work of implementing that enemy.

Now, obviously, you COULD still use something like a database as the central repository for distinguishing the identities of all of the monsters and their properties. But in practice, the property of "it gets on top of you and eats your magic shield" is only used by the Like-Likes, the property of "it grabs you and drags you back to the dungeon start" is only used by the wall hand guys, and on and on and on, and _aesthetically_ the game benefits from the fact that each interesting enemy property is only used by each unique enemy (or so I would very, very strongly argue).

I've sat down and performed that "notebook in the lap" exercise with a bunch of games in the past, with Half-Life, Castlevania:Symphony of the Night, and Mario 64 being particularly fruitful (the same exercise works for items and weapons in a game, and interactive objects in game levels as well). One of the big traits that makes SOTN the game that it is is that a fair number of the weapons and items in the game have all sorts of strange, surprising, extremely special case game code, like the Shield Rod.

My personal experience from working on game dev teams as a game programmer/designer is that, as game programmers are drawn more into database thinking as the lens for expressing game design, the kinds of sparkly, jagged, surprising rules I just gestured at start feeling more and more like violations of the architecture of the system, gumming it up and making it ugly, instead of the actual wonderful desired point of the entire enterprise of game making.

And so instead you get games where much of the variations between items or weapons or enemies are things like statistic percentage variations - this weapon has +20% critical hit chance compared to that weapon, this enemy absorbs that kind of damage, this weapon has that attack speed, this enemy has that running speed, this enemy can or can't throw grenades, and so on.

I feel like I encounter this kind of design a lot in more recent games made by large teams. And it makes sense. Often management needs tighter control over game rule possibilities because they have large teams and novel surprising custom game rules are legitimately unpredictable and hard for teams to control or reason about - especially in the context of long-lived games that are going to be maintained by lots of random people coming and going over a long time frame. Having weapons/items/enemies that vary only by properties make it easier to add or remove them to hit deadlines without breaking the critical path of the game, they're much easier to apply analytics to for balancing, and they're much easier to use as DLC without affecting games in potentially show stopping ways, too.

But there are absolutely aesthetic ramifications to this approach. At any given moment, when a player is playing a game and deciding, without consciously recognizing it, whether they're going to continue sticking with a game or whether they're bored, the question of what new kinds of new stuff they might still encounter if they keep playing is definitely a factor. And what kinds of rules a game designer can and does vary heavily affects that.

Yeah, I have a deep game development background (both in industry and as an indie dev), but I've also worked closely for a number of years on building learning game prototypes with education professors from UW-Madison and CMU. So this is a space I'm super interested in.

I actually had added a comment that I ended up deleting about Duolingo (and Dragonbox, another educational game that I think structures learning pretty nicely). I was going to add the reference specifically because of their spaced repetition and incremental addition of skills, but then I deleted the comment because, well, those games are pretty elaborate, too, and I was mindful of the scope you looked like you were aiming for.

I like the general idea - I would like a game tool like this.

(and before I give my feedback, I should say, I spent a year or two working on a solo indie Zelda/Diablo mishmash focused on teaching guitar fretboards and music theory back in 2006-2009. A video of that incomplete game is here: https://www.youtube.com/watch?v=R6O32PFGZCE . It relied on players playing intervals and chords to cast spells, for both fighting and puzzle solving, in an ARPG real-time context. I had to pause development due to life, but I'm desperately hoping to find a way to finish and ship it.)

Anyway, I think that your game is... well, really, really hard. More specifically, it feels like it gives a lot of negative feedback right from the get go.

If it were me, I would probably add substantially more scaffolding early on - pull from a smaller section of the fretboard at first for the player to master and get more positive feedback, then expand from there in much more incremental steps. I also feel like the timer feels pretty harsh and negative at the beginning. I've played guitar for many years but have, myself, not really memorized all the higher notes on all the higher strings, so I'm actually receptive for what this tool is doing. But running out of time and then losing a life while I'm trying to count off notes feels frustrating, like it's actively interrupting me doing the learning activity I'm there to do.

Hope that helps! As I say, I like the general idea and would love to see a more fleshed out version.