From Agents to a Living Metaroom: a thought experiment

I think of metarooms as a tiny home for my creatures —a place where they can explore, play, and stay happy and healthy. 

Stocking a metaroom

 When I imagine a metaroom, I think about the physical needs of a creature:

• Food
• Fruit
• Seeds
• Environmental CA - if TWB
• Toys
• This may also include interactive critters and bugs, for more nature-focused breeds - and I've found it can make the metaroom feel more alive.
• A norn home? 

I've noticed that having a variety of objects that creatures can interact with in many different ways can help creatures' personalities come out. 

When adding resources, I also think about how they will be replenished: Will objects be vended (smart vended?), or come from a plant? And if from a plant, are they "r-type" (short-lived, like grass) or "K-type" (long-lived, like a tree)? These choices can help build in a safety net for creatures.

Don't worry too much about the player 

I don't worry too much about thrilling the player - people can enjoy a variety of aspects such as beautiful art, nostalgia, finding a secret, or watching seasonal changes in a metaroom. If the norns are well-cared for by the room, hopefully anyone I share it with will enjoy it as a habitat. 

Case study: Mushroom Forest

For example, in my Mushroom Forest (2020), I had a collection of agents.

The sharmflower, which un-grew and re-grew, produced fruit.

The feature mushroom produced food. 

The pinecone (a toy) produced seeds, similarly to Freyla's Puzzleball, and also on a timed basis.

The snail was produced automatically by an invisible nest (vendor-style again), crawled around, was fun and edible for creatures, and eventually died. 

It's not a true ecosystem - but that's ok. Independent agents are stable, but may not appear lifelike, while interdependent agents are interesting, but risky. I found the snail and feature mushroom went a long way to making the metaroom interesting to me. I'm really proud of the fact that none of the code in the Mushroom Forest is 'black-box'.

Supporting an ecosystem 

Each item in the Mushroom Forest was designed to support life, but none of them interacted with each other in an ecosystem - none of them referenced each others' classifiers for hunting each other, supporting pollination, or even noticing each other.

Even the ecosystems that came with the game were notoriously unstable - population checks were sometimes non-existent or hunters too aggressive, which could make things go wrong quickly.

It feels like it's key to support the bottom of the food web first - in previous metaroom tweaks, I have made this easier with "mother" agents (but seed banks would also be a viable option). If food items, plants and non-predator animals are abundant, any predators shouldn't need help to maintain a population. Targeting the support to the base of the food web may help the rest take care of itself.

If I were to try to make an interactive metaroom, I might start by linking just a few agents. For example, a plant could produce seeds that herbivores eat, or a predator could hunt a herbivore. Even these small interactions can make the room feel alive and give the ecosystem a sense of flow. Starting simple would let me see what works and gradually build toward a more complex, interactive environment. 

Planning for surprises

I've learned that my metaroom will never be perfectly predictable, so I try to think of ways it can recover on its own. Norns move things, players may use the metaroom in unexpected ways, and agents can glitch or disappear. Wolfling mode can also make small problems easier to notice.

Rather than aiming for a perfectly self-balanced ecosystem, I ask myself: ‘What would happen if something went wrong?’

• Seed banks, vendors, nests or 'mother' agents can help a room recover - if they target the base of the food web.
• Diversity in critters, bugs and plants (having options) gives ecosystems resilience.
• Using a variety of living strategies means not all agents fail the same way - and would allow for complex behaviours for featured/keystone critters. 

While there are more sophisticated critter tutorials these days, these strategies can be computationally expensive, and TTAR can also be used to create eating behaviours. Simpler systems can still produce interesting emergent behaviour.

Wrapping up

I don’t have all the answers, and that’s part of the fun. Designing a metaroom is as much about experimenting, noticing what happens, and enjoying the surprises as it is about planning or coding.

These are just some of the things I’ve been thinking about as I've tinkered with agents. Sometimes ideas work, sometimes they don’t—and that’s ok. The creatures, the interactions, the small emergent behaviours—that's all part of it.

For now, I’ll keep adding, observing, and seeing what emerges. Maybe someone else will try the same, or come up with something completely unexpected. That’s the beauty of these tiny worlds: they’re never finished.

Peeking inside the mind of a norn: what happens when we take parts away?

Norns are so complex, and they work (on the whole) so well that it is hard to see the function of particular parts without removing them.  

Socrates: who could not learn

An early success in removing norn functionality was Socrates, a norn  who cannot learn, but who must rely on her instincts and the player's guidance to function in the Albia of Creatures 2.  Socrates led to the breakthrough, around the time of OHSS, that the learning feature was broken, which led to the development of the Canny Norns and other genetic breeds for C2.

Instinctless: When smart norns get too smart

Conversely, the good behaviour of C3 norns has lead to some players yearning for the numbskulls of yore - leading to various experiments into instinctless creatures, such as the  No-instinct Norn by Slaterbait and instinctless norns by Amaikokonut.  What these experiments revealed is the symbiotic balance between instinct and learning. Remove instincts, and the Norn becomes a blank slate. Fascinating, maybe even rewarding to raise, but also desperately inefficient without human help - particularly when lifts are involved.

Dreams: the bridge between instinct and learning

Sleep isn't just downtime for Norns—it's an essential part of how they process and apply their instincts. According to the CAOS command DREA, dreaming is where the creature experiences the situation and the consequence while they sleep, and then another situation and consequence every five seconds, strengthening the neural network between the dream situation presented and actions held in instincts.  Norns also dream while they are waiting to hatch, so a norn who feels no need to sleep is not quite the same as a norn who has no instincts, but they should behave similarly: particularly for instincts which only switch on at adulthood.

The Combination Lobe: Where norns make up their minds

In the brain of a C3 Norn, real decision-making happens in the combination lobe. This part of the brain decides what action to take on which object—like whether to eat food or hit it. Each neuron in this lobe represents one specific action-object combination, and it fires based on a mix of inputs: the Norn’s current drives (like hunger or boredom), how close the object is, whether the object or action was recently mentioned, and even how it smells.

All these factors come together to help the creature choose the most relevant, goal-driven behaviour. It's not random—it’s a carefully weighted decision. The combination lobe is what makes a Norn’s actions feel intentional, responsive, and lifelike. The genome that came with the game constantly overwrote the combination lobe's information with new learning, which sometimes caused confusion. This was tweaked in the Creatures Full of Edits and genomes based on the CFE. Here, the new intel only adds to previously-learned information, which allows for a more average experience of food to dominate here: a weird invention that dispenses fatty goodies and pain should cause less confusion.

What We’ve Learned from What We’ve Lost

Removing parts of the Norn system—learning, instincts, sleep—is more than a curiosity. It’s been a way to understand the elegant, interconnected systems that make Norns feel alive.

• Instinct without learning gives you rigid, predictable creatures.

• Learning without instinct gives you naive, chaotic adventurers.

• No sleep? You get Norns who could know better—but don’t.
  

And without a properly functioning combination lobe, even a well-fed, well-informed Norn struggles to act. It’s here that all other systems—drive, perception, memory—are brought together and turned into meaningful decisions. Break that link, and even perfect instincts and learning can't express themselves.

Each system plays a role, and each missing part makes us appreciate the whole. Like any real organism, Norns aren’t just the sum of their parts—they're the interaction of those parts.

So whether you're raising a genius or a lovable numbskull, remember: every Norn has its place in the digital Darwinian dance. And sometimes, breaking things is the best way to understand how and why they work.

Hunger and Hunting in C3 Critters

Eating in C3 critters is a special state which allows them to keep living, and is a multi-step process beginning with low energy triggering the search, searching for food, finding food and hunting for food.

The normal logic flow in the timer script

Typically, getting food is switched on by OV00 (State) being 1, and it is the first step in the normal logic flow in the timer of most C3 critters - which typically follows this pattern:

1. increase age
2. decrease energy
3. if old enough, increase sex drive
4. drown in water - lose energy rapidly
5. if low on energy (sometimes also OR if too old) flag for death
6. if hungry flag to get food
7. if sex drive high, flag to mate
8. obstacle checking - sometimes also water-shyness
9. if flagged for death go to die subroutine
10. if flagged to get food, get food
11. if flagged to mate, mate
12. if flagged to roam, roam 

The logic flow in the timer script being arranged around two phases - first flagging, then checking the flags - is an example of a behaviour tree. This has the benefits of avoiding conflicts in behaviour, creating a predictable flow, allowing for lifelike complexity (flagging for multiple behaviours allows the system to choose between them with DOIF logic), while being performance friendly.

The gfod Subroutine: Your Critter’s Inner Forager

When it’s time to eat, the gfod (get food) subroutine takes over. It’s more than a simple “go to food” instruction—gfod is a nest of smaller routines: find, hunt, vect, anim, and move, all working together to give your critter a believable foraging pattern, while avoiding the common coding error of repeating yourself.

Let’s walk through the full food-finding journey:

Step 0.5: The Critter Gets Hungry

Every time the timer runs, the critter’s energy (OV02) drops by 1. If it falls below the hunger threshold (typically stored in another variable, OV73), the critter flags itself as needing food—and gfod is called into action.

Step 1: gfod — Search Phase Begins

This is where the critter starts searching for food:

• Temporary variables (VA47, VA48, VA49) define what kind of food it’s looking for—based on family, genus, and species. A 0 means “any”.

• If there’s already a food target saved in OV16, the critter jumps straight to hunting it with hunt.

• Otherwise, it calls the find subroutine to scout for the nearest edible object.

Bonus: Some critters, like hedgehogs, have varied diets—gfod can be expanded to look for secondary food types if the favourite isn’t found. (Just be careful they don’t accidentally target themselves if the critter is looking for its own genus in general.)

Step 2: find — Locating the Nearest Snack

In this subroutine, the critter:

• First sets up a temporary variable to hold a massive number (VA99 = 99999999) and then changes that to be the shortest distance found from a target food item (VA58).

• Scans nearby objects using esee, filtering by the desired food types.

• Calculates the squared distance to each object with the Pythagorean theorem.

• If something closer is found, it updates the new, closer target (VA58) and sets OV16 accordingly.

• If nothing is found, the critter gives up—for now—and sets the target to null before changing its direction.

Step 3: hunt — Move to Target and Eat

Once a target is locked in, the critter enters hunting mode:

• It checks that the target (OV16) is still valid and hasn't disappeared.

• It figures out the direction to move by comparing its own coordinates with the target’s, adjusting movement vectors (OV10 and OV11) accordingly.

• When it reaches the target—touching it—the critter switches its state to the next one in the main logic's behaviour tree and tells the food it’s been eaten (mesg writ OV16 12) and adjusts its own energy. (targ ownr subv ov02 ov72)

Ants behave a bit differently here: instead of eating on the spot, they pick up the food (OV18 tracks the carried food) and head back to the nest, with a message (mesg writ OV16 4) sent to the food to signal collection.

Step 4. Return to roaming

The critter reuses a little roaming behaviour after it has been hungry, got food, found food, and hunted food successfully to randomly change direction and start moving - and the behaviour tree will continue on with other activities.

Conclusion: A Background Mechanic With Quiet Complexity

While critters eating is a simple background function in Creatures 3, it's a surprisingly intricate part of what keeps critters behaving believably. From hunger detection to food targeting and pursuit, the eating system is built with clear logic, modular structure, and enough flexibility to support varied diets, differences between critters, and environmental challenges.

It’s not flashy, and it rarely calls attention to itself if it's done well—but it quietly supports the broader simulation and creates a vibrant world for creatures to live in. By using a behaviour tree model, flag-based decisions, and reusable subroutines, the developers created a system for critters that’s both efficient and extensible.

Understanding how critters eat offers a window into how even the “invisible” mechanics in Creatures 3 are carefully crafted. It’s a reminder that beneath the surface of every lifelike action is a system designed to keep the world moving.

Moving on

• For a practical coding tutorial for beginners on this topic, see Ghosthande's Hungry Critter Tutorial.

Updated Metaroom Map

Just a quick note to say that Pilla of Pilla's DS Agents has created an updated metaroom map, with 99 known metarooms on it!  This is based on a collaboration at the Creatures Wiki, the Creatures 3 and Docking Station metaroom coordinates.  Don't forget to open this page to see what the different metarooms in the map are!

Changing ATTR with DOIF

Altering ATTR with a DOIF command can be a very powerful way of governing that object's abilities when it is in the world.  The trouble is that there are so many different ways they can be combined that it is difficult to see what's going on!   The medlar uses changes in ATTR to make sure that creatures can't pick an unripe fruit, and that ripe fruit fall off the patch and allow new ones to grow. 

All the time, the BHVR is 48 - edible and pickupable, so it is only the ATTR that will change and govern how creatures interact with it - you can't mess with it if you can't see it.  It also has various physics properties at installation, which will be obeyed when the ATTR says they will.

When it is installed, the ATTR for the medlar is 80. It is invisible, and will collide with room boundaries.

80:

Invisible: Creatures don't see you - applies to ESEE and STAR on creatures, as well as internal creature code.
Suffer Collisions: Will collide with room boundaries, according to its PERM.

When the medlar achieves its ripened state by stepping through its poses, the ATTR is changed to 67.  It is visible, carryable, can be picked up by the mouse, and will collide with room boundaries. 

            doif attr eq 80
               attr 67
            endi

67:

Carryable: Can be picked up by things other than creatures, vehicles and the pointer.
Mouseable: Can be picked up by the mouse.
Suffer Collisions: Will collide with room boundaries, according to its PERM.

If it is picked (either by hand or creature), its ATTR changes to include suffering physics - being able to drop.  It will also automatically change to this, and drop, if it has been hanging around, ripe on the tree for a long time.
 
195:

Carryable: Can be picked up by things other than creatures, vehicles and the pointer.
Mouseable: Can be picked up by the mouse.
Suffer Collisions: Will collide with room boundaries, according to its PERM.
Suffer Physics: Agent falls with proper physics, including gravity, air resistance and friction. Otherwise, it simply moves with velocity. 

   doif attr eq 67
      attr 195
   endi
 

The full coding of the medlar can be seen at Garden Box Central.

More Plants in C3 and DS

So we're going to look at creating more Pinky Plants to decorate our worlds.

First things first, open the starplant.cos file in your Creatures 3 bootstrap.

As you can see, it's a fairly simple plant.  Five of them (reps 5) get moved to random locations in the Norn Terrarium, (mvto rand 1740 2740 674) and then if they're not fully grown (scrp 2 4 5 9), they grow one step, at a rate of between 1 growth step per second and 1 growth step every 4 seconds.  (tick rand 20 80) If they're pushed, they give the stimulus 62, which is... reached peak of starch smell.  Perhaps this should be changed to 84, which is played with a friendly plant.  

But, moving on, we're only going to concentrate on the installation script.  We will assume that our players will not have a modified starplant.cos file, and thus all the other scripts can be found in our players' games already.  The first thing we're going to do is get rid of the reps 5 .. repe loop.  It is essential that we have the ATTR and the BHVR the same as the original starplants.

inst
reps 5
    new: simp 2 4 5 "starplant" 10 0 100
    attr 192
*act1
    bhvr 1
    tick rand 20 80
    mvto rand 1740 2740 674
    elas 0
repe

Now for the MVTO and RAND sections, (mvto rand 1740 2740 674) which govern where the starplants grow.  In a normal MVTO command, the first number is the X-dimension, lengthways across the floor, and the second is how high.  This has three numbers because of the RAND command.  In this case, it should be read as 'move to a random x-location between 1740 and 2740, and always at the 674 y-location'.  The Ctrl-Shift-X keyboard shortcut in Docking Station can be used to make the fingertip of the hand point at what XY location it's at.  MVTO moves the top left corner of the agent to that position, even if the player can't see it.  You can see that my hand is in line with the beehives, etc. to give the rest of the pinky plant space to exist if the top leftmost part of the pinky plant is created there.  If you take the time to put the attr value through Amaikokonut's ATTR Calculator, you'll notice that it collides with floors and suffers physics, so the plant will simply fall to the ground, in a lot of locations that should all be valid.

When choosing where to put your new starplants, it's a good idea to have a notion of how big the starplant is going to grow.  Open starplant.c16 in SpriteBuilder or similar and check the dimensions of the image.  The starplant will grow to a maximum size of 64 pixels wide and 80 pixels high.

If you want precision placement as opposed to letting it fall to the floor, then it will be harder. In the grendel jungle's lift shaft, there is less space to fall about aimlessly, but it still can be done.

So, from the above, we can create a new cos file and have it contain the following:
 
inst
    new: simp 2 4 5 "starplant" 10 0 100
    attr 192
*act1
    bhvr 1
    tick rand 20 80
    mvto 1336 2457
    elas 0

Installation scripts, unlike other scripts, don't necessarily have to end with endm.

Save it into your C3 bootstrap (I called mine extrastarplant.cos) and then use the caos command line to inject it into your world.

You can keep adding different starplants at different locations in the same cos file - it has distinct possibilities for enhancing your worlds through plants.