sophieArchive of my first #COTC devlog from itch.io
So I've started building a colony builder. That should be an easy project to knock out in two months or so. Right? Right???
My game will have an adult twist, but since the forums are intended to be all-ages spaces, I am not going to discuss the adult parts of this here. I think it is still worth writing a devlog because a lot of the implementation choices might still be of interest and there will be a large chunk of base-level mechanics that have nothing to do with the NSFW stuff.
So what did I do until now?
Choosing an engine
This was already a pretty big task. I wanted to learn a new engine since Godot has started to accept AI contributions a while ago (albeit reluctantly). Bevy seemed like a nice option - it is AI-free, the dev team seem reasonable, and I have been eyeing Rust for a while now.
Unfortunately, Bevy is still very new and it is very different from Godot. I tried to build a small prototype with it and worked on that for a few days but everything just took far too long. Bevy does not have the same amount of third-party documentation Godot does, and it often requires you to think about your game very differently (since it strictly enforces an ECS pattern). So I eventually decided to go back to Godot, with a bit of grumbling.
For a bit, I tried to use GDScript (since that is the only language that allows for web exports and itch.io really likes web games), like I did with Ratsnek, a jam game from 2023. But with its fairly loose type system, doing any sort of refactoring just tends to blow up in your face and I do not want to spend my time troubleshooting typos, so eventually I bit the bullet and switched to C#. I think that'll be the final tech stack, and by the time I will be done, maybe Godot will be able to export C# games to web. Who knows.
The game so far
In my experience, starting off your game by trying to find third-party assets that kinda-sorta fit your vision well enough for prototyping is pretty bad. I need to get to the fun stuff - for me, that's programming - relatively quickly. I could have used one of the tilesets from itch but decided to make my own programmer art because, surprisingly, it is just faster.
I can also just mock up any asset I want very quickly.
Aspects like tile size (16x16) and the color palette (a 16-color PC-98 palette) are, of course, pure placeholders and the only reason I went with pixel art to begin with is because it is a medium in which I feel more comfortable doing quick&dirty mockups. Integrating third-party assets or commissioning my own / collaborating with artists will wait until I have more solid ideas about what I actually need.
There already is some basic map generation (based on Perlin noise, scavenged from another prototype I did ages ago - never throw away your abandoned projects!) and, as you can see, the player can place buildings which will then be built by the characters.
Simon Says Build A House
By genre convention, you don't just select one of your minions and tell them to go build a house - rather, you place objects like you would in an RTS and your characters will then start building them when, y'know, they feel like it and don't have anything better to do.
The way I model this so far is through this neat little class:
using Godot;
public abstract partial class BehaviourTask : RefCounted {
public virtual TaskState State { get; protected set; } = TaskState.RUNNING;
public virtual bool NeedsRequeueOnCancel() {
return false;
}
public abstract void ActUpon(Gril gril, float delta);
public enum TaskState {
RUNNING,
FINISHED,
/// <summary>
/// needs requeue
/// </summary>
PAUSED
}
}
Instances of this class will be tossed into a global command queue. The logic for executing a task is within the BehaviourTask subclass so I can keep my mob classes reasonably lean. There will be many different kinds of tasks and putting all their logic into my mob classes would be an absolute disaster.
For the time being, idle characters just take whatever task is first in the global job queue, but of course more logic will be needed for that because of character preferences, skills and priorities. Certain tasks that are close together should also be batched. But I'll get to that when I get to it.
So far, the tasks are limited to felling trees, hauling items from A to B and building, uh, buildings. Of course, many more will follow, and on top of these global tasks, my characters will also have to take care of self-care - eating, sleeping et cetera.
Shady dithering
In the screenshot above, you can see that my bed and walls are semitransparent. Using the alpha channel here would look out of place in a limited 16-color palette! So instead I dither the furniture sprite, making every other tile transparent.
This was my first-ever shader, and I am very proud of it, even if it is very simple.
shader_type canvas_item;
void fragment() {
if ((int(UV.x / TEXTURE_PIXEL_SIZE.x) + int(UV.y / TEXTURE_PIXEL_SIZE.y)) % 2 == 0) {
COLOR = COLOR;
} else {
COLOR = vec4(0, 0, 0, 0);
}
}
Next steps
Some of the next systems I need to implement, now that the building system has a very basic implementation, is character stats. I need a robust system where character stats can be modified by status effects and items in a manner that is flexible, type-safe, robust and decently encapsulated, and I am not yet 100% sure how that will look.
Ratsnake
eric
Abigail
Badgerclops
Bubba🤠🚚🚽🌪️🖕🏜️🍺🥃🏴☠️