at this rate you’ll be a pro in no time!

the OST is out (it has lyrics)! www.youtube.com/playlist?lis...

this system is streamlined enough that i could easily create the entire settings menu dynamically without having to manually drag modules in, and the only reason i don't is because i want to have a degree of control over what it looks like. i'm really happy with it!! :) (9/9)

adding a new setting to the game takes these steps:
1) add name and default value to the default config
2) add a localisation entry
3) add the appropriate type of module to a settings section
4) fill in the module string ID in the editor (and allowed values for complex modules)
5) profit!!
(8/9)

config: this part is dependent on what module we're dealing with, so each type has custom code. here's the one for checkboxes for example! the config handler takes care of sanitisation, and will not break the game or save a non-valid config if the ID is wrong (7/9)

the localisation file formats all module names as SETTINGS_{SectionID}_{ModuleID}, making it easily automatable (6/9)

localisation: godot localises most labels/strings upon initialisation, but needs a push when the locale changes during a node's existence. i connect each module to a signal i emit whenever i change a setting. this does result in some unnecessary calls, but it makes adding settings MUCH easier (5/9)

all modules reside within container-based scenes called sections, which correspond to the individual sections in the config file. this will make the menus look organised while also allowing me to fetch the section name for interaction with the config and localisations (4/9)

here comes the fancy stuff, the settings menu! it works quite simply on a one-variable basis; adding a setting to the menu involves slapping in a pre-made module and giving it an appropriate string ID. it will automatically fetch localisation, config, and change the config upon interaction (3/9)

the system handles two separate .cfg files, a default one stored inside the project and a custom one in the user folder. both are loaded at start, but the custom one is only filled with lines overwriting the default one, not a full copy. this helps with futureproofing a lot! (2/9)

that's gorgeous!!

it depends, for a game with a lot of small instances of damage (hack&slash, action rpg...), i would consider 4 or 13, for one with a few instances (turn-based...) i'd test out 1 or 6. i would even consider combining them, with a tame style for small hits and a flashy one for a special attack or crit

hi, i’m a czech dev, would love to get added!

hey! :) i'm making an ordered list of the blocks, then setting up a tween for each block, first applying an interval that gets progressively longer for each, and then tweening the position. here's the relevant code! TimeDelay increases with each block, Distance and FallTime are constant

thank you!! the game's called A Hard Dairy's Work, and it's gonna be a turn-based puzzle game about herding farm animals :)