Devlog 0114 min read
A World Takes Shape
I want to build a forest that players have to go into, even though staying by the fire would be far more pleasant. The forest should change every night, so that even I don't know exactly what the next run will bring. In this first devlog I'll tell you how a whole world has started to grow around that idea.
Covers 19 July 2026 – 29 October 2026
It all starts with a campfire
I’ve always found something fascinating about dark forests. The same goes for old Finnish folk beliefs. That’s where the idea for Project Campfire came from: a cooperative survival horror game for 1–4 players, where the forest is much more than a backdrop. The goal is a camp that feels atmospheric, even cosy, with a fire at its heart. Around it there’s a forest you’d really rather not walk into, but have to if you ever want to find your way out.
The campfire is meant to be your most important refuge. It gives you a moment to prepare, but supplies have to be fetched from the forest and a way forward has to be found. Moving around in the dark is dangerous, and the fire must not go out. The contrast between a comfortable camp and an ominous forest is a big part of the mood I’m after.
Procedural generation fascinates me at least as much as the atmosphere of the forest. I’d like to not know exactly what the next run holds, even as the person making the game. The intention is that every run could be very different. One of the main ways to get there is that after you sleep, the forest around you is no longer the same.
Development started in July with player movement, the campfire and the passing of time. After that, the world started to grow around them. So far I’ve spent a large share of the work on the forest itself, because in the end it has to be more than scenery: it’s where you move, navigate, look for supplies and run into danger. That means the forest has to work before most of the actual game mechanics even exist.
The game is built in Unity 6 with HDRP. Right now it’s a prototype, not a finished game. Multiplayer, for example, is still only planned, even though it’s one of the game’s goals. The images in this post are development captures from Unity or Blender review renders.
A new forest every night
Campfire doesn’t have one hand-built map that stays the same from run to run. The world is generated procedurally: the game builds the terrain, trees, paths and other areas from rules and seed numbers. In the current prototype, sleeping triggers a regeneration of the surrounding world. The camp stays where it is, but the forest around it is replaced for the next day.
I want a new morning to stir up two slightly conflicting feelings. On one hand the forest is unfamiliar again, which can feel pretty hopeless. On the other, it’s hard not to wonder what you’ll find out there this time. The forest is meant to be unforgiving, and remembering yesterday’s route shouldn’t be a reliable way to survive. Getting lost is a real risk if you don’t keep track of where you’re going. Navigation aids are planned, but they aren’t meant to take away all of the danger either.
For the player, the world should feel unpredictable. For development I need almost the opposite: the same world has to be reproducible whenever I need it. If I find a bug in a particular spot in the forest, that’s not much use if the whole spot has vanished by the next test run.
That’s why the project has its own seed system. Every run has a seed number, and every in-game day has its own number. Together they let the same run and the same day be rebuilt from the same inputs. The next day gets a new world, without it becoming completely unpredictable for me as the developer.
Paths, vegetation, loot and the rest of the world’s structure also use their own separate seeds. The idea is that adding, say, a new loot roll doesn’t accidentally move every path in the forest somewhere else. The system also has slots reserved for features that will come later, such as weather and enemies. A reserved seed obviously doesn’t mean that system is done.
There’s also a checking tool for the seed system that goes through 10,000 seeds and 100 in-game days. That’s a million possible days in total, which is quite a lot of mornings for a game that doesn’t yet have finished content for every morning. The point of the check is to find odd results and seed collisions before they turn into problems for players.
The world change currently works like this: the camp is protected, the old surroundings are taken down, and the new terrain and the rest of the world are built into view. The game clock stops while this happens, so loading time doesn’t eat into the in-game day. A complete save and load system is still a separate, unfinished piece of work.
A forest needs more than trees
A map full of trees doesn’t make a forest worth exploring on its own. That’s why Campfire also has a logical map. It’s made of hexagonal tiles around the camp, and each tile has a job. Some are ordinary forest, one holds a special location, and some are places where you might find something.
The current development world has 631 hex tiles, and its more detailed core terrain is about a kilometre across. The structure of the map is decided first, and then the matching terrain and vegetation are built to be seen. So it isn’t all one giant pile of randomly scattered trees.
A path network is laid onto the map as well. With the current settings, four paths lead out of the camp, and there is always a route to the day’s special location. For places with something to find, the chance of a path connection is 75 percent, so not every interesting spot can be reached by simply following a path. The network also gets side branches and dead ends. Those took several rounds of fixes in August before the current version worked.
Once a path’s position is decided, it becomes part of the terrain. Trees are kept about two metres from the path’s centre line, and root-covered ground is added along its edges. The same seed produces the same path network again when needed.
But the paths aren’t meant to be just a safe signposting system. I want them to make navigation easier and lure you into exploring the forest, but following a path can also lead you astray, or even into a trap. You have to decide for yourself how much risk you’re willing to take. Navigation aids and path-related dangers are still being designed; the current path network is just the technical foundation for these ideas.
The first special location is a lookout tower. It has its own area of seven hex tiles, where a hand-built structure is fitted into the procedural terrain around it. In development builds the tower is currently forced right next to the camp, because being able to get to the same test spot quickly makes checking things a lot easier. The final placement rules haven’t been decided yet.
There’s also a prototype of the loot system. The map has dedicated loot spots, with tiers based on distance from the camp and rarity classes. For testing there are chests where you can pick a reward. The actual items, their amounts and the final balance haven’t been decided yet. So for now, loot is something I can describe as a system, not as a finished part of the game.
What if the player doesn’t want to turn back?
Even though the core of the hex map is limited, I don’t want the forest to end right in front of the player. Especially from the lookout tower, you should see forest and terrain stretching far towards the horizon, not a bare edge where the world stops.
The solution is a system that brings in more surroundings as the player moves. Close by is the actual game world with detailed terrain and trees. Beyond it, terrain and forest are built in 64-metre chunks, and chunks left far behind are dropped from memory. All of it still keeps the reproducibility of the seed system.
There’s no point drawing everything in full detail far away. With the current defaults, lighter image-card versions of the trees are used out to about 700 metres, and simplified terrain is visible for several kilometres. From the player’s point of view, the forest is meant to go on more or less forever. I’m not claiming a technically infinite world has been tested at every possible distance, though.
Something that turned out to be surprisingly tricky was making the same forest look the same from different distances. A spruce close by mustn’t suddenly turn into a tree of a different colour or shape when seen from far away. September and October went into a lot of work on matching the brightness, tones and silhouettes of the near and far versions. Some small differences still remain.
This ties into one of the game’s design principles: possible lighter graphics settings must not make the forest thinner and easier to see through. Trees can be drawn more roughly, but you shouldn’t be able to get rid of the cover they provide just by lowering the graphics quality.
Finding the forest’s visual style
Even if the forest works technically, it still has to look and feel like Campfire’s world. The visual style is still finding its place. At the end of September, though, the direction started to come into focus: a Nordic, slightly comic-book-like 3D look, where large shapes and clear areas of colour matter more than texturing every last detail. I want the game to have its own recognisable look, and it will surely need more fine-tuning as development goes on.
With darkness I’ve had to find the right balance. If the forest is too bright, it loses part of its purpose. If everything is black, playing turns into guesswork. The forest should feel dark and threatening while characters, trees and the shape of the land stay readable. The warm light of the campfire has its own role amid all the cold, muted green.
The mood of a dark Finnish spruce forest is the starting point, but I’m not trying to make the forest fully photorealistic. The graphic style is allowed to emphasise what matters in the game world: dense vegetation, deep shadows, clear shapes and the importance of light. I’m drawing inspiration for the game world from old Finnish folk beliefs, but how they will eventually show up in the game is still part of the development work.
A big part of this work has been crystallised in a single tree: the spruce. The first versions in the current Blender series were made at the end of September, and there have been 16 of them so far. Along the way the branches, trunk shape, bark and roots have all changed. The approved style was reached in October with version V15. So yes, I’ve spent quite a lot of time with one spruce.
There are currently two spruce variants in the forest. Near clearings the branches reach almost to the ground, but deep in the forest the lower trunk is barer, with dead branches left below the living crown. In the forest-interior version, the living crown starts about 10 metres higher. The choice isn’t random: it depends on whether there’s a clearing within about 10–13 metres of the tree.
In one test world there were 57 clearing spruces and 5,169 forest-interior spruces. So, in that world at least, there’s a lot more deep forest on offer than clearings. Because a tree’s variant is decided by the map, it also stays the same across different loading and display situations in the same world.
On 17 October, the first shared baseline for the look and lighting of the forest and the world was approved. That doesn’t mean the lighting is finished. It means there is now an agreed reference point that later changes can be compared against.
It paid off just two days later. An experiment with the shading of the distant forest floor let sunlight and bright reflections in under the dense forest. In a place that was meant to be dark, the ground started to look far too bright. The camera position and other conditions stayed the same between the experiment and the restored version, so the difference is easy to see in the slider below.
The effect was measured as well. A single ground pixel far from the camera was almost twice as bright in the rejected experiment as in the restored version. The experiment was reverted the same day, and the previously approved shading was restored. The sun, fog and forest density were not adjusted just to make the problem look smaller.
Since then, work on the forest floor has continued with needle litter, moss and smaller landforms. Some of it is already in use, but some experiments are still switched off by default.
It would be nice if the forest also ran
Performance has been one of the constant challenges. My own computer is currently one of the bottlenecks in development, and a lot of the optimisation has had to happen at the same time as the forest is still being built. On the plus side, problems get solved now instead of waiting for the end of the project.
When the world has lots of terrain and thousands of trees, performance inevitably becomes part of the development work. A view from high above the forest is a particularly good stress test, because the game has to draw a lot of things that would normally be hidden behind trees.
In October I compared two ways of drawing distant trees in the same view, from about 70 metres up. There were roughly 7,000 trees in the shot. When the more complex representation was swapped for the simpler one, the time the graphics card spent on a single frame dropped from about 166 milliseconds to 11 milliseconds. That is the GPU time for this specific comparison, not the game’s overall FPS. The new representation first looked too dark and flat, so it still needed fixing before it became the default.
GPU time per frame, same tower view
| Complex distant trees | about 166 ms |
|---|---|
| Simpler distant trees | about 11 ms |
Another problem turned up in how the world starts. Before the October optimisations, getting the world ready took about 90 seconds with the same test seeds. Part of the reason was that the system did only a little work at a time and waited for different stages to finish when it didn’t need to. By changing the order of the work, the same measurement came down to about 50 seconds. The target has been under 30 seconds, and we’re not there yet.
Building the world while moving also caused stutter. The calculation for one piece of distant terrain was sped up from about 25 milliseconds to under six, with the same result. That helps, but it doesn’t mean every frame drop while moving is gone.
Performance is still one of the unfinished parts of the project. Optimisation results also have to be compared with the same seeds, the same views and the same settings. Otherwise, mismatched FPS numbers can easily produce a very impressive chart that doesn’t actually tell you anything.
So how does all this actually get made?
AI plays a big role in how I develop this game, and I want to be open about it. Most of the code is written by AI agents. I use them to work on game mechanics design, visual direction and assets, and I judge what from the results actually makes it into the game. In Blender, an AI-generated model can serve as a reference, but the real asset meant for the game is built and finished separately.
That doesn’t mean you can make a game with one well-crafted prompt. Even things that look small go through several rounds and cross-checks. AI isn’t some miracle machine that handles everything in one go. Sometimes we go about things completely backwards and have to start over. Without AI, getting a game like this even to a playable state would probably take me years, but the amount of work has still surprised me.
Meanwhile in Blender
Alongside the Unity world, Blender keeps producing items, structures and vegetation that aren’t in the game yet. Models are made, review images are rendered, and they get fixed over several rounds if needed. Some are approved, some wait for more work. On top of that, every finished model still has to work in Unity with the right materials, scale and purpose.
On the vegetation side there are young spruces, fallen trunks, stumps and roots. On the item side, the campfire, an axe, a puukko knife, a storm lantern, lamp oil and various tin cans have been in progress, among others. Finished Blender models shouldn’t be confused with items already in the game, though. Many of them are still waiting for review or for being brought into Unity.
The sleeping bag is a good example. It has gone through seven versions in Blender, but in the game you still sleep in a temporary placeholder. A finished-looking item and an item that works in the game are not quite the same thing.
Where are we now?
In three months the project has grown into much more than a view of a forest. The day and night cycle, sleeping, the camp surviving the night, world regeneration, paths and the first special location all work in the prototype. The world can be explored, and it builds itself around the player as they move.
That still doesn’t mean the game itself is anywhere near finished as a whole. Loot still has prototype content, monsters and multiplayer are missing, and performance still needs work. The percentages on the project card are my own rough estimates, not calculated promises about when things will be done.
Right now the focus is on the forest’s vegetation and environment. More trees, plants, forest floor and natural detail are needed before the forest feels varied enough. Rocky ledges and paths running through them have also been tried out; the plan is to cover them in more detail in the next devlog. A weather system is planned, but it isn’t next on the list.
Above all, what the first months have produced is a working foundation for the world. The amount of work this game needs has surprised me, and most of the planned game is still to be made.
What I’m looking forward to most now is seeing the forest gradually come alive and feel like a world of its own. A place where it’s good to rest at the camp for a while, and where, beyond it, you can never be quite sure what’s waiting round the next bend.
world generationvegetationlightingperformance