cat petra on petrak@'s Website

Retrospection: One Year of Hexcasting

Thu, 29 Dec 2022 16:19:00 -0500

The very first push to the Hexcasting Github repo was made about one year ago, on Christmas. Version 0.1.0 was released for Forge on Minecraft 1.18.2 three weeks later, on January 18th.

At the time, I was not known as a modder. I had one project on Curseforge called Axiomatic Teleportation, which let you walk through walls. My other modding explorations, which I never released, consisted of two shitty Botania addons.

Now, a year later, I have over two and a half million downloads across all my mods. Hexcasting has been played live on camera by Direwolf20 and Soaryn, and included in 249 modpacks on Curseforge, including several that are based wholly around it. The Discord server has 1,571 members, and I even run the only actually active forum I know of.

So with one year behind us, and hopefully many more before, I thought I’d write a little blog post doing a bit of retrospection. What I’ve learned, where I’ve fallen, where I’ve succeeded. For posterity, maybe.

Two and a Half MILLION Downloads

I don’t know how to process that number. That is so many. That’s more downloads than people living in nearly every place I’ve lived. That’s more than the number of people I will ever learn the name of – that’s probably more than the number of people I will ever speak to.

I know that download count isn’t everything. There are lots of great mods with small download counts, and there are a lot of mods with tons of downloads that suck. But maybe that’s easy for me to say cause I’m on this side of the fence…

Aside: what the HELL happened December 23rd? December 22nd and before I was getting about 6,000 downloads per day on Hexcasting and PAUCAL pretty consistently. Then on the 23rd it spikes up to over 20,000 downloads in the day. My guess is its people’s Christmas break?

I’d really like to thank a few people here, for agreeing to poke at some funny little magic mod and get it in front of their audiences. Firstly Vazkii, who opened the door to getting Direwolf20 to play with it, and of course Dire, who wasn’t afraid to stumble around the stack on camera. I’d like to thank the FTB dev team for putting Hexcasting in the 1.18 DW20 pack, the first big modpack it got into, and all the other modpack devs who have wrangled its strange form into fitting in the pack.

I’d also like to thank Vallen, from Mischief of Mice. He was the first person who agreed to put the mod on camera, but after trying it, he decided he couldn’t do it justice with a clean explanation. I’d like to thank him for acceping that he couldn’t figure it out … oh, I’m not doing a good job of coming up with words here that don’t sound condescending. I guess I’d just like to thank him for tapping out, instead of releasing something confusing.

Lore

I am proud of the lore for Hexcasting.

I do, however, have a lot of stray thoughts about it, and I suppose this post is as good a time as any to let them out.

To put it lightly, it is not a nice mod. The mod encourages you to do some truly horrifying things in the lategame. And I suppose in the spirit of lifting the curtain, I should say when the ideas for mindflaying first started spinning around in my head, I really didn’t have anything more to think about it. I implemented it mostly because it was fucked up and spooky and because I dislike villager trading as a mechanic, and in general I was a lot stupider about the stuff I “canonicalized.”

But I’d like to think I’m wiser than I was now. I’ve kept mindflaying and Project Wooleye and all mostly as-is from those careless ideas, and I’ve done that because I think I made something thought-provoking.

I figure that it is OK to write about horrible, unethical things. It gets stickier, however, when you encourage people to do them, like the mod does. I’d like to think that what I’m doing is OK for two reasons.

I am not at all advocating for the player-character. I have done my best to make it really clear if you are rooting for them you are doing something wrong.
I’m not especially trying to make a statement with the mechanics. I think it would be very crass of me to try and draw some parallels between the events of the mod and some other human tragedy. Instead, I’m simply putting things out into the world and letting you, the player, wrestle with them.

And I think I’ve succeeded in these two points. I get a lot of worried comments from friends asking if I think I’m going to get cancelled or dogpiled upon for writing Hexcasting, but so far the most concern I’ve gotten is from people worrying about worry, not anyone actually voicing about the mod. And I’ve heard from other people who refuse to play the endgame, who will get enlightened and play with great spells, but who refuse to mindflay anything because it makes them feel icky. I think these things together tell me that, although I am definitely playing with fire, I’m doing it in a way that’s OK.

And now that the lore is over and written and it’s had time to sit, I’m starting to see one possible reading of the lore that I think is interesting. Is it pretentious to analyze the writings of you and a friend like they’re some great literary work? Maybe. But I’m going to do it anyways.

I find it fascinating how the way people act changes in different contexts. Here’s an example; I’ve been watching ilmango’s Vanilla Skyblock series, and one of the major progression gates is villager trading. As anyone who’s done villager trading knows, it is immensely frustrating. In a moment of anger at a villager who won’t go where he wants them to go, he punches them off the platform into the void, and says “if you want to have a mind of your own, you can do it in the void.”

So, there’s some sequence of events that starts with ilmango, who I trust to be a reasonable and nice person, and ends with him punching (a video-game representation of) another person to their death for being too independent.

I’m not saying that ilmango is some kind of twisted psychopath inside; in fact I’d like to explicitly say the opposite. It’s macabre, I know, but I am fascinated by how you can construct contexts in which people would do things they ordinarily never would.

So I guess you can read mindflaying as a sort of landscape in which you have to sit with that difficult question. “Am I going to do it? Is it OK that I did?”

There’s no value judgement there from me, and to be honest I don’t think the answer matters all that much. I’d just like to think I’ve created something provocative enough that you can sit and wrestle with yourself and your thoughts.

Money

And now for something completely different: how much money do I make?

Money is a big ol taboo but I do think it’s very important to talk about it, so I’ll do this quick. On both Curseforge and Modrinth I get about a dollar for every 2,000 downloads. Since I started making any money off of this March 2022, I’ve made on average $434.50 per month between Curseforge, Patreon, and commissions (although the amount per month varies wildly).

No one wants to hear it but I’ll say it anyways: please do not start Minecraft modding in the hope you’ll make a lot of money. You’ll probably be really disappointed, but more to the point making money is a really shit motivator. You’ll have a lot more fun if you’re modding for the joy of modding, and see any money you might make as a fun bonus on top.

That being said, though, it is quite nice to be paid for what I love to do. It’s not nearly enough to live on or anything, but it does help me pay the bills on top of my work study at college. It’s especially nice because there’s such a huge separation between work put in and money made; as I’ve demonstrated to myself over my December-long hiatus from Hexcasting I can take it easy and money will still trickle in, and I think that ontological distance is really good for my mental health.

And That’s All Folks

I’ve got a couple more things in the tubes. The next Hexcasting major update will probably be mostly bugfixes and balancing; there’s a lot of rough edges to the mod that I just haven’t taken the time to clean up.

Work on Bemis is slowing down mostly because it’s so boring. I really want the mod to exist. but almost all the work to be done is munging data around into Asciidoctor, which really doesn’t like outputting to things that aren’t text. Props to Vazkii; there is a lot that goes into making a documentation mod.

Come back next time for Bemis 2: Just Write Your Docs On A Goddamn Web Site And Send Your Players There.

Also, I am super smart and overwrote the State of the Petrak@ with this file. Oof. I have a backup on my old laptop and I’ll fix it when I get back to college in a few days.

A Proof that `0^0 = 1` using Type Algebra

Sat, 17 Sep 2022 14:22:29 -0500

… As taught by someone whose experience with type algebra consists of “figuring it out” and “being drip-fed things by Alwinfy.” This is going to be fast and loose.

Anyways. Type algebra is doing math on types. The core idea, I suppose, is that a type can be represented as an integer that is the number of possible values for the type.

That’s a weird idea, but let’s just try playing with it on some simple types. What about bool? There are two values, true and false, so bool = 2. We could imagine some kind of type with three states, which mathematicians call Z3 (“Z sub 3”), and that would equal 3, of course. u8, an unsigned 8-bit integer, would equal 2^8 = 256.

Also, note that i8, a signed 8-bit integer, also equals 256. Only the number of values matters in type algebra, not whatever the values might actually be. Because you can losslessly convert from i8 to u8 and back, in type algebra they’re considered the same.¹

Composing Types

Now, of course in computer science we can combine types into other types. For example, we can do this:

struct MyType {
    foo: bool,
    bar: Z3,
}

(I’m writing that in Rust, but the language doesn’t really matter.)

Now, let’s think about what integer is equivalent to MyType. We can enumerate the options pretty easily:

{ foo: false, bar: 0 }
{ foo: false, bar: 1 }
{ foo: false, bar: 2 }
{ foo: true, bar: 0 }
{ foo: true, bar: 1 }
{ foo: true, bar: 2 }

Alright, so MyType = 6.

What about a pair of (bool, u8)? Well, we have 256 options for the u8, and for each of them we can pick true or false for the bool. So it looks like (bool, u8) = 2 * 256 = 512.

Hang on a moment. We know that bool = 2 and u8 = 256… and the size of (bool, u8), 512, was the result of multiplying them together. Similarly, MyType equaled 6 = bool * Z3 = 2 * 3.

So, in type algebra, making a struct is multiplication.

We can test this idea with some property-based tests. What do we know about multiplication? Casting back to grade school,

Commutative property: x*y = y*x
Associative property: x*(y*z) = (x*y)*z
Distributive property: x*(y+z) = x*y + x*z
Identity property: x * 1 = x
Zero property: x * 0 = 0

We can’t test the last three properties because we don’t have an analogue for addition or the numbers 0 or 1 (yet). But let’s try out the other two:

MyType would have 6 possible values no matter if it was defined with foo before bar or bar before foo.
Let’s examine (bool, (Z3, Z4)). We know (Z3, Z4) has 12 = 3*4 possibilities (we could enumerate them if we want), and so (bool, (Z3, Z4)) has 24 = 2*12. And if we change that to ((bool, Z3), Z4), we already wrote all 6 possibilities for (bool, Z3) = 6. And that all multiplies together to 24 = 6*4.

Alright! Now, if we could only find a nice analogue for addition.

A Nice Analogue for Addition

Well, let’s start by exploring around. We know, say, 2 + 3 = 5 in normal-math-land. So we need to do something to bool and Z3 and end up with five possibilities.

We can go back to listing the possibilities outright, like we did way back at the beginning of the article.

bool:
- true
- false
Z3:
- 0
- 1
- 2

… and hey wait a second. Let’s remove the type headers:

true
false
0
1
2

And lookie here, we end up with five possibilities! It looks like the analogue of addition is picking one type or the other. So, bool | Z3 = 2 + 3 = 5.²

What about Z3 | Z4? That looks like it should just be 7, but if we write them out:

… we have repeats. It looks like we need to consider numbers of different types to be completely different. Some languages (like Rust) do this; most (like C and Java) will automatically convert between numerical types sometimes. But in type algebra, the 0 from Z3 and 0 from Z4 have to be completely different.

As an argument for that, imagine that we did fold these things together. So, Z2 | Z3 would have the values 0, 1, 2, and would equal 3. And bool | Z3 would have the values true, false, 0, 1, 2, and would equal 5. But we know that bool = Z2, so we would have 3 = 5 … so we can’t have that. To avoid ambiguity, if it would be ambiguous I’ll mark them as Z3(0) and Z4(0) or whatever.

Anyone who’s coded in Rust (🚀🚀🚀) might recognize this addition operator as its enum construct. TypeScript coders might recognize it as its union types.³ And programmers of Haskell or OCaml might recognize it as an algebraic data type. Hey, it’s the same algebra as in type algebra!

Again, let’s try picking at some property based tests. Addition has the following properties:

Commutative property: x+y = y+x
Associative property: x+(y+z) = (x+y)+z
Identity property: x + 0 = x
(And the distributive property which we covered above)

We also don’t know a type for the number 0, but let’s try out the other two:

bool | Z3 = Z3 | bool = 5; it doesn’t matter which order we write the types in (true, false, 0, 1, 2 vs 0, 1, 2, true, false)
bool | (Z3 | Z4) = 2 + (3 + 4) = 7; (bool | Z3) | Z4 = (2 + 3) + 4 = 7

Hey, that all seems to check out. Now, let’s tackle the distributive property. In other words, (bool, (Z3 | Z4)) should equal (bool, Z3) | (bool, Z4). Well, these types are all small enough that we can just enumerate them.

(bool, (Z3 | Z4)) has 14 possibilities:
- true, Z3(0)
- true, Z3(1)
- true, Z3(2)
- true, Z4(0)
- true, Z4(1)
- true, Z4(2)
- true, Z4(3)
- false, Z3(0)
- false, Z3(1)
- false, Z3(2)
- false, Z4(0)
- false, Z4(1)
- false, Z4(2)
- false, Z4(3)
(bool, Z3) | (bool, Z4) also has 14 possibilities. I’ll label the options L and R for Left and Rright:
- L(true, 0)
- L(true, 1)
- L(true, 2)
- L(false, 0)
- L(false, 1)
- L(false, 2)
- R(true, 0)
- R(true, 1)
- R(true, 2)
- R(true, 3)
- R(false, 0)
- R(false, 1)
- R(false, 2)
- R(false, 3)

Nice! Now if only we had types for 0 and 1.

Types for 0 and 1

A type for 1 would have exactly one value. Not a lot of languages have this, but some do:

Rust has the () type, pronounced “unit.”
Java has the Void type, which can only ever be null.
TypeScript lets you define “string types,” where the only valid value of that type is that particular string. Note that under type algebra all these string types are considered the same.

For this article I’ll call this unit. And we can play around with it: a struct (T, ()) adds no more information to T that wasn’t already there. Hey look x * 1 = 1!

What about 0? A type that has no values? What would you ever want that for?

Actually, it’s quite handy. Both Rust and TypeScript have this and call it never.⁴ It’s the type of things like exiting the program or throwing an exception. The secret sauce here is that both languages implicitly cast that type to anything else, which is OK because you can never have a value of that type. This lets you write type-checking code like:

const myNum: number = x !== 0
  ? x / 5                // type of this branch is number
  : throw DivideByZero() // type of this branch is never, which we can pretend is a number because 
                         // we'll never get to do anything with `myNum`

But that’s the realm of actual computer science; we’re doing type algebra here. And we can test the additive identity with our new never type. What happens if we go x + 0? We get something like T | never. And look at that! We can’t actually have a never. so T | never = T.

We can also test the multiplicative zero property: what happens if we have a type (T, never)? Well, we can’t actually construct an instance of that type, because we would need to get a never somehow and we can’t. So, (T, never) has 0 values … and hey look, x * 0 = 0.

An Aside About Generics

Let’s look at this type here.

enum MyEnum<T> {
    TheType(T),
    Boolean(bool),
}

(If you don’t know rust, that’s how you would write the equivalent of T | bool. The <T> is a generic parameter, meaning you can put any type you like in there).

You know the drill, start plugging things into it:

MyEnum<Z3> = Z3 | bool = 3 + 2 = 5
MyEnum<bool> = bool | bool = 2 + 2 = 4
MyEnum<u8> = u8 | bool | 256 + 2 = 258

… hey, that looks an awful lot like the function f(x) = x + 2.

In type algebra, types with generics are functions.

Exponentiation

Now let’s get onto the thing I actually promised in the title of the article. What on earth could exponentiation represent?

Like we learned above, we’re going to want some generic type over two types, T and U, that somehow ends up exponentiating them.

Let’s look at a simple arithmetic example again, let’s say 3^2. From grade school we know exponentiation is repeated multiplication, so this equals 3 * 3. So we’re looking for something that will repeat Z3 twice, like a struct that automatically has two fields.

Or how about 5^3? That’s 5*5*5, so we want something that has three fields of Z5. In fact, any T^U can be read as “something with the number U fields of type T”.

So we have every value in U, and a T associated with each one. What does that sound like? Well,

… it’s a HashMap<U, T>!

Well, almost. Most languages don’t require every U key to have an associated T value. So I’ll call the exponentiation function an OmniMap.

Let’s enumerate one of these OmniMaps to make sure we’re not completely barking up the wrong tree. What about checking 3^2? That would be OmniMap<bool, Z3>.

{true => 0, false => 0}
{true => 0, false => 1}
{true => 0, false => 2}
{true => 1, false => 0}
{true => 1, false => 1}
{true => 1, false => 2}
{true => 2, false => 0}
{true => 2, false => 1}
{true => 2, false => 2}

… and lo and behold there are 9 values!

We’re at the home stretch here! Let’s look at powers of 0. 0^3, say, would be OmniMap<Z3, never>. Let’s go and construct that:

{0 => ... wait a minute }

We can’t actually construct any values of OmniMap<Z3, never>, because in order to do so, we would need a value of type never. So, 0^3 = 0.

Alright. We’re ready to tackle 0^0. That would be OmniMap<never, never>. And … we can construct exactly one value of that type: the empty map, {}, with no keys and no values. And so, 0^0 = 1. QED.

Lightning Round

The article proper’s over! But type algebra is so cool, here’s an unedited coredump of a bunch of other type algebra fun stuff.

Functions Are Also Exponentiation

This “omnimap” is actually the mathematical definition of a function; a mapping from one type to another. I chose to use omnimaps instead of functions for the example because I think it makes the 0^0 case easier to understand.

Lists

Lists are nice, easy types, right? What’s a list in type algebra? Well, let’s look at List<bool>:

[]
[false]
[false, false]
[false, false, false]
…

Whoops, looks like lists are infinite.

Optional

A lot of languages have an “optional” or “nullable” construct, meaning a value can be whatever value, or null. So, that’s adding one value to the number of values representable by the type.

Hey, how does Rust define its Option<T> type?

enum Option<T> {
    Some(T),
    None,
}

AKA, T | unit.

Orderings

What about an ordering? That is, a list containing exactly one of each value of a type.

Well, for the first slot in the list, we have T options. For the next, we have T-1 options, because one of them we already picked for the first slot. For the slot after that we have T-2 … and so the total number of options for the ordering is T * (T-1) * (T-2) * (T-3) * ... * 1.

And that’s factorial! Ordering<T> = T!.⁵

Let’s examine the identity (T + 1)! = (T + 1) * T!. So, Ordering<Z3> = (Z3, Ordering<bool>). And that’s the car/cdr definition of a list.

You Can Take The Derivative Of Types

http://strictlypositive.org/diff.pdf

I won’t pretend to understand this any more than you do.

Mathematicians call this “lossless conversion” function a “bijection,” as in “we can form a bijection from i8 to u8.” ↩︎
I’m using TypeScript’s union type notation here, T | U. This is because Rust doesn’t let you define enums inline like this and I’ve never used Haskell. ↩︎
Actually, TypeScript will fold together identical types, so number | number == number. But I’ll ignore that. ↩︎
OK, Rust actually calls it !, but it’s pronounced never. ↩︎
An early version of this article was a proof that 0! = 1. The proof is that an Ordering<never> has exactly one value, the empty list. ↩︎

The Current Project #8: Fabulous Prefabs

Fri, 19 Aug 2022 12:28:36 -0500

I guess I’m renaming this series to TCP now, for “The Current Project.” I’ve updated the tags on the old posts accordingly.

Anyways! Work on that project I talked about last week is going pretty great. While it’s indev, I’ve code-named¹ it “Robot Language” after the meganeko album. Starting fresh has been really good for me, I think; I have gotten way more done in a week and a bit than I could have on Foxfire. I’ve implemented rendering, collision, FOV calculations … lots and lots of things.

Here’s a screenshot of the game as it is so far.

That better CRT effect is courtesy of a video by Acerola. The FOV calculations use Adam Milazzo's algorithm.

It’s a mystery game, so I won’t reveal too much … but I will say you wake up on a spacecraft with no memory, and have to figure out what is going on. I’ve been playing Outer Wilds recently, and I’m really inspired by the idea of a metroidvania where your “keys” are knowledge.

I don’t think I’ve heard of a game that mixes metroidvanias with Zelda-like dungeons. To me, a Zelda dungeon feels kinda like a metroidvania in minature.² The plan is to have the larger challenges in the game be unlocked with knowledge, and smaller, self-contained challenges styled after Zelda dungeons with a key item that unlocks new areas in the ship.

But we’ll see as I design it more.

Prefabs

But anyways this post is not really about Robot Language; it’s about a (technology? idea? algorithm?) I’ve developed as I write the game.

Robot Language’s world layout will have no randomization, given it’s a metroidvania-like. So, I need some way to make the world, and doing it from code would be a pain in the ass.

So, in short, what I do is I draw out a map in RexPaint, a kinda crufty but very useful tool for drawing ASCII art. Then, the game loads the file at runtime using the aptly-named rexpaint crate. Each character and its foreground color is then mapped to a prefab. That mapping is written in KDL, a language like XML but not horrible to write which Lemma has totally hooked me on. Then, those prefabs are mapped to actual collections of components in code.

I realize that makes no sense, so here’s some pictures to show you what I’m talking about.

Here's the map file for the area of the ship the previous screenshot is of. It's not cut off at the edge; this is a rotating spaceship! This zone is a ring is connected at the left and right.

Here’s part of prefabs.kdl, which is loaded by the game on startup.

"#" color=0xffffff {
    prefab "wall"
    type "inner"
}
"#" color=0x3333ff {
    prefab "wall"
    type "outer"
}

"+" color=0xff0000 pass-color=true {
    prefab "door"
    closed true
}
"+" color=0x00ff00 pass-color=true {
    prefab "door"
    closed false
}

// --- Furniture ---

// This orangey color is for food
"T" color=0xff4000 { prefab "table"; type "dining"; }
"T" color=0x6666ff { prefab "table"; type "stainless"; }

"c" color=0xff4000 {
    prefab "widget"
    char 0xe3 // pi
    fg "dark-yellow"
    bg null
    z-level 300
    collider false
    occluder false
    description "chair?plastic"
}

// Angstrom for any and all misc furniture
"0x86" color=0xff4000 { prefab "microwave"; }
"0x86" color=0xd900d9 { prefab "sink"; }

Every character in one of those maps has to have an entry in here where the character and foreground color both match. By marking pass-color=true, they can also pass their background color as an argument, which I use for things like notes that need a whole bunch of indices. (A white ≈ with background color 0x000000 is note #0, a white ≈ with background color 0x000001 is note #1 … etc.) Then, the prefab string is matched against a bank of strings in the game code and used to spawn it with the given arguments.

Here’s part of that code:

pub fn spawn_prefab(
    world: &mut World,
    globals: &Globals,
    prefab_name: &str,
    color_arg: Option<u32>,
    args: &AHashMap<SmolStr, KdlLiteral>,
    pos: Position,
) -> Entity {
    if let Some(color_arg) = color_arg {
        match prefab_name {
            "door" => {
                let closed = args["closed"].as_bool().unwrap();
                door(world.spawn(), pos, closed, color_arg).build()
            }
            "note" => note(world.spawn(), pos, color_arg).build(),
            _ => panic!(
                "unknown prefab {:?} (color argument {:#x})",
                prefab_name, color_arg
            ),
        }
    } else {
        match prefab_name {
            "player" => {
                let player = player(world.spawn(), pos).build();
                world.insert_resource(ThePlayerEntity(player));
                player
            }

            "wall" => {
                let ty = &args["type"].as_string().unwrap();
                wall(world.spawn(), pos, ty).build()
            }

            "table" => {
                let ty = &args["type"].as_string().unwrap();
                table(world.spawn(), pos, ty).build()
            }
            "sink" => sink(world.spawn(), pos).build(),
            "microwave" => microwave(world.spawn(), pos).build(),

            _ => panic!("unknown prefab {:?} (with no color arg)", prefab_name),
        }
    }
}

fn player<B: EntityBuilder>(builder: B, pos: Position) -> B {
    builder
        .with(Positioned(pos))
        .with(ZLevel(u16::MAX))
        .with(IsDrawable)
        .with(HasSimpleDrawable(Drawable::simple(
            Color::Magenta,
            None,
            b'@',
        )))
        .with(Describable(SmolStr::new("player")))
}

fn wall<B: EntityBuilder>(builder: B, pos: Position, ty: &str) -> B {
    let (desc, fg, bg) = match ty {
        "inner" => ("inner-wall", Color::Gray, Color::DarkGray),
        "outer" => ("outer-wall", Color::White, Color::Gray),
        _ => panic!("unknown wall type {:?}", ty),
    };
    builder
        .with(Positioned(pos))
        .with(Collider)
        .with(Occluder)
        .with(ZLevel(200))
        .with(IsDrawable)
        .with(HasSimpleDrawable(Drawable::box_drawing(
            fg,
            Some(bg),
            true,
            "walls",
        )))
        .with(Describable(SmolStr::new(desc)))
}

fn table<B: EntityBuilder>(builder: B, pos: Position, ty: &str) -> B {
    let (desc, fg, bg) = match ty {
        "dining" => ("table?dining", Color::DarkYellow, None),
        "stainless" => ("table?stainless", Color::DarkBlue, Some(Color::Gray)),
        _ => panic!("unknown table type {:?}", ty),
    };
    builder
        .with(Positioned(pos))
        .with(ZLevel(200))
        .with(Collider)
        .with(IsDrawable)
        .with(HasSimpleDrawable(Drawable::box_drawing(
            fg, bg, true, "table",
        )))
        .with(Describable(SmolStr::new(desc)))
}

// many other spawner funcs elided ...

Let’s look at the lifecycle of one of the orange Ts in the dining hall. “T with background color #ff4000” is mapped against eack entry in prefabs.kdl, and it matches this one:

"T" color=0xff4000 { prefab "table"; type "dining"; }

Then, the game calls spawn_prefab, looking for a prefab named "table" and passing it the arguments {type: "dining"}. The match statement matches it to the table function, which is called and spawns the entity. Et voila!

I stand on the shoulders of giants here:

I first saw the idea of reading prefabs from a file at all from Caves of Qud. I have a bit of an intermediary layer here; Qud’s prefabs (called “blueprints”) directly put components on the entities, whereas I have this abstraction in the middle. It’s less flexible, but it does save me some serde work. (However! I just finished writing serde support for palkia this morning, so a future version of this might deserialize components directly from the prefab file.)
Kyzrati/Josh Ge, the person behind rexpaint and cogmind, has this blog post about how they use rexpaint to add prefabs to dungeon maps. Their use of “prefab” is a bit different than mine; they mean specific rooms or features. Their implementation is a lot more regimented; each layer has a specific job, tiles are matched by their color alone on layer 1, and entities are matched by their character alone on layers 3 and 4. But that works for their game, because they have a lot of random generation to spruce things up (where I have to draw it all myself.)
The idea of KDL as a prefab language goes to Lemma and its Minecraft mod Kdly Content, which lets you add blocks and items using kdl. Also, Caves of Qud uses XML, and KDL more or less maps 1-to-1 to XML, so I figured it would be a good shot. (Early versions of this idea I had used EDN, which would have been … fraught.)

So yeah! This system lets me prototype really rapidly, which I think is REALLY important for game development.³ I’m also really glad to have figured KDL out; it really is a joy to write. (All the descriptions for tiles in the game are also written in KDL, and I’m planning for all the misc. strings and things to be KDL as well.)

I’ve been working hard making Palkia more useable as I figure out where the rough edges are by working on Robot Language. Next week will probably be a more game-design-y article, as I bootstrap Robot Language enough that I can start working on the game as opposed to the engine.

So I’ll see you all next week …

“Code-named” (haven’t thought of a real name yet) ↩︎
The ones with lots of backtracking, at least. ↩︎
If I were being really fancy, I could probably set up hot-reloading of the map, with some marker component that indicates it’s OK to clear it when reloading. ↩︎

Foxfire Fridays #7: The Perils of Ambition

Fri, 12 Aug 2022 19:00:57 -0500

Got some bad news, everyone; I’m putting Foxfire on hiatus.

To put it shortly, Foxfire was too ambitious a project for me. I’ve never made a video game of this scope before; I’ve never released a paid game before; I’ve never done devlogs before … and to try to do all that on top of completely in-house tooling was just too much for me.

I do aim to come back to it at some point, though. But we’ll see.

In The Interim

I’m going to work on some less ambitious projects, and develop my tooling and my skills. Right now, I’m working on a smaller game; a mystery game about deciphering robot language inspired by what I liked about Outer Wilds.

I will still try and post my progress on whatever it is I’ve been working on every week, though. (And patrons–you’ll still get the inside scoop a week early.)

I’m going to try to get myself into a more game-jam-like state of mind with these new projects, because I find that little bit of time pressure really keeps me from overengineering things in the name of perfection.¹ I’m going to take things about one month at a time; if a project isn’t really going anywhere after a month, I’m dropping it, cleaning up the tools I made while working on it, and moving on to another one.

Not to be kitschy, but I’d also like to take a moment to thank all of you. Everyone I’ve revealed this decision to ahead of time has been nothing but supportive. I guess I have some anxiety about the existence of some evil group of fans who see me as nothing but a content generation machine … while they’re probably out there somewhere, one or two of them, I’m lucky to have not encountered them.

So. Here’s to some smaller projects, some better games, and uhh rule of threes.

For example, there’s a whole registry system in Foxfire a la Minecraft for registering sprites, items, senses and their carrier radiation, … etc. ↩︎

Foxfire Fridays #6: Resource Management Management

Fri, 05 Aug 2022 10:57:29 -0500

One thing I realize about Foxfire is that not everybody sitting down to play a roguelike wants to be bait-and-switched into playing Factorio.

But, I do really think there’s space for resource management somewhere between Qud’s weight and water management, and building whole factories to mass produce things. So this blog post will be my musings about micro-scale and macro-scale resource management, and how I intend to steer the player towards having fun with those two things in mind.

The gist is, I want to reward both styles of play and let players choose whether to focus on micro or macro resource management, while still requiring a little of both in any playthrough.

The Progression of the Game

The goal of Foxfire is to restore the superstructure Foxfire to working order, and the plan is to do that through a list of quests.

I haven’t decided on the exact numbers, but let’s say there’s 50 quests total, and you have to do 40 of them to win. A few of the quests will be tutorial-y quests to teach new players the ropes and to help experienced players feel like they’re doing something worthwhile while gearing up a little bit. The remainder, I aim to split roughly 50/50 between dungeon delving and resource production.

Dungeon delving quests are for players who like micro-level resource management. They’ll be things like “This part, which we can’t easily manufacture anymore, was stolen by these people who now worship it. Go get it back from the bottom of their lair.”

Resource production quests are for players who like macro-level resource management. They’ll be things like “Get me 20,000kg of steel.”¹

And I’m planning to have a few story-driven quests here and there, too, helping the player get to know the world they’ve found themself in.

A cool thing about this framework is that I can have quests that are both micro level and macro level, and are different difficulties in each. Imagine a quest to fetch Foxfire some kind of Nanoquantum Widget. Now, the player has a choice to go through the 8-stage processing chain to produce a nanoquantum widget themself, or they can go fight their way down a dungeon to find one that already exists.

And, I can have quests that are different difficulties if you’re focusing on micro or macro. One thing I want in this game is a section of the map that’s just ocean, which of course is deadly to SP-1R17. If you’re specing into micro-level resource management, it’ll be a real challenge to make sure you ration your electricity as you sail to an island, do some task there, and sail back. But if you’re specing into macro, it’ll be pretty easy to just bring tanks of gasoline with you, or whatever.

Aside: I ADORE Ursula K. Le Guin’s descriptions of bleak wilderness. My favorite part of Earthsea is when Ged is sailing across the oceans, and my favorite part of The Left Hand of Darkness is when Genly and Estraven are trekking across the blasted wintry plain. She makes you remember that Nature is not designed for anyone or anything, and in fact is not even capable of caring for us. If I can, I want to evoke that feeling in the player, holding their meager resources tight to themself as they walk or sail across dead, dead earth.

The Micro

Roguelikes have a long tradition of having micro-level resource management. By this I mean any resource that you have the ability to replenish or re-spec about every ten minutes to hour of play.

Caves of Qud has you manage your water.
Nethack has you manage food and carrying capacity.
Noita has you manage health. (I’m not counting health in the other roguelikes because you can reasonably regenerate health in those by just resting after a fight with an enemy. In Noita the only really reliable source of healing is the holy mountains between zones.)
I’d like to say something about Spelunky here but to be honest I’m so bad at it I’m not really sure what you’re supposed to manage. Probably bombs or something. (Health isn’t a micro resource in Spelunky for the opposite reason; you get more hearts very rarely.)

And I’m sure you can think of analogues in your favorite roguelike.²

I see the point of these systems as a sort of soft timer on the player. How long can you go without finding more water, or making hard decisions about what to drop, or quitting exploring the level and going to the next safe zone? The depletion of micro-level resources are that timer, and the better you are at managing them, the longer that timer runs.

One thing I find disappointing in roguelikes is when these resources get too easy over time. For example, Caves of Qud lauds its water/fluid dynamics system, but I don’t think I’ve ever once thought “oh, I’m running low on water, better get out of here quick.”

Aside: I wish Qud didn’t have recoilers. It kills the feeling of there being a giant world to explore all too quickly, and makes resource management too easy. I would be OK with a gradual opening-up of the world, but it really seems like it just flips to “too easy” the moment you can identify and afford a Joppa recoiler.

I would make them have a limited number of uses, or cut them entirely in favor of an item that teleports you to the surface of whatever zone you’re in…

That’s one thing I really like about Noita; even though you get more health over time, the “obvious” path deeper into the earth requires you to keep vigilant about your HP, and any “shortcuts” or alternate progression just make it even harder.³

In Foxfire, this will be developing your chassis with better mechanisms, software, etc. You’ll be managing mostly your electricity, and although you might have some ability to create it yourself on the go in the mid-late game, your timer will be on how long you can spend away from Foxfire or other safe zones where you can recharge.

The Macro

By macro-level, I mean anything you have to think long-term about the consequences of.

Macro-level resource management isn’t as much a focus of most roguelikes, except during character creation. I find this peculiar, really; your decisions are split between immediate-term and game-spanning ones, without much middle ground. But I digress.

A genre of game that is all about macro-level resource management is the factory builder. I really love the feeling of starting from scraps and developing a factory that processes millions of items per minute all around me.

I suppose I don’t have as much to talk about on this front as I did with micro-level resource management because this is not really something I’ve seen in a roguelike before. I want it to be expensive to have a powerful build and expensive to repair Foxfire, with a volume of resources that isn’t really feasible in other roguelikes.

One thing I haven’t figured out is how the player’s going to get the resources places. I don’t think I have the wherewithall to code up a whole logistics system like Factorio or Satisfactory … I might take some notes from modded Minecraft here, where they just give you a bunch of pipes and machines and tell you to figure it out yourself. That, or magic production of raw materials … or take a page out of Kim Stanley Robinson’s Red Mars, and have the raw resources be commonplace, in the air and soil, and just require lots and lots of processing.

Aside: On the topic of books about space, I also really love The Martian, by Andy Weir. Specifically, I love the concept of living with and harnessing technology you can’t make more of, like the oxygen reprocessor and the hab. I want the early game of Foxfire to feel like that, clinging to artifice you will never be able to recreate in a thousand thousand years, praying it doesn’t die on you.

Hell, maybe even a better example of this is Lost in Space (the Netflix reboot), my favorite TV show. Season 1 and 3 do the best job of capturing that feeling for me, of being surrounded by a universe that really wants you dead in a little tiny echelon of safety you can’t ever make more of. And there’s cool robots!

Aside: There’s a lot of asides in this article.

And, I think that the micro-level play and macro-level play can wind together really well. Imagine synthesizing high explosives, crafting them into rockets, and absolutely destroying a dangerous area with atomic fire. Or, pulling off a tricky stint of dungeoneering and rescuing a chemical reactor capable of crafting faster than you’ll be able to for hours of playtime.

I guess I’m out of things to say for this blog post, then. It was ramblier than I’d like, but I do have to write two this week…

So, I’ll report back with whatever I’ve coded up in the interim next week.

Does anyone reading this blog know of Agrarian Skies? It was one of the first good Minecraft hardcore questing packs. The lategame quests were all in that vein, producing a quarter million burgers and a million wheat and stuff like that. Modern pack devs are cowards for making you craft a bunch of things into one item and turn that in. Make me pipe a million redstone into a block, dammit. ↩︎
I should play more roguelikes. ↩︎
Hmmm, today I will go get the orb on the other side of the volcano (clueless) ↩︎

Foxfire Fridays #5: A Problem of Scale

Wed, 27 Jul 2022 20:03:55 -0500

First, a bit of bookkeeping stuff; I’ve decided that as another Patreon reward, you can get next week’s FFF, this week! FFF #5 (this one) will be released on 29 July 2022; patrons will be able to read FFF #6 on the 29th too. Non-patrons will get access to FFF #6 on August the 5th, when patrons will be reading FFF #7.

TL;DR this week I’m writing two FFF’s to kick off the week advance, as opposed to not having an FFF for non-patrons this week.

Anyways! This week’s post is about a problem I’ve had a lot during development; What do I do with the layout of the grid? It’s a question in two parts: how large do I make each tile in pixels, and how many tiles large do I make the screen.

The two limiting factors for tile size are pixel density and text size. Having the textures too large means you can’t actually see the pixel art, and makes it impractical to draw any amount of text without it becoming too big. But having the textures too small makes it hard to visually distinguish things at a glance.

Window size has a similar problem. I’d love to cram as many tiles as I can onto the screen to get really nice big zones, but that makes the displayed visual size of each tile smaller.

16x24

Caves of Qud, my fallback for when I don’t have any idea how to do something, uses 16x24 textures and has a zone size of 80x25 tiles.¹

Always pat Ctesiphus before you leave Joppa.

The earlier screenshots of Foxfire I’ve been posting here were in that vein; 16x24 tiles, and 8x8 text. But, there’s a few problems with that. The problem is I want Foxfire to actually be playable in a real terminal, and that means the tiles and characters have to be the same size (cause the tiles are going to be characters.)

Caves of Qud does have a text mode, but it cheats with the game log and renders it smaller than it really should be able to if it was in a real terminal.

To be honest, I wish Qud's font was 16x24 instead of the smooth curves.

Imagine how little you could see if the log’s characters were as big as the characters making up the game world!

16x16

Here’s a little test scene in Foxfire with 16x16 tiles and an 80x50 zone:

The font is 16x16, but it's just an 8x8 font I've scaled 200%. I couldn't find a good DOS 16x16 font that wasn't serifed.

The problem here is that the log is really REALLY big. Making it wide enough to actually print a line of any length would make it cover a ton of the screen at all times… and we don’t have the advantage of Caves of Qud where they can draw it semi-transparent, either.

8x8

And here’s the same scene with 8x8 tiles, and a 120x72 zone.

I couldn't figure out how to fit SP-1R17's head and body in 8x8 pixels, so it's just a head.

And this looks … alright, I guess. But given the line-of-sight calculations, there’s gonna be a whole lot of empty space on the screen. Plus, the log still covers a lot.

What am I Going To Pick

Rorax pointed me towards this game called Cogmind, which kinda seems like Foxfire but better.²

Maybe this whole "16 color palette" thing isn't actually a very good idea, cause hot DAMN does Cogmind look pretty.

I haven’t bought it, but looking at screenshots of it I notice two things:

The zones are really large, but you only see so much of it at any given time because the camera follows the player.
There’s no game log.

That second one was something I had never thought of before, to be honest. A roguelike without a gamelog? Absurd.

Joking aside, I do want a game log in Foxfire, because I’m a much better writer than pixel artist and really love Nethack’s snarky little quips and Qud’s unapologetic purple prose. So I think I’ll take a hybrid approach:

8x8 tiles
Have a smaller game window on the left, maybe 96x72 tiles³.
Have zones be MUCH larger, 8x8 screens or more.
Have a static game log on the right that never covers anything.

I might also take a page out of Nethack’s book. Nethack replaces the normal UI at the bottom of the screen with your HP and XP and all with a log line when it’s added to the log, and then keeps displaying the UI once you press a key. And then there’s a button to bring up the whole scrollback of the log.

I found that system kind of annoying because I would always accidentally keymash through it, so I might constantly display the last 2 or 3 lines of the log at the bottom of the screen and have the quick HUD above it. I do want some form of HUD, though, because HUDs feel very robot-y to me. A HUD might increase the verisimilitude of playing as a robot, really, if I play my cards right.⁴

I’m also really inspired by Cogmind’s particle effects! So I think I might extend the colors in Foxfire to a larger palette. Here’s a post by the creator of Cogmind with a bit about how the palette in that game works; the TL;DR is that he defines a set of 21 base hues, and the game produces 10 colors for each based on different brightnesses at runtime.

But of course that all takes time to implement… so I’ll see you all next week with progress on that. Or, if you’re a patron, you can read next week’s post today!

The window is taller than just the zone, but the area outside of the main game display isn’t pixelated, so I’m not counting it. ↩︎
And also, yknow, actually out. ↩︎
I’m not sure I’m actually old enough to have nostalgia for 4x3 displays, and yet I do anyways. Hm. ↩︎
I looked for that Questionable Content comic episode where Faye and Bubbles are talking about robot senses for a while and then kinda gave up looking. If anyone has a link to it I would very much appreciate it!! ↩︎

Foxfire Fridays #4: Now Featuring A Real Blog

Fri, 22 Jul 2022 11:09:30 -0500

Wow, it is very nice to have an actual text document that doesn’t artificially cap you at 240 characters to write an FFF in. Anyways, for this week the topic is … more backend changes!

I know, exciting.

I’ve been moving the Foxfire engine from running on Specs ECS to a custom ECS-like crate named palkia.¹ Like I mentioned in the previous FFF, this is less of an entity-component-system architecture and more of an entity-component-message architecture.

Update: I’ve now open-sourced Palkia, along with all the other helper crates in Foxfire! Get it here.

Why this change? Brian Bucklew goes over a lot of the advantages of this event/message based architecture in his presentation about Caves of Qud and Sproggiwood (you can find the link in the previous FFF). But here’s my takes on it.

Systems get Really Complicated

ECM makes it easier to have tons and tons of components that interact with each other. ECS was designed to solve monolithic approaches like object-orientation, but the systems in it are still pretty top-down.

As an example, say we want to have enemies that can attack each other. Alright then, let’s make up an Attacker component and a HasHP component:

N.B. I did not actually test any of this code so it’s possible it doesn’t compile.

#[derive(Component)]
struct Attacker {
    /// Stores targets of the attack and the damage we wish to do to them.
    ///
    /// Presumably this is cleared and then filled every frame by some kind of `SysAI`.
    targets: Vec<(Entity, DamageInstance)>,    
}

struct DamageInstance {
    amount: u32,
    kind: DamageKind,
}

#[derive(Component)]
struct HasHP(pub u32);

Great, now let’s write the SysDealDamage system:

struct SysDealDamage;

impl<'a> System<'a> for SysDealDamage {
    type SystemData = (
        ReadStorage<'a, Attacker>,
        WriteStorage<'a, HasHP>,
    );

    fn run(&mut self, (attacker, mut has_hp): Self::SystemData) {
        for (attacker,) in (attacker,).join() {
            for (target, dmg) in &attacker.targets {
                if let Some(target_hp) = has_hp.get_mut(*target) {
                    target_hp.0 = target_hp.0.saturating_sub(dmg.amount);
                }
            }
        }
    }
}

OK, great.

But now, I want to add a potion of invincibility. Alright, let’s add a component for that…

#[derive(Component)]
struct IsInvincible;

impl<'a> System<'a> for SysDealDamage {
    type SystemData = (
        ReadStorage<'a, Attacker>,
        WriteStorage<'a, HasHP>,
        ReadStorage<'a, IsInvincible>,
    );

    fn run(&mut self, (attacker, mut has_hp, invincible): Self::SystemData) {
        for (attacker,) in (attacker,).join() {
            for (target, dmg) in &attacker.targets {
                if let Some(target_hp) = has_hp.get_mut(*target) {
                    if invincible.get(*target).is_none() {
                        target_hp.0 = target_hp.0.saturating_sub(dmg.amount);
                    }
                }
            }
        }
    }
}

Great. There’s a lot of rightward drift, but we could factor that out into a helper function…

But now say I want to add resistances to certain types of damage. Maybe I want a gelatinous cube that’s only hurt by slashing and magic weapons, for example.

Alright, let’s add another few levels of indentation …

#[derive(Component)]
struct ResistsDamage(HashMap<DamageKind, u32>);

impl<'a> System<'a> for SysDealDamage {
    type SystemData = (
        ReadStorage<'a, Attacker>,
        WriteStorage<'a, HasHP>,
        ReadStorage<'a, IsInvincible>,
        ReadStorage<'a, ResistsDamage>,
    );

    fn run(&mut self, (attacker, mut has_hp, invincible, resists): Self::SystemData) {
        for (attacker,) in (attacker,).join() {
            for (target, dmg) in &attacker.targets {
                if let Some(target_hp) = has_hp.get_mut(*target) {
                    if invincible.get(*target).is_none() {
                        let mut amount = dmg.amount;
                        if let Some(resists) = resists.get(*target) {
                            if let Some(resist_amt) = resists.0.get(&dmg.kind) {
                                amount = amount.saturating_sub(*resist_amt);
                            }
                        }
                        target_hp.0 = target_hp.0.saturating_sub(amount);
                    }
                }
            }
        }
    }
}

And now what if I want to add an iron golem that’s healed by fire damage? What if I want slimes to split in two when damaged?

I don’t mean to claim that entity-component-message is the be-all-end-all successor to ECS². But, for roguelikes, where it’s really fun to have everything be able to influence everything else in the world, all of your systems are just going to become horrid tangled knots.

For example, here’s the (old) code in Foxfire that makes mechanisms apply their effects to the entities they’re on.

pub struct SysApplyMechanismEffects;

impl<'a> System<'a> for SysApplyMechanismEffects {
    type SystemData = (
        Entities<'a>,
        ReadStorage<'a, HasMechanisms>,
        ReadStorage<'a, Activatable>,
        ReadStorage<'a, ProvidesSenses>,
        WriteStorage<'a, HasSenses>,
        ReadStorage<'a, ProvidesRadiation>,
        WriteStorage<'a, Radiator>,
    );

    fn run(
        &mut self,
        (
            entities,
            mechanisms,
            active,
            provides_senses,
            mut senses,
            provides_radiation,
            mut radiator,
        ): Self::SystemData,
    ) {
        for (owner, mechanisms) in (&entities, &mechanisms).join() {
            if let Some(senses) = senses.get_mut(owner) {
                senses.senses_mut().clear();
            }
            if let Some(radiation) = radiator.get_mut(owner) {
                radiation.radiations.clear();
            }
            // Without this helper function I get up to 10 levels of indentation!
            // I've elided it for brevity but it's quite long.
            for &mech in mechanisms.contained.iter() {
                SysApplyMechanismEffects::run_inner(
                    owner,
                    mech,
                    &active,
                    &provides_senses,
                    &mut senses,
                    &provides_radiation,
                    &mut radiator,
                );
            }
        }
    }
}

ECS promises that it won’t get harder and harder to add new components the more components you add. Which is true! But, the systems do get harder and more complicated. Every time I want to have a mechanism able to do something else, I’ll need to update that gigantic function.

And it makes sense organizationally to have the components and their behavior near each other. In the damage example above, wouldn’t it be nice if the code for the IsInvincible component removing all the damage was right there next to the component declaration, instead of off somewhere in the middle of the SysDealDamage function?

So, the solution Brian Bucklew hit upon, which I am shamelessly stealing, is

Message Passing

Like in ECS, under ECM you have entities, which are lists of components. But, instead of linking behavior of different components with systems, you do it by passing messages.

When you implement Component for a struct, you implement a method that registers that struct with different message types. Then, from a message handler, you can fire messages to other entities.

When an entity gets a message, it runs through its components in order, and if that component type registers a handler for that message type, it runs the handler and passes the updated value to the next component, and so on … and then finally returns the modified message to the caller.

And there’s a method on World to pass a message to all entities, as your entrypoint.

How does this all work in practice? Here’s the damage example from above written with Palkia.

N.B. palkia currently calls the messages “events,” so I suppose it’s an ECE architecture. But it doesn’t really matter what you call it.

struct EvDealDamage {
    amount: u32,
    kind: DamageKind,
}
impl Event for EvDealDamage {}

struct HasHP(pub u32);
struct IsInvincible;
struct ResistsDamage(HashMap<DamageKind, u32>);

impl HasHP {
    // Here's the signature for an event listener: the component (& or &mut), the event,
    // the entity the component is on, and a restricted accessor to the world for doing lazy
    // updates, returning the event.
    fn on_deal_damage(&mut self, ev: EvDealDamage, e: Entity, world: &WorldAccess) -> EvDealDamage {
        match self.0.checked_sub(ev.amount) {
            Some(it) => self.0 = it,
            None => {
                // Set this entity to be despawned when `world.maintain` is called.
                world.lazy_despawn(e);
            }
        }
        ev
    }
}

impl Component for HasHP {
    fn register_listeners(builder: ListenerBuilder<Self>) -> ListenerBuilder<Self>
    where
        Self: Sized,
    {
        // Register the listeners here.
        builder
            .listen_write(Self::on_deal_damage)
    }
}

impl Component for IsInvincible {
    fn register_listeners(builder: ListenerBuilder<Self>) -> ListenerBuilder<Self>
    where
        Self: Sized,
    {
        // You can use closures too, as long as they don't close over anything.
        // In the backend, the read and write listeners are treated more or less the same, but
        // there is dynamic borrow checking. So, components can send events to themselves iff it's
        // immutably borrowed.
        builder
            .listen_read(|_: &Self, mut ev: EvDealDamage, _: Entity, _: &WorldAccess| {
                // Reduce the amount of damage to zero, easy as that.
                ev.amount = 0;
                ev
            })
    }
}

impl Component for ResistsDamage {
    fn register_listeners(builder: ListenerBuilder<Self>) -> ListenerBuilder<Self>
    where
        Self: Sized,
    {
        builder
            .listen_read(|this: &Self, mut ev: EvDealDamage, _: Entity, _: &WorldAccess| {
                if let Some(reduction) = this.0.get(&ev.kind) {
                    ev.amount = ev.amount.saturating_sub(*reduction);
                }
                ev
            })
    }
}

fn main() {
    let mut world = World::new();
    // You have to register component types before you use them.
    // This function calls its `register_listeners` impl.
    world.register::<HasHP>();
    world.register::<IsInvincible>();
    world.register::<ResistsDamage>();

    // When you create an entity you should make sure the components are in a sensible order.
    // In this case, put the things that modify the event before the thing that uses it ...
    // I might add some kind of sorting function to the `Component` trait to facilitate this.
    // Caves of Qud solves this by having things be loaded from blueprint XML files, which are just
    // trusted to have the components be in the right order.
    // Anyways,
    let target1 = world.spawn().with(HasHP(10)).build();
    world.dispatch(EvDealDamage { 
        amount: 15,
        DamageKind: DamageKind::Whatever,
    }, target1);
    // Target1 is dead!
    // You have to call this method to finalize lazy updates, like spawning and despawning entities.
    world.finalize();

    let target2 = world.spawn()
        .with(HasHP(10))
        .with(IsInvincible)
        .build();
    world.dispatch(EvDealDamage { 
        amount: 7,
        DamageKind: DamageKind::Whatever,
    }, target2);
    // And `target2` has 10 HP still.
    // I haven't added querying methods yet (turns out, you often don't need them except for debugging!)
    // but I pinky-promise
    world.finalize();

    let target3 = world.spawn()
        .with(HasHP(10))
        .with(ResistsDamage([(DamageKind::Whatever, 4)].into_iter().collect()))
        .build();
    world.dispatch(EvDealDamage { 
        amount: 7,
        DamageKind: DamageKind::Whatever,
    }, target3);
    // And `target3` will have 10 - (7 - 4) = 7 HP left.
    world.finalize();
    
    // 3 entities spawned, 1 killed.
    assert_eq!(world.len(), 2);
}

And that’s about it!

Why Messages for Foxfire?

I want Foxfire to be intricate and linked. I want my players to have interactions with the game that I never could have dreamed of, but I don’t want them to be bugs. And this entity-component-message architecture is the best way I’ve seen of doing that.

I’m also used to working with events/messages from Minecraft modding. Both Forge and Fabric³ have event systems that let you run code when something happens in game, like a tree growing or a mob taking damage, and call your own code or modify the event itself (or both).

On that point, messages make the game really moddable and hackable. The eventual-eventual goal is to have Foxfire be mostly written in a scripting language, probably rhai, and for there to be official mod support! I’m really inspired by Factorio on this front.

But that’s all very far in the future. For now, I’m going to keep porting Foxfire to using Palkia. I’ve been running into the problem of trying to port the whole thing at once, so I think this week I’m going to cut a lot of the code, implement simple things like movement and graphics, and then build back up to where I was with Specs.

So, check back next week …

P.S.

Message passing is not a new idea. Check out the Smalltalk language, which was released in 1980!

Why “Palkia”? I’ve been naming most of the helper crates in Foxfire after Pokemon, just cause there’s a lot of them and I like the theming. I picked Palkia specifically because Palkia has dominion over space and palkia the crate helps me organize things. ↩︎
Especially because I haven’t even introduced what it is yet ↩︎
The two largest modding toolchains ↩︎

Foxfire Fridays #3

Thu, 21 Jul 2022 23:12:00 -0500

This Foxfire Friday was originally posted on Twitter here.

Hello, there won’t be much of a #FoxfireFridays today, for two reasons.

This week, I did mostly back-end changes. I’m switching from specs to rolling my own entity-component-message kinda system, like Caves of Qud uses. Here’s my reference:

But more importantly, this weekend is the GMTK Game Jam! (Starting in about 3 hours as of this tweet.) So I wanna go work on that. And to anyone else participating, I wish you the best of luck!!

N.B. You can play my entry, Roll Playing Game, here.

Foxfire Fridays #2

Thu, 21 Jul 2022 22:49:00 -0500

This Foxfire Friday was originally posted on Twitter here.

Hello everyone, welcome to #FoxfireFridays number 2. By tradition, Foxfire will have you manage light in order to see different places. For debug purposes, instead of completely hiding things you can’t see, these screenshots have them darker.

But, Foxfire uses a more sophisticated algorithm than most roguelikes. First, sunlight is added to the map. Then, all the “emitters” on the map are polled every tick, and rays are cast from them to figure out the intensity at each tile … and the intensity of each ray is reduced by any “occluders” they may hit until they reach the edge of the loaded area or have intensity 0.

Because there’s inv-square falloff, pools of light merge, like metaballs.

There is supposed to be a video of two pools of light merging here, but I can’t manage to get it as a gif. Check the twitter thread if you want to see it.

The player’s viewshed is calculated similarly; rays are cast to each tile in the current zone, occlusion is summed along that ray, and the intensity against that tile is compared against any sense-providing mechanisms the player has.

Speaking of mechanisms, the player (and all robots in the game, eventually) have onboard, customizable logistic networks. Here’s an example one.

Although the connections aren't shown (yet), there's a graph backing this, with mechanisms pulling items from other mechanisms.

So, electricity flows from the fusion reactor to the battery, and then to the camera, the lamp, the Hall Effect sensor, and the “waste money” (which doesn’t do anything and just consumes electricity for test purposes.) And you can en/disable mechanisms too!

Speaking of, what happens if we turn on the Hall Effect sensor …

… wait, why is everything washed out? Take a look at the status bar; we’re in a very powerful magnetic field of over 1 Tesla. The hall effect sensor is washed out!

Normally this would white-out the screen and obscure things like being in total darkness would, but again I’ve kept things rendering for display purposes.

The lamp we have is also emitting a magnetic field. So if we turn it off …

… that’s better!

This sensor works anywhere from 20 microtesla to 5 millitesla. Earth’s magnetic field is 30 uT, so we can see by it! Notice how we can see through the wall of the building in the last screenshot. That glowglobe there also emits a magnetic field, so it can wash us out too.

Finally, there’s a bit of world-generation now; specifically, a biome map. And, a cute little loading screen! But every zone still just generates one rectangle … so I’ll show you my progress on worldgen next Friday.

Foxfire Fridays #1

Thu, 21 Jul 2022 22:45:00 -0500

This Foxfire Friday was originally posted on Twitter here.

Well, looks like #FoxfireFridays is a go. (Look at me usin a hashtag.) The features I’m working on right now are only half-finished and very buggy, so instead of screenshots I’ll just give a chat.

The game is written in Rust, with Specs ECS and Macroquad. You play as a robot, in a post-post apocalypse; humans went extinct millennia ago and robots became sentient sometime after and ruled the earth for a while. But now even their monuments fade into dust.

The PC’s name/ID is SP-1R17 (“Spirit”). You fell into disrepair long ago alongside Foxfire, the superstructure you were created to serve … And one day you woke up, and the game begins, and your task is to bring Foxfire back to working order.

The game is a roguelike with a heavy focus on resource and inventory management. Your chassis is a factory, and as you bring more components back to Foxfire it will slowly wake up and let you automate it.

The plan is to have a listing of many quests for Foxfire, but not all of them will be required; you only have to complete 30/40, say. Some will be resource/automation based like “Get me 20k steel;” some will be more dungeon delve-y like “Get me this part someone stole.”

Right now I am working on senses. The system actually works! … except for the lighting engine. For testing purposes, SP-1R17 has a fusion reactor and a camera. Without power for the camera, it can’t see. It can’t see in the dark or if it’s too bright, either.

And it’s easy to add more sense types, too! For example, you could have IR cameras, UV cameras, magnetic sensors … A very sensitive magnetic camera could let you “see” through walls via Earth’s magnetic field! But for balance it would blind you if you get close to a magnet.

These aren’t hypotheticals; this code is in the game, right now. I’d just have to add a couple components to SP-1R17. (I love ECS!) Sadly right now light goes through walls and you can’t see anything up and to the right of you … so I’ll save the pics to next week.

Hello, World

Thu, 21 Jul 2022 21:10:08 -0500

Yay, I have a blog! Thank you very very much to grywo for helping me get this set up … it took about 5 hours longer than it should’ve, but it’s here now!

Off the top of my head I have a few posts I want to make but mostly I wanna stop doing Foxfire Fridays on Twitter, cause ughhhhhhh Twitter sucks as a blogging platform.