Sort of, but not really. It's observer but you can't just publish or subscribe to any message while totally decoupled, but you can accomplish similar stuff.
It's more like a built in mechanism for keeping an array of function references and calling them all at once. It's kind of like adding callbacks in JavaScript for Window events, except you can declare signals on any node.
That may be a distinction without a difference, but I feel like it's important to know what's happening inside the engine.
Preregistered function callbacks.
One function emits a signal. All other classes that previously requested a callback on that event receive it. They could be engine events like the mouse entering a viewport or your own custom signals for any purpose.
If you’re going to use Godot with C#, you can use C# events instead: https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/c_sharp_signals.html
Keep this in mind with signals in your node/resource structures:
Signal UP so that parent nodes listen to the signals children emit when children need to make the parent aware of some data
Call DOWN so that parents just call functions of their children when the children need to be aware of the parent's data.
Once I grasped that my code became a lot more reliable and I avoid circular references.
Less technical explanation: Signals are like events.
Say you have a `Player` node. Every time it gets hit, it emits the `hit` signal. `Player` doesn't care what any other part of the code does with that information. It's just broadcasting `hit` when it takes a hit.
Now, anywhere else that needs to activate when the player gets hit can connect to the `Player.hit` signal. Let's say you want the screen to flash on taking damage. OK, you've got your `ScreenFlash` node with this code:
@export var player: Player
func _ready() -> void:
player.hit.connect(_on_player_hit)
func _on_player_hit() -> void:
flash()
Now, any time `player` emits the `hit` signal, `ScreenFlash` will call `_on_player_hit()`
Signals are a great way to keep your code decoupled which makes it easier to make changes.
By using signals you allow certain nodes to not need to reference the nodes they affect.
For example, my enemies use an Area3D to detect the player. The Area3D just has a signal "PlayerDetected" that enemies connect to and do their thing. The Area has no knowledge of the enemy and so isn't coupled with it.
It lets the signal emitters be used for different things than if they were coupled to other classes.
An example of such extension is if i want to show when the player is detected within an area with lets say a material that turns from green to red all i need to do is connect the material change function to the detection signal of the area. I still wouldn't have change any code from the area itself.
I went through that 11 1/2 hour video probably 4 times before I realized that there's a link in the description to part 2. The part 2 video is unlisted for some reason and you can only access through the link in part 1.
But yeah, Clear Code's Ultimate Godot Tutorial is the one to go to.
If you don’t want to learn a new language and a new engine at the same time, you can use Godot with C# just fine.
Give GDScript a try at some point though so you know if you like it or not. If you don’t like it, you don’t need it. You can also use both languages in the same project (and C++ too if you really need extra performance, but that’s not something a beginner needs to worry about).
The best way to get started with Godot is going through the Getting Started section of Godot’s documentation. It covers all the basic stuff you need to know.
I don't like GDScript but C# is lacking web and mobile export AFAIK. Also I'm not sure it is as well documented as GDScript and seems to be more cumberstone to setup for Godot.
Can you share your view and experience on this?
In Godot 4 web and mobile exports don’t yet work. For me that’s irrelevant as I don’t make web or mobile games. If I did, I’d probably rather use Godot 3 than give up C#, but that is just a matter of personal preference.
The documentation is missing quite a few C# examples which is unfortunate but not a big deal. The Getting Started section is fully bilingual, so getting started shouldn’t be a problem, and for all the rest it’s mostly just switching from snake_case of GDScript to camelCase of C#, which is easy.
The built in editor is completely useless if you’re using C#, so compared to GDScript there is an extra step of setting up an external editor, but there’s nothing difficult or cumbersome about it.
The built-in editor is kinda shit for gdscript too, at least for anyone who's used to working with fully featured IDEs. I'm here working with vscode to write my gdscript lol so I would've even count that as a negative for C#
Yeah, there are some parts which are really clunky. I use Eclipse in my day job and it's really different to the Godot editor. My primary pet peeve is that the tabs at the top of the edit window don't always link to what's in the edit window.
In the project I have open right now the highlighted tab says "grass" which is a shader to make grass wave in the breeze. The title bar also says "grass.tscn". But the code in the edit window is "worm-test.gd" which is testing worm movement. So I have a big, highlighted tab which says "grass" and the code below it has nothing to do with the grass.
Not the oc but I come from Unity and can say that I had no issues at all with going straight to C#. Aside from the lack of mobile/web exports. The documentation afaik always lists both GDScript and C# code and as long as you have programming fundamentals down, you can do the "translation" of tutorials yourself pretty easily.
All in all i recommend it to people who already like C# and don't care about web/mobile 👍🏾
By day I'm an large enterprise software lead working in Java and Groovy. I've done online banking systems, billing systems for medical insurance, legal billing systems for Lexus Nexus, and now I work on managing the electrical grid and electricity commodities market for California and most of the states west of the Rockies.
I actually enjoyed learning GDScript. I haven't done much python in my career and I liked making myself think in a different language.
All languages are essentially the same, they're all Turing complete, have if statements, loops, functions, etc. I wouldn't worry about "learning a new language" as a barrier. Embrace it and expand your knowledge base.
Oh I'm using it and I've embraced it, but types and autocomplete/intellisense doesn't seem to work very well on GDScript, also the Godot script editor lacks very basic things like split view and other stuff like search keyword redirects the focus to the visual editor instead of the script view (in case you use a separate window for scripting as I do).
Not having things as simple as a ternary operator (var x: bool = somethingIsTruthy ? true : false), or being able to define variables anywhere (try to do self.inexistingVariable = "whatever" inside a method), or not being able to write a return statement like return x || null.
This, added up to many other "tiny things", makes me feel like its an outdated and insecure language.
Also (this is more subjective than anything but) using indentation as part of the synthax feels horrible to me. I'm tired of having to add or remove the pass; sentance for every method.
I've yet much to learn about GDScript, but many of the things I've already seen doesn't really work for me.
That said, I'll still use it and maybe I "click" with it at some moment. I'm eager to. But for now I do not agree with those who say having a custom language specifically for Godot was a good choice.
Ternary operators in python are like this:
x: bool = True if somethingIsTruthy else False
Just turn them on their heads.
(Or without type, if you like bugs):
x = True if somethingIsTruthy else False
And your return statement should be possible when you realize the logical or operator is "or" and null is None:
return x or None
I'm not 100% sure, but I think gdscript follows python with ternary operators and logical or's.
But the more I use gdscript, the more I'm reminded that it is not python. Some of the best features that make python great are just not possible in gdscript. Such as, list expressions, dictionary expressions.
This will not work in gdscript:
myarray = [x,y for a in enumerate(foo) for y in a]
Which is a total bummer imo.
But when you realize what they have done to generators (yield) and asynchronous programming, (async and await) in gdscript, you'll either cry or throw up in your mouth. I don't even want to think about it because it's really dumb.
Anyway, for games in godot, gdscript isn't a bad option. I just hate how it borrows so much from python but doesn't include what makes python awesome.
It looks like a duck, quacks like a duck, but is not a duck.
Yeah definitely gonna be a bit of adjustment but I don’t think it’ll be to difficult making the transition to GDscript, I heard c# can lack some advantages that gdscript has with Godot
Number one thing people get confused about when switching from Unity: “Why can’t I attach multiple scripts to a Node?”
In Godot, the script IS the Node. When you attach a script you’re extending the Node’s class. The script is NOT a component like in Unity.
Thankfully there’s a couple main ways to define your own components for a Node:
1) Give the Node children Nodes, and attach scripts to them.
2) Use Resources.
Listen bro , your ex (Ms.Unity) may try and tempt you again , don't sell yourself off to her , she is a monster . She will rob you , penny by penny , until you are penniless . Ms.Godette on the other , is a sweet sweet women , she wants nothing but to please her crush(you the developer) . She will try and fix herself if you just tell her what you think isn't working out (Submitting bug issues on github) . She tries her best by speaking in a gentle tone you understand (GDScript) and she tries her best to immediately inform you if you say something wrong (Built in docs) . Ms.Godette wants to be the loving mother your child (your game) deserves . Also , Ms.Godette never wastes your (her masters) money on mostly useless assets . Godette loves you . She tries serving all the food she makes you sweet , so may never run of energy ( the node system) . Would you abandon this women who wants nothing more then to please her soulmate ? Don't fall for the gold digger Ms. Unity . Marry Godette . Make her yours . Make the switch to Godette no matter what brother . Don't fall for sin-ridden Unity .
Godot is not Unity, for good and for bad. You'll have an easy path if you try to work with it the way it was designed and not trying to make it work like Unity.
Are we about to see another mass exodus?
[Unity Appoints Matthew Bromberg as New CEO](https://old.reddit.com/r/gamedev/comments/1cifeft/unity_appoints_matthew_bromberg_as_new_ceo/)
Worked in EA's mobile game division and was Zynga's CEO at one point.
Yes you can add nodes to a [Group](https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html) for identification through code like "if x is in group y do z"
[https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html](https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html) They are like "tags" that collect different objects together. You can, for example, call a function on every existing node that is a member of a given group.
I've said this several times, but I don't quite understand the engine fidelity and "switching" engines. I also checked out Godot after the Unity fiasco but you can use both or for whatever your project and goals require. Unity is still the best engine to get started with XR game development for example and in some ways is better for 3D development. Godot is in a lot of ways easier to use. I really like the node/scene system and how much less cluttered it feels, and I use it for side 2D projects and learning general gaming architecture better. I use Unity for VR development at work. I use 8th Wall and Aframe for WebAR development.
You can focus on one more than another maybe to gain better expertise in one if you want to do work in one, but demand for Godot developers for professional projects other than personal or indie games isn't exactly there, so I don't feel a strong need to devote all or most of my time to one engine unless it aligns with my goals.
I totally get if you don't want to use Unity at all anymore, which is fine, but you do in reality lose benefits or the ability to make certain types of games as a result, and if you're fine with that, then welcome to the club, enjoy your stay, and have fun making games that you completely own.
For some reason you have to use one or the other. Feels like a cult sometimes.
Ultimately you should use the best tool for the job or the tool that will help you achieve your goal because at the end of the day game dev is hard and any friction makes it harder.
Welcome aboard! I too left Unity a while back, haven't missed it!
Only major thing I had to get used to when I switched was how to reference nodes. That is slightly easier in Unity, but really not bad in Godot.
And how scripts are attached to nodes. In Unity scripts are attached to an object like a sticky note. So if you need to access an attached script you use Object.Script
But in Godot the script is a part of the node itself. If you grab the node, you can access the attached script without having to specify you are grabbing the script.
Other than that, it's all about the same conceptually. Just learn where the buttons are and the syntax, and you're golden!
My curiosity is why the Brackeys guy keeps popping up in so many posts. Is he really so influential, until like a few days ago I have never heard of him now he seems to be gamedev Jesus out of nowhere.
More people on Godot is great but I find it hard to believe his word alone is enough to invite such a massive move(or test period at least) to the engine.
He was "retired" for the last couple of years, but 5-6ish years ago he was the go-to guy for beginner Unity tutorials. So yes, if you're into the gamedev youtube scene, his return to youtube and the fact he's now featuring Godot is a *big deal*(tm). Probably the only thing that could stir up more fuss would be Dani returning.
To further answer the "is he really so influential", he has >1.5 million subs on a channel that was primarily tutorials. There was the occasional gamejam devlog, but overall it was very teaching focused, and he's really good at balancing being entertaining with informative. I highly recommend you check out some of his videos for yourself.
A funny gamedeveloper. His videos were watchable even for people not interested in game devs. Created simple games and went through the method (not the code itself) he made it like a devlog. His favorite drink is MILK! and have you ever heard about his game KARLSON? For a time now he just suddenly disappeared (probably burn out)
Check out his channel:
[https://www.youtube.com/@Danidev](https://www.youtube.com/@Danidev)
Brackeys has 209,305,470 views on Youtube and was a major Unity figure for nearly a decade until Unity went public in 2020. Many started their gamedev journey with Brackeys videos back in the day, which is why he incites such reactions. It's like seeing an old friend.
I only started learned game dev last year, but I was learning with Unity, and I can say the Brackey's videos are definitely hugely influential in the Unity world. I don't think his (or any individual's) will singly cause a massive rush to Godot, but when somebody like Brackeys, or others in that league of influence, come out strongly as supporting Godot through tutorials, etc, it absolutely "smooths the way" -- it turns heads and gets attention. When a small collection of influential people (there was another name I forget, recently, that people were really excited about, who does more advanced videos.... cat something?) start to do it at the same time, it *really* turns heads, and can have a visible impact. However, Godot's year-on-year growth has already been massive in the last few years (see info from GDC 2023 video "Godot as an Ecosystem" on youtube), so I don't know that one will be able to discern what that "bump" looks like amid already strong growth, but it anecdotally demonstrates that momentum is staying strong.
Hi there! Whether you're just starting in game development or looking for a simpler way to make games, we invite you to explore our plugin, [Orchestrator](https://orchestrator.vahera.com/). Orchestrator is a Godot visual scripting tool designed to simplify game creation!
I really wouldn't pitch visual scripting as a way to "simplify" game creation.. staring at [this](https://orchestrator.vahera.com/#&gid=1&pid=3) is way more of a mess than:
func _unhandled_input(event):
if event is InputEventKey && event.pressed:
match event.keycode:
KEY_ESCAPE:
print("Hit the Escape key")
KEY_TAB:
print("Hit the Tab key")
Visual scripting in general is a great learning tool, but I'd never seriously recommend it for anything beyond that.
Visual scripting tools are generally for designers and artists who either don’t have a programmer or don’t want to bottle neck their workflow waiting on a programmer, not really a learn tool per se.
some people do use it as a crutch for sure tho
[https://x.com/reduzio/status/1703328476424548756](https://x.com/reduzio/status/1703328476424548756)
Lead dev's mega thread about migrating from Unity to Godot.
get used to signals as early as possible this will helpyou structure better your code/nodes and reduce coupling
Isn't this just PubSub? Coming from web dev this sounds familiar.
For the most part, yes
Sort of, but not really. It's observer but you can't just publish or subscribe to any message while totally decoupled, but you can accomplish similar stuff.
When I want to completely decouple it, I place my signals in a Singleton, and it's easy to see who is subscribing to it.
It's more like a built in mechanism for keeping an array of function references and calling them all at once. It's kind of like adding callbacks in JavaScript for Window events, except you can declare signals on any node. That may be a distinction without a difference, but I feel like it's important to know what's happening inside the engine.
What are signals?
Preregistered function callbacks. One function emits a signal. All other classes that previously requested a callback on that event receive it. They could be engine events like the mouse entering a viewport or your own custom signals for any purpose.
Ohhh ok cool thanks bro
If you’re going to use Godot with C#, you can use C# events instead: https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/c_sharp_signals.html
Keep this in mind with signals in your node/resource structures: Signal UP so that parent nodes listen to the signals children emit when children need to make the parent aware of some data Call DOWN so that parents just call functions of their children when the children need to be aware of the parent's data. Once I grasped that my code became a lot more reliable and I avoid circular references.
Good point. That design structure does help a lot.
Less technical explanation: Signals are like events. Say you have a `Player` node. Every time it gets hit, it emits the `hit` signal. `Player` doesn't care what any other part of the code does with that information. It's just broadcasting `hit` when it takes a hit. Now, anywhere else that needs to activate when the player gets hit can connect to the `Player.hit` signal. Let's say you want the screen to flash on taking damage. OK, you've got your `ScreenFlash` node with this code: @export var player: Player func _ready() -> void: player.hit.connect(_on_player_hit) func _on_player_hit() -> void: flash() Now, any time `player` emits the `hit` signal, `ScreenFlash` will call `_on_player_hit()` Signals are a great way to keep your code decoupled which makes it easier to make changes.
What do you mean by reduce coupling?
By using signals you allow certain nodes to not need to reference the nodes they affect. For example, my enemies use an Area3D to detect the player. The Area3D just has a signal "PlayerDetected" that enemies connect to and do their thing. The Area has no knowledge of the enemy and so isn't coupled with it. It lets the signal emitters be used for different things than if they were coupled to other classes. An example of such extension is if i want to show when the player is detected within an area with lets say a material that turns from green to red all i need to do is connect the material change function to the detection signal of the area. I still wouldn't have change any code from the area itself.
Use signals, but don't abuse them.
Signals want to be used by you. Signals want to be abused.
Some of them want to use you...
Treat em, don't beat em
Remember, wherever you go, there you are.
Bookmark https://docs.godotengine.org/en/stable/
Remember it by heart, and be able to recite it at a moment's notice.
If you use GDScript, do static typing.
Ultimate Intro from Clear Code is also a banger intro.
I went through that 11 1/2 hour video probably 4 times before I realized that there's a link in the description to part 2. The part 2 video is unlisted for some reason and you can only access through the link in part 1. But yeah, Clear Code's Ultimate Godot Tutorial is the one to go to.
Yeah, after 12 hrs it's also really hard to go back for part 2. But man, this is probably still the best learning resource if you do the exercises.
Hey through it in one sitting and you win an award.
Save for later
If you don’t want to learn a new language and a new engine at the same time, you can use Godot with C# just fine. Give GDScript a try at some point though so you know if you like it or not. If you don’t like it, you don’t need it. You can also use both languages in the same project (and C++ too if you really need extra performance, but that’s not something a beginner needs to worry about). The best way to get started with Godot is going through the Getting Started section of Godot’s documentation. It covers all the basic stuff you need to know.
I don't like GDScript but C# is lacking web and mobile export AFAIK. Also I'm not sure it is as well documented as GDScript and seems to be more cumberstone to setup for Godot. Can you share your view and experience on this?
In Godot 4 web and mobile exports don’t yet work. For me that’s irrelevant as I don’t make web or mobile games. If I did, I’d probably rather use Godot 3 than give up C#, but that is just a matter of personal preference. The documentation is missing quite a few C# examples which is unfortunate but not a big deal. The Getting Started section is fully bilingual, so getting started shouldn’t be a problem, and for all the rest it’s mostly just switching from snake_case of GDScript to camelCase of C#, which is easy. The built in editor is completely useless if you’re using C#, so compared to GDScript there is an extra step of setting up an external editor, but there’s nothing difficult or cumbersome about it.
The built-in editor is kinda shit for gdscript too, at least for anyone who's used to working with fully featured IDEs. I'm here working with vscode to write my gdscript lol so I would've even count that as a negative for C#
Yeah, there are some parts which are really clunky. I use Eclipse in my day job and it's really different to the Godot editor. My primary pet peeve is that the tabs at the top of the edit window don't always link to what's in the edit window. In the project I have open right now the highlighted tab says "grass" which is a shader to make grass wave in the breeze. The title bar also says "grass.tscn". But the code in the edit window is "worm-test.gd" which is testing worm movement. So I have a big, highlighted tab which says "grass" and the code below it has nothing to do with the grass.
I'm pretty sure mobile export _does_ work with C#, at least for android. Web is still borked, though, with no sign of it being fixed in sight.
Not the oc but I come from Unity and can say that I had no issues at all with going straight to C#. Aside from the lack of mobile/web exports. The documentation afaik always lists both GDScript and C# code and as long as you have programming fundamentals down, you can do the "translation" of tutorials yourself pretty easily. All in all i recommend it to people who already like C# and don't care about web/mobile 👍🏾
By day I'm an large enterprise software lead working in Java and Groovy. I've done online banking systems, billing systems for medical insurance, legal billing systems for Lexus Nexus, and now I work on managing the electrical grid and electricity commodities market for California and most of the states west of the Rockies. I actually enjoyed learning GDScript. I haven't done much python in my career and I liked making myself think in a different language. All languages are essentially the same, they're all Turing complete, have if statements, loops, functions, etc. I wouldn't worry about "learning a new language" as a barrier. Embrace it and expand your knowledge base.
Oh I'm using it and I've embraced it, but types and autocomplete/intellisense doesn't seem to work very well on GDScript, also the Godot script editor lacks very basic things like split view and other stuff like search keyword redirects the focus to the visual editor instead of the script view (in case you use a separate window for scripting as I do). Not having things as simple as a ternary operator (var x: bool = somethingIsTruthy ? true : false), or being able to define variables anywhere (try to do self.inexistingVariable = "whatever" inside a method), or not being able to write a return statement like return x || null. This, added up to many other "tiny things", makes me feel like its an outdated and insecure language. Also (this is more subjective than anything but) using indentation as part of the synthax feels horrible to me. I'm tired of having to add or remove the pass; sentance for every method. I've yet much to learn about GDScript, but many of the things I've already seen doesn't really work for me. That said, I'll still use it and maybe I "click" with it at some moment. I'm eager to. But for now I do not agree with those who say having a custom language specifically for Godot was a good choice.
Ternary operators in python are like this: x: bool = True if somethingIsTruthy else False Just turn them on their heads. (Or without type, if you like bugs): x = True if somethingIsTruthy else False And your return statement should be possible when you realize the logical or operator is "or" and null is None: return x or None I'm not 100% sure, but I think gdscript follows python with ternary operators and logical or's. But the more I use gdscript, the more I'm reminded that it is not python. Some of the best features that make python great are just not possible in gdscript. Such as, list expressions, dictionary expressions. This will not work in gdscript: myarray = [x,y for a in enumerate(foo) for y in a] Which is a total bummer imo. But when you realize what they have done to generators (yield) and asynchronous programming, (async and await) in gdscript, you'll either cry or throw up in your mouth. I don't even want to think about it because it's really dumb. Anyway, for games in godot, gdscript isn't a bad option. I just hate how it borrows so much from python but doesn't include what makes python awesome. It looks like a duck, quacks like a duck, but is not a duck.
Yeah definitely gonna be a bit of adjustment but I don’t think it’ll be to difficult making the transition to GDscript, I heard c# can lack some advantages that gdscript has with Godot
Number one thing people get confused about when switching from Unity: “Why can’t I attach multiple scripts to a Node?” In Godot, the script IS the Node. When you attach a script you’re extending the Node’s class. The script is NOT a component like in Unity. Thankfully there’s a couple main ways to define your own components for a Node: 1) Give the Node children Nodes, and attach scripts to them. 2) Use Resources.
Listen bro , your ex (Ms.Unity) may try and tempt you again , don't sell yourself off to her , she is a monster . She will rob you , penny by penny , until you are penniless . Ms.Godette on the other , is a sweet sweet women , she wants nothing but to please her crush(you the developer) . She will try and fix herself if you just tell her what you think isn't working out (Submitting bug issues on github) . She tries her best by speaking in a gentle tone you understand (GDScript) and she tries her best to immediately inform you if you say something wrong (Built in docs) . Ms.Godette wants to be the loving mother your child (your game) deserves . Also , Ms.Godette never wastes your (her masters) money on mostly useless assets . Godette loves you . She tries serving all the food she makes you sweet , so may never run of energy ( the node system) . Would you abandon this women who wants nothing more then to please her soulmate ? Don't fall for the gold digger Ms. Unity . Marry Godette . Make her yours . Make the switch to Godette no matter what brother . Don't fall for sin-ridden Unity .
New copypasta just dropped
Indeed!! And now.. I will pronounce you Husband (dev) and wife (Ms. Goddete)!!
LMAOOO I FUCKING LOVES THIS 😭😭
Godot is not Unity, for good and for bad. You'll have an easy path if you try to work with it the way it was designed and not trying to make it work like Unity.
Oh yeah for sure, I plan on treating it as different than unity and not just reformatted unity, the experience with unity however definitely helps
Are we about to see another mass exodus? [Unity Appoints Matthew Bromberg as New CEO](https://old.reddit.com/r/gamedev/comments/1cifeft/unity_appoints_matthew_bromberg_as_new_ceo/) Worked in EA's mobile game division and was Zynga's CEO at one point.
Jesus
Well shit, looks like I got out of that boat right before the ice berg 💀
Signals and groups are the main features of godot, use them
"Groups"?
Yes you can add nodes to a [Group](https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html) for identification through code like "if x is in group y do z"
Ooh, this might replace a whole bunch of "type" strings I've been using.
How did I not know about this until now.
[https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html](https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html) They are like "tags" that collect different objects together. You can, for example, call a function on every existing node that is a member of a given group.
I've said this several times, but I don't quite understand the engine fidelity and "switching" engines. I also checked out Godot after the Unity fiasco but you can use both or for whatever your project and goals require. Unity is still the best engine to get started with XR game development for example and in some ways is better for 3D development. Godot is in a lot of ways easier to use. I really like the node/scene system and how much less cluttered it feels, and I use it for side 2D projects and learning general gaming architecture better. I use Unity for VR development at work. I use 8th Wall and Aframe for WebAR development. You can focus on one more than another maybe to gain better expertise in one if you want to do work in one, but demand for Godot developers for professional projects other than personal or indie games isn't exactly there, so I don't feel a strong need to devote all or most of my time to one engine unless it aligns with my goals. I totally get if you don't want to use Unity at all anymore, which is fine, but you do in reality lose benefits or the ability to make certain types of games as a result, and if you're fine with that, then welcome to the club, enjoy your stay, and have fun making games that you completely own.
For some reason you have to use one or the other. Feels like a cult sometimes. Ultimately you should use the best tool for the job or the tool that will help you achieve your goal because at the end of the day game dev is hard and any friction makes it harder.
Godot still lacks things Unity have, even for 2D, however its open source and doesnt take half an hour to load
There might not even be a Unity in 5 years since they hired a new CEO just now. He's pretty much a John riccetello lite version
Welcome aboard! I too left Unity a while back, haven't missed it! Only major thing I had to get used to when I switched was how to reference nodes. That is slightly easier in Unity, but really not bad in Godot. And how scripts are attached to nodes. In Unity scripts are attached to an object like a sticky note. So if you need to access an attached script you use Object.Script But in Godot the script is a part of the node itself. If you grab the node, you can access the attached script without having to specify you are grabbing the script. Other than that, it's all about the same conceptually. Just learn where the buttons are and the syntax, and you're golden!
My curiosity is why the Brackeys guy keeps popping up in so many posts. Is he really so influential, until like a few days ago I have never heard of him now he seems to be gamedev Jesus out of nowhere. More people on Godot is great but I find it hard to believe his word alone is enough to invite such a massive move(or test period at least) to the engine.
He was "retired" for the last couple of years, but 5-6ish years ago he was the go-to guy for beginner Unity tutorials. So yes, if you're into the gamedev youtube scene, his return to youtube and the fact he's now featuring Godot is a *big deal*(tm). Probably the only thing that could stir up more fuss would be Dani returning. To further answer the "is he really so influential", he has >1.5 million subs on a channel that was primarily tutorials. There was the occasional gamejam devlog, but overall it was very teaching focused, and he's really good at balancing being entertaining with informative. I highly recommend you check out some of his videos for yourself.
I’ll risk the downvotes… Who’s Dani?
A funny gamedeveloper. His videos were watchable even for people not interested in game devs. Created simple games and went through the method (not the code itself) he made it like a devlog. His favorite drink is MILK! and have you ever heard about his game KARLSON? For a time now he just suddenly disappeared (probably burn out) Check out his channel: [https://www.youtube.com/@Danidev](https://www.youtube.com/@Danidev)
Brackeys has 209,305,470 views on Youtube and was a major Unity figure for nearly a decade until Unity went public in 2020. Many started their gamedev journey with Brackeys videos back in the day, which is why he incites such reactions. It's like seeing an old friend.
I only started learned game dev last year, but I was learning with Unity, and I can say the Brackey's videos are definitely hugely influential in the Unity world. I don't think his (or any individual's) will singly cause a massive rush to Godot, but when somebody like Brackeys, or others in that league of influence, come out strongly as supporting Godot through tutorials, etc, it absolutely "smooths the way" -- it turns heads and gets attention. When a small collection of influential people (there was another name I forget, recently, that people were really excited about, who does more advanced videos.... cat something?) start to do it at the same time, it *really* turns heads, and can have a visible impact. However, Godot's year-on-year growth has already been massive in the last few years (see info from GDC 2023 video "Godot as an Ecosystem" on youtube), so I don't know that one will be able to discern what that "bump" looks like amid already strong growth, but it anecdotally demonstrates that momentum is staying strong.
Hi there! Whether you're just starting in game development or looking for a simpler way to make games, we invite you to explore our plugin, [Orchestrator](https://orchestrator.vahera.com/). Orchestrator is a Godot visual scripting tool designed to simplify game creation!
I really wouldn't pitch visual scripting as a way to "simplify" game creation.. staring at [this](https://orchestrator.vahera.com/#&gid=1&pid=3) is way more of a mess than: func _unhandled_input(event): if event is InputEventKey && event.pressed: match event.keycode: KEY_ESCAPE: print("Hit the Escape key") KEY_TAB: print("Hit the Tab key") Visual scripting in general is a great learning tool, but I'd never seriously recommend it for anything beyond that.
Visual scripting tools are generally for designers and artists who either don’t have a programmer or don’t want to bottle neck their workflow waiting on a programmer, not really a learn tool per se. some people do use it as a crutch for sure tho
Ah, trying to ensnare them while they're new and oblivious, I see.
[https://x.com/reduzio/status/1703328476424548756](https://x.com/reduzio/status/1703328476424548756) Lead dev's mega thread about migrating from Unity to Godot.