Hi, my name is Sebastian Kloch, and I’m the creator of this short game called Cozy Wood Chopper.

I’d like to share a few thoughts that could potentially help other devs not repeat the same mistakes (or at least learn that mistakes are part of the process).

TL;DR

Created for portfolio purposes

Almost 2 months of full-time work

About 3/8 of development time spent on the gameplay loop, the rest on safeguards, tutorials, and UI

Unity, browser build with mouse, keyboard, and touch support

Even if you don’t reach exactly what you imagined, having a goal can still get you close enough to be satisfied — with some cut corners

Making a slow game interesting is hard

Collision detection is tricky

Getting feedback is crucial for making a game understandable

A half-assed tutorial doesn’t help anyone

AI can be useful in small contexts for code generation (always reviewed)

AI is useful for providing surface-level information you didn’t know

The original motivation was to create a short game for my portfolio. During almost 8 years of professional game development, I rarely had the opportunity to work in a 3D environment with elements simulated using physics.

I developed the project over almost 2 months of full-time work. I used Unity because I wanted to try the new Unity Web platform, which allows the game to be played easily in a browser — not only on PC, but also on mobile platforms with touchscreen support. I also assumed that if someone was interested in trying the game, it would be easier for them to play instantly instead of going through the process of downloading it.

Why this type of game?

From the first time I played Monument Valley, I was charmed by its interaction with the world. Instead of just pressing buttons, you actually do things within the environment. Recently, cozy games that don’t rush the player and allow slow, relaxed play have been gaining more traction. I also noticed that I personally spend more time chilling while playing games rather than rushing to reach the next goal, so I thought I could make a game that I’d enjoy myself as well.

Instead of explaining every detail of the project (which would take a very long post, even though the game is small), I selected a few specific topics.

Take your axe and chop some wood

First, I’d like to focus on the main mechanic of the game: taking an axe from your tool belt and swinging it into a tree using the mouse or your finger on a touchscreen.

Initially, I wanted the swinging movement to be very slow. The axe should feel heavy and powerful, and the action should be relaxing. With slow movements, players should have time to think about something else or simply chill.

From the start, it turned out that making slow movement feel good is very difficult. I quickly felt far outside my comfort zone. At first, I thought it was just a matter of adding animations, but that didn’t help. To make it feel good instead of irritating, I would have needed both engaging animations and very responsive player interaction at the same time — similar to driving a jeep through mud in some simulators.

I believe it would be possible, but based on my experience and analysis, I concluded that I’d either need to make a few more games like this or spend much more time experimenting, which was far beyond the scope I set for myself. In the end, I went with a faster chopping mechanic.

I also had to give up on another idea. I wanted interacting with objects to feel like playing with toys. The axe wouldn’t be dragged from an abstract place, but would lie on the ground. The player would pick it up when needed and drop it anywhere when finished.

The first problem appeared when I introduced the chopping mechanic. The axe needed to be at the height of the trees to connect properly during a chop. After placing more trees in the level, the axe started getting blocked when I tried to move around. I had to drag it around groups of trees, which felt more annoying than fun.

To fix this, I made the axe’s collider a trigger while dragging, so the player could move it through trees. This worked well until the axe was dropped inside a tree collider. Sometimes it was gracefully pushed out, but other times it gained a lot of velocity or fell through the ground. Writing systems to handle all edge cases didn’t seem worth the time, and even if everything worked correctly, I expected weird behavior would still occasionally occur an be annoying to a player.

So I decided to make the axe return to the edge of the screen every time it was dropped. In the end, this turned out very well — the player could focus on other actions and didn’t have to remember where they left their tool 😊.

As I mentioned earlier, I used a trigger for the axe to allow it to go through trees, while still detecting collisions with a tree when a chop move is performed. Everyone who has worked with triggers in Unity knows that using them instead of full colliders comes with one annoying drawback. When an object with a trigger moves very fast — fast enough to pass completely through another object in a single frame — the trigger collision is not detected. Only fully colliding objects can reliably detect collision events when moving at very high speed.

At first, I thought I would need to create some kind of workaround (for example, making the collider longer relative to the movement direction and speed to detect everything between frames), but I also wanted to make the chopping interaction feel more responsive. I didn’t like that when you swing, your pointer-controlled axe simply clips through a tree as if it were air. I added some animations and effects to the tree prefab to show which tree was affected, but I still wasn’t satisfied.

I tried again with solid colliders, but instead of making the collider solid all the time, it stopped being a trigger only when the player moved the axe fast enough and in the right direction. This way, the player could drag the axe through trees with slow movement, but with fast movement the axe became solid and was blocked by the trees’ colliders.

It worked better than expected, because I initially thought that when the axe stopped on a tree, it would instantly become a ghost again due to its speed dropping to zero. However, by accident, I was constantly pushing the axe toward the pointer. So when the player performed a bigger swing, the axe tried to accommodate the larger distance to the pointer and moved faster, but was blocked by the trees. When the player moved the pointer in smaller swings, the axe didn’t move deeper into the trees anyway because of the shallow depth of the swings. I was very satisfied with this outcome, because I managed to kill two birds with one stone (until the first feedback was received, but more on that later).

Now, when I think about making the axe feel more like a toy and giving the player the ability to drop it on the ground, I wonder if it could potentially work if the axe floated above the trees during slow movement and moved downward when swinging. However, this could come with its own disadvantages and problems, such as having to search for the axe after forgetting where you left it. But maybe I could try it in other projects. Who knows.

We make games for others, not only for ourselves

When you work on your game for a long time, it’s easy to assume things will be obvious to players. You also get used to poorly implemented elements. A new player will instantly feel that something is wrong — and they won’t spend hours getting used to it like you did. If something is annoying, they simply won’t have fun.

This is why playtests are so important. Even though Cozy Wood Chopper can be finished in about 5 minutes, issues still appeared.

First playtest

My first tester was my brother, Kuba. He played in a browser using mouse and keyboard. One major issue he pointed out was that swinging the axe often didn’t do anything. Fortunately, he provided gameplay recordings, and I could clearly see that he moved the mouse much slower than I expected.

The solution seemed obvious: lower the minimum velocity threshold required for chopping. The downside I expected was that the axe could get stuck in trees more easily. To compensate, I considered moving the axe’s equipment position to the center of the screen. Visually, the left side looked better, but the center was easier to grab from anywhere.

However, keeping the axe on the left had one big advantage: the axe rarely moves left unintentionally when the player just wants to reposition it. Since chopping only happens when swinging left (you can rotate the camera to change world direction), moving the axe to the right turns its collider into a trigger, allowing easy repositioning.

Second playtest

My second tester was the creator of the upcoming game Keymaker (trailer — subscribe to his channel for updates). He played on a smartphone.

It quickly became clear that tutorials were a big problem, especially on touch devices. The first tutorial explained chopping, the second dragging logs, and the last camera navigation. The last tutorial wasn’t interactive and tried to teach three things at once. Once closed, there was no way to revisit it.

On PC this might have worked due to standard controls, but on mobile I used custom camera rotation with three fingers instead of two, which didn’t work well. My brother later mentioned the same issue. The tester also felt confused about what to do next — the final tutorial broke the player’s flow and didn’t clearly suggest the next action.

Honestly, the camera tutorial was half-assed on my part. I’ve never liked making tutorials, and that came back to bite me.

To fix this, I moved the camera tutorial to the beginning (popular solution in other games), split it into three parts, added a progress bar showing correct input, and allowed players to reopen the current tutorial. After the final tutorial, I showed a congratulatory message with a suggestion of what to do next.

Development Time

This wasn’t my first finished game, but I was still surprised how long the main gameplay loop took compared to everything else (tutorials, safeguards, UI).

About 3/8 of the time went into gameplay, and 5/8 into everything else. I hoped that a 5–10 minute game would require less work. The game has only two levels, yet took almost 2 months of full-time work.

The upside is that adding new levels without new mechanics could take as little as two days. Another month could result in ten more levels. The problem is that existing interactions aren’t very diverse, so content would become repetitive. That might actually work for some players — relaxing was one of my goals — but I simply ran out of time.

The scope was just large enough to prove I can build a functional 3D game from scratch. Once again, this project showed me that adding content with existing systems is much faster than introducing new mechanics. This seems obvious, but working in teams where others handled level design made it easier to forget.

Use of AI

I think it is also worth mentioning the use of AI in this project. A few lines of code were generated using ChatGPT or Gemini. At first, I planned to use this project as a learning platform and to use AI as much as possible for code generation. However, already a few days after starting development, I caught myself in the moment when I realized that I had completely forgotten about the plan to heavily use AI. After writing a few lines, I started adding incremental changes, and because I was trying to implement the chopping mechanic — which was harder than I expected — I needed to understand as much as possible of what was going on. The logic was very subtle, and another generic solution wasn’t going to cut it.

In the end, AI was useful mainly during refactoring, when there was more copy-paste work than figuring out new logic. I was pleased when AI gave me a few new ideas on how to approach the architecture. I had to go through a few iterations, but in the end the code quality improved. I usually had to guide AI through the process by copying and pasting code with a new prompt in a new chat, because when giving corrective comments, AI easily got tangled trying to merge too many ideas instead of overriding them. I used free versions of AI tools, so with paid versions you could achieve better results, but even then, some limits would still be present.

AI has a tendency to change the logic of methods. Sometimes it provides a better solution than mine, but every programmer knows that reordering lines of code can easily break everything. On other occasions, AI will remove important code. For these reasons, you obviously have to check what AI gives you. This is usually most problematic when you provide a larger class. Even if AI is focusing on a single method, it can still change something elsewhere. If you follow the Single Responsibility Principle, you should have an easier time reviewing AI-generated code. The smaller the amount of code you need to review, the smoother the process of using AI will be. This also allows you, as a programmer, to stay more hands-on and give AI more specific targets rather than general ideas of what it should do. AI performs better with smaller contexts.

Even if you don’t use code generated by AI, AI tools are great for helping bridge gaps in knowledge. I was happy when I learned about tools that had always existed but somehow I had missed over the years. I was also pushed into the territory of new algorithms — even when AI butchered the code, getting the general idea allowed me to move forward. On many occasions, I could also clearly see that a seemingly ready-to-use solution created by AI wasn’t suitable for the project, so at least I learned what I didn’t want.

Only code was touched by AI. Almost every asset was created entirely by me. The only exception was the game logo, where I used wood textures from FAB. I also tried to generate cursor icons of a hand, but after spending far more time than expected trying to persuade AI to generate a hand with a visible back, I gave up and did it myself.

So why didn’t I generate any assets using AI? For a long time, I slightly envied the fact that graphic designers can create new assets by themselves. Training takes years, and if you look at the game, you can see that my skills are basic at best. Still, I wanted to experience the process of creating assets firsthand. It was fun for me. Instead of spending time searching for ready-made assets, whenever I needed something or needed a change, I simply made it myself. Obviously, my assets are rough around the edges, but I mainly want to present myself as a programmer (and maybe a bit as a technical artist), so visuals were a lower priority.

Thank you

Thank you for reading and not giving up until the end 😃 I hope you found this dev log useful. See you in the woods, chopper.

Cozy Wood Chopper

Relax and build something out of wood.

Add Game To Collection

Status	Released
Author	kikrim
Genre	Puzzle
Tags	3D, Cozy, Relaxing, Touch-Friendly
Languages	English
Accessibility	Interactive tutorial