Building Smarter Mushroom Picker AI with a Finite State Machine | Devlog Ep. 3

A Day in the Life of a Mushroom Picker 🍄

Imagine this: you’re peacefully wandering through a forest, eyes peeled for mushrooms. You spot one, march confidently toward it, and just as you’re about to pick it—something rustles in the bushes. Instantly, you forget everything. No more mushroom. Just pure, unfiltered curiosity.

Congratulations! You’ve just experienced the mind of one of my AI mushroom pickers.

Hey everyone, it’s From QC With Game Dev, and today we’re diving into how I built the little digital brains that power my mushroom-obsessed NPCs. More specifically, how I designed a finite state machine (FSM) to manage their behavior.

🍄 What’s Going On Inside a Mushroom Picker’s Head

In computer science terms, a finite state machine is a way of defining a set of states—like looking for mushrooms, walking to mushrooms, or investigating distractions—and the rules that determine when and how you move from one to another.

I’d actually done something similar before while building the UI for my earlier game Gobara, but that approach ended up being one giant plate of spaghetti code. Everything was crammed into a single dictionary that mapped all transitions, and—spoiler alert—it got real messy, real fast.

This time, I wanted to do better. I decided that each state should be responsible for its own transitions. No more master list of chaos. Each state now knows when it should exit, what should trigger the next state, and how to handle events in between.

🧠 Building the FSM

At the core, I’ve got a base state class. Every state in my mushroom picker’s brain extends it. Each one implements a few key functions:

• Enter() — what happens when the state starts (like beginning to look for mushrooms)

• Exit() — any cleanup that needs to happen before leaving

• HandleEvent() — the fun part, where the state reacts to whatever happens next

That HandleEvent function is where all the personality comes in—it lets each state decide how to respond to events in its own way. If something interesting happens (like a sound in the forest), the picker can tell the FSM to switch to a different state entirely.

🧺 Giving the Picker Some Brains and Legs

Each state also defines which controllers it needs. For example, the LookingForMushroomsState uses a NavMeshPickerMover to actually walk around the map and a visual perception controller to spot mushrooms.

But as you can imagine, passing all these dependencies around quickly made my constructors look like the world’s worst grocery list. So I built a services provider, a handy central class that holds all shared services and hands them out to states as needed. That change made my code cleaner, easier to maintain, and much more modular.

🗺️ Navigation, but Make It Foresty

To handle movement, I used Unity’s NavMesh system. Each mushroom picker has a NavMeshAgent component that lets them wander naturally through the forest while avoiding obstacles. I can assign random points on the NavMesh for them to patrol, look around, and of course—hunt for mushrooms.

And that’s pretty much how my mushroom pickers learned to live their simple, distracted little lives. They’re curious, they’re forgetful, and they’re absolutely terrible at staying on task—but honestly, that’s half the fun.

Next time, I’ll be giving them a few more tricks to make them feel alive (and maybe a better attention span). Until then, watch out for rustling bushes—you never know who’s investigating.