Player promise
01Find ingredients in the wild, then make something useful with them
Exploration and cooking needed to depend on each other, not sit beside each other as separate mechanics.
All projects
Cook. Explore. Deliver.
Wilderness Chef
An AI-assisted 2D art experiment became a public cooking game with timed orders, persistent world state and a final forest feast.
I was the game designer and primary programmer, responsible for systems, UX, content integration, playtesting, trailer production and itch.io publishing.
Unity 6C#Systems designPublic beta on itch.io
Game development case studyEvion Studios2025
Role
Creator, designer & primary programmer
Systems, UX, content and publishing
Development
April–August 2025
Public beta in June
Platform
Windows
Public beta on itch.io
Engine
Unity 6 + C#
2D URP project
Scope
10 public ranks
Foraging, orders and a final feast
The starting constraint
Exploration and cooking solved each other's problems
On 7 April 2025, I set out to test whether generated images could support a consistent 2D game. The plan was one mechanic, one recording and then move on.
A friend's cooking-game suggestion gave the experiment a direction two days later. On 10 April, I merged it with Gather & Grow, a foraging prototype I had already started. Gathering gave the cooking game a world; cooking gave the gathering prototype a purpose.
The playable loop
The brief after the pivot
Production constraint
02Build a coherent 2D world without a traditional art pipeline
The art style had to remain consistent across UI, items, stations, animals and a growing map.
Finish line
03Turn an open prototype into a public game
A clear beginning and ending, reliable saves, a trailer and a downloadable build mattered more than an endless feature list.
The player promise
The loop gave every ingredient a reason to exist
At roughly 25 ingredients, the project had plenty to collect and no strong reason to keep collecting. I stopped adding content and asked a simpler question: what does the player do, and why should they care?
Forage
Read the landscape and gather renewable ingredients from plants, animals and fishing spots.
Prepare
Cut, mix, boil, bake or fry ingredients at dedicated stations.
Plate
Combine processed items into a meal that matches a live order.
Deliver
Serve before the timer expires to earn coins and advance toward the next rank.
Unlock
Ranks open recipes, stations, order capacity and new parts of the wilderness.
Feast
Reach rank 10 and cook the animals' requested feast menu.
Orders turn recipes into choices. Ranks turn orders into direction. The feast gives progression an ending.
Recipe for a game
Six decisions from experiment to release
The plan changed whenever a build exposed the next problem. The timeline shows what I chose and what changed.
Choose a development stage
7 April 2025
Start before the plan gets heavy
Starting point
A one-to-two-day visual experiment with one mechanic, one scene and a video at the end.
The call
Keep the question narrow enough to answer by building, not by planning a larger project.
Result
A character, item set and gathering prototype existed within days, which made the next idea cheap to test.
Design decisions
Four choices that kept the project focused
Clarifying progression and feedback often improved the game more than adding another feature.
Give the ingredients a purpose
01- Trade-off
- AI-generated art made each new ingredient cheap to illustrate. That exposed the real problem: more items added variety, but no reason to use them.
- Decision
- Stop adding ingredients; connect orders, ranks and area unlocks, then make the feast the final objective.
- Why it worked
- New recipes could be tied to a rank and a clear next goal instead of becoming isolated collectibles.
Make the boundary belong to the world
02- Trade-off
- Red boxes blocked locked areas clearly, but they looked like debug geometry and broke the wilderness fantasy.
- Decision
- Replace them with fog banks that clear when the required rank is reached.
- Why it worked
- The gate still communicates a limit, while the unlock now feels like the landscape opening up.
Upgrade where the consequence appears
03- Trade-off
- A map-based house upgrade screen separated the choice from the physical space it would change.
- Decision
- Drop the menu concept and move house upgrades into an interactable station in the world.
- Why it worked
- The player sees the current house, buys the upgrade and sees the change in the same place.
Animate within the art constraint
04- Trade-off
- AI-assisted sprites were consistent as still images but unreliable across conventional frame-by-frame animation.
- Decision
- Use controlled bobbing for characters and animals, then concentrate animation work on particles, station feedback and cutscenes.
- Why it worked
- The art stays consistent while animation is used where it gives the player the clearest feedback.
Under the cookbook
Dozens of dishes, shared rules
ScriptableObjects define items, recipes, meals and stations. Cooking, fishing and orders add runtime state on top of that shared content model.
63
item definitions
32
recipe definitions
57
meal definitions
9
station definitions
Counts from the current working Unity project; they are not a verified inventory of the downloadable August build.
From ingredient data to player goal
ScriptableObjects
Add content without changing the core code
Item assets define stack size, spoilage, burning and plating rules. Recipe assets define station inputs, outputs and processing time. Meal assets list the ingredients they accept.
State + persistence
Save the moving parts
Easy Save 3 provides the storage layer; each subsystem restores its own station contents, active recipes, timers, ranks and feast slots.
70% current-rank pool
Make new unlocks appear quickly
On 70% of rolls, order generation draws from the current-rank meal pool; otherwise it draws from all unlocked meals, which keeps older recipes in circulation.
The public build
From wilderness to delivery
The interface keeps the chain visible across current orders, inventory, nearby stations, the cookbook and the map.
Outside the builder's head
The system worked. The explanation did not.
I had tested the spoilage timer until it felt obvious. A friend seeing it for the first time thought food spoiled almost immediately.
Correct logic is only half the job
The timer behaved as coded, but a new player could not predict it. I used external tests to check timing, icon clarity and interaction rules before adding more polish.
“Why is my food rotting instantly?”
Earlier tests also found
- Hard-to-read sprites and animation
- Meal-order timing and pressure
- Limited inventory space and unclear plate rules
- Weak audio and interaction feedback
Making of
The experiment that refused to stay small
The making-of video shows why I changed direction, where the scope grew and how I decided to finish.
Game development case study
One public build, from first test to final feast.