This post is about a few different aspects regarding how the game is being rendered. It's mostly technical but I figured it might still be interesting to see behind the scenes a bit. We're using Unity as the engine for this game. A game engine is a piece of software that provides various features for you, such as systems for animations, the UI, or how things get drawn (rendered). This brings a bunch of benefits for game developers - creating all of this yourself is a big non-trivial task, so using an existing engine can save a lot of time. Plus if it's an engine that's already been used by many other games that probably means it comes with many helpful features have been proven to work well. On the other hand, using something that has been created by others to work across a wide variety of games can also mean that despite being adaptable to your needs it's probably not going to be a 100% perfect match. If you need a feature to work slightly differently you might be out of luck, especially if it's an engine like Unity where you can't change the source code yourself. Also, since the features were designed to work for many different purposes and to have as few limitations as possible, they are probably doing things that you never need, or are doing things in a way that aren't necessarily the most optimal performance-wise for your specific game. This is why we're not using many of Unitys default features and are developing our own solutions instead. One big area where we're doing a lot of custom work is rendering. You might think: why are you even using Unity then, couldn't you just make your own engine? We're still using many lower-level Unity features such as the graphics API abstractions; how assets are being loaded; and being able to deploy to many different platforms is great. So while we're not using some big parts of it the remaining parts still save us a lot of time. I also want to point out that this is not supposed to be a "Unity is bad" post. When we decide to not use a Unity feature it's usually not because what Unity has is not good, but because we have some needs that other games might not have, or we might want to have more control over what's going on so we can do some slightly unusual things. Also Unity is constantly changing too - some of the things we have developed ourselves they have added in similar form in the meantime as well, so if were restarting development on this game today then the decision to develop some things ourselves might look differently.

Frustum culling

You don't want to tell the graphics card to render things that aren't visible on screen, so you need to check if your object would be visible or not. Unity does this on the CPU, which can have some benefits. For the type of games that we're making that's not great though, because:

• we have lots of objects (e.g. a single house is not "one object" but created from hundreds of individual pieces). Checking them individually one after another is slow.
• our games are more CPU-intense than most. Simulating all the little people running around needs to happen on the CPU, so ideally we want to avoid keeping it busy with other tasks as much as we can.

So we're doing this on the GPU instead. This is great because GPUs can easily do these visibility checks for many objects in parallel, and since we're not going for AAA graphics we can afford moving some tasks to the GPU.

LOD

Usually it's a good idea to draw things that are appearing tiny on screen at a lower level of detail. Unity unfortunately doesn't have a tool to automatically generate lower level of detail versions of your objects (it looks like they're adding one soon though). Building these manually is a mind-numbing task, and while there are some commercial tools for creating them automatically the ones we found are either super expensive or not very good, so we built this ourselves.

Postprocessing

Postprocessing layers effects on top of the rendered image, which can change the look of the game quite significantly. Here's a look at some of our most important postprocessing effects.

Forest shadows

We want to give the feeling that the town is located in a clearing somewhere deep within an ancient, dense forest. To emphasize this we gradually darken anything outside the area you can build in. It's essentially the same as a distance fog effect, just using the distance to the playable area instead of the distance to the camera. Apart from looking nice this effect has the additional benefits of making it a bit more clear where you can't build, and it nicely hides the seam that would otherwise be visible where our terrain ends.
Left: effect off; right: effect on

Volumetric light rays

These light rays add a lot to the atmosphere of the scene. They are ray marched. We tried a few ways to fake them with geometry which would be cheaper performance-wise but it didn't give us results we were satisfied with. This effect only appears at the edge of the playing area. It would be a bit distracting if it appeared everywhere.
Left: effect off; right: effect on

Voxel AO/GI

This one seemed a bit crazy to do, but it's working really well. Nice lighting is one of the most important things for making a game look good. In games with predesigned levels it's achieved by doing some heavy pre-calculations that can take many hours to complete. In our games the players place all of the objects, so we can't pre-calculate anything. To still get nice lighting in Parkitect we used screen space ambient occlusion (SSAO), which is an effect that tries to darken areas that less directly exposed to light. There can be some artifacts such as some flickering when objects disappear or dark halos around objects where it doesn't make much sense but overall it works reasonably well. I've been keeping an eye on better methods for the past few years and one called Voxel Cone Tracing was looking quite promising, so we tried building something based on that for Croakwood. This article gives a pretty good overview for the technical details, but in short, we first create a voxel representation of our scene. This means rendering any contributing object a second time (at a lower LOD level) in a special way, which gives us this slightly Minecraft-looking version of the world:
This can then be used to fairly efficiently calculate ambient occlusion and color bounces:
Ambient occlusion
Color bounce Here's a comparison how this looks in-game with the effect turned on/disabled:
Left: effect off; right: effect on We think the AO we get from this looks nicer and more "correct" than SSAO, without any of its artifacts. Additionally we get a light color bounce along with the AO more or less for free, as a sort of very basic GI approximation. Some open areas for improvements that we still want to investigate is doing more light bounces, and using the voxel representation for real-time reflections on shiny materials. Another benefit that's quite specific to our game is that it allows us to still get AO from objects that aren't visible, which is quite nice when looking into a building. Note how in this example the roof is hidden, but you still get a color gradient on the wall in the corner where the roof would be:

[ 2025-04-10 09:29:39 CET ] [ Original post ]

A big part of Croakwood is providing cozy little houses that your frog villagers can live and work in, so let's take a look at how the houses work! All of the buildings are created from individual pieces, so every wall, furniture item and decorative object is an individual object that you can place. This is a system that's similar to the one we used in our previous game, Parkitect. We really like that it allows a lot of creative freedom while still ensuring that houses a pretty quick and easy to design due some restrictions on what you can and can't do. Paths, walls and furniture objects are locked to a grid so they always fit together nicely, and to make sure that things the frogs need to interact with are accessible. Purely decorative objects like lamps or potted plants can be placed freely.
One somewhat annoying thing with the building pieces in Parkitect were doors and windows. In Parkitect the doors and windows were part of the wall piece, so for each wall style we had to add special wall pieces with holes cut out for doors and windows, or alternatively there were doors and windows that you could stick onto the wall, but they would just sit on top of it without creating a hole. We couldn't figure out a better solution at the time, but now for Croakwood we came up with a way of putting holes into walls using shaders. This gives you more freedom for placing doors and windows and we have to create fewer building pieces, which is a nice win-win.
Most objects can be recolored. One challenge we faced there is that the art style of Croakwood is somewhat textured, whereas Parkitect was mostly using flat colors which made recoloring easy. Figuring out how to do this for textured objects took some time, but we eventually came up with something that works quite nicely.
It took a few tries to figure out how to do this but wasn't too difficult in the end. Our first approach was to create our textures in grayscale and then multiply in the custom colors, which gave pretty flat results because it doesn't allow for any variations in color value. We divide our textures into different sections that should be recolorable and pick one of the most prominent colors in that section as its "base color". Then we generate a new texture where each pixel contains the delta in Oklab color space from its original color to the base color.
Left to right: texture; base color sections; delta texture in Oklab color space To apply the customized colors we submit the chosen custom color for each section to the shader, add the L/a/b values from the delta texture to it and convert back to RGB. This gives pretty nice results even if pixels in a section have color values that are very different from the base color. Also our artists can simply create their textures in the way they are used to without having to do anything special to make a texture recolorable.
Of course houses can also be saved and shared, so you won't have to design a complete new house every time. We're storing them in PNGs again since that worked quite nice :) Objects have resource costs, so once they are placed construction materials arrive and the builder frog constructs the objects to make them useable.
Once the house is complete you can always peak inside and see what its inhabitants are up to :)
Figuring out which objects to hide when peeking into a house is a bit tricky. We don't want to obscure the view of anything important, but also want to show as much of the inside as possible and not unnecessarily hide things that could stay visible. We tried a few different approaches for this but what worked the best in the end was to simply check if the bounds of an object are in front of the volume defined by the paths of the currently viewed floor. This alone would result in a lot of "visual noise" when rotating the camera caused by individual objects appearing and disappearing which doesn't feel very nice, so we're grouping nearby objects together and then decide the visibility for the whole group, so that we're always changing the visibility of a larger chunk of the building at once where possible.

[ 2025-02-07 13:24:26 CET ] [ Original post ]

In a game about frogs you kind of need to have water, which means you need to program a water shader. A shader is basically a short program that calculates what color a pixel should receive. To me as a programmer they can be somewhat intimidating to create - you need to write some code that, somehow, produces something that matches a certain artistic vision. Whenever I'm working on a shader I find that oftentimes the result looks terrible for a long time until eventually a tiny change is made and suddenly everything looks great, but figuring out what tiny change is required can be a long process of trying lots of different things. Oftentimes it's also not clear from the start what the artistic vision is, especially when the art style of the rest of the game is still evolving, but you have to start somewhere. So one of our first tests around late 2021 for the water looked like this:
We liked the reflections and the wavy outlines around the edges of the water, but it felt like it was still missing something. Eventually Marve came up with this concept art for the fishing hut:
This concept is really more about the the objects for the fishing hut, but it still gave us a some direction for what the water could look and "feel" like. Over the next few years we kept making small tweaks to the water shader until eventually arriving at the current version, which looks like this:
This is what I meant at the start of this post - from a technical point of view this is really not all too different from the very first version we had, there's just some tweaks to the color, the transparency, the width and shape of the outlines, and some "smaller" additions like the ripples from the fish and other things swimming in the water, but with all of these things together it eventually looks good. We'll surely keep making more small changes but for now we're quite happy with how it looks.

Shorelines

I couldn't find a lot about how other games are doing their water, so I wanted to give a bit of technical insight into how we're doing ours. Probably the easiest approach for this kind of effect is the version we used in Parkitect, which looks like this:
This is being created by checking if the distance from the water surface to the depth in the depth buffer is below a certain threshold. It's very easy to do and quite cheap performance-wise, but you can't do a wave movement animation towards the shore and it can look as if the effect is painted onto the objects inside the water (because it essentially is; the effect can not extend beyond the geometry of the objects inside the water, so you can also only ever see it on the side that's facing the camera, not all around the object). In Croakwood we went for a slightly more complex approach. We're placing an orthographic camera that's looking straight down just above the water surface to get a texture that contains the outlines of anything intersecting the water surface. Here's an example with the generated outline texture on the right:
To be able to distinguish what type of shore it is we render the terrain into the green color channel and anything else into the red color channel (we do this so that we can give the wave effect a different movement direction and slightly different look depending on whether it's around the terrain or an object). Then for every pixel in this outline texture we calculate the distance to the nearest shoreline pixel which can be done really fast on the GPU as explained in this excellent article.
Signed Distance Field generated for the shoreline effect (the version on the right is just a different visualization to better understand what's going on) And that's all we need to know where the shoreline effect should appear! They work for objects of any shape, fully surround them and nicely combine if there are multiple nearby objects.

Waves

The waves created by swimming frogs and fish look like they might be fairly complex, but it's surprisingly just a couple dozen lines of code in a compute shader. This article and this video explain it better than I could.

[ 2024-11-12 12:50:57 CET ] [ Original post ]

In this post our art director and concept artist Marve gives some insights into her thoughts on the setting of the game and some of the influences for the art direction.

Mood

We decided pretty early on we want to keep the overall style semi-realistic and not wander too far into fantasy. From earlier conversations we referenced story-book like elements a lot, and its still one of our guiding elements in various design choices. The story-book feel is reflected in the vibrant color scheme, stylized light and extra warm shadows, to really emphasize this almost dream-like warm summer day. The perfect time for frogs to be active! Most importantly, there is no human involvement in our world. You wont encounter any stray tin cans or bottle caps. We really wanted to keep the forest and all the natural elements very untouched and wild. In a way the forest is a character on its own. The light won't reach under thicker forest nooks which creates a much more cool and mysterious atmosphere. The frogs will be discovering their surroundings alongside the players, it's supposed to be a bit secretive and unpredictable. The trees and mushrooms grow too tall, the trails can lead to unknown locations and various strange creatures can cross your path.
To help along with the immersion we found it very important to have a direct reference to scale. Seeing familiar plants, mushrooms and trees are really nice ways to grasp how small our frogs are. Also, there's something so charming about imagining such a village existing in a massive forest you have walked in.
Early concept art exploring different ideas for biomes Our world is set at a temperate climate with plenty of greenery and rain but nothing too tropical or desert dry. This helps narrow down the selection of flora and fauna we add to the environment. With some creative freedom, a lot of it is reflected in the building materials, furniture, the clothes frogs wear and symbols they use in their arts and crafts. Anyone who's had the chance to spend a lot of time in nature as a child might feel right at home here. A small yard or a garden used to feel like a massive playground, a whole forest would be filled with endless possibilities and mysteries. We want to give you this feeling of being close to the ground, where bugs and snails roam around under leaves and grass blades and the sunrays peek through the leaves.

Influences

These are some of our main influences for the mood and look:
Midsummer, Djamila Knopf This painting from Djamila Knopf has that specific feeling of wonder and warmth that reminds you of the carefree and quiet summers of childhood. There's so much magic and playfulness here and it always fills you with a sense of home. This is what we want Croakwood to feel like - warm, welcoming and a little bit dream-like. Another huge influence here has been Arrietty, the movie by Studio Ghibli. Aside from the dollhouse furniture and borrowed human items, one of the most charming parts is how the tea poured in a mug behaves, it's so delightfully weird, thick and viscous; nothing like we're used to seeing. Small details like that help so much with pushing the believability.
Because we do not have humans living in our world, the focus for Croakwood is more on natural elements the frogs can use to craft their tools, workshops and houses. In addition, Alexandre Diboine has his amazing world of Saltenpepper, which also has influenced the art direction quite a bit. The way he handles shapes and textures is very close to what were aiming for.
Tiny Garlic Shop, Alexandre Zedig Diboine Small beings living among massive plants and vegetables; a lot of furniture and house designs are a direct reference to the environment around them; how large an actual garlic is in that space and how big and chunky the rolled up leaves are in the background - all of this pushes the believably and makes it much easier to imagine how it might be like to live in this world.

Setting

Croakwoods main location for the frogs is an open and light filled meadow in the middle of large ancient forest, a space lush with various flowers, mushrooms, shrubs and building materials taken straight from the environment. There's a lot you can show with how the materials are used and the textures and detail density, for example how the wood grain would be a lot more bloated and the grooves and cracks will be more visible. Large pinecone makes an excellent material for some roof shingles. Tree bark is sturdy enough to build up walls and fences. And pine needles make a great rustic looking thatched roof. Our frogs are also a bit chaotic and fun loving creatures, they might not always follow the most convenient building regulations. Patchwork of various materials make great little cottages. They can be very resourceful with what materials they use and how they build their houses.
Some of the first concepts for frog houses The grid system and modular nature of the construction pieces do create some limitations, but weve been working hard to add plenty of variety in fun materials and elements to make this world extra cozy and alive.
Towns in Croakwood are meant to look like natural parts of the environment, everything is carefully and lovingly handcrafted by the villagers themselves. Also, the frogs coexist with the forest and its inhabitants - all the resources they make can provide for more than just for the town. Perhaps you could use some to trade in exchange of a secret or as an offering for a mischievous forest spirit?

[ 2024-09-12 09:12:49 CET ] [ Original post ]

In a game about building frog towns the frogs are unsurprisingly pretty important. Here's a look at how they developed over time and what we had in mind while working on them. First of all, as with everything else, figuring out their look took some time and we went through some revisions. The first try was a more biologically accurate version with the eyes on the side of the head. When viewed from the front the model looked like a perfectly fine frog, but in game it was a bit weird...
Left: first test version. Right: an updated version to fix some of the issues with it (but not quite the final version yet) ...especially when viewed from a more top-down camera, as you'll oftentimes see them in the game:
The positioning of the eyes made them look kinda angry from this camera view, so we changed this by moving the eyes more to the front. The head shape was also changed so you're more likely so see their "chin", which makes their default appearance look a bit more as if they are smiling. To give them some individuality there's a bunch of different patterns and colors they can have. Here's a small selection:
To make the frogs feel more alive we gave them the ability to look around freely:
We can mark objects in the game as "interesting to look at" to have some control over where they are looking, but they can also simply look at some random unspecific point somewhere in front of them. Apart from making them more interesting to watch it feels really good to see the frogs actively looking at the nice town you've built for them as they wander around They can also react to things happening around them and express their current mood. Here's some of the animations we have for that:
We have some ideas for how to push this a bit further to be a bit more readable and noticeable, but this is something we still need to work on. One problem we had is that the frogs have pretty long feet and whenever they stood on stairs or sloped terrain the feet would clip into the ground and disappear entirely:
Not very nice! So we improved it by moving the feet out of the ground using IK:

[ 2024-08-09 14:12:08 CET ] [ Original post ]

Where do you even start developing a game? There's so many things you need to work on at the same time. A good starting point probably is the terrain and general environment, so let's take a look at how that developed. As with any feature, it starts very simple. Over time we get a better idea for what exactly we need and we keep iterating to improve and expand. Since we knew it would be a grid-based game again our starting point was the Parkitect terrain. The main challenge is that you have to be able to build paths and buildings on the terrain, which means the terrain can't be too bumpy, but we still wanted it to look somewhat smooth and natural.
First Croakwood terrain tests, ~early 2022 What we came up with is not too different from Parkitects terrain actually - it's secretly still using the same blocky slopes that work well for putting paths on them, but then we add a bunch more polygons to it, smoothen it using ideas from Bezier surfaces and add a bit of random bumpiness.
This creates the problem of the bumps in the terrain clipping through the paths...
...which we can solve by flattening the terrain wherever a path is.
Another technical challenge we had to solve was that our terrain could only be a single big rectangle initially, but we wanted to create maps that are very irregularly shaped sprawling woods, with little pockets where you can build.
Big rectangular terrain, ~mid 2022 Creating this kind of playable space inside a big rectangle would mean there'd be a lot of wasted space, which is bad for performance. We solved it by splitting up the terrain into lots of small rectangles that can be created wherever we want, which allows us to give the map a much more freeform shape.
And since the terrain was more detailed than Parkitects we also had to add a system for reducing details in far-away areas.
Terrain chunks with different levels of detail Finally, to make the terrain look more interesting we added a way to paint it with a bunch of different textures.
To decorate the terrain even more we wanted a way to place lots of objects on it, for example blades of grass. Figuring out a fitting style for the grass took some iterations. Especially early on we didn't fully know what the game was going to look like yet, so the first version was more of a technical test:
Early grass test, ~late 2021 Eventually we figured out that having a nice transition between the terrain texture and the grass is really important for it to look good. On the technical side, the key to achieving this was to give the grass the same normals as the terrain to make everything look less messy, and to fade its color towards the terrain texture at the bottom. Here's a test where they blend together more nicely:
Better fitting grass, ~mid 2022 And finally it received some more texture to reach the current state. In addition to the grass there's a couple of other objects that can be spammed across the terrain.
This is getting quite technical now, but there were a few questions that stumped us for a while:

• how do you store grass in the savegame? Obviously you can't store the position of each individual blade of grass, that'd be way too much data
• how do you even keep the grass in memory? Keeping hundreds of thousands of positions for the grass blades on a huge map in memory would be too much

The answers came from a great video on the grass in Ghost of Tsushima: you create a low-resolution density map that says how much grass should be in an area, then when that area becomes visible you generate the data you need for the grass instances (i.e. the position, rotation, which mesh to use) - we do this in a compute shader, so it's super fast. When the area goes invisible you can unload all that instance data. So all you ever need to have in memory is what's visible, and all you need to store in the savegame is the low-resolution density map.
Density map debug view This allows to spawn large amounts of small objects at low performance cost.

[ 2024-07-08 08:30:58 CET ] [ Original post ]

Whew! Feels good to finally have this game announced and be able to talk about it Seeing all the reactions to the announcement trailer was incredibly thrilling, and we're all very happy that people seem to be quite excited about it and sent so many nice comments. You never know - obviously we think this game is cool, but it's very hard to judge if anyone else thinks so as well before actually showing the game. So this is very reassuring! With that, let's continue where the previous blog series left off and properly start the Croakwood devlog. We have been working on this game since late 2020 roughly and still have a lot of work ahead of us before release. So, there's lots of stuff to talk about that's already been done, and then over time we'll catch up with what's going on recently. Obviously we did end up deciding to make a town building game, despite the prototyping attempts chronicled in the previous blog series only having mediocre success. How did this happen? The conclusion from our previous attempts was that if we want to make a town builder, it should be somewhat unique gameplay-wise, with some mechanics that are more interesting than just plopping down buildings and waiting. Additionally, it should have a somewhat unique setting - everyone has already seen a dozen medieval or futuristic town building games, so doing something else seemed more interesting with a bigger chance to stand out from the crowd. The answer to the gameplay question should have been obvious after making Parkitect, but it really took creating all these other prototypes to find it: what if you could design the houses in the town yourself? What if decorating the town nicely had some impact on gameplay, like in Parkitect? Surely there must be some other town builders out there that are a mix between management and creativity/decorating but it's certainly not the norm, so that immediately seemed like it could be a good idea. Plus we'd get to apply a bunch of stuff we learned from Parkitect to it! And so we created one more town builder prototype, and since it would share a lot of gameplay mechanics with Parkitect... we simply took Parkitect and turned that into the prototype! Here's how that looked: It's not much but it had all of the core elements that are part of Croakwood: houses you can design yourself; villagers doing various jobs; resources getting created and transported around. This seemed promising and convinced us to keep going!
All that was left to figure out was a setting then. We thought a "miniature scale" world would be fun and interesting, so we started looking around for a fitting concept artist... and found Marve, who had lots of concepts of cozy house interiors and miniature scale towns in her portfolio, and was interested in doing some concept art for us!
(Not Croakwood concept art. This is something Marve had made before and is one of the pieces that caught our attention) She came up with a first concept to determine the rough setting, style and mood of the game:
And she also tried a few ideas for the villagers, of which we all liked the frogs the most.



... and she's been working on an endless stream of concept art ever since . As it turns out there's lots of objects to design if you want to fill an entire frog village. Which also means there's lots of objects to model! It was more than Garret could possibly handle alone, and we were lucky once again to find Kindra, who has not only been tirelessly trying to keep up with the concept art but also designed plenty of additional objects.
Abby originally joined us for animating all of the activities the frogs get up to, but she has also done a lot of work on shading and lighting and is currently working on concept art for additional characters.
And to make the team introduction complete, we have the same team members you might remember from Parkitect: Garret is mainly doing 3D art once again, Sebastian and Patrick are handling the programming, and Jada is taking care of production and game design tasks. Of course while there's more people around now we're still a pretty small team, so it's not unusual for anyone to do some other tasks outside their main expertise. Finally, anything regarding sound and music is handled by the great team at A Shell in the Pit again and the Croakwood logo was designed by Colby Nichols, who also created the Texel Raptor logo.

[ 2024-06-14 17:56:18 CET ] [ Original post ]