Lessons

I will write more about my progress in the next post, this one is for some lessons I've learned along the way.

Godot tilemaps

Tilemaps are probably the number one feature I use in the editor, most of the other stuff I write in code. After a while of playing around I learned about layers, which have been really great. Allows me to draw less sprites for overlapping things such as paths on top of grass, because I don't need separate tiles for path on grass/path on sand etc, I can just have a path tile with transparent background.

Godot signals

Signals are really handy, but sending them directly from the triggering component to the receiving component is a bit too tightly coupled for my taste. To address this problem I changed all my signals to go through a common "EventBus" node, which is near the scene root and always available for all nodes. The nodes that send the signals emit them through the EventBus node, and the nodes receiving them are listening on just the EventBus . This makes changing the scene tree much less work, because I don't need to worry about the signals. Very early on I also made the decision to only create signals and listeners through code, making them from the editor obscures them too much for my taste. From code it's clear to see which node listens to which signal and where they are sent from. I think this somewhat resembles what in web development world is called an Event-driven architecture.

Interfaces

I have always disliked inheritance. It's almost never worth the hassle, and often you might think that two things are similar enough to use inheritance, but end up with two completely different classes in the end. However often times there is a need to work on multiple kinds of objects in the same places, for example in this game there are multiple types of items, but all of them need to be rendered in the inventory. Interfaces have been really handy for this, I have had no need to use inheritance yet.

About art

When I started I knew nothing about art. I still don't. That however won't stop me from making a video game. I picked pixel art as a visual style purely because of my artistic abilities. Pixel art is a difficult genre to master, but my aim is not to master it, my aim is to make sprites that aren't too ugly for a video game. Pixel art gives me less pixels to care about, so I chose that.

I like to believe that I have already improved. My sprites aren't great yet, I think they do look a bit off still, but for now they will do. My plan is that either my art will improve as my game progresses and I will later redo my oldest sprites, or in the case I won't improve I'll perhaps pay someone to fix my sprites. I don't want to sink any money into this quite yet, so my art will do for now.

Art lessons

References, shading and less-saturated colors. These are the biggest lessons I've had this far. For shading I first used pixelorama's shading tool, but I have since moved into just selecting the color manually by adjusting the value for a bit. Makes a huge difference when compared to flat colors. In the beginning I used the "MS Paint" colors, everything saturated to the max. Not for style, but because I didn't know better. Now I've been using less saturated colors, looks much better. Asesprite's hue/saturation adjust feature is really great for shading, it allows me to select an area and adjust the saturation, value and hue for every color on that area. Really handy for easily making a bit variation to copy pasted tiles. In the picture below  is the new title screen. The trees are all just copypasted, but with their hues shifted a bit. Makes it look more alive with very little effort.

OOP BAD!

I admit it, I have not been a fan of object oriented programming in the past. In college I was taught Java so OOP was where I started, it was the default way of programming for me for quite some time.

During my career as a web dev I however learned to dislike it, even hate it. In web development you try to keep everything as stateless as possible. You keep it all in the DB, perhaps with some configuration in environment variables and that's it. HTTP is stateless, all APIs should be idempotent. Also, things that work well modeled as objects are very rare. A more functional, declarative style just works better for web development. An api endpoint is clear "pipe" that takes a request, writes or reads something in the DB and then returns something, and does nothing else.

In my short career as an amateur video game developer I've found that for video games, it's different. Everything is an object, and object is a pretty nice abstraction for all the things that we have moving on the screen. Everything has a state and we can't just confine the state to DB, the whole game is all about that state. Manipulating those states is what makes the video game work, and there's really no way around it.

-potiondev