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):
biomes.TOML
[[biome]]
identifier = “temperate_grassland”
name = “Temperate Grassland”
description = “A biome characterized by rolling grasslands and few trees.”
[[biome]]
identifier = “sky_islands”
name = “Sky Islands”
description = “A biome consisting of floating islands high in the sky.”
[[biome]]
identifier = “alpine”
name = “Alpine”
description = “A biome consisting of high land and some pines.”
features.TOML
[[features]]
identifier = “haunted”
name = “Haunted”
description = “a supernatural presence, allowing encounters with ghosts.”
[[features]]
identifier = “ancient_ruins”
name = “Ancient Ruins”
description = “contains the remains of an ancient civilization, with hidden treasures and traps.”
[[features]]
identifier = “unstable_geology”
name = “Unstable Geology”
description = “frequent earthquakes and volcanic activity, posing geological hazards for the team.”
[[features]]
identifier = “radioactive”
name = “Radioactive”
description = “high levels of radiation, potentially causing health problems and mutating local flora and fauna.”
exploration_zones.TOML
[[exploration_zones]]
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”]
[[exploration_zones]]
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.
The Domains of the Emperor Owl 
Pingback: Interdimensional Prophets (Game Dev) #1 – The Domains of the Emperor Owl
Pingback: Interdimensional Prophets (Game Dev) #3 – The Domains of the Emperor Owl