Aster Pebble - Devlog 00

Aster Pebble - Devlog 00

We are so excited to finally start work on our first fully fledged open source game, Aster Pebble and the Case of Bad Bureaucracy.

This game will be a lovely little pixel art point and click where you play as Aster Pebble to solve some mysteries and right some wrongs.

The story is based on an unused TTRPG campaign we had written in the past, but still really wanted to get out into the world. With a few tweaks and changes, we felt it would work great as a point and click mystery, so here we are.

Today we'll talk a little bit about setting up our project, challenges with resolution, dynamically outlining interactables, animation challenges, translation support setup, and the start of a slick collapsible UI.

So let's dive right in.

Project Setup

We're using Godot for this project. Since we work with Godot a lot, we've set up a sort of starter project template that we usually use as a base. This template has things like our license files, project folder structure, branding elements, and useful generic scripts.

So with that ready to go, we just clone that repo and set it up to be used for this project. Which really is just replacing "project name" with "Aster Pebble and the Case of Bad Bureaucracy" in a number of places.

Right now the game's repo is private, but once we release the game it will be available on Codeberg as open source.

With that all squared away we're ready to get started!

Game Resolution

This was our first real hurdle to get over.

We want a pixel art game, which tends to have a pretty low resolution. For ours, we decided to go with 240x135 for most scenes.

So we slapped together some temp art to use as a starting point.

That's looking nice and pixel-y.

The problem is that we also want to have a really crisp UI layer for easy readability, and you definitely can't do that at our chosen pixel art resolution.

We ran into a number of small issues getting this working. If you're interested in the more technical explanation, you can look at our previous devlog article for a breakdown on that.

But after an afternoon of trial and error, and too many web searches, we got it working.

It was a daunting unknown going into the project and it's a big relief to have it solved.

Dynamic Outlines

One thing we knew we wanted from the start was to have the ability to outline interactables in the game. Interactables would include things like people, objects, or things to comment on.

Now, we could do this by having each asset have an accompanying outline sprite, but that's way too time consuming (and kinda lame). We also would like to ensure this colour is clear for as many of our players as possible, meaning we'd prefer users to be able to override it for accessibility.

So we want something dynamic.

Luckily, we found a lovely CC0 shader that we could work with.

https://godotshaders.com/shader/2d-outline-inline/

This worked well, but it was in an always active state. We want it so that it to only activates when hovered over.

So in the shader, we added a new parameter called "enabled" at the top, and then updated the end of the fragment block to check if enabled is true, like so:

Which then could enabled or disabled with simple Area2D mouse over and mouse exit events:

Things are looking good! Let's just add in the animated sprites and . . . oh.

Oh no.

That's just the worst. What's going on? Why is it shifting in place?

After a bit of troubleshooting and investigation, we believed this was because the UV coordinates are not specific to the part of the sprite sheet being rendered. So we'd need to update the shader to understand how many frames we have in the sprite sheet and look at each individually and . . .

CC0 smiles upon us again because the author of the original outline shader also has one for animated sprites.

https://godotshaders.com/shader/2d-outline-inline-configured-for-sprite-sheets/

Another simple but important mechanic sorted for now.

Translation Setup

Since our projects are open source, setting them up in a way that is easy for people to take it and add to it on their own is pretty important to us.

Even though we don't necessarily plan on including translations ourselves with our current budget, we want that capability to still be available for others.

So we looked towards setting up our text in CSVs first, which we had experimented with before for Godot translations. This was immediately ugly.

I don't know about you, but having string IDs on buttons isn't the most friendly thing to work with. It would be nice to keep our buttons 1:1 with what the intended text was. And using plain text IDs can work, but will be an issue if we ever use the same string with different contexts.

We're going to have a lot of text in our game, so we need to figure out early how we can make these any better, versus just throwing hundreds of lines into a massive csv file and hoping for the best.

So we took another look at Godot's translations documentation, and came across the gettext PO file based approach. This handles things a lot nicer for the text in scenes, and even the text in source code.

But even more so, the po files can be edited in tools like poedit, which is actually made for and supports translation work.

Even better, we learned that in Godot, you can immediately preview a given language for a scene, to test out how your UI/etc. looks while editing. We can even override the locale in the project settings as workaround, until we get our settings menu updated to support selecting a locale.

So after testing it out, we were sold, and switched over to that method for the rest of the project.

Collapsible UI

We have one more minor thing to wrap up today.

As we know, screen real estate is a pretty important thing, so we were concerned about the UI feeling really cluttered if the inventory was on the screen the whole time.

We'd like to keep it small and efficient, but still wanted users to be able to hide or minimize it when not in use, so they can focus on the scenes at hand.

So we set out to work on a toggleable inventory.

We wanted to go with a smooth transition to avoid it feeling too jarring when opening or closing. So we created "shrink" and "grow" animations which simply animated the "custom minimum size" property of the top UI. For our temporary setup, we had a few of the inner components with non-zero minimum sizes but with a few adjustments we got this to work as intended.

It's good to have some of these small but important steps behind us.

Until next time, keep creating good.

---

Want early access to some of our videos, devlogs, in-development builds, and other content? Consider joining our Patreon!

Note that just like our game jam entries and other projects, this game will be open sourced upon release.

As this is a larger project, you will be able to purchase the game to get it pre-built and help support us and future open source work, or directly grab the source code and assets following their open source licenses.

💜 Love open source projects?

Here are ways you can support us making them!

https://wanderingdoorgames.obviousgain.ca/supportUs