I second that. You can also go a fair way without coding much. So you can learn the engine as you learn programming.
Also, look at some example projects. There are plenty, like a vampire survivor like. Try to understand the structure and add some very small feature.
There are also many resources online to get started. Don’t hesitate to create many small projects where you only try out a concept or idea. Godot is very composable once you know your way around, this will make things easier to move your learnings from one project to the next.
I second everything said here. I would add that C++ might be a better candidate in this case as translating Python’s OOP and Context Management would be more easily done in C++ than rust IMO. Thought it might involve a bit of template if your code heavily rely on duck typing, and you will have to get familiar with the weird move semantic of C++. Also make sure to activate ASAN and maybe UBSAN for the development phase and have an optimized build with debug symbols to run with valgrind (this is also valid if you decide to stick with C).
But if you’re already familiar in rust, pick that.
Unless you have specific platform requirements, I would avoid C for any large projects nowadays. It’s OK when learning low level stuff because it’s one of the languages with the fewest abstraction layers, but this aspect becomes a weakness at scale. And especially when porting from higher level languages.
Also, something not mentioned yet, do you actually need to move everything to C? It might be that the core of the logic is only a few function that you can more easily translate to C and then call from ctypes or a native module. So you get to discover C for 80% of the benefits and 20% of the hassle.
I like the idea of aggregating communities. Especially if the modding tools are powerful enough. This could lead to communities being essentially curated lists of other communities. Which is great for new users to discover new communities without being overwhelmed by the unordered list of communities on the instance.
Another feature that I’d like to see is an equivalent to the mastodon’s lists, a way to aggregate communities for yourself. So that you could browse the content of communities sharing a same theme in a dedicated view.
Not only organisations, but everyone really. The eldery are already massively targeted by scammers. Now, on top of that, scammers can find a child or grandchild voice sample on some social media and use that to ask for money over the phone. Or even via video call with deep fakes. And they can do that at scale.
Contrieved examples you usually see in design pattern tutorials do not properly highlight the use case and usefulness of a specific pattern.
What you did might have been fine. You only rarely need the builder design pattern.
It’s useful when the object you want to build has a complex constructor, or several ones, or you want to more easily enforce the self consistency of the created object (some languages make it hard to share initialization code) or you want to hide some internal details (I.e., you are at an API boundary and want to be able to freely change the objects your main object is composed of).
In short, Builder is a way to have a handy interface to an object constructor. It’s nice for users of a library, or if you find yourself repeating a complex constructor invocation often, but you usually do not want to have to maintain such an interface that is, at the end of the day, mostly boilerplate code.