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...

...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:

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.

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 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.

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.

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:

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:

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.

This allows to spawn large amounts of small objects at low performance cost.

It's been a long time coming, but it's finally happening:
Parkitect is launching on PlayStation 4 and 5, Xbox One and Series on July 3rd!

The regular price is USD 29.99 / 24.99€.

The port is developed by BlitWorks Games, who are known for porting and publishing console versions of indie games such as Super Meat Boy, They Are Billions, Spelunky 2 and Kingdoms and Castles.

Bringing Parkitect to consoles has been a long journey and not an easy feat. It's a big and complicated game, and apart from the technical challenges of getting the game to run at all the way the controls and UI work took a lot of thought since the PC version has clearly not been designed with gamepad controls in mind.
Thankfully BlitWorks took on the challenge and endured and we think the final result turned out really nice.

What are the differences between the console version and the PC version?

Parkitect: Deluxe Edition on consoles is roughly identical in content to the Parkitect Deluxe bundle we've got on PC, so it contains the additional campaign, rides and objects from both DLCs.
These features are missing compared to the PC version, mostly due to the restrictions of consoles:

• modding
• Steam Workshop equivalent (i.e. no sharing of ride blueprints and scenarios)
• scenario editor
• custom image banners and custom music speakers
• multiplayer mode

In return the price of the console version is lower than the PC version.

What about Nintendo Switch?

We'd really like to see Parkitect released on Nintendo Switch but it's a pretty CPU-heavy game, so performance on this platform is a big challenge.
It's not ruled out yet entirely but the chances are very slim.

Are the console controls being added to the PC version? Would that be easy to do now?

Probably no. The PC and console versions are two separate and quite different programs due to all the changes that had to be made to get the game running on consoles, plus the console version is being developed by a different company, not by us.
So it's not as easy as enabling or copying over the controls from console to PC unfortunately.

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!

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.