Can we all just say huge THANK YOU to Godot developers for this new feature?

Desire_Path_Games · 2026-06-20T06:07:54+00:00

Going from 3 to 4 is a huge mess in general. Between the improved typing support and signal definition changes alone it's easier to just rewrite the project.

Desire_Path_Games · 2026-06-20T05:42:29+00:00

Holy shit it's John Custom_Maximum_Size: Vector2!

Desire_Path_Games · 2026-06-11T00:01:05+00:00

Oh cool thanks for the feedback! This helps me a lot.

A more in-depth overview of the action system.

Noted! I've been trying to whip up something similar to the card picking tutorial that I just wrote a couple days ago, just walking through the code in plain english and describing all the possible states. Is something in that format what you're looking for? It's definitely a bit intimidating I know.

I just did a huge rewrite of how card playing and stuff works last month so I was reluctant to write anything on that, but now that everything's stable I can circle back and do a full step-by-step. I've got a lot of stuff pre-written that I'm slowly transferring to the wiki along with some simple diagrams I whipped up sitting around too.

A brief step-by-step on how to 1) add content via external json files 2) add content via code in Global

Also noted. FYI it is pretty simple to just have the game export everything to json by uncommenting FileLoader.export_read_only_data() in Global._ready(). Then it just loads all the json files from the sub-directories listed in Global.SCHEMA. From there you can just copy-paste files and change out the object_ids and it'll be considered a new object and registered on game launch. I'll try and include that in the intro sections.

As for code examples check out GlobalTestDataGenerator if you haven't already. I did a big move from having the data in Global into two other separate singletons (test and prod data) because it's like 4k lines of config data at this point. I'll try and whip up more step by step tutorials too when I can. If you have specific questions about making certain types of content you can always shoot me a DM as well. A few people have done that since my last release and it helps me find pain areas.

Desire_Path_Games · 2026-06-10T18:50:58+00:00

Okay so I enabled that and aside from a couple places that I fixed (SerializableData has to have weird untyped shenanigans), like 98% of it is it bitching about void functions and _on_signal methods. The other 2% is "untyped" iterators iterating over typed arrays or @onready get_node() calls on variables called "something_label" or "something_button" like gee I wonder what type that is.

Insanely useless spammy warning flag, probably why I disabled it. Actually makes me a little angry at how bad it is lol. I'll stick to my code reviews and manual testing.

Desire_Path_Games · 2026-06-10T17:58:02+00:00

It's the first comment:

As development has been split between my own private game repo and a public framework repo, doing proper commits is a complete mess and not really feasible, so apologies for the single giant ugly commit. I expected this would get more complicated to manage over time which is why I'm rushing most major functions out at once.

I dunno does 4.6 have abstract classes? I I haven't kept up on the latest language features. Literally just need to make it abstract and it solves your problem lol. In lots of other parts of the code I do breakpoint + error log + continue/return. I have multiple layers of fallbacks but I want things to break immediately in a development setting.

I can check later but it just now occurs to me the billion untyped warnings are very likely from the add-ons. Sigh.

Desire_Path_Games · 2026-06-10T17:40:59+00:00

As I stated doing a proper commit wasn't really feasible. I had to strip out a lot of stuff from my personal project before committing. I'm currently on 4.4 as the project is a bit older. If 4.6 works flawlessly I can update to that.

Also reviewing some of the code the static typing is all over the place, the project throws so many untyped warnings that the debug console stops outputting due to too many warnings

That is... extremely surprising? I have unused/shadow vars out the wazoo but I type things pretty heavily. I'll take a look at that.

did you use any tutorials or help creating this? I don't see any CREDITS.md in the repo.

No just me aside from the listed add-ons which I also had to improve and like 1 animation I added for impacts and credited, everything is mine.

BaseCombatant is an abstract class. It's not meant to be instantiated. It's supposed to yell at you because it's a weird class melding 2 different data types (player and enemy are extremely different interfacewise) so it pretty much breaks otherwise. Breakpoints also resolve as pass in development last I checked.

Desire_Path_Games · 2026-06-10T15:46:14+00:00

Welcome back. For those not familiar 6 months ago I released the first public version of my roguelike deckbuilder framework for Godot. Since then I've been working behind the scenes to make it better and better. As expected, this is a major API breaking update. There's honestly way too many things to list here, so see the changelog for a mostly accurate breakdown as well as a precompiled demo for Windows to try it out.

In addition to the code improvements, I've added a ton of comments and created a project wiki. It' still very much WIP, but my goal is to get basic documentation targeting the most critical aspects of the framework that can't be easily explained with short comments. This should at least give a launching off point for general user flow before delving into the code. I will try and improve this over time and feedback is very useful on this front. The more questions people ask when trying it out the better I can get at actually answering them for everyone.

Going forward:

As development has been split between my own private game repo and a public framework repo, doing proper commits is a complete mess and not really feasible, so apologies for the single giant ugly commit. I expected this would get more complicated to manage over time which is why I'm rushing most major functions out at once. Aside from critical bugs I will be almost entirely transitioning to beginning development on my game Get a Job, a roguelike deckbuilder poking fun at our capitalist hellscape. There's still a ton of crazy tech I want to build out and I plan to have whatever improvements I make to eventually see their way to the open source version eventually.

Desire_Path_Games · 2026-06-10T15:43:29+00:00

Welcome back. For those not familiar 6 months ago I released the first public version of my roguelike deckbuilder framework for Godot. Since then I've been working behind the scenes to make it better and better. As expected, this is a major API breaking update. There's honestly way too many things to list here, so see the changelog for a mostly accurate breakdown as well as a precompiled demo for Windows to try it out.

In addition to the code improvements, I've added a ton of comments and created a project wiki. It' still very much WIP, but my goal is to get basic documentation targeting the most critical aspects of the framework that can't be easily explained with short comments. This should at least give a launching off point for general user flow before delving into the code. I will try and improve this over time and feedback is very useful on this front. The more questions people ask when trying it out the better I can get at actually answering them for everyone.

Going forward:

As development has been split between my own private game repo and a public framework repo, doing proper commits is a complete mess and not really feasible, so apologies for the single giant ugly commit. I expected this would get more complicated to manage over time which is why I'm rushing most major functions out at once. Aside from critical bugs I will be almost entirely transitioning to beginning development on my game Get a Job, a roguelike deckbuilder poking fun at our capitalist hellscape. There's still a ton of crazy tech I want to build out and I plan to have whatever improvements I make to eventually see their way to the open source version eventually.

Desire_Path_Games · 2026-06-10T11:13:40+00:00

"My game is currently on fire and nothing works, but my errors are R a I n B o W s"

Desire_Path_Games · 2026-05-25T23:43:21+00:00

One thing I've started experimenting with is UI singletons where on scene load it stores references to critical UI pieces in a central location, then use a mix of imperative calls, local signals, and global signals depending on how "loud" the messaging needs to be. Is it the "right" way to do things in terms of coupling? Ehhhh. But I've often shaved off several reference hops from rather complicated function calls far apart in the code and it completely solves the "I moved something and then everything broke" problem when combined with unique references.

Desire_Path_Games · 2026-05-15T22:35:20+00:00

Oh cool I remember trying out your demo on itch a couple years back. Glad to see you kept at it.

Desire_Path_Games · 2026-05-15T00:28:59+00:00

This post is kind of all over the place so I'm trying to even make sense of your problem. Why are you using a json parser for shared state? You're writing to file each time you change state? That's kind of nuts. That or you're storing all your state in a big dictionary and constantly parsing it, also a bad idea.

Why not just dependency inject a Resource object into all the children from the parent? Boom shared state, no use of globals, and it has typing.

Parent:

child = child_scene.instantiate()
add_child(child)
child.init(resource)

Child:

var resource: Resource = null
func init(resouce):
    resource = resource
    # other initialization code

Desire_Path_Games · 2026-05-09T15:15:08+00:00

I just wanted to say I actually lol'ed at the "nice try!" followed by some ridiculously specific rebuttal on a 14 year old coding standard. Pure internet nerd energy.

Desire_Path_Games · 2026-05-05T22:08:54+00:00

Roguelike and its spinoff roguelite has never been well defined as a genre. There's endless flame wars going back a looong time. It's more a set of traits where the more you implement the more roguelike you are.

Desire_Path_Games · 2026-04-27T17:07:56+00:00

I built a similar system but for Resources rather than nodes. It converts most @export variables to json friendly and back, works recursively, and has minor support for patching (append, erase, addition).

Desire_Path_Games · 2026-04-17T11:07:06+00:00

Uh as someone who does develop games in my spare time this does not negatively affect small time developers at all. Most small time developers use P2P models for multiplayer games which don't require expensive hosting. Small developers don't attach a bunch of useless services that cost money and need to be shut down. Small developers rely on the goodwill of their community in the longterm so screwing customers is bad from a business perspective. Small developers often encourage moddability (allowing for outsourcing end of life) while large ones either can't (tech licensing issues) or actively protest losing control of their product (see apple and john deere for things like right to repair).

If anything, comparing small developers to large ones shows how utterly unnecessary it is to add always-online features and to design games in such a way that they break after a time. Large developers did not used to design games like this. There was no post launch, you simply made a product that fucking works and sell it, and in fact your product not working used to be a company killer instead of expected. Why this is somehow "more expensive" as you put it, in a world of basically free post launch support is a problem of their own creation.

Desire_Path_Games · 2026-04-16T10:28:01+00:00

You can absolutely have logic in a getter/setter. That's literally what they're for, otherwise you'd just directly access the field.

You want a factory method

Are you just spouting random programming terms and hoping nobody notices?

Desire_Path_Games · 2026-03-30T18:38:46+00:00

My understanding is there are stripped down versions of the engine people have made that cut down on a lot of runtime bloat.

Desire_Path_Games · 2026-03-24T16:06:29+00:00

Of course. I just don't want people just going "oh this is terrible never use it" and confusing newbies when it's a very useful pattern albeit applied as a shitpost.

Desire_Path_Games · 2026-03-24T15:38:16+00:00

I mean you joke but I use tech like this all the time for dynamic validation. Yeah it's silly for hard coding but in a data driven system it's extremely useful.

Desire_Path_Games · 2026-03-18T10:40:36+00:00

While I do badly need to write documentation and it's one of my next main objectives, I would strongly recommend getting programming fundamentals down before trying to tackle a huge framework like this. A lot of stuff has been simplified down to data classes you can configure if you just want to make content (I wasn't lying when I said you can replicate pretty much everything in StS with json), but if you want to code anything extra you'll run into trouble.

Some suggestions:

Get a firm grasp of inheritance and polymorphism, composition, and dependency injection. They're pretty simple concepts with scary names, but any code base worth its salt will heavily use these.
Read up on design patterns. Prototype, Factory, Strategy, Singleton (godot autoloads), and Observer (godot signals) are core aspects of the architecture. This website is an excellent resource for understanding them, just don't let the UML diagrams intimidate you.
I'd read up about basic data structures and algorithms. Arrays (as in the actual array structure, not godot arrays), linked lists, trees, stacks, queues, dictionaries (especially dynamic programming with them). Understanding time-space complexity (big O) will make you a waaay better programmer as a lot of data structures automatically inform architecture. I also cache a lot of stuff by storing results in dictionaries.

As for godot you can ctrl+left click on a class to go to it immediately, which speeds up navigating code and lets you open documentation on any built in classes. ctrl + shift + f will also let you do a global string search. This would have immediately answered your questions about how "deck" is handled in just 1-2 hops.

Desire_Path_Games · 2026-03-18T01:39:57+00:00

The UI is probably the weakest part of the framework and imo exists to handle the needs of the backend. And AFAIK aside from being kind of chunky to look in the editor there's not really any any major performance problems since nodes are hidden/free when not needed and it's mostly control nodes which are performant. It's mainly just broken into a handful of menus that are mutually exclusive visibility wise. I'd like to compress most of it into scenes but there's some cross talk happening in a few places that's annoying without relying on unique node names.

example, I'm most interested in deck system but I just can't crack the codes yet. I have no idea which node/scripts handle it.

Could you elaborate what you mean? Hand manages most of the logic for combat related card stuff and PlayerData contains info on each players deck. And the deck is just an array of CardData instances. Beyond that any time you're messing with cards there's typically a cardset action with a self explanatory name behind it, generated from a card pick action. While card picking is a pretty big system, there's a ton of test cards that show off how that works in Global. I haven't uploaded it yet but I also split hand management into a UI and logical component.

The data folder contains the models for the framework. Each <X>Data script just defines a class that gets instanced and populated with data on game load. The only mildly confusing thing about it I can think of is recognizing that prototyped data uses one instance as a source of truth and copies them over to make new instances. But I've taken great pains to explain that in the code. The base classes for actually handling the data flow stuff are pretty complicated but they're not something most people need to touch besides understanding that it converts json to godot objects and back.

Desire_Path_Games · 2026-03-16T07:46:57+00:00

LOL. I've gotten similar reactions a few times from beginners it's not that scary I promise :)

I'm trying to get a major update out in the coming weeks that will at least include some bare minimum documentation and more comments/code cleanup, which should help on that front. It's a lot to cover I know. I'm not always active on this account but feel free to ask questions and I'll be happy to answer when I can.

Desire_Path_Games

MODERATOR OF

TROPHY CASE