We’re Fucked, Pt. 97: AI-generated audiochapter

As in previous times, my enslaved AI voices have contributed to enliven the current chapter of my ongoing novel We’re Fucked, this time chapter 97.


  • Leire: A sassy infiltrator who hangs out at the Ragged Flagon in Riften
  • Alberto the blob: So many scaly dudes from Cyrodiil
  • Leire’s father: some delusional guy who sells swatters in Diamond City
  • Leire’s mother: a ghoul who sells bits and pieces in a good neighborhood

I have produced audiochapters for this entire sequence so far. A total of an hour, forty minutes and forty-six seconds. Check them out.

AI news #2

For me, the holy grail of gaming involves characters driven by AI that could pass the Turing test, and who could trigger changes in the game world according to your unscripted conversations with them and/or their own decisions.

The first half of that dream is already being developed for different games thanks to the astonishing AI of GPT-4. Check out the progress done for the undying Skyrim (its VR version no less, for added immersion):

These conversations are character-appropriate, so the video is much more impressive if, like me, you’ve known all these characters for about twelve years. The voice generation can be plugged to Eleven Labs’ API for more realistic results, although that would burn plenty of the monthly allowed credits.

Here’s another video of this technology in Skyrim, now using Eleven Labs’ voices:

I love how Ysolda admits to being a drug dealer right in the middle of Whiterun’s market. And what’s with that town guard abusing metaphors?

Here’s more or less the same kind of stuff but with a human being acting like a bastard toward Fallout: New Vegas characters:

The following video is an overview of this technology applied to Skyrim (and other games in general), along with its possibilities and limitations.

We’re Fucked, Pt. 96: AI-generated audiochapter

Don’t you love AI-generated voices that have no choice but to act out your scenes whenever you want? Check out the audiochapter I produced for chapter 96:


  • Leire: Vex, thief extraordinaire from back in Skyrim times
  • Blob: Lizard men from Cyrodiil
  • Spike: Travis Miles, that radio guy from Fallout 4 (sorry, Spike)

I have produced audiochapters for this entire sequence so far. A total of an hour, thirty-three minutes and nine seconds. Like a whole movie! Check them out.

Interdimensional Prophets (Game Dev) #6

I had finished programming the non-visual part of Team Struggles (a part of the encounter system that involves character traits and psychological dimensions against some performance thresholds) when I faced the fact that the game was loading too damn slow. I admit, I have been a bit overeager demanding more anime photo IDs from Midjourney, and they are completely unoptimized, but still, I figured that this project could load much faster. So I figured the following solutions:

  • Lazy loading. Instead of loading encounter, biome, and photo ID images at once, just the image path is registered. Right before I need to draw a certain image, I check if it has been loaded, and if it hasn’t, I load it. That makes it so that the many images that won’t be seen in a particular testing session won’t need to be loaded at all. This change alone has sped up game loading significantly.
  • Multithreading. This project didn’t feature any multithreading up to this point, as it is a static, 2D strategy game, but the process of loading the various parts (most of them from TOML files) could use some multithreading. My previous experience with this subject involved trying to develop a Dwarf Fortress-like simulation in Python, only to realize that Python isn’t suited for multiprocessing, nor remotely big simulations at all, due to its garbage-collected nature and a core that is locked to a single thread. However, Rust has mature crates that make multiprocessing relatively simple.

I asked GPT-4 to give me an overview of multiprocessing in the Rust programming language. It suggested a combination of the “rayon” and “crossbeam-channel” crates. The process works like this:

let (sender, ecs_receiver) = crossbeam_channel::unbounded();

You declare a sender and a receiver. The sender part will put on a queue the work done from a different thread, and the receiver will remain on the main thread to try to figure out what it can extract from the queue. However, those threads don’t need to disconnect: they are open channels. I assume that you could have a dedicated thread pumping out pathfinding-related calculations back to the main thread.

Spawning a thread is as easy as the following:

       std::thread::spawn(move || {



The “move” order, or whatever you would call it, is tricky. Any information at all that you are sending from the main thread changes its ownership, even if you clone it normally, so you need to use the “Arc” library to clone it in some special way. Not sure how expensive it is.

Anyway, “load_ecs_threaded(sender)” is in this case the function that will run in the spawned thread. The definition and contents are the following:

use crate::{


    world::{create_world, ecs::ECS},


pub fn load_ecs_threaded(sender: crossbeam_channel::Sender<ECS<ImageImpl>>) {


        .send(create_world::<ImageImpl, ECS<ImageImpl>>())



That function merely sends through the sender the results of the “create_world” function, that registers all necessary components with “specs” Entity-Component System.

You won’t be able to check if the spawned threads have done anything unless you are running some sort of loop on the main thread. In this case I’m running the game with the 2D game dev “ggez” crate, which operates a simple, but well-working, game loop. From there, you need to rely on the “receiver” part of the channel to try to receive data:

        if let Ok(ecs) = self.ecs_receiver.try_recv() {

            match self.shared_resources.try_lock() {

                Ok(mut bound_shared_resources) => {


                    self.progress_text = Text::new(“Loaded Entity-Component System”.to_string());


                Err(error) => return Err(GameError::CustomError(format!(“Couldn’t lock shared resources to set the world instance. Error: {}”,





Through the call “ecs_receiver.try_recv()” I will get either an Ok or an Error. An error may just be that the channel is empty because the remote function hasn’t finished working, so we just check Ok. In that case, the thread has finished doing its job. We gather the results (the “ecs” in this case) and store it into our shared_resources as I did previously.

That’s all. You need to be careful, though, because there are some structs that you can’t send through channels. For example, you can’t send the graphical context of “ggez”, meaning that you always need to load images in the main thread. You also can’t send the random number generator through, as it’s explicitly working on a single thread. But I haven’t found any issue sending my game structs.

Now that the game doesn’t seem to freeze on launch, I can focus on implementing the visual aspect of Team Struggles.

Interdimensional Prophets (Game Dev) #5

A couple of entries ago I presented my first version of the encounter screen. As the team of explorers wanders around in the map, the stored encounters will get shuffled, and the first one whose condition gets triggered will present itself. Here’s the somewhat updated screen:

I was checking out the moddability of this game by changing most pictures to manga/anime aesthetics, and I realized that I liked it more this way. With a simple change of directory names, all names and pictures could get swapped to American ones. In any case, this screen presents what encounter has been triggered. The description gives a brief overview of the situation. The rest of the text informs that this encounter, at least the psychological part of it, will test each team member’s self-regulation (which is one of the psychological dimensions, the grouping of a few psychological criteria).

Yes, I know that there’s a lot of black space. Don’t know what to do about that.

Once you click the round button on the lower right, you are shown the results of the psychological test:

A brief text indicates the reason of this psychological test; in this introductory event/encounter to a narrative line called “The Verdant Assembly,” the characters test their self-regulation against the overwhelmingly lush and alien surroundings. For each character, the average value for that psychological dimension gets tested against a series of performance thresholds in the TOML files. The highest threshold they pass, they get that reward (or punishment). In game terms, an Encounter is associated with a series of Outcomes. Here’s how the outcomes for this encounter look like in the raw TOML file:

# Possible placeholders:





identifier = 1

outcome_type = “PsychologicalTest”

description = “Overwhelmed by the alien nature of this plant-based world.”

consequences_identifier = 1


identifier = 2

outcome_type = “PsychologicalTest”

description = “{CHARACTER_FIRST_NAME} becomes fascinated by the plant-based entities, leading to increased motivation and a desire to learn from them.”

consequences_identifier = 2

They are self-explanatory. The most important part is that they link to another store of game entities, the Consequences. I intended to unify the concept of game consequences to a single block of game logic that could be applied to psychological tests and, in the future, to team struggles. The TOML file of related consequences is the following:


identifier = 1

illness_identifiers = []

injury_identifiers = []

mental_status_effect_identifiers = [1, 2]

character_trait_identifiers = [1]

add_features_identifiers = []

remove_features_identifiers = []


identifier = 2

illness_identifiers = []

injury_identifiers = []

mental_status_effect_identifiers = [3]

character_trait_identifiers = []

add_features_identifiers = []

remove_features_identifiers = []

It is quite inexpressive in its contents because it only links to other entities through their identifiers. However, the outcome of each psychological test and team struggle could have any of the following consequences (or all of them):

  • The team member(s) involved receives one or many illnesses. Illnesses reduce the team member’s health every turn until they run out or are cured.
  • Receives one or many injuries. Instant reduction of health, and the permanent ones even reduce max health.
  • Receives one or many mental statuses (like Confused or Discouraged). They increase or reduce the value for associated psychological criteria.
  • Receives one or many character traits (like Terrified of Octopi, or Botanist). These help or hinder during team struggles.
  • The exploration zone the team is exploring either gains or loses features. For example, if some outcome enrages the natives, the exploration zone could gain the feature Enraged Natives, which would present more combat-oriented encounters in the future.

The consequences are already being applied in the code (which was some heavy amount of code, well-tested thanks to test-driven development), and once I get around to implementing team struggles, their consequences will work seamlessly with the code already written.

In the near future I’m going to focus on making sure that encounters can be blocked by other encounters or even their outcomes, if necessary. For example, if during a team struggle the team screws up bad enough to unleash something dangerous, that should cut off access to more positive branches of that same narrative.

A detail about Rust’s fastidious nature: this is a programming language built upon security and protection against the nastiest bugs from the C++ era. As far as I can tell, in Rust it’s impossible to corrupt some memory allocation that it wasn’t supposed to touch. That forces you to change your approach to programming in quite a few ways, but not because Rust is annoying for no reason, but because in other languages you were doing dangerous things. In my code, I was passing around a SharedGameResources entity that had access to “specs” Entity-Component System (that’s a whole thing; if you are interested, google it) as well as the stores of data loaded from TOML files. At one point I had to borrow that SharedGameResources entity both as immutable (just to read from the stores) as well as mutable (to write the results in the components). That’s impossible. Although it forced me to rewrite some basic architectural code, it illuminated the point that stores of game systems (like the “databases” of mental status effects or of character traits) are separate to the Entity-Component System, which handles a lot of mutation. In the end, Rust’s compiler steers you towards proper architecture, because you simply can’t run your program otherwise.

Asking GPT-4 the real questions

“Do groundhogs actually exist?”

Yes, groundhogs do exist. They are a type of marmot, a large rodent found in North America. Groundhogs are also commonly known as woodchucks, and their scientific name is Marmota monax. They are primarily herbivores and live in burrows, which they dig with their strong claws. Groundhogs are often associated with the North American holiday Groundhog Day, which takes place on February 2nd each year. On this day, it is said that if a groundhog emerges from its burrow and sees its shadow, there will be six more weeks of winter; if it does not see its shadow, an early spring is predicted.

“Is it true that groundhogs cause someone to be trapped in a loop that repeats a single day?”

The idea of a groundhog causing someone to be trapped in a time loop that repeats a single day is not true in reality. This concept comes from the 1993 movie “Groundhog Day” starring Bill Murray. In the film, the main character, a weatherman named Phil Connors, gets trapped in a time loop that causes him to relive February 2nd (Groundhog Day) repeatedly. The movie is a work of fiction and should not be taken as an accurate representation of the abilities or effects of groundhogs in real life.

Interdimensional Prophets (Game Dev) #4

As I was writing unit tests for a perilous, convoluted part of the game logic, which I wanted to lock in place as I moved forward, I realized that to test one relatively small part of the code, I would need to create both World, the main entity of the Entity-Component System “specs”, as well as Image, which is tied to the Context of the 2D game dev “ggez” crate. World is heavy by itself to fire up for a simple unit test, but Images themselves may not even be feasible, as they are glued to the graphical context (no graphics should run during unit tests), and they are tied to a single thread, while the unit tests run in all CPUs.

Therefore, I came to the dreaded conclusion: I needed to refactor their entire code into traits (interfaces). Traits are contracts that encapsulate a behavior without implementing anything. If you program to traits (interfaces) instead of to classes, you are working with future, potentially unimplemented structures whose details are irrelevant to you or the compiler, because they are only forced to fulfill a contract (the trait/interface). It’s like telling an animal to say something; a dog would bark, a cat would meow, but both have fulfilled the contract of “talking,” which is apparently all you cared about.

It just happens that traits in Rust involve generics, and generics in Rust are unholy. Due to Rust’s welcome but tough borrowing rules and lifetime whatevers, Refactoring any behavior to traits involves dealing with bizarre generic declarations, and worse yet, nearly incomprehensible lifetime signatures.

Behold the horror:

pub struct MainState<‘a, T: ImageBehavior + ‘static + std::marker::Send + std::marker::Sync + Clone, U: WorldBehavior<T>> {

    active_stage: Option<GameStage>,

    base_state: BaseState<‘a, T, U>,

    expedition_state: ExpeditionState<‘a, T, U>,

    encounter_state: EncounterState<‘a, T, U>,

    shared_game_logic: Arc<Mutex<SharedGameLogic>>,


That’s the definition of MainState, the head honcho of the state machine that figures out which other stage needs to update, or draw on the screen. It declares that it’s somehow involved, to start, with an ImageBehavior contract. Every image throughout the program, except in the launcher, is now unaware of what type of structure it’s actually dealing with, except that it fulfills the contract of being static (I assume images are fixed in memory or something), they Send and Sync for multithreading, and can be Cloned. That’s the hardest one. Then we have WorldBehavior, which abstracts away the entirety of the “specs” Entity-Component System into a wrapped class. The resulting contract for WorldBehavior, if I may say so myself, is a thing of beauty:

pub trait WorldBehavior<T: ImageBehavior + std::marker::Sync + std::marker::Send + Clone> {

    fn new(world: World) -> Self;

    fn join_coordinates_and_tile_biomes(&self) -> Vec<((i32, i32), TileBiome)>;

    fn retrieve_player_coordinates(&self) -> Option<(i32, i32)>;

    fn retrieve_biome_at_player_position(&self) -> Option<Biome>;

    fn retrieve_unique_character_traits_of_team_members(&self)

        -> HashSet<CharacterTraitIdentifier>;

    fn count_team_members(&self) -> u32;

    fn calculate_average_mental_strain_of_team(&self) -> f32;

    fn calculate_average_health_of_team(&self) -> f32;

    fn set_player_position(&mut self, x: i32, y: i32);

    fn retrieve_player_entity(&self) -> Entity;

    fn retrieve_name_of_entity(&self, entity: Entity) -> Name;

    fn retrieve_psychological_profile_of_entity(&self, entity: Entity) -> PsychologicalProfile;

    fn retrieve_health_of_entity(&self, entity: Entity) -> CharacterHealth;

    fn retrieve_team_members(&self) -> Vec<Entity>;

    fn retrieve_team_members_except_player(&self) -> Vec<Entity>;

    fn retrieve_photo_id_of_entity(&self, entity: Entity) -> PhotoId<T>;

    fn move_direction(&mut self, direction: Direction);

    fn create_entity(&mut self) -> EntityBuilder<‘_>;


With that contract in place, there’s no more need to deal with “specs” way of working. You want to retrieve the player entity? Call “retrieve_player_entity”. Do you want a calculation of the average mental strain of the entire team? Call “calculate_average_mental_strain_of_team”. Of course, the contract can be developed further as more information or calculations need to be gathered.

I’m at ease now that I have managed to refactor those two unit test blockers into behaviors, but it took hours, and if it weren’t for the indefatigable help of GPT-4, I wouldn’t have been able to do it. But thankfully there shouldn’t be any major obstacles to unit test every part of the code now, which should speed up development significantly.

A boring entry compared with the three previous ones, perhaps, but programming is a fight against entropy: the further you build your system, the harder it becomes to change. You have to stop every few days (if not once a day) to make sure that some part of the code isn’t rotting already.

Interdimensional Prophets (Game Dev) #3

The core loop of this game/experiment of mine consists of the encounter system. As the team of explorers (consisting of four members for balancing reasons, like in Arkham Horror LCG) ventures through strange new worlds, they will face encounters (psychological tests, team struggles) in the following circumstances: either the player ends the turn deliberately, or he/she moves the team to a different tile. That will trigger the code to shuffle the potentially very, very large list of encounters loaded from a TOML file, and then a complex function will determine which will be the encounter that the team of explorers will face based on numerous conditions.

The following is an example encounter from the TOML file, that gets loaded to the game on start.



identifier = 1

title = “A New World”

image_path = “/resources/encounters/1.png”

description = “We have made it. Nobody believed we would manage to create a portal to a multiverse, but here we are, in this strange new world. I take a deep breath as I gaze at the field of grass.”

duration_in_turns = 1

encounter_condition = 1

psychological_test_identifier = 1


identifier = 1

requirements_biome_identifiers = [1]

requirements_feature_identifiers = [

    { AnyRequired = [] },

    { AllRequired = [] },

    { AnyExcluded = [] },


requirements_encounter_identifiers = [

    { AnyPreviousEncounter = [] },

    { AllPreviousEncounters = [] },

    { AnyExcludedEncounter = [] },


requirements_trait_identifiers = [

    { AnyRequired = [] },

    { AllRequired = [] },

    { AnyExcluded = [] },


team_size_requirements = [

    { MinimumTeamSize = 1 },

    { MaximumTeamSize = 6 },


team_overall_mental_health_requirements = [

    { MinimumTeamOverallMentalHealth = 0.0 },

    { MaximumTeamOverallMentalHealth = 100.0 },


team_overall_health_requirements = [

    { MinimumTeamOverallHealth = 0.0 },

    { MaximumTeamOverallHealth = 100.0 },


time_spent_in_alternate_earth_requirements = [

    { MinimumTimeSpentInAlternateEarth = 0 },

    { MaximumTimeSpentInAlternateEarth = 10 },


Each encounter is, so far, associated with a psychological test, but soon enough they will be associated with a team struggle as well. The most important part of an encounter is the conditions for it to trigger, which can be the following:

  • The current biome is any of the required (obligatory: all encounters should be attached to at least one biome).
  • The features associated with this exploration zone (ex. NativeInhabitants, Irradiated) are compatible with the any/all/excluded specifications.
  • The list of previous encounters is compatible with the any/all/excluded specifications. This should allow for story-like threads of narrative that depend on previous “chapters” having been passed.
  • The combined list of character traits (from all team members) is compatible with the any/all/required specifications.
  • The team size should be between the set values, if any.
  • The team’s overall mental health should be between the set values, if any.
  • The team’s overall health should be between the set values, if any.
  • The time spent wandering in the current exploration zone should be between the set values, if any.

This allows, for example, for encounters with mythical beasts that only inhabit certain biomes, maybe during some lunar condition (which would be a feature), and only when the team of explorers has trackers (which would be a character trait). Also, when the team’s mental health is deteriorating and their overall health is becoming dangerous, encounters about the team stopping to rest and heal could pop up.

When an encounter triggers, the user is presented with the following window:

I’m not an interface man. I need to figure out which background color would be preferable to plain black, but white and such other clear options seem too grating to me. Anyway, the photo on the upper left is the one associated with the encounter. The row of photo IDs under that is the team of explorers, starting with the player. Regarding text, there’s the title, a short description (thankfully you can program text wrapping). A blue text that you can barely distinguish from here announces that there’s a psychological test associated with the encounter, and that it tests the following psychological dimensions: cognitive abilities and interpersonal skills. Then the values of those psychological dimensions are displayed for each team member.

In the lower right you get a reminder of what biome you are currently in (in this case, a temperate grassland). The fancy button to its left is the one to trigger the psychological test. I have already written the code to gather all the results, which will appear under the description of the encounter.

Thank you Midjourney for the effortless AI images. Regarding GPT-4, I make a point of bothering it by presenting my code and asking “this represents an Outcome given [game concept]. Can you offer any suggestions and improvements?” The AI is eager to point out what I’ve done wrong, with no regard to my feelings. As such, it has proven to be an invaluable tool while programming. Also, when I suspect there’s more to squeeze out of a concept (such as psychological tests, team struggles, outcomes, etc.), I ask GPT-4 if it can come up with more features for that concept, and more often than not, it provides very valuable insight.

Anyway, I have been feeling guilty because I’m mainly a writer and I have neglected my novel for a week. I think that for the foreseeable future I will write one day, program the next. Programming is very addictive for the obsessive mind I was born with, as long as you don’t end up in some ditch of which you don’t know how to climb out.

Interdimensional Prophets (Game Dev) #2

Although I had managed to develop the code to load environments (now called exploration zones) from a Lua file, to pick one and then create a map using the biomes that the exploration zone allowed, the process of loading relatively simple data from Lua annoyed me. It seemed way too complex for this day and age, even though GPT-4 wrote most of the code helped me. I asked the AI for preferable alternatives, and it suggested either JSON files or TOML ones. TOML seemed fancier and better somehow (I have already forgotten the reasons), so I have spent some hours going through the somewhat grueling process of destroying the basic code that worked, to improve the system.

Thankfully, deserializing TOML files to Rust instances is trivial thanks to the “serde” crate. In addition, it had worried me that the process of adding a new type of biome or a feature (some aspect of the exploration zones, like bad weather) required me adding a new element to the corresponding enum, which meant that no user of the game (meaning me for the most part) would be able to add new biomes nor features without access to the code. Obviously that’s terrible for modding; the holy grail of modding consists on having every piece of game data exposed to be fondled by the greasy fingers of the users.

Behold the TOML files that now store all the game data for biomes, features of an exploration zone, and the exploration zones themselves (obviously the data itself is made of examples):



identifier = “temperate_grassland”

name = “Temperate Grassland”

description = “A biome characterized by rolling grasslands and few trees.”


identifier = “sky_islands”

name = “Sky Islands”

description = “A biome consisting of floating islands high in the sky.”


identifier = “alpine”

name = “Alpine”

description = “A biome consisting of high land and some pines.”



identifier = “haunted”

name = “Haunted”

description = “a supernatural presence, allowing encounters with ghosts.”


identifier = “ancient_ruins”

name = “Ancient Ruins”

description = “contains the remains of an ancient civilization, with hidden treasures and traps.”


identifier = “unstable_geology”

name = “Unstable Geology”

description = “frequent earthquakes and volcanic activity, posing geological hazards for the team.”


identifier = “radioactive”

name = “Radioactive”

description = “high levels of radiation, potentially causing health problems and mutating local flora and fauna.”



identifier = “zone_1”

name = “Verdant Valley”

description = “A lush valley with dense forests, clear rivers, and abundant wildlife.”

allowed_biomes = [“temperate_forest”, “river”, “temperate_grassland”]

features = [“rich_flora”, “native_inhabitants”]


identifier = “zone_2”

name = “Frozen Tundra”

description = “A vast, frozen wasteland with treacherous ice and snow, and sparse vegetation.”

allowed_biomes = [“tundra”, “ice”, “glacier”]

features = [“extreme_cold”, “limited_visibility”]

From now on, as long as the identifier of a biome written in the exploration_zones TOML file matches with an entry in the biomes TOML file, the game will work properly and use that biome (and its image). If not, the game will burn to the ground (in Rust’s terms, it will panic).

Now I will move on the encounter system, which is composed of various steps:

-A very complex determination of whether or not any given encounter will trigger (can depend on certain biomes and/or features and/or previous encounters having been seen and/or the team members having certain traits and/or the team size being between a certain range and/or the team’s average mental health being between a certain range and/or the team’s overall health being between a certain range and/or the time spent exploring being between a certain range. That code is already written and is the most unit tested area of the game so far (thanks to GPT-4).

-If an encounter triggers, then each team member should go through a number of psychological tests. For example, having walking octopi wanting to drink your blood may test their self-regulation and/or coping skills. The outcomes are on a range of thresholds, so worse outcomes should cause worse consequences, and so on. Those will also end up as TOML files.

-After all the psychological tests pass, there should be one or more team tests. The way these tests work, the best one that GPT-4 and I have come up with, is adding beneficial character traits * their individual weight against negative character traits * their weight, and applying outcomes based on a range like in the case of the psych tests.

If that psychological test thing followed by team test reminds you of something, yes, I was inspired by the Arkham Horror LCG, my favorite card game. In that game, before your turn starts, you are forced to deal with some nefarious encounter (it’s always unnerving to see that card coming from the deck) that you have to face with your abilities. The encounter can make you lose sanity and/or health, or who knows what other horrors. Afterwards you can act with your cards, and other players can get involved if you share a location with them. Hence my notion of a round of psychological tests followed by a team test/struggle.

I won’t go through the trouble of creating a anything visual for this encounter system until it works well in the console and is well-tested. The encounter system seems like the toughest nut to crack of this game, and I’m for one excited to face how to implement it.

If you, whoever the hell you are reading this, can come up with some idea for this game, please tell me. If it’s good, I’ll implement it. Otherwise I’ll yell at you and call you stupid.

Interdimensional Prophets (Game Dev) #1

A couple of years ago I wrote a wild (and long) free verse poem about some unhinged scientist who was leading teams of unfortunate people through an interdimensional portal to explore alternate Earths. This is the link to that poem (it requires a rewrite, though, particularly to add periods). I was fascinated by the potential for stories that such a concept included. I played around with the notion of developing some game around it, but my experience with programming solo was more often than not the same: I tried to implement some general game concept only to find myself hitting my head against an implementation detail that had seemed easy to solve. Eventually I discarded all my grand programming ideas. One of them involved Python, and it was the language itself that ended up pissing me off.

Enter GPT-4, the most advanced AI that I have ever interacted with. Turns out that GPT-4 is great at programming in Rust. Literally, you tell that damn thing to write unit tests for your code, and it does. I remain constantly amazed by its insight. In a couple of days, I cobbled this stuff together:

This is the beginning of the “base” screen, set on regular Earth, where the team will manage its staff, handle their health and psychological problems, and, more importantly, delve into alternate Earths through the portal. A description gives the general notion of the alternate Earth on the other side of the portal: “A bizarre, otherworldly environment dominated by massive fungi, and strange creatures.”

This is the map view during exploration. The icon represents the actual position of the team. I didn’t mention it before, but the person on the upper left side is the player (for now generated randomly), who will lead the team of explorers to face the dangers alongside them.

I already have many, many different environments written and illustrated, thanks to the back-and-forth between GPT-4 and myself, and Midjourney for the images. A bigger example, the Stormy Desert biome:

All these environments are written in a Lua file, so they are intrinsically moddable (so far, as long as the Biomes and the environment Features are coded in game). Here’s an example of a single environment in the file environments.lua:

    Highland = {

        description = “A high-altitude environment consisting of rolling hills, plateaus, and mountains, with a mix of grasslands, forests, and rocky terrain.”,

        allowed_biomes = {










        features = {





















The combination of biomes and features will determine which types of encounters the team will face. That’s a whole different system I’m developing, and that I intend to be fully moddable as well.

I wanted each team member to be as psychologically complex as possible. Each encounter will test one or more psychological dimensions of their personality. For example, if they come across walking octopi that try to drink the team members’ blood (which happens in the poem), certain psychological dimensions will be tested.

For now, all psychological dimensions that GPT-4 and I have discovered (mostly the AI, though) are Interpersonal Skills, Cognitive Abilities, Self-Regulation, Coping Skills, Drive, Cross-Cultural Skills, and Mental Strain. For example, a single psychological test of that encounter could test a team member’s Coping Skills, and if he fails, his Anxiety psychological criterion could increase permanently. They could also lose health, acquire traits, etc. The notion is that when Mental Strain reaches 100, they are committed to a mental institution. They may quit some time earlier, though. The health system is very barebones at the moment (literally just a 0.0 to 100.0 value), but I want to create a whole system for that as well, including permanent injuries.

The grouping of psychological criterion to psychological dimensions is the following:

  • Interpersonal Skills: Extraversion, Agreeableness, Social Skills, Empathy, Conflict Resolution, Teamwork
  • Drive: Conscientiousness, Leadership, Risk-Taking, Time Management
  • Self-Regulation: Emotional Stability, Emotional Intelligence, Self-Esteem, Self-Awareness
  • Cognitive Abilities: Openness to Experience, Problem-Solving, Creativity, Situational Awareness, Decision-Making
  • Coping Skills: Resilience, Coping Strategies, Adaptability
  • Cross-Cultural Skills: Cultural Competence
  • Mental Strain: Anxiety, Depression, Stress

Right now, when a new team member is created, every psychological criterion is assigned a number from 0.0 to 100.0 on a normal distribution. GPT-4 even wrote psychological reports from the perspective of the team leader. The following is such a report generated in-game for the team leader herself:

Some experience working with others and collaborating towards shared goals. They may need additional support in order to effectively build relationships with others and resolve conflicts.
Average cognitive abilities and is capable of problem solving and critical thinking. They may need additional support or training in order to tackle more complex problems and situations.
Struggles to manage their emotions and reactions in high-pressure situations or when encountering unexpected events. They may be prone to panic or irrational behavior, making them a potential liability to any team exploring alternate Earths. They may require significant support and training to effectively manage their emotions and reactions in these situations.
Some coping skills and is able to manage stressful situations to some extent. However, they may require additional support or guidance in order to effectively deal with unexpected events or extremely stressful situations that may arise while exploring alternate Earths.
Some motivation and drive to achieve their goals, but may struggle to maintain focus and commitment when faced with obstacles. They may require additional support and encouragement to stay on track and fulfill their responsibilities on an exploration team.
Solid experience with cross-cultural communication and collaboration. They are able to adapt their communication style and approach to effectively engage with people from different cultures and backgrounds. They may benefit from additional training or exposure to further enhance their cross-cultural skills.
The candidate’s mental health is poor, and they may be highly vulnerable to the extreme stress and potential trauma of exploring alternate Earths. It would be inadvisable to consider them for such a high-risk job without extensive support and preparation.

As you can figure out, I’m quite pumped up about developing this shit, to the extent that I haven’t written any fiction in two days (that’s a lot for me).

Please, if you can come up with any ideas, I’d love to hear and implement them. One of the worst parts of programming for me is having built a careful architecture only to realize that a better idea will require a whole restructuring. I’ve already had to do that twice for the encounter system. So I want the best ideas first.