Some of you may have seen my first release earlier today, Buttered Sausage. If you haven’t, check it out - it’s a Result object pattern for consistent error handling. But right now, I’m here to talk about my next project: Dingus.
Yes, really. Because every project needs a resource manager with a ridiculous name.
The blended transform animation problem in Buttered Sausage is not forgotten. But I have hit a dead end and need a fresh perspective. The solution will come when I least expect it. Working on Dingus is a much needed distraction after the marathon sprint to Buttered Sausage 1.0.
What is Dingus?
It’s a Godot 4.5+ plugin for managing custom resources with disk persistence and UID tracking. Think contact management where each contact can have associated photos. Or character sheets with equipment. Library resources, disk resources, proper UID handling throughout.
Dingus is part of the AWOC (Avatar Wardrobe Organizer and Colorer) ecosystem. I am extracting systems from AWOC one at a time so I can focus on each one in a controlled way. This not only helps me keep dependencies wrapped up and concerns separated, but for example, in the case of Buttered Sausage, it went from a simple toast and menu system to a fully configurable animation, result, and toast package. I’m hoping to give some other components the same treatment. Something about standing on its own helps drive robustness.
But here’s the twist: More than just code you can download, Dingus is about documenting the journey.
Why does code always look so polished on YouTube? Those developers have skills I’ll never possess, right?
Not true. Before any code makes it to YouTube, there was some programmer banging away at their keyboard at 3:00 in the morning, tracking down frustrating bugs, celebrating small victories, carefully planning the next move or just throwing code at the wall to see what sticks.
I’m documenting that messy process in real-time. Including the false starts. The dead ends. The “wait, I was wrong about that” moments.
Example: Today I killed a class called ResourceReference. It has been a part of the AWOC ecosystem since the very beginning. Held a moment of silence. Two hours later, I brought it back to life because I realized why it was actually needed. That whole journey - the reasoning, the reversal, the final hybrid design - is documented in the repo.
What you’ll find:
- Main branch: README + DECISIONS.txt (the design journey document)
- Develop branch: The actual code, starting from raw AWOC extraction
- DECISIONS.txt: Chronicles every decision, including ResourceReference’s death and resurrection, UID performance analysis, manager architecture evolution, and more
- Git history: Will document the transformation with descriptive commits
I’m not suggesting my way is better or worse. It’s just A way, and I’m inviting you to watch it unfold with full transparency. You might gain insight. Or maybe you’ll just enjoy watching someone figure things out in real-time.
What I’m hoping for: If you’re interested in design decisions, architectural thinking, or just want to see what development actually looks like behind the polished tutorials, give it a look. Feedback welcome, especially during these early formative decisions.
But if you just want a resource management system like I described above, just give me a little while. I’ll turn it into something you can actually use as quickly as possible.
Edit: Forgot to mention that AWOC lives on the develop branch. Main branch is empty until AWOC 1.0.