To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DarkDax/ . You’ll also get 20% off an annual premium subscription. Update: Thank you to everyone commenting tips and pointing out useful API functions, I've learned so much more already! Keep sharing the info so we can all benefit!
I used Construct since 2007. Got to the point where I was building everything myself inside it, and decided to move to another engine. In the end I went for C with raylib, which is a framework, and I got to say, it's so reliving to not have to worry about engine's structure. At the same time, I agree, that doing something now takes somewhat longer, since I've got to design a lot more stuff myself. But it is refreshing that you know that it's your code and you have control over it.
14 years as a professional .Net developer specialising in C#. Have tried things like Unity and Unreal in the past and the big hurdle for me adopting them is their terrible interfaces and over complication of the none coding elements. Godot is amazing and I've picked it up pretty much straight away. And despite my hatred for indentation and the lack of semicolons I actually use GDScript over C# due to C# in Godot not being as up to date as well as GDScript just being really nice to develop in.
Super interesting. I initially found Godot a tiny bit clunky but found it much better over time. Definitely got used to it quicker than Unity (Unreal goes without saying haha). Is there anything in particular you’ve found worse off with using C#?
I started using Godot with a Python background and found GDScript really frustrating until I decided to accept it for what it is and quit comparing it to Python. Then I liked it.
I want to say that with the latest 4.3-rc1/2, Godot Mono has greatly improved and fixed many issues, but it's still not perfect. I wanted to share this story as I made the opposite choice. My journey with Godot began with a university project where I developed a SAS-like 2D game using GDScript 3.0.X. After spending several years working professionally with TypeScript, I decided to return to game development, aiming to rebuild my project in 3D. Initially, I started by rewriting and improving the old GDScript codebase, enjoying the familiarity and ease of use. After a few months, I recognized the need for greater typing safety and a better developer experience (DX), which led me to decide on translating the entire project from GDScript to C#. With the assistance of ChatGPT, this translation process took around two weeks. This shift allowed me to refactor and enhance the code, resulting in a more robust and maintainable structure. Transitioning to C# wasn't without its challenges. I had to relearn how to write my code, understanding the same concepts in a less intuitive way (e.g., the lack of @onready). I encountered several issues that slowed my progress, related to both Godot and C# in Godot. These included problems with corruption in the compiled C# code and node configuration issues around signals and resource classes, which required significant adaptation in my approach to building the project. Despite these obstacles, adapting my workflow was a necessary step to overcome the limitations and make progress. The 4.3-rc1 update has been a godsend for many issues I faced in my project. Recently, I felt that the major challenges required to create good systems for my game have been fully or partially addressed. I've established a functional and scalable framework of reusable components for my game. This foundation has allowed me to focus on developing features and content that add depth and layers to the gameplay. Embracing the composition pattern was initially slow, as it required careful design of reusable components. However, now that these components are in place and scalable, I'm able to make progress on the bigger picture of the game, which has made me very happy to see. I’ve also tried working with Unity and Unreal Engine but found them overwhelming due to their extensive feature sets and the steep learning curve required to get started. Godot, on the other hand, offers a more flexible approach. Its visual editor is not tightly coupled with the coding process, allowing me to develop the game closer to the code. This aspect of Godot, where I can code reusable nodes with minimal interaction with the IDE, is something I particularly appreciate. With Godot, you can start small and gradually expand, unlike Unity or Unreal Engine, which often feel like you need to master a vast array of features from the outset. This has made my development experience smoother and more enjoyable. I do not regret choosing Godot or translating the entire codebase to C#. The journey has been filled with learning and growth, and the decision to use C# has provided the stability and scalability needed for my project.
@@maximefb2338 Yeah this is my problem with GDScript, it's great for quickly putting together a prototype or small game. But for anything that needs actual architecture, it just gives me headaches compared to the control I have with C#. Just the fact alone that GDScript doesn't have a "private" drives me crazy when in C# I make EVERYTHING private whenever possible to minimize the accessible surface area of all class to only what is absolutely necessary.
@@maximefb2338I want to use godot mono but the lack of intellisense for sharing of code between gds and c# is what's helding be back. How do u address this in ur project?
When I started using Godot, it was right after the Unity pricing changes. There were a lot of things to get used to, but once you're over that initial learning curve, things just get a whole lot faster to do. I haven't used C# in a project yet, though. I've just been knee-deep into GDS, and it's pretty easy to understand and write. If you're willing to learn, do it. Dont be afraid to learn something new.
Thanks for sharing your experience. Initial learning curve can be frustrating, especially if you know how to do something in another tool already. I might give GDScript a go at some point just to check it out! Do you think you’ll ever try C# or do you feel happy enough sticking with GDScript?
@@DarkDax At this point in time, I have no need to use C# as I've been able to do everything I've wanted to with GDS. However, I understand that C# can be more preformant in certain areas. So, it might be beneficial to learn its appropriate use cases with Godot. If you're willing to lean GDS, the docs are always a great resource. I'd also recommend having a look into GD Quest and the newest Brackeys videos on Godot. GD Quest, in particular, provides further explanations and use cases for stuff that the docs might not.
@@DarkDaxas someone who also came from Unity with a C++/C# background, gdscript was extremely fast to learn. In some ways it’s very nice to use, and imo can be a better experience as it’s more tightly integrated into the engine. But on the other hand there are features I miss. Like interface feature like in C# or multi inheritance like in C++, sometimes one level isn’t always enough and I do weird work arounds. At times I wish the language was stronger, but not often enough to switch to C#. I think being used to gdscript first when I switched makes switching to C# harder as the experience just isn’t as seamless 😅 also when researching more obscure tools with less documentation having to convert to C# syntax is just extra trouble I don’t want to deal with sometimes ¯\_(ツ)_/¯ Edit: I do miss my curly braces :< Edit 2: You can do more then one level inheritance, idk why it didn't work when I tried it before, I must've done something wrong oops
The beauty of the node system in godot is that the hierarchy is actually a pretty good representation of what's going on in your game. Every element has a node. In unity, a single node in the hierarchy may consist of 50+ components, and from the hierarchy alone you could never tell. Also, the "nested prefab" feature from Unity (which we have waited for YEARS to finally get) just follows from the design principles in Godot. The downside is that the hierarchy can become visually cluttered faster, so keep things tidy and for lords sake, *name* your stuff in the hierarchy.
I remember, when learning Blender, someone saying "don't try to force it to be program it isn't. Blender is doing it's own thing" and I feel like it's the same for someone witching engines.
I moved over to Godot, And managed to recreate a project that took years to make in Unity and managed to recreate it in a week in Godot. Partly because I knew what I was creating, And when I was trying to make it in Unity I had no idea how to program in general and let alone how to exactly make what I had envisioned in my head.
Areas have a method called get_overlapping_bodies / get_overlapping_areas, which gives an array of all bodies/arrays within an area. Not sure if this would help, but it may make it easier than keeping a separate log.
@@DarkDax The list you get from get_overlapping_bodies / get_overlapping_areas is the list from the past physics frame. For most uses that is good enough. However, if you want to get an up to date list, or if you don't want to use a node at all, you can use a shape cast from get_world_3d().direct_space_state.intersect_shape (Addendum: that is capitalized different on the C# API) The drawback is that then you don't have a gizmo/inspector to easily set it up, nor a debug shape (you can enable Visible Collision Shapes in the debug menu). I'm not saying this is better, I'm saying it is tradeoffs. Addendum: Using the shape cast API might be a performane concern, so I'd advice to stick with the Area3D unless you really need it. By the way, know that you can always make custom node classes that do it exactly the way you want (and that is not even getting into making plugins).
this has been my experience switching to kdenlive for video editing. it has some tricky hangups but it feels nice that my entire pipeline is open source now
Feel your pain there mate. Davinci has definitely been a hurdle. Not as much of one then I thought but the different ways of doing things goes into what I talk about here with the frustration of knowing how to do what you want in one thing but being strangely lost in another tool. Hope you're getting on well with your new open source tool set!
I swapped from Unity to Unreal a couple of years ago, and this mirrors my experience pretty much exactly. I had a very hard time getting the Unity way of doing things out of my head, and that made it just that much more difficult to learn the new engine. But, slowly but surely, I started picking up more and more of the 'correct' patterns and things starting clicking, which got me even more excited, which led to even quicker learning. It feels like the learning starts slow, but the growth is exponential, so it gets so much faster as you do it.
Coming from an art background with godot being my first game engine I really like the node hierarchy function of it! I'm use to folders in folders in folders so wrapping my head around the fact that they are basically just folders with specific functions was very intuitive.
Raycast node has a shape variable, that's how you can quickly use shape traces. Also there have been community tests, using the node for raycasts is faster than doing it programmatically.
I have been using Godot for a year after the Unity fiasco. I decided to stick to C# and I'm very happy with it. Once you get the nodes concept, that´s basically composition, everything makes sense. It´s pretty fast to load and compile, to debug, so you save up a lot of time here. Also for the UI, once you get how anchors work, it makes your life so much easier. Must say I'm only using it only for 2D at the moment.
Totally agree. I know it’s more composition based but I still find myself ‘breaking’ that now and then. I’m definitely getting better with it though! Godot has really impressed me so far!
I really agree with the c# over indentation. I think the thing that frustrates me the most though is the use of magic strings everywhere. That I have to use GetNode and type in a string path makes things more brittle. If I change a node's name to make it more readable, it could make my code stop working without really any compile time check.
On the topic of C# vs GDScript, I think you do what makes you comfortable. I believe that once you learn programming concepts, it's easy to just learn syntax and some quirks and use whatever language however I am a hypocrite because I don't want to learn the nuances of C++ and just use C. Kinda the same thing with Godot vs Godot C#. So ultimately this comment was just for boosting engagement and admitting my flaws on a public forum.
Same here - once you understand the mentality for programming, for the certain paradigms you can 'feel it out'! Also thanks for taking one for the team 🫡
@@NihongoWakannai I agree. But a mindset I want to focus on is that those feature sets are more like quality of life improvement (unless you are talking about Pandas or some hyperspecific language for math or text parsing). Like with my example for C, it can do everything C++ can. Can it make virtual functions and classes? Well sure, if you break down what those are to base concepts. Like assembly. To me coding languages are like, How do I make an array? How do I concatenate a string? How do I pass default arguments? It's less about a huge toolbox and more about knowing how to make four tools do everything. I also do a lot of unsafe programming shit with python and C my first go around.
@@NickAndWolf Quality of life is SUPER important. That quality of life can knock months or years off of your development time. We're not coding here, we're programming. If you don't have a language that allows you to write robust program architecture easily then you're just shooting yourself in the foot. Like GDscript having all functions and properties be public is a nightmare. Everything being private by default in C# allows me to significantly reduce the exposed surface area of my classes which helps to make the code self-documenting and very easy to debug.
1:52 DUDE. Yes. thats the EXACT feeling when you first open ANYTHING for the first time. I have that exact feeling when i first opened Blender, Unity ofc, and yes i even had that feeling when trying to learn OBS years ago.
I used Gamemaker for 2 years, Unity for 5 and now Godot for 5(nearly)... And while I'm a total Godot fanboy, I still wouldn't say go from Unity to Godot if you're doing 3D, Godot right now isn't going to hit AAA like graphics and if you're okay with graphics that aren't cutting edge then still Unity seems awesome for 3D while Godot is catching up. However if you're doing 2D... GET ON GODOT! It's night and day different from every engine I've used (since programming in DOS to now)
Fair and balanced coverage. For my use-case the main concerns I had were ease of use, Android builds, and performance. My first game was made in Unity about 10 years ago, I had fond memories of the easy cross-platform builds and mobile performance. This time I tried Godot and built a prototype and had it running on my phone over a weekend. The scrolling was jittery and horrible, but otherwise I was happy with the workflow, the scripting, everything is easy to pick up and modify. I wasted a week first trying to optimise my scene before porting it all to Unity only for it to be even worse there, with about 15 fps and stuttering. Finally went back to Godot, looked closer, realised the jitter was a physics issue, did some googling and found a setting to change to set the physics FPS and screen FPS to be the same (there are other fixes too, but this was good enough for me for now). Performance was my final main concern and Godot has knocked it out of the park! Now I just have to knuckle down and try to port my prefab-thinking over to nodes... Here goes nothing I guess!
Honestly the node way of thinking about things really did make think about things for a hot minute. I’m still probably doing some things wrong (oh well) but I’m really enjoying the engine so far. The comment section here has been great help too. Hope your journey continues to go well!
Hi, as a debutant/newcomer into game making, Unity was kind of... like if you were passing from a bicycle (Scratch) to an fighting helicopter (Unity) when by the other hand, Godot is like learning to drive a car. That's the first experience with the engines i'm talking about ,o,
For raycasts, just make a static class with helper functions that automatically adds and reuses a raycast node. I've made mine function more or less identical to the unity implementation. There's a blog post floating around complaining about the default physics querying functions because of how inefficient they are compared to the node implementations, so using a helper static class you get the best of both worlds.
You can directly access the underlying physics server which shouldn't be slower than a node. If you're making a wrapper class then you may as well do that. It's recommended in the "Optimization using Servers" article in the documentation.
@@NihongoWakannai From memory the problem with using the physics server via C# is that the underlying dictionary objects you get back cause garbage with no way of supplying your own buffers and calling into the engine via c# is just fundamentally slow. It's fine if you only do a call here or there but adds up quickly if you do alot of raycasts per a frame. Apparently you don't get the same drawbacks by using the node implementation though since it's all handled natively. It's been a while since that blog post dropped so it's very much possible there has been improvements since then, but I won't know for sure without benchmarking.
Good insight, tbh. I am trying to finally complete a game in Unity, but every like half a year I get into Godot to see all the new updates and make small prototype to develop some skills in that engine over time. Somehow my initial struggles were not as painful as some people describe it. First time when I used it, v4.1 Ii think, it was hard to transition from components to nodes on my own, but after following a few tutorials in a day or two, paradigm "everything is a node/scene with single simple purpose" started to just look like Single Responsibility Principle in visual form. Everything and anything is a specialized lego piece and I find that comforting and practically useful. I forget what game objects do all the time, seeing what thing does at a glance on hierarchy saves some time. Also, on a side note, Unity supports C# asynchronous stuff via async/await workflow for at least 3 years now, even though its tricky to use correctly and to not produce multiple memory leaks or brick your app untill pc restart (totally not speaking from experience).
I have a background in coding simple projects completely unrelated to games or gaming. But recently I’ve been inspired to learn a game engine. I poked around unity and unreal, but Godot clicked with me out of the gate. I am stoked to embark on a game development side project once I get the hang of the engine. Seeing so much support for Godot has been awesome to see.
I love Godot because if I get an idea that I want to try out, I can start the editor, open a project and be coding within seconds. Depending on the project, this would take several minutes in Unity and ten minutes in Unreal 5. Less of an issue when constantly having the editor open, of course. But still a pretty big factor for me, personally.
10:40 It's just ShapeCast3D, another node type. From code look at intersect_shape in PhysicsDirectSpaceState3D class. Also code api for raycasting is quite old, and it is known that it will be refactored some time in future, so hopefully it will be a little more ergonomic after that
What's funny is the node system was practically how I was using Unity/Unreal before I settled on Godot. I am only hoping that Godots 3D improves significantly. I am not asking for unreal levels of course but decent graphics out the gate.
Well it’s super interesting how games like Road to Vostok look insanely high fidelity on an engine not necessarily focused on providing that. Just shows its versatility!
Native fbx with 4.3 and blend support since a lil while ago :) I'm not sure what exactly you mean with "decent graphics" - what I've seen even in earlier versions of Godot was anything but indecent xD
I've loved Godot. Skipped Unity after a short little bit, and I have made more progress than I ever have in any other project. The UI is so clean, and all the methods make sense IMO... Love your video!
I've been meaning to give game dev another try. Maybe it's time. I just hope C# support has come further than last time, especially in the documentation.
There goes my hero, watch him as he codes... Now, seriously, almost spitted out my coffee at the IndentGate news bit, as I too am an Unity dev that really hates identation and lack of semicolons and variable types. Loving to use Godot with C#, tho. About async functions, I'm using GDTasks. It replicates UniTasks almost fully and has been wonderful to code asynchronous methods as I would in Unity.
Great video dude! It's been really interesting to see your take on the switch as we both went through it together. I think we hit a lot of the same obstacles. Once the new concepts clicked for me with Godot and the node system, I have found it to be easier and faster working in Unity. I always found myself getting a little too lost in the code with Unity whereas with Godot it's easier to see the bigger picture and keep progressing your game overall. I know you preferred to stick with C# which makes sense with your experience but for my just making the switch along to GDScript as well was a welcome change and I think it is just such a great compliment to the node system. I like the sponsorship dude I think Brilliant is a good fit for your channel.
Honestly man, going through it at the same time was great for motivation and not feel completely in it alone haha. Completely agree about being able to get on with what you want rather than getting lost in the implementation. I’ll definitely have to give GDScript more of a chance soon - a lot of people really do praise it how much it complements the philosophy of the engine. Thanks 🙏🏻 I definitely thought they were fitting for this type of video!
C sharp async await IS THE SAME as any other async / coroutine setup. Unless you spawn another thread (which gdscript actually allows natively), C# async is single threaded and pauses / resumes coroutines just like gdscript. This can be proven very easily with minimal code. Async is NOT multithreading.
@@DarkDax A Task is like a Javascript Promise, it's a structure that stores information about return value, execution context, etc, and allows functions to be mapped asynchronously to store their state for later so they can be paused and resumed. For example, you can map a function to a task's ContinueWith, so that when the task completes it begins another one. Godot doesn't have its own "Promise" implementation but it can be made using signals or Callables.
Obviously as a huge Godot fan myself I was hoping for a "Everything is perfect and I loved the switch" which I've heard from other game developers. But realistically, this is how the experience will be for most people. I think the value in this video isn't the fact that we have one more Godot user, but rather that other people looking at this don't try to switch to Godot with the expectation that it's just Unity but blue.
I’m glad you feel video was able to bring that to the conversation. I think Godot has been sold in some conversations as the Unity replacement and I worry people will give up if they struggle to get into it straight away. Hopefully this video helps highlight that teething issues are all part of the transition!
I used many different programming languages for small programs. My journey in a List DOS, QBasic, NASM, Windows 95/98, Linux Debian 2.2, Windows ..., C, Java, PHP, VB, SQL, RegExp, Python, C#. C based languages for localized keyboard layouts, are a bit annoying because you have to press shift all the time. For semi colons, colons, brackets, parentheses,braces, points, gt, pipe and many other symbols. Especially Basic dialects have the END Block keyword and return key at the end of a statement reducing the special keys to press when coding.
glad you're taking advantage of the C# put in for Unity refugees, but you may want to give GDScript a serious shake at some point- it's a lot less wordy and has a lot more conveniences built in to save you time. Epic is going in the same direction with their upcoming Verse language.
Yeah! It's definitely something I want to try out at some point. I figured I'd learn the quirks of Godot first and then dive into GDScript - it probably won't make a difference tbh but at least I don't feel completely lost by C# atm. I'll give it a go at some point, thanks!
"a lot less wordy and has a lot more conveniences" that's exactly why it's bad. Convenience isn't good for large scale game development when it comes at the cost of unstable architecture. Having things be wordy means they're extremely well defined and you have way more control over your architecture. Just the fact that every function and property in GDScript is public is insanity.
Great video! It was really interesting to hear your experiences moving engines. Sometimes it feels that people get too dug into their chosen tools and forget it's about making a great game.
There is a shapecast node but also you can do it from the space state via an intersect_shape query. Look it in the docs, its part of the PhysicsDirectSpaceState just like the raycast.
I also switched from Unity to Godot, and prefer Godot. I have used both to create data visualization tools, not games, and Unity simply didn't have the features I required - the ability to read/write arbitrary files of arbitrary formats with full file-pickers, accept file dragging from the client desktop into the "game" (not just the editor), and a full network stack (UDP and TCP), so I can pull data over the network from sensors in real-time. Unreal wasn't ever under any sort of consideration for our use due to enterprise licensing issues that even predate the Unity events. I also don't mind the indentation thing - I indent my code in more-or-less the same way that GDScript wants anyway, even in languages that don't require it, and I've never been a big fan of syntactic noise.
Great insight, thanks for sharing! It’s a brilliant reminder that engines can be used to make more than just games. Do you see yourself exploring other engines at all or have you found your home with Godot?
@@DarkDax I haven't yet run into a roadblock with Godot. In fact, I found myself with an issue that I had to work with some geometry on a planetary scale (modeling a system large enough where the curvature of the Earth is meaningful and must be accurately represented), and the stock Godot single-precision version wasn't going to cut it, so I simply recompiled it for double-precision and problem solved. As far as I can tell, you can't do that with Unity or Unreal - the normal trick of rebasing the origin wouldn't work for me, since there are various things going on at full scale, not just locally. I'm hoping that, as a project, Godot follows the same trajectory as Blender.
Yeah, prototyping simple projects in Godot is fast, prototyping complex projects in Godot... the difference is exponential. I am still working on closing my gameplay loop today. The thing is the asset store carries you across major thresholds like coming to prototype especially on really deep projects. On the plus side I can say my API development experience is not many times stronger than when I did Unity.
6:58 you can make a bootleg interface/abstract class (god knows what the difference is) by giving the script a class_name and adding your "abstract" methods to that base script, and later extend that class.
@@crabsquid325that doesn’t really defeat the purpose of interfaces, even in C# a class can implement multiple interfaces. However the problem I think is more that GDscript does not enforce implementation of abstract methods so it doesn’t give you the same kind of safety.
@@carsonreader515 'Defeats their purpose' as in 'you cant just use classes instead, theres no point', interfaces were made to solve the diamond problem(which you cant run into in gdscript) while still enforcing multiple(!) implementation contracts. Trying to emulate the behaviour of just one interface seems pointless to me.
"Home sweet home" from Beyond Good and Evil as a background music?? Now that's what I call good tastes. Glad there are still people out there aware of the existence of this master piece of a game (Great video btw)
Thank you for making this video. As a full time Unity Dev I've been wanting to expand my capabilities at some point and It's useful to learn from others you have jumped ship. But am I taking crazy pills. I use Async methods and threading all the time in Unity, right?... Confused. Also I would definitely miss not having the Job system using other engines. DOTS is one of the main reasons I have trouble committing to learn something else.
Update: I just learned that the Task.Run() initialization appears to run on a separate thread but otherwise you would have to explicitly create a thread or thread pool to run the logic in parallel. I don't know how I didn't know that up until now... Explains a lot. Also, I should mention since the UnityEngine only runs on a single thread, you do have to handle the logic you run in parallel carefully as you can't make Unity API calls from another thread. You can use a MainThreadDispatcher or design the code to handle Unity calls after the parallelized logic is done. This is part of the point of the Job system, so consider using a job instead. (its also safer.) Sorry for all this Unity talk on a Gdot video...
I'd have to look at the Godot API, but the extra work to iterate over the array of collisions sounds like something that could be turned into an extension method that basically does the same thing as the Unity API, except maybe with some more arguments.
A coroutine in unity is very much async. You can create a custom yield instruction that goes away does things on another thread and then comeback and let the couroutine continue on the render thread. The very defintion of async
I love that I can use node for raycast in Godot, as I can easy see where raycast is potining, instead of realing on Debug.DrawRay like in unity that is easy to mess up.
I might be misunderstanding you but you can definitely for-each over the results of a raycast query. Also I think you can give a collision shape to a raycast node to have it cast the shape instead of a point? Or maybe there's a dedicated shape cast node. You can also do a physics query to check an area for objects, similar to doing a raycast through a query instead of the node. Also, indentation is the more humane programming paradigm. Think of all of the semicolons that get to live long, happy lives in the wild now
I must not be looking in the right place because I can't find where you can foreach it. I'll keep looking! Thanks for the heads up! I think that's the only point about indentation that might have changed my mind. So many needless semicolons used 😭
@@DarkDax Well now I've managed to confuse myself, I just checked my code and realized that an intersect_ray() call only returns one result. intersect_shape() is the area check one I mentioned, and that one returns an array of results that you can for-each over
Unity has had async functions for a long time. They are a bit wonky because how synchronization contexts in Unity are set up, but they are there, and can be used out of the box But unity is on C#8 with some C#9 subset, on .NET 4.8 😢 Godot works perfectly with C#12 or 13, and .NET 8 or 9, with all the extra speed etc.
Godot is only getting better from what I’ve seen. And fast too. I’m sure by Godot 5 or 6, you’ll see C# fully compatible. And 3D will be = if ! > than Unity (beating Unreal in 3D, although? Not sure anyone can. Lol). So, there’s a lot to look forward to. Looking at UA-cam tutorials, with ones made with Godot 2 or 3, I see massive changes now with 4. So, Godot is definitely an up and comer.
7:19 yup im with you in this one, i dont hate INTENTATION but if thats all that defines were something begins and end, its stupid, the brackets or end points are always better.
@@ariffirdaus5376 well ye but no, my problem with pythonesque languages is the lack of a end token that can be a closing braket or a actual "end", but the lack of it makes it very difficult to read code with more than one level of indentation, at least for me.
Frankly I love Godot because it doesn't feel nearly as bloated and clunky as Unity's Editor. God I LOVE that every project needs to have at least a GIGABYTE in default packages before I can even START making a game. :)
Don't like indentations? You should indent your code any way, despite of language! For sake of easy to read. GDScript (with Python) just give syntaxial meaning for indents.
I hate indented languages because I like to rely on my editor to automatically indent all the code. With an indented language I have to manually adjust indentation levels whenever I move code around to ensure it's at the right level. With braced languages I can just move code into the right place and let the editor indent automatically. No tedious and error-prone whitespace babysitting.
I never understand the hate against indentations. Look at 4:41.. It's C# with indentations! So if everyone uses them anyway, why is it so bad just to have them required?
I came from Unity and C#, now i use Godot and GDscript... I love the node system and the composition based approach of the engine. I instantly felt at home in GDscript. It is far more accessible for me than C#.
The more I use it the more I’m getting used to thinking composition first. It’s good from a mindset perspective too since it reinforces the idea of single responsibility.
I think Unity VS Godot is comparable to a toy box VS a box of single lego pieces. If you want a ferris wheel, you gotta build it in order to spin. Not just get a spinner toy and put people in there. It is understandably frustrating for a lot of people, but when you become comfortable with it, you start feeling rewarded at a rapid pace, and you can build some massively useful things. It's hard to say a spinner toy will suit every moving object you need or want, right? Have fun and good luck in everyone's Godot endeavours :D
Use the engine you want to use. If you like Unity and it does what you need it to go for it. If you want to move to Godot for its community then go for it! Don’t overthink it, just make games!
I think no one will argue about lighting in games? So, godot currently has the largest number of acceptable lighting options. Unity has an outdated enlighten and mediocre lighting baking. Unreal has a shitty flickering lumen and good baking, but crooked uncontrollable lightprobes. I switched to godot primarily because of the lighting. Initially I had a bias towards godot, but practice has shown that it is a very promising and good engine..
What I dont like in Godot is the weird coordinate system, where positive z does not go "into" the screen, but comes out of the screen. Messing up all kinds of simple math calculations by switching rotations. The camera is basically looking into the negative z direction ...
I started with Blender and Z is up. Then I started using Maya with Y up, same as Godot. Then recently I started learning Unreal and Z is up again. Lol Anyways Y-up is probably the right choice because of how ubiquitous Maya is. I wish they had gone with Z up just to be like Blender
@@josephbrandenburg4373 I never had so much problems with Z up or Y up. The problem in Godot is, that Z ist mirrored. So looking along the x axis or y axis in 3D space, a positive axis number goes away from the camera, but looking at the z axis a positive number goes towards the camera. And that makes not sense as convention. Its unnecessarily confusing. They should have just stuck to the convention Unity uses, as this is their direct competitor.
It's a convention from graphics programming where positive Y is down because CRT monitors started in the top left and scanned right/down, and positive Z is towards the camera because positive Z means an object gets rendered on top of another. It's dumb for this to be used in a game engine which is focusing on creating virtual worlds in which it makes much more intuitive sense for up and forward to be positive values. I'm pretty sure every other game engine and 3D software realized this when making their software.
Being more open is fine, but when i go from Maya to Blender, there are a lot of choices that just seem dumb. Like what you have to do to get a uniform, bevel for example, is just insane to me XD The shortcuts are a mess. Even just the basics. Like why can i not graph multiple materials. Or: In Maya, translating, rotating, scaling, selecting is all in QWERT. In Blender it's .. uh.. G annd S... and R? S for scale and R for rotate, okay, it is dumb to do that based on an abbreviation instead of intuitive placement on the keyboard but okay, uncomfortable but okay. But then you have G for translate. It's not consistent at all. And each tutorial for Blender is like "Press shift C, ctrl alt T, then shift F12 and tap D twice", you know? So there is a balance between "open mind" and "oh my god make it make sense at least" xD
Yeah... this is why I never used Unity in the first place, and why I quickly ditched 3ds Max in favor of Blender over 15 years ago. Inevitably, I'm going to end up on all open source software anyway. So why not just start with only open source software and never learn the proprietary solutions in the first place? This was a great Idea with Blender, and pretty sub-par idea with everything else and a downright terrible idea with Photoshop. Probably lost a decade of potential productivity honestly... but eh, that's the price of holding true to our convictions.
Great video! The thing that really annoys me is people trying to diminish Godot as it was objectively worse than Unity just to validate the fact that they do not want to change engines. It seems kind of a weird thought process that actually some of my friends have that's like: - Unity is bad as a company, I should change engines; - Best option is Godot, I should use it; - But I don't want to change engines because it will be a pain; - If I convince myself that Unity is objectively better, I will have a good reason not to change; - Therefore, Godot is bad lol XD.
I absolutely hate C#... but I'm right there with you about indentation based languages. It gets so annoying to have to type 'pass' everywhere, or have to worry about not mistakenly indenting a line into a for loop or something, or to not mix tabs and spaces, or not being able to just freely break a long line into many.... Alas, I still have to use GDS in Godot, because there are no good alternatives. :) C# requires that I fill my computer with more and more .NET garbage. I'm not having any more of that.
But this is their strategy. You will be so dependant on their programm you will never change it cause it will be so hard to relearn everything. So the less one program has in common with another thats doing the exact same thing the better for the company that is the "industry standard"?
Completely natural, any new process will kick your arse initially. Sounds corny but make mistakes, and laugh at em. Your biggest hurdle is your expectations
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DarkDax/ . You’ll also get 20% off an annual premium subscription.
Update: Thank you to everyone commenting tips and pointing out useful API functions, I've learned so much more already! Keep sharing the info so we can all benefit!
I used Construct since 2007. Got to the point where I was building everything myself inside it, and decided to move to another engine. In the end I went for C with raylib, which is a framework, and I got to say, it's so reliving to not have to worry about engine's structure. At the same time, I agree, that doing something now takes somewhat longer, since I've got to design a lot more stuff myself. But it is refreshing that you know that it's your code and you have control over it.
14 years as a professional .Net developer specialising in C#. Have tried things like Unity and Unreal in the past and the big hurdle for me adopting them is their terrible interfaces and over complication of the none coding elements. Godot is amazing and I've picked it up pretty much straight away. And despite my hatred for indentation and the lack of semicolons I actually use GDScript over C# due to C# in Godot not being as up to date as well as GDScript just being really nice to develop in.
Super interesting. I initially found Godot a tiny bit clunky but found it much better over time. Definitely got used to it quicker than Unity (Unreal goes without saying haha).
Is there anything in particular you’ve found worse off with using C#?
I started using Godot with a Python background and found GDScript really frustrating until I decided to accept it for what it is and quit comparing it to Python. Then I liked it.
I want to say that with the latest 4.3-rc1/2, Godot Mono has greatly improved and fixed many issues, but it's still not perfect. I wanted to share this story as I made the opposite choice.
My journey with Godot began with a university project where I developed a SAS-like 2D game using GDScript 3.0.X. After spending several years working professionally with TypeScript, I decided to return to game development, aiming to rebuild my project in 3D. Initially, I started by rewriting and improving the old GDScript codebase, enjoying the familiarity and ease of use.
After a few months, I recognized the need for greater typing safety and a better developer experience (DX), which led me to decide on translating the entire project from GDScript to C#. With the assistance of ChatGPT, this translation process took around two weeks. This shift allowed me to refactor and enhance the code, resulting in a more robust and maintainable structure.
Transitioning to C# wasn't without its challenges. I had to relearn how to write my code, understanding the same concepts in a less intuitive way (e.g., the lack of @onready). I encountered several issues that slowed my progress, related to both Godot and C# in Godot. These included problems with corruption in the compiled C# code and node configuration issues around signals and resource classes, which required significant adaptation in my approach to building the project. Despite these obstacles, adapting my workflow was a necessary step to overcome the limitations and make progress. The 4.3-rc1 update has been a godsend for many issues I faced in my project.
Recently, I felt that the major challenges required to create good systems for my game have been fully or partially addressed. I've established a functional and scalable framework of reusable components for my game. This foundation has allowed me to focus on developing features and content that add depth and layers to the gameplay. Embracing the composition pattern was initially slow, as it required careful design of reusable components. However, now that these components are in place and scalable, I'm able to make progress on the bigger picture of the game, which has made me very happy to see.
I’ve also tried working with Unity and Unreal Engine but found them overwhelming due to their extensive feature sets and the steep learning curve required to get started. Godot, on the other hand, offers a more flexible approach. Its visual editor is not tightly coupled with the coding process, allowing me to develop the game closer to the code. This aspect of Godot, where I can code reusable nodes with minimal interaction with the IDE, is something I particularly appreciate.
With Godot, you can start small and gradually expand, unlike Unity or Unreal Engine, which often feel like you need to master a vast array of features from the outset. This has made my development experience smoother and more enjoyable. I do not regret choosing Godot or translating the entire codebase to C#. The journey has been filled with learning and growth, and the decision to use C# has provided the stability and scalability needed for my project.
@@maximefb2338 Yeah this is my problem with GDScript, it's great for quickly putting together a prototype or small game. But for anything that needs actual architecture, it just gives me headaches compared to the control I have with C#. Just the fact alone that GDScript doesn't have a "private" drives me crazy when in C# I make EVERYTHING private whenever possible to minimize the accessible surface area of all class to only what is absolutely necessary.
@@maximefb2338I want to use godot mono but the lack of intellisense for sharing of code between gds and c# is what's helding be back. How do u address this in ur project?
I want all the indentations, I like how it makes a stairway.
Okay, I’m convinced
Well you can't have them. They're mine. Sorry.
When I started using Godot, it was right after the Unity pricing changes.
There were a lot of things to get used to, but once you're over that initial learning curve, things just get a whole lot faster to do.
I haven't used C# in a project yet, though. I've just been knee-deep into GDS, and it's pretty easy to understand and write.
If you're willing to learn, do it. Dont be afraid to learn something new.
Thanks for sharing your experience. Initial learning curve can be frustrating, especially if you know how to do something in another tool already.
I might give GDScript a go at some point just to check it out!
Do you think you’ll ever try C# or do you feel happy enough sticking with GDScript?
@@DarkDax At this point in time, I have no need to use C# as I've been able to do everything I've wanted to with GDS.
However, I understand that C# can be more preformant in certain areas. So, it might be beneficial to learn its appropriate use cases with Godot.
If you're willing to lean GDS, the docs are always a great resource. I'd also recommend having a look into GD Quest and the newest Brackeys videos on Godot.
GD Quest, in particular, provides further explanations and use cases for stuff that the docs might not.
@@DarkDaxas someone who also came from Unity with a C++/C# background, gdscript was extremely fast to learn. In some ways it’s very nice to use, and imo can be a better experience as it’s more tightly integrated into the engine. But on the other hand there are features I miss. Like interface feature like in C# or multi inheritance like in C++, sometimes one level isn’t always enough and I do weird work arounds. At times I wish the language was stronger, but not often enough to switch to C#. I think being used to gdscript first when I switched makes switching to C# harder as the experience just isn’t as seamless 😅 also when researching more obscure tools with less documentation having to convert to C# syntax is just extra trouble I don’t want to deal with sometimes ¯\_(ツ)_/¯
Edit: I do miss my curly braces :<
Edit 2: You can do more then one level inheritance, idk why it didn't work when I tried it before, I must've done something wrong oops
The beauty of the node system in godot is that the hierarchy is actually a pretty good representation of what's going on in your game. Every element has a node. In unity, a single node in the hierarchy may consist of 50+ components, and from the hierarchy alone you could never tell. Also, the "nested prefab" feature from Unity (which we have waited for YEARS to finally get) just follows from the design principles in Godot. The downside is that the hierarchy can become visually cluttered faster, so keep things tidy and for lords sake, *name* your stuff in the hierarchy.
I remember, when learning Blender, someone saying "don't try to force it to be program it isn't. Blender is doing it's own thing" and I feel like it's the same for someone witching engines.
"witching engines" do they use duck typing?
@@ThisIsNotAUsername-v3oBravo!
I moved over to Godot, And managed to recreate a project that took years to make in Unity and managed to recreate it in a week in Godot. Partly because I knew what I was creating, And when I was trying to make it in Unity I had no idea how to program in general and let alone how to exactly make what I had envisioned in my head.
Areas have a method called get_overlapping_bodies / get_overlapping_areas, which gives an array of all bodies/arrays within an area. Not sure if this would help, but it may make it easier than keeping a separate log.
Imagine my face... thank you so much!
@@DarkDax The list you get from get_overlapping_bodies / get_overlapping_areas is the list from the past physics frame. For most uses that is good enough.
However, if you want to get an up to date list, or if you don't want to use a node at all, you can use a shape cast from get_world_3d().direct_space_state.intersect_shape (Addendum: that is capitalized different on the C# API)
The drawback is that then you don't have a gizmo/inspector to easily set it up, nor a debug shape (you can enable Visible Collision Shapes in the debug menu).
I'm not saying this is better, I'm saying it is tradeoffs. Addendum: Using the shape cast API might be a performane concern, so I'd advice to stick with the Area3D unless you really need it.
By the way, know that you can always make custom node classes that do it exactly the way you want (and that is not even getting into making plugins).
this has been my experience switching to kdenlive for video editing. it has some tricky hangups but it feels nice that my entire pipeline is open source now
Feel your pain there mate. Davinci has definitely been a hurdle. Not as much of one then I thought but the different ways of doing things goes into what I talk about here with the frustration of knowing how to do what you want in one thing but being strangely lost in another tool.
Hope you're getting on well with your new open source tool set!
@@DarkDax i wish i could put ease-in-out on a learning curve! haha
Wow it isn't like I am downloading the open source one right now, that would be crazy
@@DarkDax That's really cool! I actually use DaVinci Resolve to make my videos - still learning, though, only so much I can do with $0 🥲
I swapped from Unity to Unreal a couple of years ago, and this mirrors my experience pretty much exactly. I had a very hard time getting the Unity way of doing things out of my head, and that made it just that much more difficult to learn the new engine. But, slowly but surely, I started picking up more and more of the 'correct' patterns and things starting clicking, which got me even more excited, which led to even quicker learning. It feels like the learning starts slow, but the growth is exponential, so it gets so much faster as you do it.
Coming from an art background with godot being my first game engine I really like the node hierarchy function of it! I'm use to folders in folders in folders so wrapping my head around the fact that they are basically just folders with specific functions was very intuitive.
Raycast node has a shape variable, that's how you can quickly use shape traces. Also there have been community tests, using the node for raycasts is faster than doing it programmatically.
Ah thanks for the info! Will stick to the node 👍🏻
I have been using Godot for a year after the Unity fiasco. I decided to stick to C# and I'm very happy with it. Once you get the nodes concept, that´s basically composition, everything makes sense. It´s pretty fast to load and compile, to debug, so you save up a lot of time here. Also for the UI, once you get how anchors work, it makes your life so much easier. Must say I'm only using it only for 2D at the moment.
Totally agree. I know it’s more composition based but I still find myself ‘breaking’ that now and then. I’m definitely getting better with it though!
Godot has really impressed me so far!
UI theming seems quite intimidanting, however. I have yet to grok it and the documentation isn't being very easy to digest.
I really agree with the c# over indentation. I think the thing that frustrates me the most though is the use of magic strings everywhere. That I have to use GetNode and type in a string path makes things more brittle. If I change a node's name to make it more readable, it could make my code stop working without really any compile time check.
Godot wants everyone to make atleast 10k child nodes for there parent :3
Godot is a Rabbit confirmed
It's "their", not "there".
@@fawzanfawzi9993 eeh ¯\_(ツ)_/¯ ya still got the meaning of the sentence
On the topic of C# vs GDScript, I think you do what makes you comfortable. I believe that once you learn programming concepts, it's easy to just learn syntax and some quirks and use whatever language however I am a hypocrite because I don't want to learn the nuances of C++ and just use C. Kinda the same thing with Godot vs Godot C#.
So ultimately this comment was just for boosting engagement and admitting my flaws on a public forum.
Same here - once you understand the mentality for programming, for the certain paradigms you can 'feel it out'! Also thanks for taking one for the team 🫡
It's not just syntax, the languages have different feature sets which is very important.
@@NihongoWakannai
I agree.
But a mindset I want to focus on is that those feature sets are more like quality of life improvement (unless you are talking about Pandas or some hyperspecific language for math or text parsing).
Like with my example for C, it can do everything C++ can. Can it make virtual functions and classes? Well sure, if you break down what those are to base concepts. Like assembly.
To me coding languages are like, How do I make an array? How do I concatenate a string? How do I pass default arguments?
It's less about a huge toolbox and more about knowing how to make four tools do everything.
I also do a lot of unsafe programming shit with python and C my first go around.
@@NickAndWolf Quality of life is SUPER important. That quality of life can knock months or years off of your development time. We're not coding here, we're programming. If you don't have a language that allows you to write robust program architecture easily then you're just shooting yourself in the foot.
Like GDscript having all functions and properties be public is a nightmare. Everything being private by default in C# allows me to significantly reduce the exposed surface area of my classes which helps to make the code self-documenting and very easy to debug.
Common Godot Knowledge
GDscript : Light work
C#, C++...: Heavy work
Feels like it haha
Correction:
GDscript: A Light Jog
C#: A Decent Workout
C++: OLIMPIC WEIGHT LIFTER.
Lua >>>>>> gdscript
Mate, I löve Lua, but now you're just aggroing beehives for no reason. It's painting a target on Lua's back, really. Like you're a 0/12/3 teammate.
@@ethanbuttazzi2602 doesn't godot support native aot now? if thats the case then there wouldn't be a difference between C++ and C#
Godot usage in gamejams has almost doubled over the last year, judging by GMTK's data. So you're not the only one lol
It’s insane to see. I think it’ll only influence more people to move and I think Unity needs to do something to pull their thumb out.
1:52 DUDE. Yes. thats the EXACT feeling when you first open ANYTHING for the first time. I have that exact feeling when i first opened Blender, Unity ofc, and yes i even had that feeling when trying to learn OBS years ago.
Seriously, opening blender that first time had me quaking hahaha
I used Gamemaker for 2 years, Unity for 5 and now Godot for 5(nearly)... And while I'm a total Godot fanboy, I still wouldn't say go from Unity to Godot if you're doing 3D, Godot right now isn't going to hit AAA like graphics and if you're okay with graphics that aren't cutting edge then still Unity seems awesome for 3D while Godot is catching up.
However if you're doing 2D... GET ON GODOT! It's night and day different from every engine I've used (since programming in DOS to now)
Very cool video!
Also, love the background music choice (bg&e❤)~
Thank you! Gotta love a bit of BG&E. God I miss Pay'j.
Fair and balanced coverage. For my use-case the main concerns I had were ease of use, Android builds, and performance. My first game was made in Unity about 10 years ago, I had fond memories of the easy cross-platform builds and mobile performance. This time I tried Godot and built a prototype and had it running on my phone over a weekend. The scrolling was jittery and horrible, but otherwise I was happy with the workflow, the scripting, everything is easy to pick up and modify.
I wasted a week first trying to optimise my scene before porting it all to Unity only for it to be even worse there, with about 15 fps and stuttering. Finally went back to Godot, looked closer, realised the jitter was a physics issue, did some googling and found a setting to change to set the physics FPS and screen FPS to be the same (there are other fixes too, but this was good enough for me for now).
Performance was my final main concern and Godot has knocked it out of the park! Now I just have to knuckle down and try to port my prefab-thinking over to nodes... Here goes nothing I guess!
Honestly the node way of thinking about things really did make think about things for a hot minute. I’m still probably doing some things wrong (oh well) but I’m really enjoying the engine so far. The comment section here has been great help too.
Hope your journey continues to go well!
Hi, as a debutant/newcomer into game making, Unity was kind of... like if you were passing from a bicycle (Scratch) to an fighting helicopter (Unity) when by the other hand, Godot is like learning to drive a car.
That's the first experience with the engines i'm talking about ,o,
For raycasts, just make a static class with helper functions that automatically adds and reuses a raycast node. I've made mine function more or less identical to the unity implementation. There's a blog post floating around complaining about the default physics querying functions because of how inefficient they are compared to the node implementations, so using a helper static class you get the best of both worlds.
You can directly access the underlying physics server which shouldn't be slower than a node. If you're making a wrapper class then you may as well do that. It's recommended in the "Optimization using Servers" article in the documentation.
@@NihongoWakannai From memory the problem with using the physics server via C# is that the underlying dictionary objects you get back cause garbage with no way of supplying your own buffers and calling into the engine via c# is just fundamentally slow. It's fine if you only do a call here or there but adds up quickly if you do alot of raycasts per a frame. Apparently you don't get the same drawbacks by using the node implementation though since it's all handled natively. It's been a while since that blog post dropped so it's very much possible there has been improvements since then, but I won't know for sure without benchmarking.
Good insight, tbh.
I am trying to finally complete a game in Unity, but every like half a year I get into Godot to see all the new updates and make small prototype to develop some skills in that engine over time. Somehow my initial struggles were not as painful as some people describe it. First time when I used it, v4.1 Ii think, it was hard to transition from components to nodes on my own, but after following a few tutorials in a day or two, paradigm "everything is a node/scene with single simple purpose" started to just look like Single Responsibility Principle in visual form. Everything and anything is a specialized lego piece and I find that comforting and practically useful. I forget what game objects do all the time, seeing what thing does at a glance on hierarchy saves some time.
Also, on a side note, Unity supports C# asynchronous stuff via async/await workflow for at least 3 years now, even though its tricky to use correctly and to not produce multiple memory leaks or brick your app untill pc restart (totally not speaking from experience).
Can you make a video about moving from Godot to Unity?
I have a background in coding simple projects completely unrelated to games or gaming. But recently I’ve been inspired to learn a game engine. I poked around unity and unreal, but Godot clicked with me out of the gate. I am stoked to embark on a game development side project once I get the hang of the engine. Seeing so much support for Godot has been awesome to see.
I love Godot because if I get an idea that I want to try out, I can start the editor, open a project and be coding within seconds. Depending on the project, this would take several minutes in Unity and ten minutes in Unreal 5.
Less of an issue when constantly having the editor open, of course. But still a pretty big factor for me, personally.
Your use of Crash Bandicoot The Wrath of Cortez music at the beginning gave me such a nostalgia trip lol
10:40 It's just ShapeCast3D, another node type. From code look at intersect_shape in PhysicsDirectSpaceState3D class.
Also code api for raycasting is quite old, and it is known that it will be refactored some time in future, so hopefully it will be a little more ergonomic after that
Ahhhh thank you so much letting me know - I don’t know how I didn’t see that haha. Glad to hear the raycast API is being looked at!
Raycast refactors will be great, 4 already has so many nice updates compared to 3!
What's funny is the node system was practically how I was using Unity/Unreal before I settled on Godot.
I am only hoping that Godots 3D improves significantly. I am not asking for unreal levels of course but decent graphics out the gate.
Well it’s super interesting how games like Road to Vostok look insanely high fidelity on an engine not necessarily focused on providing that. Just shows its versatility!
Native fbx with 4.3 and blend support since a lil while ago :) I'm not sure what exactly you mean with "decent graphics" - what I've seen even in earlier versions of Godot was anything but indecent xD
I know the "Dogs Life" theme anywhere...what an interesting project to recreate in Godot!
An absolute underrated gem. My god I love that game haha
I've loved Godot. Skipped Unity after a short little bit, and I have made more progress than I ever have in any other project. The UI is so clean, and all the methods make sense IMO... Love your video!
Godot is very good - I feel some UI is a little clunky but the whole experience gets even better each update! Glad you’re loving it - thank you!
I've been meaning to give game dev another try. Maybe it's time. I just hope C# support has come further than last time, especially in the documentation.
Go for it!
There goes my hero, watch him as he codes...
Now, seriously, almost spitted out my coffee at the IndentGate news bit, as I too am an Unity dev that really hates identation and lack of semicolons and variable types.
Loving to use Godot with C#, tho. About async functions, I'm using GDTasks. It replicates UniTasks almost fully and has been wonderful to code asynchronous methods as I would in Unity.
Great video dude! It's been really interesting to see your take on the switch as we both went through it together. I think we hit a lot of the same obstacles. Once the new concepts clicked for me with Godot and the node system, I have found it to be easier and faster working in Unity. I always found myself getting a little too lost in the code with Unity whereas with Godot it's easier to see the bigger picture and keep progressing your game overall. I know you preferred to stick with C# which makes sense with your experience but for my just making the switch along to GDScript as well was a welcome change and I think it is just such a great compliment to the node system.
I like the sponsorship dude I think Brilliant is a good fit for your channel.
Honestly man, going through it at the same time was great for motivation and not feel completely in it alone haha.
Completely agree about being able to get on with what you want rather than getting lost in the implementation.
I’ll definitely have to give GDScript more of a chance soon - a lot of people really do praise it how much it complements the philosophy of the engine.
Thanks 🙏🏻 I definitely thought they were fitting for this type of video!
C sharp async await IS THE SAME as any other async / coroutine setup. Unless you spawn another thread (which gdscript actually allows natively), C# async is single threaded and pauses / resumes coroutines just like gdscript. This can be proven very easily with minimal code. Async is NOT multithreading.
Thanks for the info! So far I’ve only used them with Tasks so that’s where I might have crossed wires!
@@DarkDax A Task is like a Javascript Promise, it's a structure that stores information about return value, execution context, etc, and allows functions to be mapped asynchronously to store their state for later so they can be paused and resumed. For example, you can map a function to a task's ContinueWith, so that when the task completes it begins another one. Godot doesn't have its own "Promise" implementation but it can be made using signals or Callables.
Obviously as a huge Godot fan myself I was hoping for a "Everything is perfect and I loved the switch" which I've heard from other game developers. But realistically, this is how the experience will be for most people. I think the value in this video isn't the fact that we have one more Godot user, but rather that other people looking at this don't try to switch to Godot with the expectation that it's just Unity but blue.
I’m glad you feel video was able to bring that to the conversation. I think Godot has been sold in some conversations as the Unity replacement and I worry people will give up if they struggle to get into it straight away.
Hopefully this video helps highlight that teething issues are all part of the transition!
I used many different programming languages for small programs. My journey in a List DOS, QBasic, NASM, Windows 95/98, Linux Debian 2.2, Windows ..., C, Java, PHP, VB, SQL, RegExp, Python, C#.
C based languages for localized keyboard layouts, are a bit annoying because you have to press shift all the time. For semi colons, colons, brackets, parentheses,braces, points, gt, pipe and many other symbols. Especially Basic dialects have the END Block keyword and return key at the end of a statement reducing the special keys to press when coding.
glad you're taking advantage of the C# put in for Unity refugees, but you may want to give GDScript a serious shake at some point- it's a lot less wordy and has a lot more conveniences built in to save you time. Epic is going in the same direction with their upcoming Verse language.
Yeah! It's definitely something I want to try out at some point. I figured I'd learn the quirks of Godot first and then dive into GDScript - it probably won't make a difference tbh but at least I don't feel completely lost by C# atm.
I'll give it a go at some point, thanks!
Incidentally, Godot has supported C# (to one extent or another) since before the runtime fee fiasco.
"a lot less wordy and has a lot more conveniences" that's exactly why it's bad. Convenience isn't good for large scale game development when it comes at the cost of unstable architecture. Having things be wordy means they're extremely well defined and you have way more control over your architecture. Just the fact that every function and property in GDScript is public is insanity.
Thumbs up for wearing shorts! 👍
Long live the knees! 🎉
Let them free! ✊🏻
Pretty sure you can still use ; in GDScript. I think you can change it in the settings
Oh that’s interesting - Godot and GDScript just feel so very accommodating
Great video! It was really interesting to hear your experiences moving engines. Sometimes it feels that people get too dug into their chosen tools and forget it's about making a great game.
Glad you enjoyed it! Sometimes it’s great to shake things up a bit… sometimes maybe by your own volition 😅
There is a shapecast node but also you can do it from the space state via an intersect_shape query. Look it in the docs, its part of the PhysicsDirectSpaceState just like the raycast.
I also switched from Unity to Godot, and prefer Godot. I have used both to create data visualization tools, not games, and Unity simply didn't have the features I required - the ability to read/write arbitrary files of arbitrary formats with full file-pickers, accept file dragging from the client desktop into the "game" (not just the editor), and a full network stack (UDP and TCP), so I can pull data over the network from sensors in real-time. Unreal wasn't ever under any sort of consideration for our use due to enterprise licensing issues that even predate the Unity events.
I also don't mind the indentation thing - I indent my code in more-or-less the same way that GDScript wants anyway, even in languages that don't require it, and I've never been a big fan of syntactic noise.
Great insight, thanks for sharing! It’s a brilliant reminder that engines can be used to make more than just games.
Do you see yourself exploring other engines at all or have you found your home with Godot?
@@DarkDax I haven't yet run into a roadblock with Godot. In fact, I found myself with an issue that I had to work with some geometry on a planetary scale (modeling a system large enough where the curvature of the Earth is meaningful and must be accurately represented), and the stock Godot single-precision version wasn't going to cut it, so I simply recompiled it for double-precision and problem solved. As far as I can tell, you can't do that with Unity or Unreal - the normal trick of rebasing the origin wouldn't work for me, since there are various things going on at full scale, not just locally.
I'm hoping that, as a project, Godot follows the same trajectory as Blender.
Yeah, prototyping simple projects in Godot is fast, prototyping complex projects in Godot... the difference is exponential. I am still working on closing my gameplay loop today.
The thing is the asset store carries you across major thresholds like coming to prototype especially on really deep projects.
On the plus side I can say my API development experience is not many times stronger than when I did Unity.
Raycasting via code is crap in Godot, but once you wrote the code, you can neatly tuck it away as a utility function.
6:58 you can make a bootleg interface/abstract class (god knows what the difference is) by giving the script a class_name and adding your "abstract" methods to that base script, and later extend that class.
Based.
There's also has_method() to check if an object has a function without needing it to extend a particular class
In gdscript you can't inherit from multiple classes at once which kinda defeats the purpose of interfaces.
@@crabsquid325that doesn’t really defeat the purpose of interfaces, even in C# a class can implement multiple interfaces. However the problem I think is more that GDscript does not enforce implementation of abstract methods so it doesn’t give you the same kind of safety.
@@carsonreader515 'Defeats their purpose' as in 'you cant just use classes instead, theres no point', interfaces were made to solve the diamond problem(which you cant run into in gdscript) while still enforcing multiple(!) implementation contracts. Trying to emulate the behaviour of just one interface seems pointless to me.
"Home sweet home" from Beyond Good and Evil as a background music?? Now that's what I call good tastes. Glad there are still people out there aware of the existence of this master piece of a game (Great video btw)
One of the most underrated games ever!
I use numerous raycasts and have them set to different layers, keep it easier for me when doing a bunch of detecting.
I do something similar for my current project where I’m trying to get the average normal of the terrain 🥳
Thank you for making this video. As a full time Unity Dev I've been wanting to expand my capabilities at some point and It's useful to learn from others you have jumped ship.
But am I taking crazy pills. I use Async methods and threading all the time in Unity, right?... Confused. Also I would definitely miss not having the Job system using other engines. DOTS is one of the main reasons I have trouble committing to learn something else.
Update: I just learned that the Task.Run() initialization appears to run on a separate thread but otherwise you would have to explicitly create a thread or thread pool to run the logic in parallel. I don't know how I didn't know that up until now... Explains a lot.
Also, I should mention since the UnityEngine only runs on a single thread, you do have to handle the logic you run in parallel carefully as you can't make Unity API calls from another thread. You can use a MainThreadDispatcher or design the code to handle Unity calls after the parallelized logic is done. This is part of the point of the Job system, so consider using a job instead. (its also safer.)
Sorry for all this Unity talk on a Gdot video...
16:27 C# is a PitA. GDScript's similarity to Python is one of its biggest appeals to me. I'll always choose meaningful whitespace if I have the option
I'd have to look at the Godot API, but the extra work to iterate over the array of collisions sounds like something that could be turned into an extension method that basically does the same thing as the Unity API, except maybe with some more arguments.
So qhen you moving back?
After this project I'm currently working on, I do plan to try out Unreal Engine next!
A coroutine in unity is very much async. You can create a custom yield instruction that goes away does things on another thread and then comeback and let the couroutine continue on the render thread. The very defintion of async
Following Brackeys tutorials made it so much easier to learn
The King 👑
11:31 Infact you will become an Alien after learning Godot. I've enjoyed this video a lot. Cheers
components and nodes are the same thing
wowzers!
I love that I can use node for raycast in Godot, as I can easy see where raycast is potining,
instead of realing on Debug.DrawRay like in unity that is easy to mess up.
That said I’d love that Debug Ray! Don’t suppose you know if you can do that in Godot?
@@DarkDax Sorry, I don't know how to, do that in Godot, as I don't even bother to find, as I wrote I prefe using Raycast Node.
@@DevJeremi no worries at all! I bet there’s a way - I’ll have to find it haha
async functions guarantee that data that is processed asynchronously are resolved before moving on to the next piece of code.
cool video.
I might be misunderstanding you but you can definitely for-each over the results of a raycast query. Also I think you can give a collision shape to a raycast node to have it cast the shape instead of a point? Or maybe there's a dedicated shape cast node.
You can also do a physics query to check an area for objects, similar to doing a raycast through a query instead of the node.
Also, indentation is the more humane programming paradigm. Think of all of the semicolons that get to live long, happy lives in the wild now
I must not be looking in the right place because I can't find where you can foreach it. I'll keep looking! Thanks for the heads up!
I think that's the only point about indentation that might have changed my mind. So many needless semicolons used 😭
@@DarkDax Well now I've managed to confuse myself, I just checked my code and realized that an intersect_ray() call only returns one result. intersect_shape() is the area check one I mentioned, and that one returns an array of results that you can for-each over
@@coldwarpgates622 ahh okay thank you so much for letting me know!
Unity has had async functions for a long time. They are a bit wonky because how synchronization contexts in Unity are set up, but they are there, and can be used out of the box
But unity is on C#8 with some C#9 subset, on .NET 4.8 😢
Godot works perfectly with C#12 or 13, and .NET 8 or 9, with all the extra speed etc.
The component system is the best, I dont understand why not every engine has it
component for lyfe, node based suck a big time lol
I've found Perplexity AI is incredibly useful for learning new software
Godot is only getting better from what I’ve seen. And fast too. I’m sure by Godot 5 or 6, you’ll see C# fully compatible. And 3D will be = if ! > than Unity (beating Unreal in 3D, although? Not sure anyone can. Lol).
So, there’s a lot to look forward to. Looking at UA-cam tutorials, with ones made with Godot 2 or 3, I see massive changes now with 4. So, Godot is definitely an up and comer.
7:27 The reason your wrong is because it makes the code easier to read(in MOST cases)
Would love to hear your thoughts on Godot 4.3 now that it's officially released.
It's a pain in the ass but you can do it man, it'll be sooo much worth it in the long run
Thanks mate! I’ll keep trying!
I'm a Java boy, and I have indentation too.... But it does live rent free in my brain now
7:19 yup im with you in this one, i dont hate INTENTATION but if thats all that defines were something begins and end, its stupid, the brackets or end points are always better.
brackets is somewhat a thing, ive seen many multiline if statements
@@ariffirdaus5376 well ye but no, my problem with pythonesque languages is the lack of a end token that can be a closing braket or a actual "end", but the lack of it makes it very difficult to read code with more than one level of indentation, at least for me.
Frankly I love Godot because it doesn't feel nearly as bloated and clunky as Unity's Editor.
God I LOVE that every project needs to have at least a GIGABYTE in default packages before I can even START making a game. :)
Don't like indentations? You should indent your code any way, despite of language! For sake of easy to read.
GDScript (with Python) just give syntaxial meaning for indents.
(I definitely do indent in general haha)
I hate indented languages because I like to rely on my editor to automatically indent all the code. With an indented language I have to manually adjust indentation levels whenever I move code around to ensure it's at the right level.
With braced languages I can just move code into the right place and let the editor indent automatically. No tedious and error-prone whitespace babysitting.
i hate indentation and lack of semicolon
I never understand the hate against indentations. Look at 4:41.. It's C# with indentations! So if everyone uses them anyway, why is it so bad just to have them required?
I came from Unity and C#, now i use Godot and GDscript... I love the node system and the composition based approach of the engine. I instantly felt at home in GDscript. It is far more accessible for me than C#.
The more I use it the more I’m getting used to thinking composition first. It’s good from a mindset perspective too since it reinforces the idea of single responsibility.
Indentation is great. Everyone should love indentation.
Hating significant whitespace is very rational, though.
omg you just unlocked in me the memory of dog's life for ps2, great video though
Just remember why you do what you're doing for, King.
I think Unity VS Godot is comparable to a toy box VS a box of single lego pieces. If you want a ferris wheel, you gotta build it in order to spin. Not just get a spinner toy and put people in there. It is understandably frustrating for a lot of people, but when you become comfortable with it, you start feeling rewarded at a rapid pace, and you can build some massively useful things. It's hard to say a spinner toy will suit every moving object you need or want, right?
Have fun and good luck in everyone's Godot endeavours :D
Bro I started to make a game in unity and now people are telling me to move to Godot 😭
Use the engine you want to use. If you like Unity and it does what you need it to go for it. If you want to move to Godot for its community then go for it!
Don’t overthink it, just make games!
I think no one will argue about lighting in games?
So, godot currently has the largest number of acceptable lighting options. Unity has an outdated enlighten and mediocre lighting baking. Unreal has a shitty flickering lumen and good baking, but crooked uncontrollable lightprobes.
I switched to godot primarily because of the lighting. Initially I had a bias towards godot, but practice has shown that it is a very promising and good engine..
Now I know good and well that I'm not crazy, is that some good 'ol crash bandicoot I'm hearing?
What I dont like in Godot is the weird coordinate system, where positive z does not go "into" the screen, but comes out of the screen. Messing up all kinds of simple math calculations by switching rotations. The camera is basically looking into the negative z direction ...
I started with Blender and Z is up. Then I started using Maya with Y up, same as Godot. Then recently I started learning Unreal and Z is up again. Lol
Anyways Y-up is probably the right choice because of how ubiquitous Maya is. I wish they had gone with Z up just to be like Blender
@@josephbrandenburg4373 I never had so much problems with Z up or Y up. The problem in Godot is, that Z ist mirrored. So looking along the x axis or y axis in 3D space, a positive axis number goes away from the camera, but looking at the z axis a positive number goes towards the camera. And that makes not sense as convention. Its unnecessarily confusing. They should have just stuck to the convention Unity uses, as this is their direct competitor.
@@vast634 wait I didn't know that. That makes absolutely no sense. What
No word of a lie - this broke my brain for a good while
It's a convention from graphics programming where positive Y is down because CRT monitors started in the top left and scanned right/down, and positive Z is towards the camera because positive Z means an object gets rendered on top of another.
It's dumb for this to be used in a game engine which is focusing on creating virtual worlds in which it makes much more intuitive sense for up and forward to be positive values. I'm pretty sure every other game engine and 3D software realized this when making their software.
How can you hate indentation if you still indent in c# even if you use curly brackets
😱
Respect for the music from Mario64 ;)
Being more open is fine, but when i go from Maya to Blender, there are a lot of choices that just seem dumb. Like what you have to do to get a uniform, bevel for example, is just insane to me XD The shortcuts are a mess. Even just the basics. Like why can i not graph multiple materials. Or: In Maya, translating, rotating, scaling, selecting is all in QWERT. In Blender it's .. uh.. G annd S... and R? S for scale and R for rotate, okay, it is dumb to do that based on an abbreviation instead of intuitive placement on the keyboard but okay, uncomfortable but okay. But then you have G for translate. It's not consistent at all. And each tutorial for Blender is like "Press shift C, ctrl alt T, then shift F12 and tap D twice", you know? So there is a balance between "open mind" and "oh my god make it make sense at least" xD
Yeah... this is why I never used Unity in the first place, and why I quickly ditched 3ds Max in favor of Blender over 15 years ago.
Inevitably, I'm going to end up on all open source software anyway. So why not just start with only open source software and never learn the proprietary solutions in the first place? This was a great Idea with Blender, and pretty sub-par idea with everything else and a downright terrible idea with Photoshop. Probably lost a decade of potential productivity honestly... but eh, that's the price of holding true to our convictions.
😂 that ending though!!
Great video! The thing that really annoys me is people trying to diminish Godot as it was objectively worse than Unity just to validate the fact that they do not want to change engines. It seems kind of a weird thought process that actually some of my friends have that's like:
- Unity is bad as a company, I should change engines;
- Best option is Godot, I should use it;
- But I don't want to change engines because it will be a pain;
- If I convince myself that Unity is objectively better, I will have a good reason not to change;
- Therefore, Godot is bad lol XD.
I absolutely hate C#... but I'm right there with you about indentation based languages. It gets so annoying to have to type 'pass' everywhere, or have to worry about not mistakenly indenting a line into a for loop or something, or to not mix tabs and spaces, or not being able to just freely break a long line into many....
Alas, I still have to use GDS in Godot, because there are no good alternatives. :)
C# requires that I fill my computer with more and more .NET garbage. I'm not having any more of that.
6:00 where are my VRC boys at?
More on C# in Godot please.
you can use groups with ray casting
But this is their strategy. You will be so dependant on their programm you will never change it cause it will be so hard to relearn everything. So the less one program has in common with another thats doing the exact same thing the better for the company that is the "industry standard"?
Completely natural, any new process will kick your arse initially. Sounds corny but make mistakes, and laugh at em. Your biggest hurdle is your expectations
“The hardest part is learning them in the first place.”
Me who’s still trying to make a single game: “well s#!t”
You got this mate!
The only good identation is -3!
Long live to DreamBerd!
I also don't like indented languages.
Braces just looks cleaner for me.
Maybe partially because I'm free to organize my code in my own way.
I don't have strong feelings regarding indentations but I miss semicolons ;(
Also GDscript, being easy to understand, has helped me learn OOP
BTW, not sure if it is still the case, but Godots c# is slower then GDscript.
really? if so then it's no point to use C# in godot except for familiarity
@@Luluskuy Yeah, and last time I've checked, which was maybe couple of weeks ago it's not fully implemented yet too.