When you make a git commit, git pulls your name and email from your git configuration, and writes it into the git database. GitHub uses that data to look up a GitHub user based on the email, and shows the commit as coming from that author. But wait, what's this?

The commit is showing up as "Unverified"! Okay, phew, maybe GitHub doesn't have a huge security hole.

Except it kind of does! Because unless you've turned this on in your settings:

anyone can create commits on GitHub that look like they were written by you!

But ugh, who wants to deal with GPG

Nobody.

But you don't have to! Since Git 2.34.0 (released Nov 2021), you can sign commits using the same SSH key you use to push commits to GitHub. And it's super easy to set up. Here, I'll walk you through it.

First, make sure your version of Git is newer than 2.34.0:

$ git --version
git version 2.38.0

Then, tell Git you want to sign your commits with your SSH key:

$ git config --global gpg.format ssh
$ git config --global commit.gpgSign true
$ git config --global tag.gpgSign true

If you have more than one SSH key on your machine, you should also tell Git which one to use (by default it will use the first one listed in ssh-add -L):

$ git config --global user.signingKey ~/.ssh/github_key.pub

And lastly, let GitHub know which key(s) you are going to be using to sign your commits. Go to your key settings, click "New SSH Key", and be sure to select "Signing Key" as the key type.

And that's all! Now all your commits will show up with the little "Verified" badge on GitHub.

One more step you might want to take is to turn on Vigilant Mode. That will make GitHub's UI show commits that have your email, but haven't been signed by one of your keys, as "Unverified". That serves as an extra warning to anyone who might come across a pretender trying to pass their code off as yours that something is afoot. It does have the downside that all the commits you made before you started signing your commits will also show as "Unverified". Such is the price of progress!

There are lots of different ways to write code that produces UI. If you were going to start from first principles, which I did for Adrift, you might start out writing code that computes the location of each character directly, something like this:

left = 10
top = 10
drawCharacter(left, top, "|")
drawString(left + 1, top, "Inventory")
top += 1
for (item in items) {
  drawCharacter(left, top, "|")
  drawString(left + 1, top, item.name)
  top += 1
}

Keeping track of the precise location where each character should be placed quickly becomes cumbersome. It's really easy to mess up the calculations for what should go where, and it's hard to reorganize UI that's written like this. Not to say this style of UI code can't be perfectly serviceable—most of NetHack's UI code is written this way, for example, and Cataclysm: Dark Days Ahead too! And you can achieve some nice idiosyncratic effects with it.

But: it seems like a lot of effort. I'm time-poor, and I want the computer to help me with this. Enter UI layout algorithms. Instead of describing the specific location of each character on the screen, I'd rather describe at a high level the relationships that different parts of the UI have with each other, and then let the computer figure out where precisely to draw everything. For instance, I might express the above snippet like this:

widget = BorderLeft(
  Column(
    Text('Inventory'),
    items.map(item =>
      Text(item.name)
    )
  )
)
draw(widget, 10, 10)

I still specify the location on the screen of the top-left corner, but everything else is the computer's problem.

How might we make a system that works like this? What kind of properties would we want this kind of system to have?

As previously covered, I'm time-poor, so instead of coming up with this system from scratch myself, I decided to copy someone else's. The first thought I had was to look at tools like Ink, which bring something close to CSS's flexbox to the terminal. Ink is based on Yoga under the hood, which reimplements the CSS flexbox algorithm in a cross-platform way. However: it's really complicated. The layout code is nearly 5,000 lines of C++, not to mention bindings, and to use it I'd have to bring in another native library. On top of that, Yoga isn't built with discrete grids like the console in mind: all its coordinates are floating-point numbers. It seemed like there was a simpler way.

But this got me thinking: what layout algorithms are out there? I've already mentioned flexbox, and CSS also defines a grid layout algorithm, among other layout algorithms. But there's also Auto Layout, which is a constraint-based system that uses linear programming under the hood, and Flutter, which uses a single-pass algorithm, and SwiftUI which is similar, and GTK which has a whole bunch of different layout algorithms (including a constraint-based one like Auto Layout), and so does Qt. What a dizzying array of options! Which ones of these are good? Which are appropriate for building UI in roguelikes?

I don't know, but I was drawn to the simplicity of the SwiftUI/Flutter model. It seemed flexible and powerful while still being simple and fast. The two models are similar but Flutter is much better-documented, so that's the one I went with, and which I'll describe here.

Flutter calls its fundamental units of layout RenderObjects. There's some other stuff around this but RenderObjects are what do the actual layout, so I'll ignore the other stuff. The layout algorithm is as follows. Descending through the tree in a depth-first manner, each RenderObject:

1. receives a minimum and maximum size from its parent,
2. lays out its children, passing down size constraint information, and then
3. picks a size for itself within the bounds given to it.

Each RenderObject picks its own size (within the bounds given), but offsets are chosen by the parent. There's a more in-depth (but still really readable) explanation in the Flutter documentation.

This is a single-pass layout algorithm. Once the algorithm is complete, every RenderObject has a size and offset, and a second pass is done to paint the UI onto the screen.

This turned out to be really easy to implement! This is the structure, roughly speaking:

interface Constraints {
  int minWidth();
  int maxWidth();
  int minHeight();
  int maxHeight();
}

interface RenderObject {
  void layout(Constraints constraints);
  void paint(PaintContext context, Offset offset);
  Size size();
}

Now, this RenderBox interface doesn't by itself do any kind of layout—it's not even a tree!—it just provides the structure for the algorithm. This is where the power of this approach comes in: you can write any layout logic you want as long as it follows this structure! You could even have a nested RenderObject that lays its own children out using a completely different algorithm, as long as the total final size obeys the constraints that were passed to it.

As an example, a BorderLeft RenderObject might look like this:

class BorderLeft implements RenderObject {
  private RenderObject child;
  BorderLeft(RenderObject child) { this.child = child; }

  void layout(Constraints constraints) {
    // Since we're going to be 1 character wider than our child,
    // ask it to make itself be 1 narrower than we were asked to be.
    Constraints childConstraints = new Constraints(
      /* minWidth = */ constraints.minWidth - 1,
      /* maxWidth = */ constraints.maxWidth - 1,
      /* minHeight = */ constraints.minHeight,
      /* maxHeight = */ constraints.maxHeight,
    );
    child.layout(childConstraints);
  }
  
  Size size() {
    // We are always 1 wider than our child.
    return child.size().add(new Size(1, 0));
  }
  
  void paint(PaintContext context, Offset offset) {
    context.paintBorder(offset.x(), offset.y(), size().height());
    child.paint(context, offset.add(new Offset(1, 0));
  }
}

This is composable with any other RenderObject, and will add a border to the left of it.

There are lots of kinds of useful, generic, reusable RenderObjects. For instance, an object that renders text can handle text wrapping based on the maxWidth that is given to it. A column object can lay out its children vertically on top of each other (or, for a more general tool, see for example the Flex widget in Flutter, that implements a simplified version of something like CSS flexbox).

I built this system into Adrift and I've converted all the UI code over to it. I've been liking it a lot! Maybe you would like it too? Give it a try and let me know how it goes!

I'm not going to give a complete overview of the wave function collapse algorithm, because many others have done a great job of that already. If you haven't encountered the algorithm before, I'd recommend taking a moment to read a little about it and take a look at some of the things other folks have done with it. It's an impressively flexible algorithm!

Adrift uses a variation on the wave function collapse algorithm, implemented using a constraint solver, to generate different kinds of rooms in arbitrary shapes. These are the sorts of things it can produce:

So far the space partitioning algorithm that generates the room boundaries always generates rectangles, but this approach for generating room contents can handle rooms of any shape.

So how does that work, then?

The idea is that each room is assembled by solving a jigsaw puzzle with a bunch of pieces of different sizes, where each piece can only match certain other pieces. So we have a bunch of jigsaw pieces with differently-shaped edges, and we try out placing them next to each other until we get an arrangement where all the edges match.

Each jigsaw piece defines a little chunk of the room that makes sense for the type of room being generated: in the break room, the pieces might be a couch, a table and chairs with a pack of cards, a TV by the wall, a bar with stools and a refrigerator. In the infirmary the pieces might be a gurney, a medicine cabinet, an oxygen tank, and so on. To assemble a room, all we have to do is solve the puzzle. Unlike a regular jigsaw puzzle though, there are many possible ways of connecting the pieces together. We're not aiming for a particular final room, just any arrangement of the pieces where the pieces fit together.

Adrift's architecture is heavily data-driven, and these room piece definitions are no different. For example, here's the current set of parts for the break rooms, snipped directly from the YAML data that drives the game:

- type: roomgen
  name: lounge
  algorithm: WFC
  options:
    parts:
      # empty space is allowed anywhere
      - |
        ***
        *.*
        ***

      # a sofa next to the wall
      - |
        xxxxx
        *hhh*
        *...*

      # a TV on the wall with some space next to it
      - |
        xxxxx
        *.D.*
        *...*

      # a bar with a refrigerator and some stools
      - |
        xxxxxxx
        *....R*
        *=====*
        *.s.s.*
        *.....*

      # chairs and tables
      - |
        *****
        *.c.*
        *.Tc*
        *...*
        *****
      - |
        *****
        *.c.*
        *.T.*
        *.c.*
        *****

      # heating vent
      - max: 1
        part: |
          xxx
          *V*
          *.*

      # replicator
      - max: 1
        part: |
          xxx
          *P*
          *.*

Each part defines a jigsaw piece. The characters around the edges of the piece define what will match there: x meaning the edge of the room, * meaning anything, and other characters matching those characters. So the first piece, a . with * surrounding it, is defining a 1x1 piece that can match anything on its four edges. The second piece, the sofa, is a 3x1 piece, and will only match the room's edge on its top side, and floor on its bottom side. The engine also automatically generates flipped and rotated versions of each piece, so the sofa could also appear on the left/right/bottom walls as well as the top.

The job of the room generator is to assemble these pieces into a room such that each piece is placed next to something that matches it, and every spot in the room is covered. For this, Adrift uses a constraint solver. If you're familiar with WFC, this is similar to the "simple tiled" model in WFC.

Wave Function Collapse is Constraint Solving

At its heart, the WFC algorithm is a simplified constraint solver. The vanilla WFC algorithm has no backtracking, though, and relies on an entropy-based heuristic to guide its search towards a satisfactory solution (i.e. one which has no mismatched edges between pieces). This is roughly similar to the "first-fail" heuristic which common in constraint solvers, where the solver chooses the next variable to try setting based on which has the smallest number of possible values remaining (proposed as early as 1965!). There's some subtlety in the way that noise is applied to entropy values in WFC that I have thus far ignored, but the results still seem pretty good even without taking that into account.

Formulating WFC as a constraint program and using a constraint solver rather than using a dedicated WFC algorithm gives us two advantages:

1. We get intelligent backtracking for free, and
2. We can impose generalized constraints on top of the inherent tile-adjacency constraints that WFC enforces.

You might have noticed the max: 1 annotation in the YAML above, which stipulates that at most 1 copy of that tile can be placed in the final room. (Adrift also supports a min count.) Vanilla WFC cannot accommodate this kind of constraint, but since we're using a full-blown constraint solver, it's relatively straightforward to add. I've also been able to add reachability constraints that prevent the solver from generating maps with unreachable sections. Adrift uses Choco as its constraint solver, though I also recommend or-tools for this kind of work—it has Python, C++ and Java bindings.

Constraint solvers only speak in integers, so in order to explain to the solver how to generate a map, we need to translate the task into its language. For generating rooms, we translate each cell in the grid as an integer variable with a range between 0 and n, where n is the number of possible ways a cell could be assigned (including rotation and flipping). So we have w ⨉ h integer variables. Then, we add in a constraint between each pair of horizontally adjacent variables, specifying the legal assignments of the pair. For example, if tile i can fit to the left of tile j, then (i, j) is a legal assignment of a pair of variables that are horizontally adjacent. Similarly for the vertically adjacent pairs. This tells the solver that it's only allowed to assign values to variables when they match their neighbors.

A note about the room pieces that are larger than 1x1: to explain these to the solver, we break each larger piece up into 1x1 sub-pieces, each of which can only match the appropriate sub-pieces from the same parent piece on its edges.

One of many

WFC, even with the additional power we get from using a full constraint solver, won't be a fit for every kind of room we want to generate in Adrift. That's why the data format allows for specifying different room generation algorithms, with options specific to the algorithm. In future, it might also turn out to be useful to be able to 'layer' room generation algorithms, first running WFC or another algorithm to generate the base furniture, and then running further algorithms to modify the results of the first algorithm—for example, adding trash to the room, or growing plants in it, or moving some of the furniture around.

That said, I've been happy with the quality and variety of the results so far, and I think there's a lot more I can get out of the algorithm by carefully authoring room pieces, and constraining it in interesting ways.

I was looking back through posts I've made about Adrift on the r/roguelikedev subreddit about Adrift over the last year or so and I found some cool stuff that I'd written, so I wanted to collect it in one place so it's more easily linkable. There's no real theme here other than "things I've thought about Adrift".

If you've not heard me talk your ear off about Adrift already, this is probably the best place as of writing to understand more about what kind of game it is I'm trying to make. The fragments are in chronological order, so the later parts are closer to the current state of the game.

REXPaint Mockups

I did a few mockups in REXPaint after seeing Kyzrati's talk at Roguelike Celebration 2018 and having my excitement about developing Adrift rekindled. These mockups are still pretty close to how I want the game to feel, though I no longer like the RPG-style dialog box.

Map generation

I wrote a little about what I'm going for with map generation:

Adrift has some unique map generation requirements which make it difficult to reuse ideas from other roguelikes. First, the map has to be completely filled. It doesn't make sense for there to be empty space on a spaceship like it does in a dungeon. So every single tile on the map must have a purpose. Second, the map should feel designed, but still unpredictable. A spaceship is a carefully constructed artifact, and the map should follow some kind of discernible logic, while keeping it interesting to replay and focusing on responding to the situation rather than memorizing a premade map.

This still holds true.

My theory at the moment is that constraint programming is a good toolset for generating these sorts of maps. With a constraint solver you can set up variables (e.g. what kind of room is this? Which walls have doors?) and then constrain the values of those variables so that only certain combinations are allowed. I've been using choco-solver, and this week I discovered the choco-graph extension, which allows enforcing constraints like "every room on the map must be reachable", which was a huge breakthrough for this technique.

I'm dividing the world into 5x5 rooms, and the solver operates at the level of the room, not individual tiles. For each room slot, the solver chooses what type of room will go there, and then enforces that the adjacent rooms have to match the kind of walls that the just-placed room has. It keeps going like that until the whole map is full, at which point it return the completed map, or until it runs into a contradiction, which will cause the solver to backtrack and try a different placement. The algorithm is very similar to Wave Function Collapse, but with the added ability to backtrack, and better ability to enforce global constraints such as "connectedness".

The maps still feel pretty random and messy, though, not "designed". I think some additional constraints will be able to help push the map towards a more designed feeling, such as enforcing some kinds of symmetry in local areas, and restricting how corridors can be placed to avoid corridors that just open out into other corridors and similar nonsensical layouts.

I've since played fairly extensively with this approach this and haven't found success with it. But BSP is working great, and I'll be able to reuse the constraint programming stuff elsewhere, I think.

Data with a soul

I wrote about data-driven design early on, and Adrift continues to be a very data-driven design, with the vast majority of content being specified in YAML files.

This week I moved all the info about items, terrain, furniture and so on out of hard-coded Scala and into YAML files. I really like Brian Buckelew's theory that stories are just data with a soul, and I've seen data-driven development be a huge acceleration boost for games like Cataclysm, and I want to do that too. I reused some code from another project for parsing and sampling item-generation tables from JSON/YAML, so it was nice to not have to reinvent that.

I implemented room prefabs in the map generator, all defined in YAML, so now it's super easy to add new rooms and variations, and fill them with stuff. I didn't get to spend much time on actually creating them though, the game's still in a very early state and I'm trying to get all the systems in minimal working order before filling out too much content.

I've since evolved my opinion on YAML, specifically, as a data format. Here's my opinion: YAML sucks. But it sucks much less than having to write a custom editor.

I'll probably not put anything into the game that would require me to write a custom editor. If I can't figure out a way to express some data I need as YAML, I'll cut that feature. Building a custom editor is just too much work for an already extremely ambitious project (compared to the amount of time I have available to dedicate to it).

I had a small epiphany this evening chatting to Nato about storing items and their locations. Previously I've found a lot of tension between having items responsible for knowing where they're located in the game (in a backpack? on the floor? worn?) and having locations be responsible for knowing what items they contain (e.g. a map cell having a list of items it contains). We were exploring some options and we hit on the idea from the world of databases: if all your items were in some sort of SQL database, you could query by item ID or item location, no problem. SELECT * FROM items WHERE location = (32, 12).

I don't want to go full-blown SQL, but that idea was pretty neat, and it eventually lead me to a solution to the problem of whether to store item-locations on items or in locations. That is: neither! Instead, have a data structure separate from items and locations which stores the item-location pairing, and supports lookup by location or by item.

I'm still using this system and it's working great. Highly recommend.

In which I somehow implemented four foundational systems while packing up my apartment

Apparently I called this "a short week"? But these systems are all fundamental to the game. Time is weird.

The game now supports color! Each category of items now has a foreground and background color from a palette, as well as a character. Eventually I'll implement a lighting system too, so the display will be quite colorful, but I want to keep the "raw" item colors in a pretty narrow range to keep things readable.

I'd forgotten that I wanted to implement a lighting system! I was thinking of an earlier antecedent of Adrift, an experiment that I did as Nintendo DS homebrew called Torch.

I'm not sure if I want to go back to this—I'd been thinking that a more austere graphical approach might be appropriate to the theme—but having recently been looking at Cogmind gifs again, I'm definitely on the fence. Cogmind looks so good!

The automatic doors (you know, like Star Trek) are now broken up into two components: a mounted presence sensor which detects nearby humans and emits an "activate" signal to items in the same tile, and the door itself, which can listen to the "activate" signal and open the door. If you take away the motion sensor (for instance, by dismantling it) then the door will be stuck. Eventually those mechanisms will also require power to work properly, and you'll also be able to hook up doors to other kinds of sensors and buttons.

I think this is going to be an interesting and unique part of Adrift.

I implemented a small message-based behavior system like the one Brian Bucklew described for Sproggiwood/Caves of Qud. I'm not sure I quite like what I have yet, but I'll run with it and see how far I get.

Still running with it. Still not sure I like it.

I started on implementing a system for item damage: sometimes, items have components that are broken, and you'll need to take them apart and fix them. But taking an item apart can also damage it if you're not careful or your tools are sub-par (for example, dismantling a computer display with a hammer is unlikely to leave any delicate components in-tact).

The system I implemented for this was very simplistic, and since Adrift is ultimately intended to be a very repair-focused game, I think it'll end up being expanded a lot. For example, one idea Nato had in this area was that items like doors that make a sound when you activate them should make a different sound if they're broken—and the sound should differ based on how the item is broken! For instance, if the motor in the door is broken, it might make an impotent "whrrrr"ing sound; if the motion sensor is broken it won't make any sound at all (since the door didn't activate); if a panel is bent it might make a "clonk" noise. I love this idea, though I think it would be too much work to apply it everywhere, doing it for some common items like doors would be well worth it.

Items should have a mass and a volume, and you shouldn't be able to pick up things that are too big or too heavy. An item's mass should be simply the sum of the masses of its components (and eventually, once there are containers, its contents), but an item's volume could be bigger than the sum of the volumes of its components.

Still haven't done this, but I still want to.

I want to make a start on the power system. I'm not quite sure how it should work yet, but I have thoughts about transformers and voltages and wires that you can drag across the floor to plug stuff into other stuff.

I implemented a very simplistic power system, just enough to make it so that the ship can run out of power and doors stop opening.

The Parts Have Parts

Adrift is a roguelike without combat. Instead, Adrift focuses very heavily on items, furniture, and environmental elements, as well as the systems of the space ship that is its setting.

I added support for non-rectangular rooms to the map generator, and to test it I added an air mix room with a bunch of gas tanks. None of them do anything yet, but eventually all those tanks will be hooked up to the machines in the center, and the machines will be regulating the atmosphere on the ship.

Nato added an airlock room, and I tweaked the map generation so they only spawn next to space. (Not much point having an airlock elsewhere, I suppose.) The structure of the ship is a spinning cylinder, so the map will wrap around in the X direction, but along the Y direction the ends will be the vacuum of space. I have some thoughts about movement in microgravity for when you travel inwards to the center of the cylinder...

Oh, and those spacesuits Nato added? They're full of parts. And the parts have parts.

I didn't make any headway on adding mass and volume to items yet, but I did start working on power a little. There's a soldering iron item that you can find (which you need to be able to disassemble stuff that's soldered together, like electronics), and I'm in the process of making it so that the soldering iron has a battery which gets depleted when used, and the tool becomes useless once the battery is dead. As part of that I've also had to make it possible for items be partially disassembled, because something has to happen if your soldering iron runs out halfway through taking apart a door.

Cables

If you have to repair a broken space ship, there's definitely going to be some messing about with cables.

This week I've been working towards implementing a ship-wide power system that things can plug into, but I found I needed a few other pieces first. In particular, there'd be no point to a power system if you couldn't plug anything in, would there? So I added cables that you can unspool and drag along the floor to plug things together. Right now, plugging things into each other does nothing, but in future you'll be able to connect up machines to each other using power cables. I have some thoughts about doing semi-realistic power transmission systems involving transformers and high-voltage / low-voltage lines, but that's for another day...

I've also started thinking more about how to make the whole ship feel more designed. Right now there's just a random jumble of rooms without much logic or sense to it. I did some good brainstorming with Nato last weekend and came up with what I think is a pretty good 3-layer system for thinking about the map layout:

First, generate a "schematic" for the ship, which shows where the crew sector is, where engineering is, and so on.

Then, lay down "superblocks" that are groups of rooms that are restricted to be laid out in a certain way, without yet specifying exactly which rooms will be placed.

Lastly, place the individual rooms within the superblocks, completing the map.

I tried the "superblock" system out and I didn't like it. I think there's still potentially merit in the layered approach though; I'll probably resurrect it when I start thinking about placing rooms in specific places in the ship according to their type.

Superblocks

I was still keen on this superblock thing.

Last week I said I wanted to work on building out the ship power system and making the map generation feel more 'designed', and I've done some of both of those things. On the map generation front, I've built out the superblock system to the point where it's working, so now the map generator first lays out the schematic, then fills it in with superblocks, and then drops in the specific rooms. Here's the superblock layout and the filled-in map (both of these screenshots show connections between superblocks/rooms rather than the rooms themselves; each character in the filled-in map represents one 5x5 tile room in the final map).

On the power system side, the cables I made a couple of weeks ago do actually now function to pass power between things—there are still a whole ton of bugs here, but it least it sort of works! You can disassemble a soldering iron, plug a power cable into the battery, then plug the other end of the cable into an automatic door to get it working again even when ship power is down. At least, until the battery runs out. Here's a video of me jury-rigging a door: it's stuck open at first, then I disassemble a soldering iron to get its battery, and plug the battery into the door, which returns to working condition (temporarily).

Finally, here you can see a rather poor quality animation of the map generation in action. You can see that in the lower area of the ship it has some trouble choosing what rooms to place and tries a few times before "getting" it and moving on to the top layer. All driven by choco and choco-graph :)

I stopped posting updates on r/roguelikedev around the end of 2018, and also mostly stopped working on Adrift. I picked it back up in late 2019, and started working on it weekly with Nato's help. (Thanks Nato!)

Here's an abridged list of things we've added since then:

• Atmosphere simulation. Each tile on the map has a gas composition, represented as partial pressure of various atmospheric gases (currently CO₂, O₂ and N).
• Plants. They grow, flower, are pollinated (by tiny flying robots), and bear fruit. Plants absorb CO₂ and emit O₂. At some point they'll also interact with some growth medium, i.e. soil or water, as well as require light to grow.
• Heat. The ship starts out very cold, and as you exchange heat with the environment, your core body temperature drops very quickly and you'll eventually die of hypothermia. Clothes can help you maintain homeostasis. We don't model metabolism yet so your body in the game is basically an RTG.
• Cylindrical topology. The ship is constructed as a spinning cylinder, which you walk around on the inside of. So there's no left/right edge of the map, but there is a top/bottom.
• WFC-like room layout generation. The rooms that the higher-level BSP algorithm generates have nonuniform shapes, which makes generating the contents of those rooms challenging. Adrift uses a constraint-based algorithm to assemble rooms of arbitrary shapes from "puzzle pieces".

We also experimented fairly extensively with the idea of using a genetic algorithm to generate levels. It didn't end up working out but we had fun and read some cool papers.

Nato also has some really cool ideas for how electronics might work:

I really want to get Adrift to the point where it's playable for someone who isn't me, to the point where it's at least barely, just a little, getting across some of what I have in mind for the game.

There are three main parts of the game arc that I think are necessary to show the scope of what I have in mind.

1. "Cold & afraid" - you're decanted from your cryopod, and you're naked, starving, and freezing cold. You have to find food and clothes, fast, or you're going to die.
   Mechanics needed: hunger, thirst, eating/drinking, death by starvation/thirst, death by temperature excursion. I think it's OK in the first alpha for it to be relatively easy to get out of the cryopod room and find food/clothes, it just has to be the case that you'll die if you don't.
   Content needed: preserved food, clothing, more room variety in crew quarters.
2. "Survive & thrive" - you've found some warm clothes and a stash of freeze-dried fruit. That's enough to live, for now, but unless you get the hydroponics room online, you're going to find yourself at the end of your supplies in short order. Also, is it just you, or is the ship getting colder?
   Mechanics needed: plant growing needs to be balanced & fleshed out (e.g. dirt, light, water requirements), dangers/damage that prevent you from exploring the entire ship, crafting/disassembly, life support system (incl. pipes/wires?), repairable damage to ship systems.
   Content needed: life support rooms, item damage design, food preservation machines / methods, variety in rooms in engineering.
3. "What happened?" - this is the end-game, and involves finding your way to the bridge.
   Mechanics needed: high-level map topology (i.e. cylindrical shape of main deck, multiple levels), functioning elevators.
   Content needed: backstory/lore hints, bridge rooms, mid-deck rooms.

That's all for now. I'll close with some inspiration.

There's a lot in this verse. I think Laozi is wrestling with the nature of the world—there are bad things, ugly things, hard things. Why? Because without them, there would be no good things, beautiful things, easy things.

How is one supposed to move and behave in this world full of death and hatred and meanness and awful things? Well, refusing to acknowledge that things are that way is not an option. Laozi says: let go of your expectations. Don't hold on to stuff. Not the good stuff or the bad stuff.

این نیز بگذرد‎, this too shall pass.

I first encountered the Tao Te Ching when I was 22 years old. I don't remember how I came across it. Maybe I'd heard that it was a book of wisdom, and decided I could use some of that.

It's not the sort of book that tends to leave one's mind easily, once it enters. It has a timeless quality to it, seemingly as relevant today as it must have been over two millennia ago when it was penned (brushed?). Recently, thinking about creativity, the Tao bubbled to the top of my mind again, and I cracked open one of my favourite translations of it, by the inimitable Ursula K. Le Guin.

Mostly as a way to trick myself into spending more time with this beautiful text, I thought it would be a good idea to read through a few different translations and write a little about what meaning I'm finding in each chapter. I'm far from a scholar of the Tao Te Ching, and I know nothing whatsoever about religious Taoism. But Laozi teaches, fill the bowl to the brim and it will spill. So, perhaps, my bowl is half-full. No chance of a spill!

The three translations I've chosen are Le Guin's (which is by her admission more of an interpretation than a translation), that of Stephen Mitchell (which is trying to be more faithful to the original, though is still fairly modern), and Ron Hogan's (which attempts as far as possible to extricate the text from the 'wisdom of the ancients' feeling that other translations ooze). Hogan's was the version that spoke to me the loudest when I was 22. It seems a little hokey to me now, and I prefer Le Guin's version. But I still think there's something lovely about Hogan's friendliness and straightforwardness.

So, the opening verse of the Tao Te Ching. Le Guin calls it "Taoing" and writes that to her, it encapsulates the entirety of the rest of the work. Perhaps I'm insufficiently enlightened, but I don't see it, at least not today.

The idea that if I can talk about it, and name it, then it isn't Tao, bothers me. Isn't that a bit of an evasion? A way to say, "ah, sorry, I can't just tell you the secret"? Though at the same time it seems obviously, self-evidently true. If it could be spoken, simply told to you, then life would be a solved problem. It's also sort of a warning against taking advice—"if someone tells you how to live, then they're definitely wrong", which just about captures how I feel about books like 7 Habits and Getting Things Done. Pretty self-deprecating, for a book that's sometimes thought of as containing the meaning of life.

I have to be honest, I don't really understand the bit about names being the origin of everything. Hogan dodges that bit, even. My best guess here is maybe this is about defining the self. It's pointing out that naming things, and thus dividing the world, is a personal thing that happens in your mind, not a property of the world itself. Like Lesson 51 (you may prefer Pilote's version), "I have given what I see all the meaning it has for me".

(Side note: ACIM's Lesson 51 has a lot of Tao in it, like "I am willing to recognize the lack of validity in my judgments, because I want to see" vs the TTC's "Can you step back from your own mind and thus understand all things?" in chapter 10. I have no idea what ACIM is, but their website is killer.)

The third bit—about the unwanting and the ever-wanting—gives me strong echoes of a feeling I wrote about last week. I wrote about wanting to create things, about wanting to create things I'm proud of. I want that a lot. The Tao is telling me, here, that the wanting is showing me lack. It's showing me what I don't have. And offering that, maybe, to unwant would be to see past that and connect to something truer. Or would that just be a salve to make me comfortable with my current status quo? I don't know. A lot of the Tao Te Ching is about wei wu wei, doing not doing, acting by inaction. I wonder sometimes about whether that is implicitly supporting the way things are, encouraging complacency.

But what would I know? My bowl is only half full.

I haven't found a great deal of satisfaction in my creative life. I start a lot of things and rarely finish them. I distract myself with incidental complexity, or other projects, or rewriting in Rust, and lose sight of whatever creative vision I began with. It's familiar for me to feel torn between a lot of projects, to feel paralyzed by the idea that if I was to work on any one of them I'd be neglecting all the others—which usually ends up with me working on none of them. I'm afraid of falling short of my own expectations. And hey, if I never finish a thing, it can't be a disappointment, right?

I want to work on that. On feeling more satisfied. I don't have any great answers, though: I'm struggling with it, trying to figure out what feels good to me, what blocks me, and how to be gentle with myself when what I make is disappointing to me. But I know that I don't want to stay this dissatisfied.

So what would it look like to be more satisfied with my creative work? And how would I take a step along the path to finding that satisfaction? Ira Glass says you just have to make a lot of crap. I hate making crap. I think I need some coping strategies.

When I think about the things I've made that I feel satisfied with, the things I'm proud of having made, I've noticed that it's the things that I've shown to people. Especially, it's the things I've made which others have found useful or interesting that I find most satisfying. I feel satisfied with saxi, json0, and hf-mission-planner. I'm proud of having completed Inktober in 2019. In my mind those projects are at peace. When I think of them, I feel happy with where they are, even if they're not perfect, or not "finished". By contrast, the far greater quantity of my unfinished and unreleased projects, the things I haven't shown to people, feels oppressive and restless. Those unfinished things haunt me and cry out for my attention, and I have to say to it all, over and over, sorry, today I'm not interested enough to work on you.

So maybe I could find more satisfaction by focusing on showing more work, on talking to people about the things I'm making. Although perhaps there's a correlation–causation confusion, and it's the case that being satisfied with something causes me to show it off, or that some things I make are good, and I'm both satisfied with the good things and choose to show them off. Or perhaps the feeling of satisfaction is primal, and the work incidental: rather than seeking to make things with which I'm more satisfied, I should cultivate a general feeling of satisfaction, and only then will I be able to make things that satisfy me.

In any case, I don't feel that my dissatisfaction is serving me well, and so I want to reduce it. Maybe talking and writing about things I'm making will help me with that. It's worth a shot, anyway.

Also, I should probably set fire to that pile of old projects. They're not serving me either.

I've written about creativity before: about shunning the empty promise of perfection, the doldrums and the wind, and about taking pleasure in making small steps.

Uh, wait. While I was writing this article, I discovered that the fellow who created the game, Martin Wells, is a friend of a friend of mine. I sent him a connection request on LinkedIn and mentioned Cybots, and we chatted for a bit and he brought the game back up! You can try it out at playcybots.com if you're so inclined. Also, the tech world is so damn small. Also, definitely the best thing that LinkedIn has ever done for me.

So hat do I miss about it? What was Cybots? Sadly I can't find any screenshots to share, but it was a browser game in a similar vein to Kingdom of Loathing. You were the controller of a squad of violent robots patrolling the Vulcore Plains, hiring mercenaries, escorting tag droids, and generally causing (or running away from) mayhem. As you, er, liberated credits from your enemies, you could buy better stuff for your squad to increase the ratio of mayhem caused to mayhem fled from. I'll admit that Cybots was not a paragon of game design and probably 80% of what I miss about it is down to nostalgia. But I think it did some things pretty well.

One mechanic I really liked in Cybots and still find myself drawn to is that each action you took cost "KCharge", and KCharge replenished in real time. That is, there was a limit to the amount you could play each day. A lot of other games do this now (e.g. Fallen London, and lots of f2p mobile games), usually with the option to buy more credits with real world money. But I think limiting the number of actions per day can be an interesting design choice even leaving aside its potential for extracting dollars from players.

Limiting actions guides players away from exploring the game by "spamming", and towards a careful consideration of how they spend their time with the game, drawing the player into the mechanics more than they might have been otherwise, or into the non-action-using bits of the game (e.g. lore or art). It respects the player's time by giving them a cue to stop playing (though it might counteract this somewhat by being a bit of a psychological trick to draw the player back to the game the next day).

Another nice consequence of limiting the number of actions each player can take per day is that it levels the playing field in terms of what every player has access to. There isn't really anything meaningful you can do in Cybots without KCharge—you can mess about with the equipment on your squad, but that's about it—and everyone gets the same amount of it. It's pretty easy to use up all your KC for the day in under an hour, which is a fairly low amount of time to spend on a game each day. So it stops the players who have the most time on their hands from being the winners every time.

The early 2000s was a different time in terms of Internet culture, and the chat frame that Cybots included at the bottom of the game was not the pit of vile adolescent swill we've come to expect from online multiplayer games. I really enjoyed chatting to other players who were online at the same time as me, though I'm not sure the same feature would work well for games being developed today. Look no further than Barrens chat for an example of why.

I have an itch to make a clone/homage to Cybots one day, perhaps changing up the theme and combat mechanics but keeping the same structure: a squad of characters whom you equip with various items, intermittent battles interspersed with exploring a semi-random set of areas described with text. Reading about storylets and narrative delivery systems in this paper by Max Kreminski (Sketching a Map of the Storylets Design Space) lead me to the realization that, combat aside, the structure of Cybots is very similar to the structure of Reigns: there's a "deck" of cards which you draw randomly from. What cards are available to you in the deck at any given time depends on the state of your character (and possibly other global state). But you only get to see one at a time. You can also "travel" to different areas—in Reigns, the dungeon would be an example, or in Cybots, the Vulcore Plateau—which changes the available set of cards.

I'll throw it on the pile of "one day" projects, I suppose. It would make a good jam game!

The first thing that usually comes to mind when you think about solutions to climate change is renewable energy. But nearly half of the top 20 solutions that Drawdown identifies are related to food, and taken together, changes to the way we produce and eat food account for an impact more than 30% larger than changes to the way we generate electricity.

In particular, Drawdown estimates that the impact of shifting to a diet rich in plants is the 4th-highest-impact of all the 100 solutions they examined, and projects that reducing meat consumption could result in a total reduction in CO₂-equivalent emissions of over 65,000,000,000 tons over the years from 2020–2050. To put that in perspective, that’s comparable to what Drawdown estimates will be the impact of shifting to solar power. It’s six times the estimated impact of shifting to electric vehicles. And it would account for about as much less carbon in the atmosphere as does the ocean, which sequesters about 2.5 Gt/y [1]. The ocean. All of it.

Since I read Drawdown, I’ve been paying much closer attention to the amount of animal products that I eat. I don’t eat zero meat, but I’ve substantially reduced the amount of meat I eat, now at about one meal per week. And I’m wondering if other people are doing the same.

I know that the Baader-Meinhof effect will mean I’m more aware of stores and restaurants offering plant-based options, so it will seem to me subjectively that there’s a growing movement of plant-based food even if there isn’t. Data on vegetarianism and veganism is surprisingly difficult to pin down—studies report anything from 4% to 13% of Americans are vegan or vegetarian[2]—and it’s even harder to find data on people like me who aren’t vegetarian per se, but are choosing to eat less meat. Things get even trickier when you try to correlate those numbers between countries.

Google Trends is far from an authoritative data source, but perhaps it can be a proxy as part of a broader investigation into whether plant-rich diets are on the rise. I looked at trends for searches for veganism, reasoning that I usually search for those things when I’m eating out in a place I’m unfamiliar with, and that it probably correlates with the number of people who are doing the same sort of thing.

It’s a little difficult to parse this chart, but it looks roughly like veganism is about twice as popular in the U.S. now as it was in 2013. And the trend holds up for other geographies than the U.S., too.

Google Trends only reports data about people who use Google, which notably excludes China (for now) and, largely, India. That’s more than 2 billion people in the world missing from this analysis. China has a rapidly growing middle class who often associate meat with wealth and status. India also has a rapidly growing middle class, but has a large number of adherents to Dharmic religions such as Jainism, Buddhism and Hinduism which prohibit the consumption of meat and as such, India is about 30% vegetarian already.

These graphs would suggest that plant-based diets are on the rise in Western countries, and rapidly so—2x in 5 years is an incredible rate of growth.

Let’s consult another source of data to see if these trends correlate! I grabbed the OECD’s data on meat consumption, which includes kilograms-per-capita data for 43 countries going back to 1990. The built-in graphing function on the OECD website wouldn’t show me summed meat consumption across types of meat (poultry, beef, etc.) so I downloaded the raw data and plotted it myself. The data for beef didn’t go back before 2000 for some countries, so I’ve plotted just the years 2000–2017.

This chart tells another story. While it looks like people in Europe and the U.S. are eating about the same amount of meat as they always have, people living in Brazil, Russia, India, China and South Africa (BRICS) are eating nearly 30% more meat than they did 20 years ago (though interestingly, meat consumption in India remains low). Worldwide, per-capita meat consumption is up 15% since 2000.

So it seems that while enthusiasm for plant-based diets is growing in the West (who are by far the hungriest for meat), it isn’t yet an entrant into the cultures of the Global South (which contains vastly more people). Even though the average person in China consumes half as much meat as the average person in the U.S., there are four times as many people living in China.

I don’t know what it will look like for plant-rich diets to take off in China, or Brazil, but it probably won’t look like veganism in the West.

Climate change isn’t a problem that any one of us can have a significant impact on in our personal lives. The scale of the problem is such that effective actions are those at the scale of thousands to millions of people. But eating a plant-rich diet is by far the most impactful change you can make yourself, way way more than recycling or changing your lightbulbs. And you’ll be living your values every time you eat a meal. Assuming you value the continued existence of human life on Earth, that is.

You don’t have to eat 100% vegan—as my wife Cole says, if everyone ate vegan half the time, it’d be like half of us were vegan!—but you do have to start now. We’re running out of time.

forget it