You can get a lot of fun things to do because the game is already started, and you can have fun modifying things.

Without having to worry about how to organize the project structure and create the game from the ground up.

Modding is one of the funnest and fastest ways to get real stuff happening in response to your programming, especially if you are new to programming.

i also avoided signals while prototyping ... but keep in mind that signals allow you to make the components that work with different node trees ... check this link for more guidance i've made my card game from scratch, only used jquery because of lots of cross browser issues that existed at the time (8 years ago). gotta say it takes a lot of work and it's not easy at all but u do learn a ton

while trying to come up with simple solutions to the game mechanics you end up understanding why some patterns exist and how they are facing each problem.

yes, I know the benefits of signals :) That is one of the many reasons why I advocate people to use them They just aren't what I need for my specific game

lots of basically proc gen means I don't design my levels in the editor (technically it isn't proc gen but it has the same effect) for example

yeah procedural gen is in state of the art in all frameworks i've seem... it's harde cuz each game has it's own specifics and it's almost impossible to create a tool that will work on most cases

yea, so instead I am structuring my code more like how you would structure a React program. Nodes have no way of calling up the tree or to the side by default. What they do have is a way to accept a lambda which they can use to throw stuff up/sideways. However, they can only do that if the parent actually gives them this lambda. (Which is generally spoken required)

having this strict rules also means that C#'s Event system is kinda useless as there is always at most 1 node that can listen to events, so that is why I am using lambda's instead of Events/Signals 😅

Signals also have the drawback of only being able to transmit stuff that extends Godot.Object, which rules out quite a bit for me

i've never seem someone using react premisse on a game before. it feels a bit wrong cuz react (in browser) kinda gathers all DOM manipulation and resolves it in a single (and heavy) render function.

i see how their architecture can be adapted to a game implementation, but it will change quite a lot

sure, but I use it to explain how my nodes interact with each other 😅

not so much how stuff actually ends up being rendered

a parent has basically full control over its children while children can only interact with the parent through functions provided by said parent siblings don't even know about each others existence

also, ideally a parent can only see its direct children. However, I am a bit lax on that rule as sometimes Godot forces me to put a node in the way to make things look good rather than for actual code reasons. In which case, I don't mind skipping that bad

(Also, my editor breaks these rules, A LOT. Its on the list to rewrite though 😅 )

that makes sense ... i just goggled some react games and apart from the very simple ones, all the others are using a canvas element. kinda throws all jsx on the garbage, so it fells like using a drilling machine to drive a nail.

yea, no don't use React to make games 🤣

but the node separation makes a lot of sense

Do use its rules on how nodes (or components as React calls it) can interact with each other

those rules are nice

I do wish I had access to a FnOnce kind of type though. Would make my callback system even nicer as I then could enforce that a callback can only be called once before it needs to get a new one

but alas, no borrowchecker in F# :(

And, Diahborne, this conversation is a great example why programming can be hard, if you are designing something instead of just modding. 🙃

So many decisions LOL.

yep

ah okay

My brother is learning programming, and he's pretty great at logic.