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.

Additional behaviours for critters

 Let's revisit 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.

This is just the beginning. Potentially, richer, more lifelike behaviours could be layered in that fit the same flag → check → act model:

---

1. Sleep

• Trigger (Flag): Circadian rhythm, night-time.

• Effect: Critter becomes inactive for a while if they have no other urgent needs. (Before obstacle checking in the normal flow.) Could lower stress or reset certain behaviours.

• Note: Should not rely on "energy"; just time-based. There is the possibility for nocturnal critters as well. See C2toDS for several examples where critters pay attention to the time of day.

---

2. Environmental-related behaviour

• Trigger: Environmental variable (e.g., cold weather, or absence of heat, or seeking/avoiding water bodies).

• Effect: Move toward heat sources or huddle with others. Should be a high priority if temperature is out of survival range (with drowning behaviour). Avoiding or seeking water bodies while walking around might be treated as part of the obstacle checking.

---

3. Nesting / Territory Marking

• Trigger: Reproductive phase or roaming with high comfort stat. This might be when ready to lay an egg or mating recently completed.

• Effect: Stay in one area, mark it, or modify it if possible, for example with a nest. Ants and woodpigeons create nests.

---

4. Social Bonding / Seeking Company

• Trigger: "Loneliness" stat increases and creature is not hungry.

• Effect: Move toward friendly creatures or group zones and stay for a time (perhaps until hunger or mating drives override)

• Why it fits: Allows a secondary social layer that may encourage interaction with or imprinting on creatures. The Kyutai Whale engages in this kind of behaviour.

---

5. Play / Curiosity

• Trigger: Boredom or low-stimulation stat.

• Effect: Interact with random objects.

• Note: Helps when no high-priority flag is set. Tails and the playful interactive land critter script covers this.

---

6. Altruism

• Trigger: Being played with or a drive that builds up over time.

• Effect: Create a gift that creatures can interact with.

• Note: Rewards creatures for playing with critters. The interactive land critter with a drive script covers this.

---

Wrapping up

The default behaviour tree works for basic life-cycle simulation—but Creatures has always been about emergent complexity. The beauty of the timer script's structure is that it invites expansion and variation - if you explore the C3 agents in depth you can see a host of variations between fish and birds and land critters that I haven't even begun to touch on here.

By thinking in terms of clear triggers, thoughtful flag-setting, and responsive actions, you can add whole layers of depth without breaking the base flow. The result? Smarter, livelier, more unique agents that feel like part of a real ecosystem. 

Now that you know about "eat, mate, die", you can also go beyond it. Your critters deserve richer lives—and your worlds will be more fun for it.

Death and dying in C3 critters

 Death in C3 critters is a special state which allows them to remove themselves from the world, and is a fairly simple process beginning with low energy or rarely old age triggering a flag, creating a new detritus object, removing the original critter, and the detritus object slowly decaying, giving nutrients to the world, and rarely, being edible itself (ew).

The normal logic flow in the timer script

Typically, dying is switched on by OV00 (State) being 99, and it is an early step in the normal logic flow in the timer of most C3 critters, after some maths has been done - 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.

Death is the first thing checked for to encourage performance friendliness of the critter - there's no point it continuing on if it's scheduled for death - which allows other objects to carry on. 

Death is explicitly hardcoded in the agent's life cycle - it is best to give yourself the wiggle room of using less than or equal to 0 for the energy object variable just in case it dips below 0 (as it might if the critter falls into water andican't get out). Keep in mind that a Boolean OR expands the circumstances in which a critter may die.

 subr die_ — Detailed Breakdown

This function:

• Switches the current agent to a "dead" version (with a different genus and sprites)

• Stops its activity and animations

• Optionally shows a "death" animation

• Deletes the live agent cleanly

---

Step-by-Step Breakdown:

1. Save Current Position and Direction

setv va50 posl
setv va51 post
setv va52 ov10

• Stores the hedgehog's current x/y coordinates and direction (ov10) for later use — either to play the animation in place or reposition the death sprite.

---

2. Choose a Death Sprite Based on Age

doif ov01 gt 1000
new: simp 2 10 15 "hedgehog" 50 0 2000
else
new: simp 2 10 15 "hedgehog" 50 50 2000
endi

• Older hedgehogs get a different look than younger ones.

• new: simp creates a new agent to represent the dead body.

• 2 10 15 is the classifier for this new, "dead" object.

• "hedgehog" 50 0/50 points to different sprites within the sprite file (adult vs. youth corpse).

---

3. Set Physical Attributes

accg 2
setv ov34 24
setv ov35 27
tick 4
attr 195
aero 0

• Adjusts tick rate and physical properties to make the corpse static and inert (e.g., no air physics).

  Also sets the BASE of the object in ov34 and ov35.

---

4. Reposition the Dead Object

setv ov10 va52
setv ov61 20
setv ov01 0
doif tmvt va50 va51 <> 1
kill targ
kill ownr
endi
mvto va50 va51

• Moves the new corpse agent back to the hedgehog’s old location, and gives it the same x-direction as the live hedgehog.

• If the test move fails (tmvt ... <> 1), it kills the agent to avoid bugs.

---

5. Set Pose and Animation for Death

setv vely 0
kill ownr
anim []
doif ov10 >= 0
base ov39
anim [0 1 2 3 4]
endi
doif ov10 < 0
base ov38
anim [0 1 2 3 4]
endi

• kill ownr removes the original live hedgehog — it's replaced by the static death object.

• Animates the death sprite using either left or right "roll-up" sequences (ov38 or ov39).

• This lets the "corpse" play a final passive animation and exist in the world for a little while.

---

6. Finalise

over
retn

• over is often used to signal end of animation or processing for the agent.
• retn ends the subroutine.

---

Summary:

The die_ subroutine doesn’t just delete the hedgehog—it:

• Transitions it into a visual "dead" object

• Plays a direction-based final animation

• Handles resource cleanup and positioning

• Keeps the game world consistent (dead objects may even affect the environment later, by donating some nutrients in their timer script, or being edible, as is recommended by the Creatures Development Standards).

Roaming in C3 critters

 Roaming in C3 critters is almost considered an 'else' state after everything else is handled - it is a normal state that critters return to as a default behaviour.  But roaming isn’t just filler—it’s an integral part of the critter's behaviour tree that ensures believable, conflict-free, and performance-friendly actions.

The normal logic flow in the timer script

 Typically, roaming is switched on by OV00 (State) being 0, and it is considered the last 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 

You’ll notice roaming comes last—it’s what a critter does when it’s not busy trying to survive, eat, mate, or die. Think of it as a "what now?" behaviour that kicks in when all else is calm.

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.

Before you move

Navigating the World: How Obstacle Checking Works

In a world full of walls, slopes, water, and other creatures, critters need a way to avoid running headfirst into trouble. That’s where obstacle checking comes into the timer's logic flow—just before the critter decides what to do next, and crucially, before it performs any roaming behaviour.

Obstacle checking happens between flagging and acting. This allows the critter to alter or cancel its next intended action if something is physically in the way, preventing it from trying to move through a wall.

Direction Memory: How Critters Know Where They're Going

It's also important to understand how a critter "remembers" which direction it's trying to go in. This is usually done using two object variables:

• OV10 – Stores the left/right movement direction

• OV11 – Stores the up/down movement direction

These values help the critter maintain consistent direction between ticks of the timer script—even if it gets distracted or interrupted (say, by a curious Norn picking it up). They’re essential to making movement look fluid and purposeful.

Roaming: More Than Just Wandering

The roaming subroutine itself is built on a layered system of nested subroutines, creating lifelike complexity without chaos. The main roaming call includes:

• subr roam

  • subr vect – Picks a random direction

  • subr anim – Sets the correct walking animations based on direction

  • subr move – Applies motion using direction data

By nesting logic like this, developers avoid redundancy and reduce bugs—especially those caused by copy-pasting the same code across multiple scripts.

Interestingly, even “special” behaviours like eating or mating briefly use the roaming-related nested subroutines vect anim and move. This helps reset the critter’s motion naturally, allowing it to continue behaving in a believable way after completing a focused task.

1. subr roam: The Control Hub

At the top of the roaming behaviour stack is the roam subroutine. Think of this as the orchestrator—it's the entry point that decides whether and how the critter should move.

The roam subroutine typically does three things:

• Runs a random chance check: This is used to occasionally trigger special roaming behaviours specific to a species. For instance:

  • A hedgehog might randomly decide to burrow.

  • A grasshopper might chirp.

  • Other critters might sniff, pause, or perform ambient animations.

  These special behaviours give each critter type its own personality and make idle time feel alive.

• Changes direction occasionally: Using another random roll, the roam routine may decide to alter the creature's current path, which keeps its motion from looking too linear or mechanical. 

• Calls the three nested subroutines: Once direction and behaviour have been decided, roam hands off control to the nested logic for handling movement:

  • subr vect

  • subr anim

  • subr move

2. subr vect: Choosing a Direction

The vect subroutine is where direction gets set. This subroutine simply:

• Picks a new random direction for the critter to head toward.

Because this direction change happens at the end of a completed behaviour cycle (e.g., after eating, mating, or completing a wander loop), the shift in direction feels natural and not abrupt.

The randomness is constrained enough that it avoids chaotic zig-zagging but ensures that the critter won’t pace in a straight line until it hits a wall.

3. subr anim: Choosing the Right Animation

Now that we know where the critter wants to go, it’s time to make it look like it’s going there. That’s where anim comes in.

This subroutine:

• Selects the correct walking or movement animation based on the current direction (OV10, OV11).

• Ensures that the visual feedback matches the movement intent—a critter moving left plays a "walk left" animation, and so on.

Animations in Creatures 3 are not just eye candy—they’re essential for readability and believability.  anim ensures the visuals reflect the internal logic.

4. subr move: Making the Critter Move

Finally, move applies the logic that turns direction and intent into actual motion.

This subroutine:

• Adjusts the values of OV10 and OV11, moderating the direction based on the new vector chosen in vect.

• Calculates the velocity the critter should move at.

• Applies motion by setting the velocity directly.

Where vect decides where to go, and anim decides how it looks, move is what actually causes the critter to move on-screen.

Together, these three nested subroutines called by roam allow each creature to wander its environment convincingly, which is why they are also called in the gfod and mate subroutines.

Mating behaviour in C3 critters

Mating in C3 critters is a special state which is typically controlled by sex drive (OV21) increasing past a threshold (when they are old enough), and by a flag being set - although food is considered more important.

The normal logic flow in the timer script

 Typically, mating is switched on by OV00 (State) being 6, and it is an intermediate 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.

Mating strategies

Interestingly, some critters have male and female types (OV06 being 0 or 1) and find an opposite sex mate to impregnate (reusing some code from the hunting food behaviour, as in the hedgehog and the dragonfly), and some simply reproduce parthenogenetically (without needing to find or hunt a mate) when their reproductive drive is past a certain threshold (and they have enough energy), such as the hoppity.  Additionally, even some critters that find mates and get pregnant only use pregnancy as a binary state (pregnant or not) rather than having a gestation period.

Reproduction Step-by-Step: a Hedgehog in Love

Let’s walk through how a hedgehog goes from carefree youth to proud parent:

1. Maturity and Sex Drive

• The hedgehog ages via the ov01 counter.

• Once it passes age 1000 and enters adulthood (ov05 = 2), it starts building sex drive (ov20).

• This happens gradually, simulating the onset of reproductive maturity.

Fun detail: The "youth" hedgehog is actually removed and replaced by an adult version—a trick to avoid bounding box errors.

2. Seeking a Mate

• When sex drive (ov20) exceeds 200, the hedgehog changes state to "Find Mate" (ov00 = 2).

• It searches nearby using genus and species markers (ov47, ov48, ov49) for a compatible mate of the opposite sex.

3. Mating Process

• If a suitable mate is found, the state changes to "Mate" (ov00 = 6). If a mate is not found, the hedgehog returns to roaming behaviour. An error in this logic, fixed in the Norn Woodland Fix Patch, is that ov16 should not be set to null twice before calling the find subroutine, and that hedgehogs are curiously undiscerning of their target's gender when seeking a mate.

• The mate subroutine verifies gender compatibility and, if successful, sets the pregnancy counter (ov70 = 1) for females.

• The sex drive (ov20) is reset to 0 after mating.

4. Pregnancy and Birth

• The pregnancy counter (ov70) increases over time.

• When it exceeds 10, the hedgehog enters "Give Birth" state (ov00 = 7).

• The layg subroutine handles the birthing process, spawning new baby hoglets.

Once their part in the mating ritual is finished, the parent hedgehogs return to roaming (ov00 = 0), ready to begin the cycle again.

Key Variables for Reproduction

• ov06 – Gender: 0 = female, 1 = male

• ov00 – State:

  • 0 = Roam

  • 2 = Find Mate

  • 6 = Mate

  • 7 = Give Birth

  • 99 = Die

• ov20 – Sex drive level (increases with age and plays a role in determining when a hedgehog seeks a mate).

• ov70 – Pregnancy counter: When it’s greater than 0, the hedgehog is pregnant.

• ov01 – Age counter: When the hedgehog reaches a certain age (1000), the script starts checking for mating behaviour.

• ov16 – Target (food or mate): Used to track the hedgehog’s current mate.

• ov05 – Life stage (1 = youth, 2 = adult).

• ov02 – Energy: Used for survival but also affects mating behaviour. If low, the hedgehog seeks food.

• ov73 – Hunger threshold: If energy drops below this, the hedgehog seeks food.

Visualizing the Process:

• Roam (ov00 = 0) → Find Mate (ov00 = 2) → Mate (ov00 = 6) → Pregnancy (ov70 1-10) → Give Birth (ov00 = 7) → Roam (ov00 = 0)

This flow ensures that hedgehogs mature, seek mates, reproduce, and care for their young, all while adhering to a life cycle that mirrors natural behaviours. Note that this is laser-focused on only the reproductive cycle, and seeking food takes priority in the hedgehog's mind - it cannot search for a mate until it has first checked if it is hungry.

 Bugs 

One particularly odd case is the dragonfly, whose mating behaviour appears to be a bit of a bug—literally and figuratively. While it starts the process of finding a mate using the same targeting logic as other critters, it sometimes treats them as prey instead of a partner—approaching the intended mate only to eat them rather than complete the mating process. This quirky behaviour likely stems from overlapping use of the ov16 target variable, the fact that dragonflies hunt their own whole genus, the fact that dragonflies are more likely to be in contact with energy-draining water bodies, and a bug in state transitions, causing the dragonfly’s natural instincts to blur in a way that's more predatory than romantic. This bug is fixed in the Steam and GOG.com editions of Creatures Exodus.

Conclusion: Added realism and depth

While the mating logic in Creatures 3 operates entirely behind the scenes, it plays a fun and crucial role in making the ecosystem feel alive, real and self-sustaining. It’s not something players typically see directly—but it quietly governs when critters reproduce, how they prioritise needs, and how population dynamics shift over time, such as when a norn develops a taste for hedgehogs.

At the heart of this system is a behaviour tree structure: a two-phase loop where the critter first flags possible actions based on internal variables (like hunger or sex drive), and then acts based on priority. This design avoids conflicting behaviours, keeps things running efficiently, and allows complex decision-making to emerge from relatively simple rules.

This kind of background scripting, although largely hidden from view, adds realism and complexity to your creatures’ world—creating behaviours that feel organic, even when driven by simple variables and checking a list of possible states.

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.

Researchers trained an AI model to ‘think’ like a baby, and it suddenly excelled

Shutterstock

Susan Hespos, Western Sydney University

In a world rife with opposing views, let’s draw attention to something we can all agree on: if I show you my pen, and then hide it behind my back, my pen still exists – even though you can’t see it anymore. We can all agree it still exists, and probably has the same shape and colour it did before it went behind my back. This is just common sense.

These common-sense laws of the physical world are universally understood by humans. Even two-month-old infants share this understanding. But scientists are still puzzled by some aspects of how we achieve this fundamental understanding. And we’ve yet to build a computer that can rival the common-sense abilities of a typically developing infant.

New research by Luis Piloto and colleagues at Princeton University – which I’m reviewing for an article in Nature Human Behaviour – takes a step towards filling this gap. The researchers created a deep-learning artificial intelligence (AI) system that acquired an understanding of some common-sense laws of the physical world.

The findings will help build better computer models that simulate the human mind, by approaching a task with the same assumptions as an infant.

Childish behaviour

Typically, AI models start with a blank slate and are trained on data with many different examples, from which the model constructs knowledge. But research on infants suggests this is not what babies do. Instead of building knowledge from scratch, infants start with some principled expectations about objects.

For instance, they expect if they attend to an object that is then hidden behind another object, the first object will continue to exist. This is a core assumption that starts them off in the right direction. Their knowledge then becomes more refined with time and experience.

The exciting finding by Piloto and colleagues is that a deep-learning AI system modelled on what babies do, outperforms a system that begins with a blank slate and tries to learn based on experience alone.

Cube slides and balls into walls

The researchers compared both approaches. In the blank-slate version, the AI model was given several visual animations of objects. In some examples, a cube would slide down a ramp. In others, a ball bounced into a wall.

The model detected patterns from the various animations, and was then tested on its ability to predict outcomes with new visual animations of objects. This performance was compared to a model that had “principled expectations” built in before it experienced any visual animations.

These principles were based on the expectations infants have about how objects behave and interact. For example, infants expect two objects should not pass through one another.

If you show an infant a magic trick where you violate this expectation, they can detect the magic. They reveal this knowledge by looking significantly longer at events with unexpected, or “magic” outcomes, compared to events where the outcomes are expected.

Infants also expect an object should not be able to just blink in and out of existence. They can detect when this expectation is violated as well.

Infants can detect when objects seem to defy the basic laws governing the physical world. Shutterstock

Piloto and colleagues found the deep-learning model that started with a blank slate did a good job, but the model based on object-centred coding inspired by infant cognition did significantly better.

The latter model could more accurately predict how an object would move, was more successful at applying the expectations to new animations, and learned from a smaller set of examples (for example, it managed this after the equivalent of 28 hours of video).

An innate understanding?

It’s clear learning through time and experience is important, but it isn’t the whole story. This research by Piloto and colleagues is contributing insight to the age-old question of what may be innate in humans, and what may be learned.

Beyond that, it’s defining new boundaries for what role perceptual data can play when it comes to artificial systems acquiring knowledge. And it also shows how studies on babies can contribute to building better AI systems that simulate the human mind.

Susan Hespos, Psychology Department at Northwestern University Evanston, Illinois, USA and Professor of Infant Studies at MARCS Institute, Western Sydney University

This article is republished from The Conversation under a Creative Commons license. Read the original article.