Post by arctictype in Musings: Who Are You Writing Code For? comments

Musings: Who Are You Writing Code For? » Comments

Viewing post in Musings: Who Are You Writing Code For? comments

Thanks for the suggestion! I need to look more at the codebase to actually see where this pattern would benefit this project. Because after an hour-ish of pondering I don't have a conclusion that's very useful.

In general, I tend to avoid Callables unless they're very simple (I use a Queue of Callables for the floating synergy text in my game). I've worked with too much clever code (including my own) that was too hard to debug or add to.

It sounds like your use case is solid. You can store Signals as variables and emit them (queue.pop_front().emit()) but it sounds like you probably want dynamic arguments so Callables sound like a great tool for your use case.

leeevans11 days ago (2 edits)

Ohh I hadn't thought of storing signals like that, that's a good tip.

You're right that too clever can smell. Too terse also, like big regexes and clever one-liners. Don't ask why I know that :)

Tough question, how to make something easy to debug and remain extensible. The Godot State Charts addon is a good example. It comes with a GUI debug control, so internally its organization is concrete enough to build tooling for. But it's also very flexible to use, I think because it's not highly abstracted from vanilla Godot.

I'd love to spend more time on tooling, speaking of writing code for myself.

arctictype11 days ago(+1)

I have been writing my own tooling because it's a good way to learn, but as I look toward actually creating finished games I'd like to look more into libraries like that. That State Chart library seems pretty cool, it's doing stuff I haven't thought of like adding editor plugins (and on a more minor note, I didn't know you could provide icons for Resources!)

itch.io

Viewing post in Musings: Who Are You Writing Code For? comments