andolanra

I'm not sure what "cool advanced projects" you're thinking of, but to my recollection, there was very little in the way of finished work created with the original Blender Game Engine. There were two game efforts associated with the Open Movie Projects: Yo Frankie! (associated with Big Buck Bunny) and Sintel The Game (associated with Sintel.) The former had something like a proper release, but the latter only ever got a few alpha releases before being abandoned: neither was terribly impressive except inasmuch as a demo of the technology, and to my recollection, neither inspired much hype. (The Wikipedia page for Yo Frankie! says dryly, "The game was noted by the gaming press," without any further elaboration, which does not speak to massive amounts of excitement or hype.)

Since then, aside from some interesting bits of work that didn't actually make shipping games easier, the engine really languished. My understanding is that a big part of the reason the engine was removed was that it made work on other parts of Blender more difficult, and that dispensing with the (little-used) engine in favor of the (increasingly popular) modeling tool was clearly a net benefit to being able to develop Blender, especially since the mantle of "open source game engine" had been taken up by other competent projects like Godot.

So yes, they may have at some point aspired to becoming a "mainstream game engine", but there's more to that effort than just aspirations and demos. (And at the same time, the fact that the BGE faltered doesn't mean that other open source game engine efforts would necessarily face the same fate.)

It's probably also worth saying that people have forked the game engine and you can still use it: the forked version is called UPBGE, and there are people out there trying to make it work. By and large, though, the Blender project seems to point people at projects like Godot, with the idea that a focused game engine is probably better suited to modern games than something that strapped a game engine onto a piece of modeling software.

The former is referring to representing an AST using a GADT in order to include the typing discipline of the target language in the host language. For example:

  data Term t where
    Num :: Integer -> Term Integer
    Bool :: Integer -> Term Integer
    Add :: Term Integer -> Term Integer -> Term Integer
    IsZero :: Term Integer -> Term Bool
    IfThenElse :: Term Bool -> Term a -> Term a -> Term a

With this AST, you can express well-typed programs like `Add (Num 2) (Num 3)`, but the Haskell type system will stop if you express an incorrectly-typed program like `Add (Num 2) (Bool False)`.

The "Trees That Grow" paper, on the other hand, is about reusing the same AST but gradually adding more information to the nodes as you progress through the compiler. For example, you might want to start with variable names being raw strings (so that a term corresponding to `lambda x: lambda x: x` looks like `Lam "x" (Lam "x" (Var "x"))`) but eventually replace them with unique symbols so that shadowed names are non-identical (so that under the hood it looks more like `Lam 1 (Lam 2 (Var 2))`, although in practice you'd want to keep the old name around somewhere for debugging.)

One way to accomplish this is to introduce an explicit type-level notion of compiler phases, give your terms a type parameter which corresponds to the phase, and use the phase to choose different representations for the same nodes:

  data CompilerPhase = Parsed | Resolved
  
  data Expr (phase :: CompilerPhase)
    = Lam (Name phase) (Expr phase)
    | App (Expr phase) (Expr phase)
    | Var (Name phase)

  type family Name (t :: CompilerPhase) :: *
  type instance Name Parsed = String
  type instance Name Resolved = Int

Using this example, an `Expr Parsed` will contain variables that are just strings, while an `Expr Resolved` will contain variables that are integers, and you can write a pass `resolve :: Expr Parsed -> Expr Resolved` which just modifies the AST. (This is a toy example: in a real compiler, you'd probably want to create a new type for resolved variables that still keeps a copy of the name around and maybe some location information that points to the place the variable was introduced.)

That's kind of the point of default values, though. If you wanted to make a change to the method and you want it to break to alert you to all the calls, then you can add a keyword without adding a default value for it.

    def foo(kwargs = {}, frob:)
      kwargs
    end

If you know git: a federated wiki works like that. To make a federated wiki work like a traditional wiki, you can think of there as being a "canonical copy" which you can clone, make edits, and then use a 'pull request' process for incorporating those edits back into the original. But you also don't need to have a single source of truth: you can, for example, have a group of people—say, students studying for a class—who are building their own wikis, and among each other they can copy in pages, make changes, copy changes back, and so forth, all building a web of things. In the same way that git can replicate a subversion-like workflow but also introduces the possibility of different workflows, a federated wiki can replicate a traditional wiki but also has a number of workflows it can accomplish.

The other one I mentioned—Maze Rats—is licensed as CC BY 4.0, so that might be a good place to start! (The Black Hack is licensed under the OGL 1.0, which unfortunately means it's not immune to the whole mess that this thread is about, but I'm hoping that a lot of the creators who put stuff out under the OGL 1.0 either come up with a new license that's not associated with WotC or relicense their stuff under something like a CC license. I guess we'll see!)

Absolutely and then some! I personally would argue that D&D itself—5E in particular here—is actually a fairly middling tabletop game. It's held back by a lot of historical cruft because even new editions end up being forced to stick to decades-old design decisions for the sake of tradition. A simple example here is the distinction between ability scores and ability modifiers: this is an old D&D-ism and trying to remove it sparks complaints about how it's "not D&D", but it's frankly some unnecessary complexity and other tabletop games lose nothing by dropping scores and just using modifiers.

Apart from the core design, D&D is also pretty middling as a product. Being a DM for D&D is hard—a fair bit harder than running many other tabletop games—and the book are at best a so-so resource: there's a lot of extra prep and careful balance that rests on the DM's shoulders, and doing it right means either falling back part-and-parcel on adventure modules or doing a lot of careful tuning and reading forums and Reddit threads. In an ideal world, the core books would include everything you need to know, but in practice the best DM advice is outside the core books (and sometimes even contradicts the books themselves!) Many other games don't have this problem.

To be clear, I don't think D&D is a bad game, but plenty of other games out there have clearer core designs, better presentations, easier-to-grasp rules, and overall more polish.

There are a truly massive number of RPGs out there with a wide variety of open licenses, especially the various Creative Commons licenses. The indie RPG sphere is massive and includes tabletop systems that range from "mild variations on the core D&D formula" to "almost fundamentally alien approaches to doing structured role-playing". D&D has long-standing brand recognition and cultural cachet, but it hasn't been the only player in this space for decades.

Sure is lucky that the title of the post explicitly says "mostly dead" and includes a big disclaimer about how not all of them are dead, then!

> This all works, people have been doing it for years in C, C++, Java, Rust, and more. In Zig, we can do better.

We can also do better in those other languages, too. For example, in Rust, I can use a crate like `bitfield` which gives me a macro with which I can write

    bitfield! {
        pub struct Color(u32);
        red, set_red: 0;
        green, set_green: 1;
        blue, set_blue: 2;
        alpha, set_alpha: 3;
    }

Don't get me wrong: it's cool that functionality like this is built-in in Zig, since having to rely on third-party functionality for something like this is not always what you want. But Zig is not, as this article implies, uniquely capable of expressing this kind of thing.

It is not at all the point of this talk, but as a side-note:

> …the functional programming language Haskell [compiles] via C, for example…

This is not correct. GHC, the de facto Haskell compiler, targets an intermediate language called C--, which resembles but is not identical to C and was explicitly designed as a compiler target. The point that some languages do compile to other high-level languages is true—Nim and Haxe being some good examples—but it is not true of Haskell.