Hectic Honey

For my third-semester study, we were tasked with programming a game as part of a group project. Hectic Honey is the result of this multi-month undertaking.

Along with my study buddy, with whom I had already worked during our Game Design lessons, we started brainstorming the idea for our project. In the end, we went with the project we already planned out as an exercise for our game design course, giving us a head start on the planning.

The idea was roughly laid out like this: A beekeeping simulator where you take care of a diverse roster of different bees that each affect each other's efficiency in interesting ways, trying to produce honey in an efficient way, searching for broken combos, expanding your bee-queendom.

As with all big projects, reality hit us later on and we had to scale back our idea to deliver a polished-looking game with interesting gameplay elements.

A panning camera

In our first discussion with our supervising professor we came to the conclusion that for the scope we were aiming for the most suitable perspective would be a top-down camera making it possible to pan around using the mouse.

Our original game design document included things like NPCs and a rich explorable world, akin to games like Schedule I, but we knew from the start this would be a too tall order for a single semester, but the resulting opportunity for input simplification didn't occur to us at first.

Coding a panning camera itself is not hard. Building a good one is. And I am ashamed to say that shortly before crossing the finish line I diluted the code a bit with lines that should have been implemented in a cleaner fashion. Despite this I think the basis of my PanningCamera3D Script is solid. If you want to use it you can view a cleaned up version here

Of course mentioning it here without a proper overview and explanation would be kind of boring, thus here are a few details I find particularly noteworthy:

The camera operates in two separate modes: Panning velocity based and panning to a target.

In the first mode the camera is moved each frame according to a 2D velocity vector, parallel to the horizon plane. This velocity can be accelerated by moving the mouse across the screen while holding down LMB or using the W, A, S and D keys. It also experiences some amount of drag each frame.

In the second mode the camera is moved towards a target position. Of course I am not just lerping the camera's position, but move the camera such that it looks directly at the given target position. This mode is used when you Alt+LMB somewhere in the scene, or you select an inventory to be opened.

Of course you can modify when exactly certain modes are used, how to switch between them and which input methods should be used for camera control.

Pathfinding bees

Godot already offers pathfinding solutions. Additionally the Godot community had published countless addons themselves. And yet for bee pathfinding I couldn't find a great implementation. The main issue lies in the pathfinding often being constrained to points on a 3D mesh, not freely inside a 3D volume.

To work around this I began coding my own path solver. This had the additional advantage of making it possible for me to optimize the pathfinding for my needs. Countless bees traveling on chaotic looking paths through the air.

At first my mind went to octtrees. Octtrees are collections of differently sized voxels that represent free volume. This makes it possible to have large uninterrupted volumes in which bees could path find freely just by flying in a straight line and smaller ones where bees could instead chain multiple free voxels together to navigate through tighter gaps. The effort of managing an octree with occasional recalculations seemed a bit excessive though.

That's why, after discussing my issue with another of my professors, I settled on a much simpler approach: I would densely distribute points around the world (or at least in the chunks where bees would reasonably fly around), connect nodes when the path between them was not obstructed and then use A pathfinding to find the shortest route from one node to another. These results could also be cached, offering a lookup table for directions to following bees, cutting the performance cost way down. Placing new obstacles would obstruct some connections between nodes, thus requiring me to backtrack what other paths and nodes relied on that connection and clearing parts of the lookup table.

To make the bees themselves look somewhat natural I coded them in a way that "springs" them towards the interpolated target point on the calculated paths.

Inventories and Items

Bees now tend to fly towards a few flowers, collect pollen and then return to their hive. Then they rid themselves of pollen and do the whole thing again. But what actually happens after a bee delivers pollen remained a question mark.

We decided on giving our beehives the ability to, over time, ferment all collected pollen inside their inventories to honeycombs. This builds on a custom Inventory class, managed by the beehive, that handles a list of items, transfers stacks between inventories and handles all other kinds of transactions. Displaying all kinds of inventories full of items was also handled by reusable scripts that populated respective control containers with item panels.

There are some instances of spaghetti code introduced over time but overall, the classes I built Item and Inventory management on top of kept it mostly readable. This also made it very simple to add further Objects with inventories, such as the centrifuge, which converts honeycombs collected from beehives to glasses of honey.

Additionally I introduced a crafting menu, found in the lab inside a shed. It reads what Items are inside the player inventory and offers crafting recipes like honey to coin, coin to flower or more complex recipes like converting a regular bee to a bumblebee using some leftover pollen.

An art style

We needed good and consistent-looking graphics for the game which were easy enough for us to make. That's why we decided on gradient texturing. If you have ever used some of Kenney's Assets you might be familiar with the way this works but essentially you use various gradients saved on a decided texture to shade your models, creating illusions of ambient occlusion and texture or just an interesting gradient spanned over a face.

Additionally I created a shader for the grass, which is essentially a toon shaded Perlin noise sampler that is roughened up with a Voronoi texture. This creates patches of differently coloured grass, breaking up the monotony of the flat one-color plane we had before. In newer versions I switched to shell-textured grass instead, which I might write about in detail another time.

I also created a glowing bubble shader for the chemicals inside the lab, putting some more life into the world. About modelling I unfortunately cannot tell you much because that was my partner's job, but he did an amazing job at it so check out the game now to explore his modelling skills as well as the gradient textures he made.

Game design pivots

Originally the game was meant to be a hectic simulator where you have to combo different kinds of bees to maximize your honey production. While this was not what we arrived at in the end I think the game would have great potential as a cutesy cosy game. This is also apparent in the way I described the game on itch.io:

Hectic Honey is a Beekeeping Simulator, in which you slowly turn your garden into a buzzing sea of flowers by producing and selling honey.

Placing flowers and taking care of your bees while seeing your garden get more and more lively really scratches an itch I can't quite pinpoint. I think if I expanded the game it would be a good idea to lean more into this sort of feeling.

I am currently considering presenting this game at the 2026 Gamescom in Cologne, Germany. Maybe I'll rework the game until then.

I'll bee back, Max.

written on 10.03.2026