Big Part of my daily business is explaining people what they should code... People aren't reliable as well.
I'm sure in a few years from now nobody will code anymore and you will just tell the AI what you want to see implemented.
Same as nobody writes actual machine code anymore and everyone only uses higher languages.
Thanks for mentioning this. I will definitely check this out
Pro Tip:
Don't just watch other people doing stuff in a video and replicate it. Make your own project, think about what needs to be done and then explicitly search for answers to your questions.
Game Dev is even more about identifying tasks then it is about solving them.
I cannot explain the exact details but I remember during the first great Twitter exodus some people discovered a drawback in the ActivityPup protocol that seems to cause performance issues when very influencial users post on a small/under powered instance.
Because communicating all that stuff to many other instances is more costly than spreading it only to people on the same instance. So technically speaking large instances have a performance advantage and must just scale accordingly to the user number.
Everyone agreed that this need to change in oder to ensure a healthy federated ecosystem but I don't think it was be fixed by now.
Actually, I don't think there is a technology some could recommend that will magically boost your career. Because this will highly depends on what will be required in upcoming projects and no one can know this. So just go with whatever you want and what your interested in.
However, one skill that many technical people are missing is the ability to communicate with other people outside of their own skill spectrum. In my eyes this is the most important thing if we talking about career, because in the end the money never comes from technology it comes from humans and in many cases non technical people decide about you promotion.
So I don't think there is a blueprint for learning such skills, but I guess best thing to do would learning by doing. Go start communicating more with people outside of a technology bubble, try to organize events with other people or maybe even get politically active. Learn to know when people know what you are talking about and when not. Good example would be the use of the abbreviation LOE in your original comment. People seam not to understand what this actually should mean. Here it doesn't hurt much but doing this stuff to often when explaining a concept to a college maybe end up in false Implementation because of misalignment.
Honestly after using it for a while now it's not that bad at all :) And you can install a dock / taskbar so I have all I needed
Actually I started a Multiplayer project quite some time ago (and never finished it to this day 🥲)
The tricky part about multiplayer in godot is not handling network connection stuff because this is done by Godot itself and you do not need to know anything about TCP or UDP and this technical stuff, although it does not hurt to know some background. So Godot is utilizing something called ENet-Protocol to implement Remote-Procedure-Calls (RPC).
That means you can call functions over the network in other instances of your game running. And from this 2 tricky things emerge. The first is that you need to construct those functions in a way that they cannot be exploited, not in an cheater manner and not in a system security manner (as long as you don't have any file system access in those functions at least the security aspect should be very easy to fulfill)
The other tricky part begins when you want your network game to be played outside of a fast Local Area network (LAN) and be playable in the open world of the internet. Because not only will you be forced to provide some sort of infrastructure enabling your game instances communicating from within a players local network with another instance in another local network, additionally packet travel time is becoming significantly worst and data lost must be assumed. So you need to structure the interaction of the game instances in a way to handle this. Basically you will need to predict what will happen in clients before you will receive any a definitiv answer and then maybe addapt to this answer without the player noticing this...
The following articles I found very helpful for understanding problems some might encounter while make a multiplayer game: https://www.gabrielgambetta.com/client-server-game-architecture.html
Also this videos I think are usefull to understand the concept of RPC and Multiplayer in Godot better. Please note that a older Godot version is just in there and the syntax has slightly changed by now but the concepts remain the same: https://www.youtube.com/watch?v=d8QpnamQq1A https://www.youtube.com/watch?v=lnFN6YabFKg&t=1s
And like always the Documentation also has somthing to say about this: https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Some more tips to get you started: If you not already using it consider the Godot CLI to setup multiple instances of your game for debugging this is quite handy. https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html
And of course you could just skip all this RPC/Enet stuff and start implementing your own network calls but I don't think that this is really worth the trouble for 99.9% of the use cases.
I thought about this now for a while and the only case in which I could imagine this "no-dock" Workflow beneficial is when just using one application (or more in split screen) and not switching around much between random applications.
However this is not my Workflow since in my daily business I often need to switch From Blender to Godot, maybe have to select single project files in different directories and edit them with gimp or plain Texteditor. Then realizing I have no idea what I'm doing and try to find a solution online I could copy and paste... And many times just with one screen available because of directly working on the notebook.
I voted this up just for all the toxic irony in it. Really missed this since I'm no longer on reddit 😄
It seems that how gnome is coming in Debian 12 it is coming without a permanently visible dock. (Yes I know sounds crazy) so there was nothing wrong with the system the error probably just occurred because I (re)installed gnome-panel in an attempt to fix something that was not broken.
There is a opened feature wish for this https://github.com/LemmyNet/lemmy/issues/3071
However I think with all the other (maybe more important) stuff on the line I think it will take a while.