For the past year I worked on Half-Earth Socialism, an online game accompanying the book of the same name by Drew Pendergrass and Troy Vettese (Verso 2022). The game launched at the beginning of May; you can play it here. This post will make more sense after you've played the game!

This post is adapted from a talk I gave at Trust (who organized the project) and goes a bit into the design and development process of the game.

Genesis

Trust was approached early in 2021 about developing a website to accompany the forthcoming book Half-Earth Socialism, which would be published a little more than a year later. To very, very briefly summarize the book (the book itself is a quick read so I encourage you to give it a look!): the authors focus on land use as the central variable of concern for the health of the planet (hence the name "Half-Earth" socialism, building off of E.O. Wilson's idea of the same name) and emphasize the need for rational democratic planning to make decisions around the future of the world. For example: how much land should be devoted to energy production, and how much to food?

Democratic planning requires some way for people to meaningfully engage with plans: to understand them, evaluate them, and make their own plans. The original proposal for the site was based around a linear programming calculator where people could play with the parameters of a model that Drew wrote. I imagined it as something akin to Chris Crawford's Balance of the Planet (1990), where the player is similarly adjusting parameters of a global model to influence planetary health.

In this original version you could choose your energy mix, energy use levels, meat consumption, and so on. The model would figure out the allocation of land, emissions, and so on that were required. Using this model you can easily compare results and see, for example, that veganism opens up quite a lot of land for energy production. But part of the book's appeal is the vignettes throughout that imagine what life might be like under Half-Earth socialism or what it might be like were it not to happen. We wanted to take this model and build a richer, more narrative experience around it to reflect some of the feeling those vignettes evoked: the pacing of such a world, people's concerns and values, and the social fabric of their lives.

Reading Group

Before any development began we first participated in a reading group, organized by Chiara Di Leone, covering topics like: socialist cybernetics, cybernetic planning, complex systems management interface design, climate modeling, and games that we found interesting or related to the these topics. These helped us coalesce on a set of mechanics, design elements, constraints, and feelings to develop the game around.

Two games that we looked closely at were 11 Bit Studio's Frostpunk and Nerial's Reigns. Frostpunk's gameplay is centered around one primary variable (heat) and is filled with many brutal, no-win policy decisions around managing morale. The game is really well organized around its primary variable—it's very easy to see how heat is distributed, what's producing it, how it decays, and so on, so even though the decisions can be difficult, you're seldom disoriented or confused about what your priorities are. The game is, however, very dark and depressing. In contrast to Half-Earth Socialism's more utopian outlook, Frostpunk is a never-ending crisis. We knew that we wanted our game's arc to be different: the beginning is a difficult struggle to get through, but if you do well the game opens up into a world better than the pre-crisis past. There's light on the other side!

We knew early on that we wanted the game to be a web game, keeping in line with the original website idea and making sure that it's easy to access. If you're making a web game then you really need to consider mobile usage. We expected that most people would share the game on Twitter and thus others would likely encounter it on their phones and want to give it a try right there. That assumption's held: the majority of plays so far have been on mobile resolutions. Reigns was a main inspiration of how you could make a simple yet deeply engaging game for mobile. It has one main interaction—swiping left or right—but it's enough to support a great branching narrative. It's also very flexible in terms of time commitment: you can play a session for a few minutes or an hour if you want. That's something we wanted to replicate in our game—players could finish a run in 5 to 10 minutes, do something else, and come back and try a different approach later. That isn't how things turned out (people have spent 30 minutes just reading the starting cards) and in the end the scope of our game was just too complex to really reproduce these elements of Reigns.

From the whole reading group process came a few orienting values:

• Accuracy: Most games prioritize a fun and engaging experience, and often systems that have real-world correlates are simplified in service of this priority. But because of the nature of the book and the weight of the subject, we wanted to prioritize rigor and accuracy a bit more than a typical game would. This was a huge challenge because representing something as complicated as the planet and human economic activity requires a great deal of simplification regardless of commitment to accuracy, and with the complexity of the planet and the global economy, details matter a lot. And often details that don't seem to matter end up becoming quite important later on.
• Amusing: Climate change and ecological disaster are already very weighty topics without us needing to exaggerate it. We wanted to bring some levity to the game so that the player doesn't feel pummeled by depressing thing after depressing thing (although it does kind of happen because of the subject matter). So using dialogue, character design, etc, as outlets to lower the "seriousness" of the game and leave plenty of space for the content to do that.
• Expressive: Another goal was for the game to play like a political compass quiz, in a way. We had a few player "builds" (above) in mind that made play feel expressive.
• Quick: Shorter games that you play in rapid succession, to try different things. I think originally we wanted a session to be 5-10min...but sessions last far longer now. It takes at least 5 minutes just to soak in the game's starting content!

As mentioned above, take a cue from the book and convey the feeling of living under HES through dialogue and other narrative elements.

Development proceeded in roughly five categories:

• Story: the main beats of the game and game dialogue.
• Art Direction: character design, graphics, game feel, and so on.
• Game Design: the game's primary mechanics and interactions.
• Legibility: the game's information design, how players access/read the information they need to make decisions and how they make those decisions.
• Technical Requirements: various constraints around the game's technical infrastructure and architecture

Story

We wanted to give the game world a richer feel through events, which give us opportunities to world-build and develop character personalities. They're also one main way players get feedback about their plans. More importantly they allow us to represent way more than we could with the core game model alone, which focuses on a relatively limited set of variables (water usage, land usage, electricity production, fuel production, etc). With a very simple probability system we can represent a much wider range of events like mass coral bleaching events or cultural changes like a new cuisine trend of eating invasive jellyfish, without needing to make the model itself much more complex.

Of course, the events we have in the game pale in comparison to all the possible events one might think of for the future. They allow us to represent more detail than we could otherwise but open up an overwhelming amount of things we could represent. It's one of those areas where we had to just stop adding things at some point, even though we probably could have added hundreds more.

Technical Requirements

Mobile and web support were the primary technical constraints, and those came with their usual challenges (mostly cross-browser compatibility). The more interesting technical requirements were related to the models and data that we needed.

Early on we knew we wanted to have some kind of climate model running, but climate models are usually huge, requiring supercomputers long periods to run. Drew suggested Hector, which is a "simple climate model". It runs quickly on commodity hardware, but of course lacks the depth and detail of its massive counterparts. From a technical standpoint I didn't really want to have a server crunching a climate model for several players at once, even if it's a relatively simple one. We managed to get it to run directly in the browser so that each player runs their own model independently.

We have some other models running too:

• a biome model, not running on mobile but on desktop, which colors the world according to temperature and precipitation changes over time.
• a linear programming model for determining production resource allocation and guided assistance in planning. This ended up being reduced to a much simpler form because there weren't models available for the browser that handled the kind of optimization we needed.

The other major set of requirements were data requirements. For processes there were input requirements per unit output, impacts (e.g. CO2 emissions) per unit output, and current global process mixes. We also needed current emissions, current biodiversity loss, population projections aggregated for each region, global per-capita demand for each of our outputs, estimate per-capita impacts based on regional income levels, and impacts and inputs for different sectors/industries.

It's often very difficult to track down good numbers for these. Data may be available at regional or national levels, but not globally. Or there may be a lot of variability in estimates. Some technologies like vertical farming and cellular agriculture are very new, so there are only estimates for very limited cases, if at all. For example with vertical farming we could only find a couple sources that on a one or two crops published by vertical farming startups (so very unclear how trustworthy the numbers are), and instead relied more on values from more general indoor greenhouse farming.

Art Direction

The game's art direction is mostly Son La's department but I'll briefly mention my two main contributions.

The first is the globe's design, which took an embarrassingly long time (I'm really inexperienced with shaders). Our main aesthetic reference was a sort of retro-computing, so we played a lot with poorer color representation (dithering) and lower resolutions (pixelation).

The final version drew from this graphic that was produced for an article about the book:

And here's the final version:

One major element of the game's feel was the imagery we used to represent projects, processes, and events. We had a very small team, and it was really only Son La creating visual content (and also working on the UI development). We ended up with 238 events, 123 projects, 29 processes, 9 industries, and 20 regions, all of which needed images, so ~420 images total. There was no way we could create all of that on our own, so we looked at CC-licensed and public domain imagery. The problem with sourcing images that way is that they vary a lot in quality and style, and they kind of just look like digital photos. We played around with ways to process them so that they were more interesting and consistent and ended up with the following line:

Legibility

There is a lot to consider when assembling your plan and so a major challenge was making information available and clear to the player. All throughout the interface are tooltips and "factors" cards that breakdown what's contributing to whatever variable you clicked on. The hope is that whatever info you need to make a decision is available quickly, but it still is and feels like a lot of information!

Game Design

The most challenging part of the project was the game design. There were a lot of different things we wanted to communicate, different feelings we wanted to evoke, and so that led us down a few different design paths. But the biggest difficult was that the game is meant to somewhat accurately represent a set of very complex systems—we wanted some legitimacy and rhetorical weight behind what happens in the game. This commitment to accuracy of complexity is directly at odds with making an entertaining and accessible game. Most games are not complex in terms of their mechanics. Even games that are very deep do not have to be complex, and they often aren't. Truly complex systems make for unfun games because they in their very nature inscrutable, so they become a very frustrating experience. You never quite know why something is happening: is it because of something you did, is it because of something you didn't do, or did it have nothing to do with you at all? Part of what makes a game fun is learning its rules and systems, and one reasonably expects consistency, predictability, and legibility in how the game responds to your actions. Complex systems don't care.

Balancing was also very difficult to do with such a complex game. We couldn't anticipate all the paths or strategies a player might try. Ultimately we hoped to avoid players finding a strategy that works in the game that wouldn't work in the real world because of some detail we left unmodeled, but it would require a lot more testing to have some assurance that we succeeded.

I'll briefly describe two sets of ideas we had that I really liked but got cut for one reason or another.

Regional System

I remember "space" being a big concern. Given the book's focus on land use, how we deal with space is really important. But it came in conflict with priorities like accuracy. Games might abstract space to make it more manageable, like using larger units of space which then reduces the level of detail you can represent spatially; or they might limit their focus e.g. to a single region or map or level. The earth is really big. We can't really represent it in great detail without just blasting the player with stuff to manage. So we could limit the player's focus at a given time to a single region. That's basically where this design came from.

One bonus was the opportunity for more visual feedback/eye candy: you could zoom into a region and see wildlife return, to make your impacts on the world feel rewarding and more obvious.

But there was a more important game design element to this regional system. We wanted to avoid was the "god view" in games, where the player unilaterally makes decisions of all kinds, which is contra the democratic planning that's emphasized in the book. It's very challenging to design a game about global planning without making it a god game! Games are often fantasies of control...representing democracy in a game very difficult because it can disrupt that fantasy and make the game a frustrating experience. It's interesting how certain kinds of friction are expected in a game, like a hard boss fight being difficult, but others, like having your decisions questioned or ignored, are not.

I don't think we succeeded in avoiding the god view. The parliamentary system is supposed to represent that to some degree, and you can be ousted from power if you're too unpopular. But that's not quite the same as democratic planning. One iteration of this regional system idea had a greater and more autonomous role for individual regions (in the current game they mostly just exist to spatialize the game a bit, but they don't really do much on their own). The player would set targets and maybe some specific policies/projects but regions would go and figure out how to achieve those targets on their own. There would be more bargaining with regions to accept targets or to achieve them in a particular way.

A further iteration on this idea—which was definitely out of reach given our constraints—was a multiplayer regional system. Different people play different regions, and perhaps elect one player to be a global planner for a term. The global planner mediates regional relationships: regions have to negotiate with one another, like if I'm representing East Asia I want North America to reduce their energy usage in exchange for reducing my coal usage or something.

Turn-based System

The other major concept was a turn-based game, similar to Into the Breach. Each turn is some fixed time amount, and you have a preview of everything that will happen in the next turn or next n turns. For example: this natural gas plant will emit this much methane next turn, this patch of permafrost has 50% chance of melting by next turn, this hurricane will move left 2 tiles next turn, etc. It doesn't really work for the global scale, since you can't deal with things like an individual power plant, but I still think you could make a fun and interesting game this way if you could get away with more simplifications. And it's not clear what amount of time a turn should represent. The hurricane movement, for example, requires a much shorter turn time, but other decisions like building new power plants are better suited to turns of a year or more. Similarly, it's not clear what the spatial resolution should be. How many hexagons should the globe be divided into? A hurricane and a power plant are on two different scales.

One advantage of this design was that scientific uncertainty can more easily be a bigger part of the game. That natural gas plant might emit this much methane, but you don't really know without better sensors. That 50% estimate for that patch of permafrost is based on your best climate models, but if you invest in improving them and training more climate scientists you'd have a better estimate. In this way the benefits of good long-term planning manifest as "powerups" in a sense that make the shorter game loop easier.

Card System

We ended up settling on a card-based system. It felt more familiar and easier conceptually, giving players something to hold on to while we barraged them with other new information to absorb. Cards also provide a convenient way to compartmentalize "abilities" and a give players a discrete object to think with. Basically all player actions are expressed through manipulating cards in some way.

There are still a lot of ways to use cards. One idea was to have your plan be something like equipment slots in an RPG, like Diablo (on the left here). But instead of a head slot for your helmet you'd have a concrete slot for your concrete production technology, and another one for your transport policy, and so on.

This is kind of how it works in Civilization 6 (on the right). This form ended up being too limiting because there are many projects we wanted to include that don't fit neatly into an existing slot, thus requiring many single-purpose slots, and just making the whole thing clunky and confusing.

Above are a couple other ideas—on the left we have something based around a deck. One idea was that your "plan" is a deck of cards that you assemble and use to react to events, under the idea that a good plan prepares you for the future. So if your scientists are telling you a major heatwave is likely, you'd have a mass cooling center policy prepared to respond to that heatwave, if it does happen.

This ended up not really working because it feels like busywork for the player—you're making two redundant decisions, the decision to establish the cooling centers, and the decision to use them when the heatwaves occurs. In trying to minimize extra actions, we'd assume that if you have the cooling centers in place, you'd want to use them.

Above is one of our prototypes for card interactions. This one is a Reigns-like interface, with four directions instead of two. We ditched it because as I mentioned the Reigns reactive playstyle didn't quite fit what we needed.

We settled on this "scanning" interaction, which has a retro computing punchcard-like vibe. Conceptually this is like the deck idea without the redundancy: in a way you're scanning cards to add them to your deck (plan) so they make bad future events less likely.

We also wanted to add a political aspect to the game, in part to make gameplay more interesting (the player can't just do everything they want to do—to lessen the "god view" problem) and also add some drama and an opportunity to develop the world through some strong personalities. They also give players some scaffolding to develop playstyles. There's more clear guidance on what an accelerationist might want, for example, to nudge the player towards using those cards. The parliament system was also conceived to bring some of the "democratic" side of "democratic planning", but I don't think we succeeded in that. It's my main regret of the game. I feel that we would have needed to design the game very differently for that to have worked, and at that point it was too late to make such major changes.

Tooling

One last thing I want to show off is the Half-Earth editor, where all the content (dialogue, events, regions, projects, processes, and so on) and model parameters are written. Whenever I embark on a project like this, one of the first things I do (once the main architecture/schemas are sorted out) is build content authoring tools. It makes later work much quicker, makes it easier to experiment with the content, helps me think through more ideas and possible conflicts in that level of the design, and makes it much easier to bring on others (like writers/researchers Lucy Chinen and Spencer Roberts) to contribute without needing to muck about in the code.

Final note

Half-Earth Socialism was one of the bigger projects I've worked on, and I'm proud of what we accomplished with such a small team. Our ultimate ambition was way beyond our capacity and resources, but we managed to achieve quite a lot of it. The game was made possible because of these people:

Wow, it's been almost a year since I last updated this blog.

I haven't had time to work on Fugue until a month or so ago. Since then I've been chipping away at more tooling. Once the core game mechanics/systems are in place, I'm expecting that most of the time will be spent creating content for the game: writing, modeling, environment design, etc. So I'm building out tooling and figuring out strategies to streamline all of these processes.

Godot makes it easy to develop editor plugins that integrate relatively seamlessly. It's not without its challenges and frustrations but those are more to do with Godot in general than specifically about their plugin development process (see below).

Writing

The game will play out mostly through characters saying and doing things, and these actions need to be specified in a way where I don't need to meticulously program each one. Previously the game's narrative elements used "Dialogue" as the main organizing element, focusing on spoken dialogue, and let me write "scripts" of spoken dialogue lines with a playback system to have the appropriate characters say their lines in order. That ended up being too limiting because I want to write not only dialogue but to specify various actions/stage directions to write scripts that basically describe entire scenes, including character movement and animation, sound and environmental cues, and so on. So I restructured that whole system around "Sequence" as the main organizing element, with "Dialogue" as a sub-component.

A Sequence is composed of "Actions", which include dialogue lines, choice prompts, animation triggers, game variable setting, character movement and rotation, etc. At the time of writing the following actions are available:

• Line (L): A line of dialogue, spoken by a single Actor.
• Decision (%): A set of choices that the player must choose from.
• VoiceOver (V): A line of voice-over dialogue. The difference between this and Line is that it does not require the speaking actor to be present and shows in a fixed position on screen.
• Prompt (?): Basically a combination of Line and Decision. A line of dialogue is displayed with the decision's choices.
• Pause (#): A blocking pause in the sequence
• SetVar (=): Set a state variable to the specified value (strings only). There are a number of targets
  • Global: Set it on the global state
  • Sequence: Set it on the local state (local to the current sequence). These values persist through multiple executions of the same sequence (i.e. they aren't reset whenever the sequence is run again).
  • An Actor: Set it on the local state (local to a specific actor).
• PlayAnimation (>): Play an animation with the specified for the specified Actor
• MoveTo (->): Move the Actor to the specified target
  • You can use this to "bounce" the player character if they enter somewhere they aren't supposed to.
• LookAt (@): Have the Actor look at the specified target
• ToggleNode (N): Toggle the visibility of the specified node. Can fade it in/out (but looks quite janky)
• RepositionNode (>N): Move a node to the position and rotation of the specified target. This happens instantaneously...so you could use it for teleportation; but more likely you'd use it to rearrange a scene while it's faded out.
• TogglePortal (P): Enable/disable the specified portal.
• AddItem (+): Add an item to the player's inventory
• PlaySound ())): Play a sound
• Parable (~): Start or end a Parable (Quest)
• Fade (F): Complete fade the scene in or out
• ChangeScene (>S): Change the scene. Because sequences are associated with one scene, this will end the sequence!

Sequences may be triggered in one of three ways: the player interacting with an object (such as talking to an NPC), the player entering a zone/area, or they automatically start when a scene loads ("ambient" sequences).

A "Sequence Script" is a graph of two types of nodes: "Verses", which are lists of actions, and "Forks", which include one or more "Branches" that each have a set of conditions. If a branch's conditions are true then its child verses are executed.

Sequences are associated with only one scene. Generally multiple sequences will be related in some way: the might be part of the same narrative arc, for example. So Sequences can be further organized into "Stories" which is basically just a grouping of Sequences, without any significant additional functionality.

The Sequence and Story Editors both make it very easy to quickly sketch out scripts and later refine them. They both have built-in validators to ensure that scripts are correctly specified, i.e. they don't refer to any objects that aren't in the scene, aren't missing any required data, etc.

Sequences and Stories are just stored as relatively simple JSON so they can be further processed/analyzed outside of Godot easily.

I expect that as the game's writing and development continues more actions will be needed. But for now this set has been comprehensive enough.

Textures

Finding source images that fit my licensing requirements and then editing them into textures is a very tedious process. I built a web tool that makes it much easier to find public domain and CC source images (vastly simplified by Openverse), cut out clippings from them and pack those clippings into textures or generate seamless textures by wrapping and blending their edges. It tracks where the clips were sourced from so that attribution is much easier to manage.

Music

I'm not at the point where I've given a ton of thought to the game's music, but I do have one tool, dust, that I developed to help sketch out musical ideas. I didn't develop it specifically for this game but it'll be useful here too. It's a chord progression generator/jammer that outputs MIDI so it can be used as an input to most DAWs (tested with Bitwig Studio and Live 11). It helps to get around blank-canvas-syndrome by giving you a chord base to start working with.

Miscellaneous

Items

I've started working on the item system, which is very simple at the moment (and hopefully will stay that way). To manage the items I created an Item Editor, which, though a lot simpler than the Sequence Editor, is just as useful.

Blender scripts and templates

Blender's also been nice to work with because of its support for Python scripts. It's a little clunky to get things integrated, but can be powerful once you're going. In my case I'm mostly using a "quick export" script that helps me avoid the tedious work of keeping exported files organized (navigating to the correct folder, setting the filename, etc) and double-checking my export settings are correct. In the case of items, which require a static icon to show in the UI, the export script automatically exports a properly-cropped render of the item to the item icons folder so I don't have to bother with that at all.

Another small but immensely helpful thing is having a specific template for Fugue modeling work, with materials, cameras, and what not preconfigured. My material settings change very infrequently; I'm usually just swapping out textures, so this saves me a lot of time configuring materials over and over again.

Dialogue Layout System

Not really a tool, but something I've been refining for awhile now. This is the system that determines where dialogue boxes are placed on screen. Many games have a fixed dialogue box, e.g. at the center bottom of the screen, but I want it to feel more spatial, especially as there won't be any voiced lines in the game (too expensive/too much work/difficult to change and iterate on) so there won't be any 3d audio to offer that auditory depth.

As far as I know there is no easy or reliable way to layout rectangles in a 2d space to guarantee that there are no overlaps. Not only should there be no overlaps, but each dialogue box should be reasonably close to its "host" (the actor that's speaking) so that it's clear who's speaking. I have a reasonable expectation/constraint for myself that something like five at most actors should be speaking at once and the game has a minimum viewport size to ensure there's a reasonable amount of space. That is, I'm not expecting that overlaps will be impossible, only that they are unlikely given these constraints.

The approach I'm using now is using a fixed set of anchors for each object and a quadtree to detect collisions. We just try placing a box at one of an object's anchors, and if it collides with an existing dialogue box or object, try the next anchor.

As you can see from the prototype above (on-screen objects are beige, off-screen objects are grey, and dialogue boxes are black), it's not perfect. The box 8 at the top overlaps a bit with object 2 — this is due to how dialogue boxes for off-screen objects are handled, which could be refined, but I'm treating as an acceptable edge case for now.

Another shortcoming is how 2d bounding boxes are calculated from 3d objects. Basically I compute the bounding rectangular prism around the object and project that to 2d space. Depending on the shape of the object that may work well or it may end up placing an anchor far-ish from the object's mesh. You can kind of see it in the screenshot below, the "I'm on the move" dialogue box is meant to accompany the smaller NPC, but it's kind of far away. Tighter bounding boxes might be possible but I'm worried about the overhead they'd require. Something to look more into.

Unit Testing

Godot doesn't have its own unit testing framework but there are two popular third-party options: gdUnit3 and Gut. They both seem fairly powerful but Gut felt a bit clunky and I couldn't get gdUnit3 to work properly (compile errors, which I chalk up to Godot's weird stochastic-feeling nature, more on that below). I ended up writing my own very simple testing framework instead. It lacks basically all of the advanced features present in other testing frameworks (spies, mocks, etc), but for my needs it's working great.

Things not covered here

There are still a few key content areas that I don't have a good approach for:

• Character animation. This is something I'm not very good at and a huge factor in the visual quality of the game. Crunchy textures and low-poly models are a lot more forgiving than terrible animations. There are now deep learning motion capture tools that might work with a commodity web camera, but I haven't tried them yet so I don't know if their output is good and what the workflow is like.
• Mapping textures. Taking a texture and then adjusting a model's UV map so that it doesn't look warped is also really, really tedious. No idea how to streamline that.
• Object modeling. This is harder to streamline/automate because there's so much variation. Some categories like buildings and plants could be streamlined through procedural generation via Blender's geometry node system. Fortunately I enjoy modeling so I don't really mind doing this, it'll just be very time consuming. One more general possibility is to figure out a decent processing pipeline for taking free models and converting them into an polygon count that matches everything else. But finding an approach that is robust enough seems unlikely.
• Character modeling. To make the world feel lively I'd like to have many, many background characters and a fair amount of more important NPCs. This might be doable with some kind of procedural/parameter character variation system (i.e. creating a few key archetype models, then having a script to vary some vertices, scales, etc) alongside with a procedural texture generation system (for clothing, etc). Again, this might be doable with Blender's geometry node system.

Thoughts on working with Godot

I've spent a far amount of time with Godot while working on all of this. My only reference point is Unity, which was very unpleasant to work with. Everything felt so fragile. Small changes can break tons of other things, with no easy way to undo the damage. Kind of like how in Microsoft Word adding a space can mess up your whole document's layout.

Godot has overall felt better than this, but it still has a similar, if reduced, fragility. I've felt discouraged to experiment with new ideas out of the fear that I will just break a bunch of existing code/scenes and have to manually fix everything. I've found that even just opening a scene file can alter its contents—not yet in a way that has caused me trouble, but it's still very different than other programming work I've done, where things really only change if you change them. It's like trying to build a house on moving ground. Version control is a bit of a safety blanket but its effectiveness depends on what changes I can revert to.

GDScript has been a surprisingly pleasant language. It still lacks many features I'd like like sets, first class functions, and iterators (all of which I believe are coming in Godot 4) but usually those haven't been an issue. What has been very frustrating is how Godot parses/compiles scripts. If you have a syntax error in one file it ends up breaking a bunch of other files that depend on it (which is to be expected) but it reports these issues as obscure errors that don't point to the originating error. I'll be inundated with messages like The class "YourClass" couldn't be fully loaded (script error or cyclic dependency). (it will not point you to what this error might be) or mysterious errors like Cannot get class '_'. repeating several times. Then it requires a painful process of trying to figure out where the syntax error actually is by opening scripts one-by-one until I stumble upon it.

This is less likely to happen if you're using Godot's built-in script editor because you're more likely to catch the syntax error before it causes too much trouble. However Godot's built-in editor is really lacking, mainly because you can only have one script open at a time and if you need to edit multiple files at once it requires a very tedious process of manually jumping between files one at a time. So I use an external editor, which does have a language server integration with Godot—so it does catch syntax errors, but sometimes I don't catch them in time, and then these dizzying cascading errors happen.

I've also noticed that sometimes there will be compile errors that are fixed by reloading the project. It feels like these happen because of an unusual (sometimes seemingly random) parse order for scripts, like classes are found as undeclared when in fact they are. I haven't looked into it too much.

That all being said, Godot has been wonderful to work with overall. These frustrating experiences are infrequent, and it sounds like many of them are being addressed in Godot 4. I've enjoyed it way more than Unity and it's an amazing privilege to have access to such a powerful open-source project!

This week: low-density ancient urbanism, an extraction-free Atacama Desert, AI and climate change, and Wakanda.

The real urban jungle: how ancient societies reimagined what cities could be, Patrick Roberts

Most cities around the world, while still considerably varied, seem to have comparable density, layout, and land-use. The ancient tropical cities of the Khmer and Classic Maya empires were more sprawled and interspersed with agricultural plots and "forest gardens". In general they sound more integrated with the environment—perhaps easier because unlike the cities that would come later they were not yet inundated with toxic industry. Whether or not the impact of urban living shakes out to be an environmental net positive or negative is something I've meant to read more about but yet haven't gotten around to. But these examples of different forms of urban life are nice to think about, even if they occurred under tremendously different circumstances.

Lithium Landscapes: From Abstract Imaginaries to Deep Time and Multi-Scalar Topologies, Samir Bhowmik

A reflection on the vast timescales that give rise to lithium and the earthbound terraforming (human extraction of) lithium gives rise to. I especially like this painting:

Portuguese artist Mafalda Paiva's painting Lithium Fields, which depicts the Atacama Desert reminds us of what could have been—a paradise instead of an extractive landscape. In the artist’s vision, “the salt flats hum with a preternatural vibrancy, an effect produced by the exaggerated density of species and radically foreshortened topography.”

These Are The Startups Applying AI To Tackle Climate Change, Rob Toews

I'm skeptical that AI can be applied to substantially help mitigate climate change. There are specific applications that seem to be useful, e.g. around power efficiency, the development of new materials, etc. It probably has a role to play but hard to say whether it will be much more than other technologies treated with far less fervor—this article breathlessly states: "Artificial intelligence is the most powerful tool that humanity has at its disposal in the twenty-first century."

I wonder if the wide proliferation of AI that many of its proponents either foretell or actively try to engineer through their own companies/investments will net out positive or negative in terms of carbon, given the intense energy requirements to train the largest, most sophisticated models. If AI is commodified and so as unnecessarily ubiquitous as microchips then perhaps it'll come out net positive emissions.

This list of companies claiming to use AI against climate change is interesting, especially because it reveals what it means to publications like Forbes to "tackle" climate change. Several of the companies are focused on identifying climate risks or managing climate insurance for businesses. A great deal of time is spent companies applying AI to carbon offsets, which looks more like companies bending over backwards to legitimize a completely ineffective/actively harmful way of "addressing" climate change rather than actually working to reduce their emissions. The "solution" to offsets sounds like more surveillance infrastructure.

Wakanda

I'm not a big fan of the MCU, but the creation of a cinematic universe opens up a lot of storytelling and character possibilities so I reluctantly follow along every so often to see what they're doing with that capacity. I wish it were some other more interesting, less indulgently militaristic fictional universe that had the resources to do something like that. Instead we get Marvel and soon the Mattel Cinematic Universe.

Ever since I found Wakanda listed as a US free trade partner I wondered how Wakanda might relate to other countries and how people outside perceive it. While reading Doomwar I came across this off-handed mention from Shuri:

I'm so curious about the terms of that loan. The first Black Panther movie wrestled a bit with Wakanda's responsibility towards its neighboring nations or developing nations (as it used to posture as) but if I recall it never really answered that question. I haven't watched Black Panther recently so forgive any misremembering, but I believe Killmonger was just defeated without any satisfying resolution to his analysis/proposals about spreading Wakanda's wealth. IIRC he proposed distributing vibranium for uprisings across the world—even if T'Challa disagreed with violent uprisings, maybe the spreading of that wealth is worth considering. Although given what Shuri says here, maybe that's exactly what they're doing. But again, I wonder on what terms?

I wonder if in some ways the now-opened Wakanda is perceived in similar ways to how China is perceived in our world. I don't know what it takes to qualify as a "superpower" but I imagine Wakanda checks off many of those boxes. Surely many people in the MCU pin their hopes on Wakanda to usurp the planetary hegemons...sadly, they'll probably be disappointed.

---

This week: Comfort with contradictions, anime and Gen Z

Dialetheism and Eastern Philosophy

We recently finished watching The Good Place, which was very sweet. Overall I enjoyed it, but there was one plot hole that I was disappointed to see left unaddressed, I'll leave it in the footnotes to avoid spoilers¹.

The other disappointment is the show's heavy (maybe exclusive) reliance on Western philosophy² I don't really blame the show for this because it's just an enormous problem in how philosophy is taught in general. Something else that would have been nice to include is a reckoning with the extraordinary racism of Kant (see the previous link for some examples).

That's all to say that after the show I wanted to read more on non-Western ethical systems. This interview introduced me to the idea of "paraconsistency" and I got sidetracked into reading about dialetheism, which is the view that statements can be both true and false (in orthodox logics statements can only be one or the other; such inconsistencies "explode", i.e. entail everything to be true). The simplest example is the Liar's Paradox, which in one sentence is "this statement is false". My understanding is that under dialetheism this statement is not a paradox and to be rejected but accepted as-is.

As the SEP entry on dialetheism explains, dialetheism shows up a lot in Eastern philosophies (as well as in Western philosophy: dialectics, for example). The Daodejing and Zhuangzi are riddled with them. "The Way of the Dialetheist: Contradictions in Buddhism" (Yasuo, Garfield, Priest) gives an overview of how dialetheism shows up in Buddhism, describe some interpretative possibilities: are they presented as literal/true, or are they used as rhetorical/pedagogical tools for insight (as in Zen)?

My own understanding is usually that these apparent contradictions are not actually the case—for example, a common form is to say that thing X has property Y and Z such that those simultaneously having two properties is inconsistent/impossible, which I often take to mean "thing X" refers to our term for X and not X itself; and that in fact that term refers to two things that are different. For example, "race is real and not real" could refer to how race is not "real" as in it is an immutable part of the universe but is still "real" as social reality—as something that feels total and inescapable in our lives.

But this interpretation doesn't work in many cases. When Buddha says "the ultimate truth is that there is no ultimate truth", that seems to be more of a straight-up contradiction.

Welcome to Planet Egirl, Cecilia D'Anastasio

I definitely feel old given how much more I've been reading about subcultures through publications like Wired rather than experiencing them. But I'm struck by how much anime has influenced Gen Z and how visible/trendy it is, whereas for my generation it was an almost clandestine activity. Ariel brought up a good question: is this a popularization of Japanophilic culture or is anime being separated out? Anime production is still more or less the exclusive domain of Japan as far as I'm aware.

---

This week: The secularization/Westernization of Buddhism, IDEO, UFOs/UAPs, and #fixingfashion.

Questions on the origins of Buddhist concepts and Is secular Buddhism looked down upon in the Buddhist community?

Very interesting to read these threads on secularized/western Buddhism—which tries to "sanitize" Buddhism of its more fantastical elements. The western presentation often boils down to something like: "life is suffering, suffering is driven by desire, end desire to escape suffering". Maybe the notion of karma remains because it's in line with other western folk wisdom (e.g. "what goes around comes around"), but other elements like rebirth or that the Buddha had supernatural insight/powers are dismissed as nonsense. Even what it means to be "enlightened", as one commenter notes, is different under this secularized view: "Do you imagine that enlightenment just means feeling calm?". Maybe this kind of secularization or tampering down is a typical course for religions—thinking about secular Jews and most Christians I've met don't believe angels are real—but with Buddhism in particular it has strong colonialist overtones (usually from white people and with some implication that people who do believe in the supernatural elements are backwards/ignorant for doing so—unenlightened in the sense of "the Enlightenment").

I don't necessarily mind secular Buddhism as a concept (the problem is more the industry around it and its extractive/appropriative nature) but it's this attempt to re-write the historical image of the Buddha to conform to those beliefs—such that there exists an "authentic Buddhism" that does away with the elements you don't like—that is upsetting.

Surviving IDEO, George Aye

I worked at IDEO almost a decade ago—it was my first "real" job out of college, and so I didn't have any prior office experience to compare things to, but it was clear that there was a lot of kool-aid to drink and a lot of people drank it. I joined as part of a new team that was separate from the company's typical design consulting work (we were brought into help out with specific technical needs here and there) and so I was fortunate enough to be insulated from a lot of the broader office politics, pettiness, and discrimination outlined in this piece. Given the general lack of self-awareness the place has—e.g. speaking really highly of its practice as world-transformative but basically doing little but intensify capitalism's entrenchment in all aspects of our lives¹ (I remember quite a bit of the work was basically creating new luxury offerings for financial institutions)—what's outlined here is sadly not very surprising.

Related to this topic: I recommend "It's Not You, It's the System" by Janani Balasubramanian. This piece was helpful for me in deciding whether or not to quit IDEO.

How the Pentagon Started Taking U.F.O.s Seriously, Gideon Lewis-Kraus

As a kid I liked the idea of extraterrestrial life and thought things like Fermi's Paradox and the Drake Equation were really fascinating (although the Drake Equation seemed almost arbitrary/impractical). A number of games I played growing up also built stories around aliens, like Dinosaur Safari (aliens going back in time to document dinosaurs) and The Journeyman Project 3: Legacy of Time (an "ancient aliens"-style game set in the mythical cities of Atlantis, El Dorado, and Shangri-La that, though the story was based around aliens, taught quite a bit about the actual ancient cultures these cities were inspired by). But aside from reading about these topics here and there I never got very deep into UFOs and the like. It felt like a cliff's edge into unsubstantiated and woo conspiracy theories. At the same time, it seemed reasonable that there would be some phenomena that is difficult to explain, and that in itself was interesting without needing to jump to the conclusion of aliens. This article explores that latter space, and also goes over a campaign meant to consign UFOs and an interest in them into the former conspiratorial category (read: "crazy"), effectively making the topic untouchable if you want to be considered legitimate. I'm skeptical that anything really earth-shattering will come out of June's UAP report but who knows, maybe something interesting will happen.

#fixingfashion videos

A really well-produced and comprehensive series on how to take care of your clothes, repair them, and modify them:

• How to take care of your clothes
• How to upgrade your clothes and keep them longer
• How to repair your clothes

A bunch of my clothing recently got several rips, and repairing them has been a nice way to keep my hands busy on long meetings.

Here's the most recent repair I did—you can see the smaller yellow patches where I underestimated how large patches actually need to be relative to the size of the hole. The edges of those patches ended up tearing, leading to the substantially larger sashiko patch there now.

---