Switching To Godot... How It Went?
Vložit
- čas přidán 26. 06. 2024
- Last month, several prominent Unity developers announced their intention to either move to the Godot game engine, or to investigate the possibility. Three of those developers documented the process, so we can see how the move from Unity to Godot went for these developers, the good and the bad. The developers or games in question are Mega Crit, Road to Vostok and Caves of Qud.
We also get an update on Project Unifree announced by AppLovin as a tool to move people from Unity to other game engines. Short story is, it was a PR stunt and nothing more. This is unfortunate.
Links
--------
gamefromscratch.com/developer...
-----------------------------------------------------------------------------------------------------------
GFS Patreon : / gamefromscratch
GameDev News : gamefromscratch.com
GameDev Tutorials : devga.me
Discord : / discord
Twitter : / gamefromscratch
-----------------------------------------------------------------------------------------------------------
Time stamps
----------------------
0:00 Introduction
0:22 MegaCrit Dancing Duelists Game Project
1:25 MegaCrit On Evaluating Godot
6:54 Road to Vostok
7:26 Godot Port Update #1
13:41 Godot Port Update #2
18:14 Caves of Qud Porting Saga (Brian Bucklew)
20:58 AppLovin Project Unifree Status Update (booooo!)
21:48 Conclusion and Recap - Věda a technologie
Links
--------
gamefromscratch.com/developer-experiences-moving-to-godot-from-unity/
-----------------------------------------------------------------------------------------------------------
GFS Patreon : www.patreon.com/gamefromscratch
GameDev News : gamefromscratch.com
GameDev Tutorials : devga.me
Discord : discord.com/invite/R7tUVbD
Twitter : twitter.com/gamefromscratch
-----------------------------------------------------------------------------------------------------------
Time stamps
----------------------
0:00 Introduction
0:22 MegaCrit Dancing Duelists Game Project
1:25 MegaCrit On Evaluating Godot
6:54 Road to Vostok
7:26 Godot Port Update #1
13:41 Godot Port Update #2
18:14 Caves of Qud Porting Saga (Brian Bucklew)
20:58 AppLovin Project Unifree Status Update (booooo!)
21:48 Conclusion and Recap
I am following one of developers who is porting from Unity to Godot and it's quite interesting. He makes update videos on the more interesting things that he encounters during the process. czcams.com/video/ai0Sdhb-yEo/video.html ( dev vlog part 7 )
how about cryengine its also a good alternative for unreal and unity, i think
cryengine is more for AAA games compared to unreal the issue with cryengine is dying slowly no documents update its a dead engine less resource for learning which means hard learning curve @@shadow6161
Mike, I love your videos but I wonder if maybe you could do shorter summaries in the future instead of reading entire paragraphs. I know it would be more work for you but it would result in shorter, more concise and to-the-point videos. Sorry for the criticism but thank you for the consistently great videos.
Bro the dev of "caves of QuD" is a madman
- import assets
- copy over all the code
- fix the bugs
- game just runs
what a gigachad
Well, most of the code of that game is engine-agnostic, as he only used Unity to show some characters.
Honestly the road to vostok guy is amazingly talented. His ports to godot is the best 3D power advertisement for godot ever made till now.
Fbx that!
My biggest issue with Godot is that 90% of tutorials older then a year are completely outdated due how far the engine has come since than.
It's a double edged sword, but I hope more devs start making more Godot specific tutorials.
@@kmouratidis not sure if that's relevant, shader languages are generally very similar across engines, and what I think they talk about more engine specific things, best practices, idiomatic code, newer features, which can be more difficult to carry over to new version if there were non-backwards compatible changes, or the tutorial used workaround that isn't needed/doesn't work anymore. But generally I agree, that's good skill to have in general
The documentation is so good just try looking it up, you may find you don't even need a video tutorial.
@@anicepineapple9067 Yes and no. Some parts are well documented but others not so much: I was missing up-to-date docs for GDExtension and for the audio sub-system in particular.
@@kmouratidis - This is true. My first foray into 3D was following Imphenzia’s ‘The Most Basic Unity Tutorial I’ll Ever Make’, and then doing it again in Godot.
older than*
The fiasco was already a MONTH AGO?! man, what is time.
Since COVID, time has managed to pull off this wonderful trick...
It manages to fly by at amazing speed, while being glacially slow while doing it! It's so odd, day to day it feels like so much is happening, like theres 58 hours in a day. Then you blink and it's the next calendar year.
I can’t believe I’ve been trying to do game development since the first COVID lockdown in March 2020.
It feels like both ‘just last year’ and ‘a few decades ago’… and then I look at what I’ve created and think ‘Is that all you’ve achieved? Just give up now, you hack!”
(FYI: a meme-based asteroids clone, the barebones beginnings of a Metroidvania, a clicker puzzle god sim, and a crappy local two-player 2D snowball fighting platformer game… all done in different engines)
Really hoping Road to Vostok can pound through his port as quickly as he thinks he can and get a new demo out there.
Brian's megathread is so entertaining 😄
Also quite educative.
I had already started messing with Godot before the Event. It really just cemented my plans to go all in with it going forward.
for me, the timing of the schism was fortuitous. I had to take a break from gamedev to focus on my job and my health. I was just starting to download and update my tools again when the schism hit. Gave me the chance to look at both Godot and Unreal, bot of which are great. Unreal does so much for you before you even start, but it's a big fat pig of an application and so are the games it makes...and once you have your own framework put together in godot, well you don't need all that unreal fatness...I ended up with Godot and so far I am very happy with that decision.
i had hoped they would transfer the engine to the Mozilla Foundation and make the files copyleft so they couldn't rug pull newer versions
@@joshallen128 Thank Godot they didn't.
@@joshallen128 Godot still has strong ties to the SFC and the Godot Foundation has pretty much copy pasted the SFCs policies for their own. They are in good hands and can't do a "rug pull."
Tbh, you gotta have some balls to throw all your code into a different framework and face the tsunami of errors that it brings. It's not like you can just run the game once in a while to see how things are working. You're gonna be in the dark for a while.
95% indie games can be done in Godot, 4% need custom solutions, 1% needs Unreal fidelity with performance.
Exactly
Godot for 2d, unreal for 3d. Godot is just so awkward for 3d
@@LeoStaleysimple stylized 3d is fine in gd for anything more than that, I agree👍
@@LeoStaley Neh, Godot can do 3D just fine. I admit the asset pipeline for 3d is a bit less refined but otherwise no biggie.
@@xormak3935 you can tell you've never done any high level 3d stuff in Godot. The statement you made is highly untrue and I suggest you either learn or do more research on the subject. Godot can not handle high level 3d content. I agree Godot for low poly stylized 3d or for 2d games. Unreal is king of 3d and if your looking for an engine for high fidelity games Godot is not there yet. There's O3DE, stride, flax just to name a few of you want higher fidelity 3d engines.
honesty this whole situation has had me getting into learning how to make games, plus your content has pushed me towards moving forward and seeing where this goes. Wish you the best of luck and success!
I switched to Godot from Unity at the start of the year, so I used version 3.5 for my first project in the engine and updated to 4.x for my current one. Haven’t tried making a 3D game yet, but overall it’s been a lot more fun to develop with than Unity! Working with text and fonts was kinda rough in 3.5, though, and I’m still waiting for CanvasItem shaders to get per-instance uniforms.
have you experimented with other open engines like open3d engine from amazon?
--"I’m still waiting for CanvasItem shaders to get per-instance uniforms."
Could you elaborate on this? I may be fuzzing on how you're using the terms and misunderstanding. If I'm not, I might be able to provide a solution for you, but I might be reading you wrong.
Haven’t tried open3d, but I’d rather not work with more than one general-purpose engine at once.
And I’m waiting for per-instance uniforms for CanvasItem shaders so I can use a shader to tint sprites a solid color. I know you can use the modulate property in shaders but I’d prefer to keep that separate for transparency, and making the shader resource local to the scene seems like it wouldn’t be particularly scalable; that’s a separate instance of the shader running for every object that needs to be tinted.
I implemented solid tinting in my first project by making white silhouette variants of the spritesheets and using those as overlays, but that setup isn’t ideal for a few instances of 2d skeletal animation in my current project. I might be able to rig up something using a subviewport? But that seems like overcomplicating things when I know that instance uniforms are already a thing for 3d shaders and saw there was some activity on the repo about making them work for 2d as well.
Awesome to get this sumarry, we also started doing a devlog series for porting our Unity Game to Godot, though we are using 3.5.2 because of the export limitations.
It has worked well up until now and we ported the whole thin in 4 weeks, (plus some major refactoring since the project was born out of a game jam XD)
Such a great perspective on trying to establish future options! We all have our biases though I feel you are doing an excellent job of looking at options in an eyes wide-open frame of mind. 👏👏👏
I did essentially what the Qud dev did with my port, except I didn't do the entire code solution at once lol. I brought my most abstract code over at first (things with very little coupling to any other system or Unity), then moved down the line from there. I also created some wrappers and extension methods that wrap some Godot API into Unity-like API calls.
Most of my work was brute forcing fixes for the thousands of compile errors though, but I can happily say that my game code does compile without error in Godot now though!
My main problem that has put a bit of a pause on my work though is that I have yet to find a good solution for replicating my Unity worklfow for ScriptableObjects and my component scripts in general due to the fact Godot does not display serializable classes and structs in the inspector like Unity can. Turning them all into resources is untenable, because you'd have to create instances for everything that doesn't really need one. I'm also not happy with some of the workarounds provided from some searches I've done.
Has the guy who ported all of his code talked about this? I can imagine he would have had to deal with that, even for me when I make simple scripts I sometimes need to serialize a struct.
This reminds of when I tried porting my game from Godot 3.5 to Godot 4.0 - I haven’t touched it since.
You can make an addon to the editor that does this for you. Making editor addons is actually really easy, doesn't require tinkering around in the source code
Resources are reference-counted unless you specify that it shouldn't be.
I'm surprised someone didn't like Godot's UI system, it's one of the engine's strongest points in my opinion (people even make non-game software using it).
A lot of interactions with standard inputs can be improved if you want something really polished. Some of them a re OK in general but might not fit your game, some just do not allow you to control their behavior to full extent.
so you are from North Korea I see
Personally I have mixed feelings. I've used it extensively for my pet project apps, and to me it seems very powerful but also over-complicated in some respects, especially when it comes to themes. And I think it doesn't really make it very easy to restructure things when you're trying to figure out what works better. E.g, if you decide you need a vbox instead of an hbox, you can't just check/uncheck a box or something, you have to change the node type, and then the name to avoid confusion, and then the alignment/anchoring layouts, etc. Part of the problem is the inspector still being a bit hard to work with in some respects.
I've never worked with Qt or WxWidgets or anything like that, so I don't know how Godot's UI compares to them. I don't know if it's simpler or more complicated than those, but still seems like it could be simplified or streamlined in places.
SplitContainers could also be improved. You can see their problems just by using the Godot Editor itself, as you try to enlarge one section and the other gets enlarged instead, and that sort of thing. And they can only split between two elements, which sometimes sucks. The way the Godot Editor does four 3D viewports with a center drag-handle that can adjust all viewports at once, is actually by hacking around the limitations of the SplitContainers.
@@skaruts you literally can just check/uncheck a box. it's called a BoxContainer and it lets you toggle between hbox or vbox behavior.
People who takes on Godot's UI is the best or better are simply brianless morons, it's not even comparable to thoese industry level well made and not frustrating to use robust frameworks that have shipped all kinds of projects. The thing about Godot is just that, it's trash.@@skaruts
I'm a 3d game teacher using Godot for a few years and I can say that Godot its the easiest engine to learn for sure.
I have covered hundreds, or possibly thousands of game engines at this point and I have to disagree with you on this one.
Now many the easiest General Purpose game engine, that I could agree with (although easy is subjective). But there are plenty of game engines that focus around ease of use and/or learning that blow Godot out of the water in terms of ease. My current fav to point at is Microsoft MakeCode as an example. On the 3D side, something like CopperCube is certainly "easier" than Godot.
Not a bash on Godot, just pointing out for a pure beginner, there are easier engines.
@@gamefromscratch Look at the RPG Maker Engines, literally children can make pretty complex JRPGs in an hour or two. However good luck making literally ANY other genre of game.
Why are you teaching them engines tho? Surely programmers should be knee deep in maths and bitmasks and artists should be doing traditional art and applying that to maya or photoshop.
@@spacechannelfiver free alternatives: Blender, Photopea (photoshop clone), GIMP (it kinda sux but it's ok for basic editing), Krita, and any other app that don't require a expensive monthly fee to get the same results.
@@spacechannelfiver Please tell me this was a joke right?
Caves of Qud is not really a good example in this instance IMO, because the game is using Godot essentially only as a fancy terminal window with sound output. Definitely impressive speed and shows that the game is very well designed from code architecture point of view, but not really a good example of how easy it is to port.
More interested in the 3D Sonic framework for Godot his kids are working on, honestly.
Yeah, the real test would be at least one (ideally multiple) shipped, complex commercial games, preferably some months post-launch, so we can also see how stable it is to support/maintain over time. I'm just seeing "Godot can do X too", but nothing so far that it does *better* than everyone else, to balance the risk of jumping ship.
It's a great example, for the exact same reason you think it's a bad example. He took 500k+ lines of C# code, and he ported the entire game in 14 hours total. This is impressive because a common source of complaint is that Godot isn't yet as C# capable as Unity.
That's why Caves of Qud is an excellent reference point.
Exactly, Caves of Qud already had large engine agnostic portions.
And he didn't port the whole thing yet, he connected the game logic portion to it which was not dependent on Unity, the portion that heavily used Unity was the GUI, the Godot version will only come out next year with an upcoming update.
It's still cool tho, maybe more devs should take a similar approach instead of relying on engines for things they don't need.
@@DD-co1zn x lines of code doesn't really convey any meaning here. Math calculations for instance, take up lots of lines, but are pretty standard & easily-ported. It's a cool thing to watch, it just doesn't really answer the concerns.
Someone should tell MegaCrit that using types on GDScript isn't just a "recommendation" as it happens on Python and Javascript, using them actually forces the types and makes performance better.
It's not about performance, it's about the robustness of the architecture you can create.
@@NihongoWakannai In what way?
@@heavymetalmixer91 C# allows you to be extremely explicit about what data is allowed to be passed where. And while gdscript type hints are an improvement, they are not an across the board change in philisophy for the language. It still relies on dynamic inputs.
Why would I choose to use gdscript with type hints when C# has better syntax and also more features with structs, interfaces, abstract, private, etc.
The fact that godot just has everything in your class be public by default is insanity.
Hardcore Henry is a movie
As a developer who recently started on a similar journey (for no particular reason what so ever).
One of my biggest gripes with Godot is the lack of support for exposing value types in the inspector.
I normally expose structs or classes in Unity but in Godot cannot do that. Meaning if I want more advanced data attached to my script it needs to be loaded from elsewhere. They did try to mitigate it a bit by using resource assets. But those come with their own limitations.
like there is no filtering, all resources can be assigned to a field regardless of type. And the resource assets will still not persistently store data in structs and classes.
Also, splitting the Inspector up depending on class inheritance seemed cool to begin with but as soon as you start doing multiple inherits of custom scripts it quickly becomes a mess.
You might want to check out this guys work:
github.com/don-tnowe/godot-dictionary-inspector/tree/godot-4
I think it does exactly what you are looking for. He also has a plugin for exposing Godot resources in the inspector. Be sure to switch to the Godot 4 branch by the way.
Hes done PR to have it integrated into Godot. I should actually cover his work in a video, its very useful to people like yourself. If you try it out, let me know how it goes and if it solves your problems.
Well it's not structs, there are no structs, but you can expose dictionaries, which should accomplish the same thing.
@@gamefromscratch Thanks, i'll look into that.
What do you mean "there are no structs" ?
Nothing is stopping me from defining a struct and using it in Godot C# I just can't edit it in the inspector.
@@gamefromscratch a weakly typed dictionary is absolutely not the same thing as a staticly typed struct. You could put literally anything into that dictionary and pass it into the same fields, that's nauseating.
You can inherit from Resource and export that, it will show up as a "custom struct" in the inspector, respecting types (limited to those in the godot APi if ur using c#)
@@jordy2854 Sure, but I'm still limited as to what I can expose in the inspector in that custom resource.
For example, If have a list of structs I want to store. There is still no way to expose that struct in the inspector. Meaning if I want to achieve the same result all my structs will have to inherit resource (i.e. no longer a struct) and saved individually.
I love how opening a blank 3d scene doesn't chug in this engine.
Really like the look of what Megacrit have done in such a short time, off to read that post now!
That Road To Vostok porting devlog is an excellent watch/read, really recommend it.
The third dev could’ve got it done in a day if he hadn’t gone outside and touched grass. Though I guess them strawberries ain’t going to eat themselves.
Strawberries are mighty important!
More seriously, it shows that porting a game to Godot is not only viable, but might be less effort than one originally thought.
@@PanduPoluan I think Brian's big advantage over most games was that since Caves of Qud is all procedural, most of his game was written in code rather than handled in the Unity editor. Code is going to be pretty easy to bring over, but I suspect editor scenes/gameObjects are going to be more challenging.
@@llareia that comment would make you the first person to state that C# is an advantage in Godot Vs Unity .... I guess you didn't get the memo, but one of the most enduring criticisms against Godot Vs Unity is that Godot is 'nowhere near as C# capable' yet ...... But then the Caves of Qud guy comes along and ports 500k lines of C# code in 14 hours ..... Huh ? Supposedly C# usage is supposed to be a disadvantage, but now we've got people saying it's an advantage .... what a time to be alive.
@@DD-co1znI think it is bad...compared to GDScript. Due to the glue code that the team used for Godot 3, there is still a lot of cleanup needed to make it as feature-complete as GDScript 2 (like porting to mobile and web platforms). Although, I'll wait for 4.2 to see how many of these issues have been addressed.
I would just continue to advise the right tool for the job. I've seen several "I've gone back to Unity" vids lately. If there's something you need your game to do, make sure your engine of choice does it.
I think things are going to get really interesting in about 3 to 6 years, when all these engines become so close in capabilities that it won't matter which you pick. Let's see anyone overcharge then. 😉
love your vids!!
This is more of a coder vs designer problem. You need a coder that understands (human) design language and not just code. A code monkey thinks it's okay to drive a car with a banana because it's sufficient in their mind (code).
This is still an industry problem since most popular OSS is locked beyond behemoths actually creating a framework like Qt for example or you end up with the UI jungle that was pre-Material Design Android for example. Even that Holo UI up to 5.0 was okay except no one used it which made Google force Material UI upon everyone because of the above mention example (problem).
I mean you still see the same issue even with UE games that usually comes with a random UI layout (let's call it the dart board picker) where the only consistency is that they're all non-consistent.
You can make the menu work for both kb+mouse and controllers while still keeping it with the theme you're going with. Somehow UE3 games were just that for the most part. Funny how things changed for the worse.
The problem actually lies much deeper in that the "type" of person who codes are most likely the majority of hires everywhere and they usually have little no input themselves on how to make something better (again see the first example) because they lack said thought process to begin with. Again not dissing on devs here, just pointing out the general problem that no one wants to deal with, and even worse now when it's all about release now and fix it later (iof ever), at least when it comes to games. This makes me of think of that Alien game which had a typo in the script for the AI which released as a broken mess because someone couldn't be bothered to QA a typo let alone test the game before shipping it.
Could you do a review on the Nuklear Immediate Mode GUI? I want to use the library, but the lack of learning resources makes me hesitant. Maybe if the library gains some publicity, it'll become more popular and additional learning resources will start to pop up. Thank you.
As I understand it, Godot for a long time had a reputation for poor performance because they rejected a lot of optimizations due to being 'not beginner-friendly code' that ended up with then doing things like murdering CPU cache performance.
Overusing linked lists instead of memory coherent vectors, that kind of thing.
Sounds like they need to have the equivalent of mods. Then they can have the basic beginner friendly go do but you can plug in the high-performance mods that is harder to use that overrides a particular subsystem.
What you're referring to there is basically the difference between GDscript and C#/C++ .... That has/is been/being addressed with GDExtension which improves C#/C++ (and other languages) tremendously.
Personally, I see no problem with them maintaining their own scripting language for the sake of complete noobs - so long as GDExtension is there for the Devs who want to get into the weeds with the code and efficiency.
@@DD-co1znconcise doesn't mean it's only for complete noobs. GDScript gets the work done without writing a tons of boilerplate like C# and C++. It would be however noobish to stick with only one language just for the sake of it.
I ++ the notion above me that multiple languages being used should be the approach for more complex games, gdscript to keep a good flow and speed while taking the parts of code that need it to the other language
though some people seem to be just not at ease with gdscript, mostly because their lifetime experience with c# or c++, at which case, I see no reason to just use c# for the whole project ^^
It took them 3 major versions to get batching a thing pretty much every game engine implements during their alpha stages its insane and from what I see right now things have only gotten marginally better hopefully Juan will get his shit together or the project is going head first into becoming a giant drama subject
Great video, thanks!
I think a lot of the 3d concern is with mobile and lower end machines. For now, there is a dev focused on mobile development helping with adding in mobile friendly features and I can imagine that most low end machines can handle a game out of Godot. So maybe in another year or two we can see some better news around this.
i would love to see a game made in godot run on windows 9x machines / dos / other platforms or systems
Optimization is a big issue, plus there's still the issue of porting to Store-friendly versions. Android typically requires the ability to adjust the manifest/resources, and iOS requires creating an XCode project and using Apple's own workflow. And those have to be kept up-to-date with the annual OS release cycle. It's a lot, probably takes a dedicated team, not just the occasional PR.
@@mandisaw the dev team is dedicated to solely mobile, I forget the team name but it seems dedicated. How fast they will be is another question.
@@mandisawtbf, for iOS, I believe that's because of Apple's horrible policies
@@crimsondespair_9505 Apple has many crappy policies, to be sure! But the part about optimizing and keeping up with OS updates is universal across console & mobile, for all manufacturers.
This is an interesting topic. In the future can you please put the article sources in the description or something. As much as I appreciate you reading me an article, I also might want to read it myself
This is a man after my own heart, I paused to read all of it, and it reads like I could've written it myself.
Statically typed is superior, and if you don't understand why, it's probably because you never dove into old poorly written code to fix some obscure bug in a large project.
I don't understand how you could use loosely typed for anything even remotely serious. It's rife with opportunity for bugs.
@@TheOnlyToblin Meanwhile huge firms all over the real actual world are running all kinds of tech in python.
@@mattseaton5832 Yeah, and I've worked in one, and it's pain.
Imagine seeing a long, poorly documented function. Just figuring out what arguments to give it is painful.
You look up git blame only to see the person who wrote it has already left.
Anyways, modern Python has support for static types now (heck, GDScript copied their syntax). A lot of firms are also moving to Typescript, so just because the industry thought something was hot doesn't mean it's good (remember when enterprise OOP pasta was considered "industry standard" in the 90's early 2000s?)
@@mattseaton5832 probably they used type annotated python
also that's why gdscript and python provide optional type annotation
and people choosing typescript instead of vanilla js
do you write a project with 500k+ lines of code in python without type annotation?
if you do tell the experience
for simple 2d games gdscript is fine
I had just started following a Godot video course when my gpu died (and won't be able to replace it for months). Ironically now I can't use Godot because it needs Vulkan... Even more ironically I managed to get Unreal to work decently with my integrated graphics (after the first crash trying to use it I went to lower the dynamic graphics thing and switched to mobile rendering and it works ok). Unity of course opened right away with no issues, haha. So here I am trying to build Google's swiftshader to see if I can get Godot to run, haha...
Still trying to decide whether to move from Unity to Godot or stay.
Best thing to remember "Godot is not Unity but is a good game engine nonetheless". Godot isn't Unity and thank goodness it probably never will be!
I get this a lot when talking to people about Linux (my OS of choice is Linux Mint) it isn't Windows it was never meant to be Windows. You can't switch technologies with the hope that everything is just a better clone of what you left.
The Road to Vostok dev video also includes a little snipped of demoing the 3D performance in Godot (timestamped), for those curious or doubtful:
czcams.com/video/5xqcc384SD8/video.html
I have used SDL for 15 years now. It is low level but there it's been around so long that there is official and unofficial libraries for any asset you need to load.
People also have the wrong idea about frameworks vs using fully integrated engines. Alot of developers using lower level libraries are still using UI for level editors and editing assets. Most tools export to xml so it doesn't take techno wizardry to load.
I just want to say this is not a knock against using game engines. Even if you are using an engine you might still want to use a framework for building a certain custom tool to improve your workflow or speed up a tedious process.
jesus christ xml....
@@zaftnotameni You can just use tinyXML and handle the input.
Not bad at all
Good stuff.
So far I have liked Godot, I'm making a game with a lot of procedural geometry and that aspect of it has gone really well, better than Unity in many ways when it comes to procedural geometry. But I've also encountered many strange things indicative of a young game engine, bizarre issues of unfreezing a rigidbody and it launches into space (what is the point of the freeze functionality if it does this when you unfreeze it?), turning the lowpass filter of an audio bus down too low breaks all other buses that don't even have a lowpass filter on them, and other weird things that just don't really make sense and aren't intuitive to fix. But all in all, I like Godot 4 better, but it is not perfect by any means, there is still plenty of room in the market for another game engine.
I personally didn't have a great time on Godot 4. I really like the Node based system and just how easy it is to get started and make UI, but i encountered a bug related to loading and freeing scenes that made it a total nightmare to fix. I found a workaround but for people that doesn't want to bother with internal problems the engine might have i don't think Godot is there yet for them.
I started with Godot, so far it has been going pretty well. Some parts about the node system seem strange, like how node types inherit from other node types, and where you need multiple nodes which inherit from the same base node, like that's just asking for performance issues, and having to gain access to child nodes, but other than that it's been fine.
Godot is quite straight-forward to learn. I'm a beginner, so it is important to me. I tried making something in unity and unreal engine first, but later decided to go with 2D game on godot. So far it's been good
I've been playing around with the engine for a while now and it's a decent engine, not having the "hold on" popup from Unity is wonderful.
I just noticed some quirks like a ghost window that keep opening on 2D projects or visual artifacts on 3D models if you don't apply the position/rotation/scale and also renaming a 3D model that is already used somewhere seems to be a war crime for Godot but despite all of it I really enjoy this engine
this will be fun to see in a few months.
godot don't scale nowhere near what other engines can do. for small games and pixel crap is fine but so is doing your own engine from 0.
lol, I still can find the same bugs I had when I last tried to use the engine in 2020. yeah, I can fix it myself but... I can also work on my game? Where I make my money from?
Let's see again in year if any of these devs stayed and if any even finished a game using this engine
To me, Being able to successfully make an indie game isn’t a question of how capable your game engine is. It’s a question of how you spend your time. I’m a solo dev, I don’t have time to pioneer new solutions for every minor hurdle I encounter, and doing that is part of using a new, experimental game engine like Godot. I’m no sheep and I want to finish my game before I die so I’ll be sticking with Unity.
Big devs are now using Godot.
This is awesome.
Happy to see I'm not alone on the UI widget hate xD
I think UI terrifies most people but once you figure out screen space and anchors, doing pure code with utility functions makes it a breeze.
Due to it being open source, I would also expect many of these developers may even directly improve Godot which then makes it better for other developers and attract more and it just gets better and better.
The issue with Unity and companies like that are that their decisions are primarily based around shareholders, and they have to make more profits than they previously made year on year, meaning they reach a point where they struggle to improve the product and get more sales, so they then actively begin to make the service worse kind of like Netflix. Unity has reached the peak and is now on the road to crashing.
Switching to Godot is been the best decisions of my professional life so far
We did things both in Unreal and Unity. We started with Unreal because of it's superior graphical capabilities and a well established tool chain. Later we created unity team because of good supply of skilled devs. In the end however we moved back to 100% Unreal and latest Unity's shanigans just enforced our decision to never look that direction again. The lack of stability of what's gonna happen next is just not worth it.
Tried out godot and made a small 3D game for a jam. As good as godot is now I'd still give it a year or two before considering switching for serious 3D projects. For 2D, it's good enough at it's current state.
I wonder, what features are currently missing from Godot for you to use it for 3d projects?
For 2D, I'd say it's not just good enough. it's a pretty damn good 2D engine.
@@Skaro11 importer is pretty hard to use, especially with industry standard formats. Working with world space interfaces is almost impossible (I discussed this on their proposal repository), 3D scenes have a tendency to corrupt very frequently, something I haven't observed with 2D, lack of versatile terrain system (two of the most popular plugins are rather specific in use and are currently in early development, one of them is awaiting engine changes to even implement a custom editor), and occasional crashes when working with high resolution 3D objects that are notoriously hard to reproduce, which probably means they're platform specific. I imagine most of those will be handled within a year or two.
Godot has its sweet spot and vulnerables. Too many bugs to work around and some are even unattended for up to 4 years, they just closed the discussion for no reason.
Do you think more third party apps such as optimizing imports, textures etc. will come to Godot since it's opensource? No need for license etc.
Yes, once a commercial app store is in place, you will see them come. Nothing about Godot, beyond the lack of a store, prevents it.
I'm still happily hacking away at my Godot 4 plugin for generating roguelite floor layouts (aka what you see what you look at the minimap in BPM, BoI or Moonlighter)
Though it's nice to see big(-ish?) names joining the Godot community.
Are there any engines where UI isn't a massive pain in the ass? The kinds of games I'm trying to make are extremely UI heavy (menu and text based stuff, not a visual novel so Ren'Py isn't a good fit) and it's been mind-bending trying to work out the layers and layers of vbox and hbox containers to make things actually look how i want.
i used to use Twine with Sugarcube, which definitely made handling text easier, but then I ran into problems if I wanted to make the game look nice or, heaven forbid, animate a single meter
When I first worked with games I used GameMaker and it's easy to use as it's built for 2D. I don't use it anymore now, but it might be easy to use for a UI focused game.
If your game specifically revolves around UI, I'd say just go with a javascript UI framework/library like React/Angular/Svelte
Funnily enough, I found creating UI the easiest in LÖVE, even though I’d only spent a day learning the basics of that framework before taking part in a week-long game jam for it.
I think it was because it was designed entirely in code, and coming from a web development background it felt completely natural to me, like using HTML & CSS.
Depends what you mean / find painful. Biggest issues with UI are usually in the design & performance stages, the actual implementation is usually straightforward once you have your basic widgets. Only 2 issues I ever had with Unity UI was 1- a generic, pooling List/Grid solution (got an asset, but it could be cleaner), and 2- some setter/getter timing conflicts with a ToggleGroup. The former might be solved now with UIElements, and the latter might have been my own code problems.
I just code my own UI stuff.
Not well. I followed you tutorial on porting from Unity. I didn't get my assets, simple 2D sprites, to show up at all. So I gave up trying to salvage anything and started from scratch. It went well until a known bug in skeletal animation since 4.0 decided for me that Godot is not the engine for me.
Switching engines isn't an easy thing to do, but it does help if you have experience on another engine as that will speed up the learning curve, but as each engine can be quite different, it's easy to pick up but hard to master, in other words, if a developer can make the transition to Godot and make it work in such a short space of time, it's likely only going to get better for them as they learn to master it and the engine develops overtime.
Godot isn't a perfect engine, it's great for 2D and capable of good 3D but clearly more work is needed in the 3D department if they want to take on the other 3D engines, but the foundations are in place and with more time, resources throw at the engine, it could become one of the best engines to use, maybe end up doing what Blender did for rendering.
Also, I think the real advantage of Godot is that it's got quite the community behind it, being as it's open source, there's nothing stopping any developer working on the Godot engine to enhance it in areas that could be done better or to get it to do things it can't at the moment and if I'm not mistaken, with Godot 4, much of that work can be done within the engine it's self, unless I missed something on that bit.
So yeah, the foundations are in place, as more developers use it, it's likely going to quicken the pace of development on the engine and likely to get better in a lot more areas.
As for me, would I go to the effort of porting a game to another engine? It depends on how far along the project is, if it's still in the early phase then I would do the port, but if I'm over 50% in, I think I would stick to the engine I'm on and move to another engine on my next project, but on the other hand, porting your existing game to another engine can be a great learning experience, so it really depends on the developers, but one thing I do know, any future projects would be on an open source engine because what we saw at Unity, there's no telling whether the same could happen to other engines like Unreal in the future and if Godot is good enough for your needs, it's probably a better choice, especially for indie developers that are working on lighter games.
I also do agree with the benchmarks, the engine is clearly capable, but it needs some examples to show other developers what the engine can do, examples are always a good selling point.
I like Godot. I’m working on my own version of daggerfall with it.
I want that !
That’s interesting, seeing as you can get Daggerfall ‘remastered’ in the Unity engine from GOG for free.
Are you doing a 1:1 remake from scratch, or building a Godot-based runtime bringing in the content of the game, much like the Unity version?
Or have I misunderstood and you are actually making a new game that’s like Daggerfall, but not actually Daggerfall?
@@owdoogames it's not a carbon copy. It's its own thing. It's my oldest DnD adventure remade into an old styled video game.
@@murderedcarrot9684 - That’s great to read. The Elder Scrolls games get enough attention already. Wishing you the best in your Godot adventures.
@@owdoogames In comparison with Dungeons and Dragons?
I abandoned Unity for Godot, but I'm fully re-creating my first two projects in Godot from the ground up as learning experiences. My last month has been an absolute nightmare of pneumonia & family emergencies so I'm still working on the first one (there may also be a little bit of scope creep).
I *love* the speed since my computer is getting on in years (Unity took about 20 minutes to boot my projects and sometimes ~3-5 minutes to recompile) and I like the conception of nodes and the SceneTree, but it's definitely taking me a little longer to really internalize the workflow than I expected. The biggest pain point has definitely been the lack of text features. I do miss TMP.
I got fed up with engines and now I'm working hard on a bring-your-own-framework style engine using BGFX and an assortment of other support libs for animation, sound, whatever.. basically Mr. Potato Head... life is tough this way though.. is Godot good now ?
Yeah I wasn’t too keen about using ChatGPT to port code over? so it doesn’t surprise me personally that it’s dead in the water
As of Godot 4.2, GDScript can have static typing enforced so it'll error out of a variable or function doesn't have a defined type. Imo this should always be turned on.
I'd like to see Go in Gogot 😎
Not going back to Unity. For now, I am experimenting with MonoGame. Unlike the Splay Spire Dev, I am much more interested in a lower level framework. For our projects, we spend a lot of time rewriting part of Engines anyway.
Yeah the C# integration is pretty good
Road to Vostok ported on Godot . ? Damn John Somethingtello did do a lot of damage
As a developer I am happy they fired the CEO, but their misstep has made me decide to use a different engine for future projects. Changing midway is too much work, but I am not going to be dedicated to using one engine in the future anymore.
Ive been thinking that for a while godot have so many 2d demoes showing off the 2d capabilities but 3D demoes are few and far in-between.🤔
If their 3d support was crap until the latest version, that would explain it. The Road to Vostok guy was informative - he's using a mix of modern & old-school 3d techniques, for a sort of PS2-ish effect. But I think most indie devs working in 3d are looking for more robust tooling. There's a lot of stuff in Unity you can just expect to be there, either built-in to the engine (e.g. PBR shaders & material instancing), or accessible via assets/community. Having to build that from scratch into Godot may push 3d out of an indie's reach.
Thoughts on the blogpost titled "Godot is not the new Unity - The anatomy of a Godot API call"?
I'm super excited that RTV is going to be built out of the Godot engine. Someone who knows what they're doing is finally going to put to rest the "Godot can't do gud 3D games" fears people still have about it.
If he would know what he is doing he would stay with Unity, and not use Godot as an excuse to start everything from new.
@@SnakeEngine It's not his fault, or any other developers' fault, that Unity has scared them away by demonstrating the abuse of trust that they have. What is the point of a developer making a game with Unity if Unity can just take all of their success away on a whim, and make them pay for the rest of their lives for making the mistake of trusting them? That's a non-issue with FOSS. Have you ever actually used Godot to make anything at all? If you had, you'd know it's perfectly capable.
@@SnakeEngine Also, don't act so entitled. It's unbecoming. Nobody owes you finishing their game in the quickest way possible. If you can't appreciate a developer looking out for themselves then maybe you should stick to the profit-driven AAA market hype trash that's coming down the pipe instead? Just a thought.
@@CharlesVanNoland It's simply a dumb overreaction to switch from Unity to Godot. Unity's licence model has to stay attractive because they have competition. So they won't screw you over. Second, Unity can hire and pay experts full time to work on the engine. That is not the case with Godot, and it shows. First time I checked Godot I noticed an annoying visual bug; a vertcial line at the left edge of the screen in the Borderless Fullscreen mode. God knows when this is going to be fixed, because no one has the expertise or time to fix it, according to comments. And who knows how many more problems you will encounter down the road. So if I would be serious about commercial game-dev, I would put my bet on a robust battle-tested engine, and not on a question mark.
Iv decided to use Godot for game jams but i will be using Unreal engine for my main projects since Nanite and Lumen imo is really neat to use.
Neat? Only if you are not making games. They are really demanding for high spec PC which 70% of the players do not have.
@@unknownrh155 Hmm depends on what style ur making games in . I use a 1650 on my pc runs fine with it on medium to high. I make mostely low poly ps1/2 and Anime based style games.
Iv also used it for animations too really nice tool. Demanding sure but worth it imo.
20:58 that was to be expected from the AI based project
Fair point.
You mean nominal type system. Both Py an Js has it's structural type systems.
Still trying to work my way into it.
What makes me want to use Godot more is how lightweight it is but I'm still struggling on my sprites having lines when in Nearest, but I need Linear Filtering.
Yes…Godot needs to go the Blender route and create a studio that works on open projects directly with the programmers. This would help fix issues and toolchains that just don't crop up when you are in developer land and not making an actual game.
Godot should have been faster to capitalize. Maybe take out a bank loan and up the ante. But no.
They mentioned their issues with funding before. They made an open source project, but they're not from a country like the US. So some things they can't do as easily as the Blender team. And to clarify, I'm not implying the Blender team is from the US.
@tiacool7978 That's unfortunately, the issue with everything free often means it's taken advantage of or taken for granted. Just because something is free doesn't mean we shouldn't be giving them money happens from everything from open source projects to Indie 3D modelers most people won't even pay $1 for an STL file but it gets 1000plus downloads the second it's free
I understand not everyone has money and I'm not saying there needs to be a subscription or huge price on everything subscriptions are awful I'm in the boat of so poor I can barley pay rent every month I don't have money to give but we still need a culture shift to happen so the people who can donate are able to help open source projects have the funding they need
I completely ditched Godot after 4.0, I think 3.x was and still the best version of Godot you can use especially for 2D games, one of the things they completely ruined is the tileset editor which I wish they revert it to what it was before 4.0...
Im not using Defold and learning Lua in the process..
Apparently 4.2 beta has a lot of love for tileset editor, and brings back some stuff from 3.5. Perhaps you should check it out? Also I recall seeing some addon for 4.x which practically emulates the way it was done in 3.5....
I’ve moved away from Godot for similar reasons, and am also looking at Defold, for other reasons also, including its 2D performance and ability to export to consoles for no additional fee.
The tileset editor was supposed to be an improvement in 4.0 and I was looking forward to using it, but it’s a mess. I also felt the hype around its improved 3D capabilities hasn’t lived up to expectations… I’ve actually been drifting towards Unity in that regard, though am also considering Flax and even UE5 now I have a beefier PC.
As a beginner i am amazed how cool UI's these developers do in a game jam. I won't be able to achieve this in even six months
Trappor? :3
4:00 not sure what they mean here, but if they mean that Godot's Control nodes in general are too template-like then they have no idea what they are talking about.
Python and JavaScript _are_ icky lol C# is the way to go, or should I say, the way to Godot?
YAML is a text file. Perforce works great with text files. Or binary files. Any number of them. Any size. That's it's whole hook. I have no idea what he's talking about vis-à-vis YAML.
I'm just going to say it. Godot looks decent, but I hate the documentation UX UI design. Keep in mind that I have a web dev background so I'm used to occasionally reading docs.
For years Godot docs are so painfully hard for me to read/understand that I often get burned out from it and opt into either building my game from scratch or using a Javascript library like Babylon js.
Godot may be a yes to some people and I respect that, but I've reached my mental tolerance for it.
I like how you mention that it's a long document and you don't want to go too much into detail about what it says, and then you read it to us out loud sentence by sentence
Well I did say "I don't want to", not "I'm not going to" ;)
No C# for Godot 4 for web wtf
I hope Godot adds visual scripting back.
I guess Godot Does what Unity Don't.
Unity is better than Godot
@@billcephus Is Unity better open sourced than Godot? Anyway, to make a game, you only need good enough. No need for the "best".
While i feel the pain of the UI elements criticism,
YSK that the entire Godot engine UI is built in-engine.
They (and we) are eating so much of our own dog food its insane.
Forget if the ui uses the same ui elements but still!
I find unreal engine so beautiful easy and powerful
100%
5:09 meanwhile in Unreal land...
At the end of the day indie devs will never need all the fancy stuff unity or other game engines have. Why pay to build a game when you can do it for free. Godot will continue to grow and become better as more people switch over.
i think it would be. The Toolset for Unity allows AA quality from single devs. Godot perhaps not.
For now maybe. But as the community demands arise, I think it will eventually reach more than what you expected.
They'll have more people/power/features and more
What AA game has come from a single person?
@@MechanicaMenace Stardew, Falconeer, even Cuphead had a pretty small team (2-4ppl?). Although I guess it depends what you consider AA...
@@mandisaw Hellblade is AA, it's the game that brought the term into being. Basically "trying to be exactly like AAA games with a smaller budget." Those really aren't AA, they're antithetical to AA.
@@mandisaw those are all very simple games and could easily be made in godot. You could probably program cuphead in a day, the hard part is all the art and boss design.
It's cool they were able to redo their game in Godot, but some devs did not want to deal with Godot simply because it could not port to consoles, where the money is. I've read that there are 3rd party companies who can help with that. I think Godot only requires a propietary plugin template for this, which could be bought; but who provides this, and at what cost?
W4 Games is going to provide that template. But currently they don't. The company was only founded earlier this year and spent the last couple of months upstreaming stuff needed to get the template working properly (like a direct X renderer). The template itself should be out soon-ish.
There are few options for Godot 3, most cost "contact us" (i.e. it is expensive). Lone Wolf Technologies openly said it costs 3000usd+, I saw another company (I forget which) offering a revenue share deal instead. For Godot 4, W4Games has said it is in testing, and should be available for the public for Q1 next year.
Console *and* mobile. Without those, and better support for profiling/optimization, it really doesn't matter how "cool" Godot is, it won't be practical for commercial development. It's already near-impossible to make a living as an indie, period, let alone being PC-only.
@@mandisawmobile already is supported? I know there was a few issues with c# and iOS but that's it?
And it's not like Godot is going out of their way to make consoles not supported, it's just the fact these SDKs can't be integrated with an open source project nicely
@@tomtravis858 If there are issues with optimization and with iOS then it doesn't really support mobile. As for consoles, integrating with proprietary SDKs isn't really new/unique, it's something Team Godot has had years & years to work out a solution for.
It's cool if stuff will eventually change for the better, but we're talking about where it's at right now.
21:34 it was an “AI” project, of course it wasn’t going anywhere
To be honest though, I think those people should have expected for something like this to happen.
In general, the awareness of the meaningful difference between the "free" in FOSS and the "free" in "you are free to download and use the service of our publicly traded company" is way too poor.
I mean, why do people think FOSS advocates & fans are so adamant in their conviction?
It's exactly because we don't want to bother with nonsense like this.
i am try make lowpoly 3d android mobile game with godot 3.5 run fine at mid phone ,just shadow make lagging game for mobile on low end phone.
Statically typed languages are objectively better (pun intended)
Never rely on a product that you're told you have to pay for more than once for your well being.
FUN FACT! W4 Games actually does have a dogfooding team for the engine!
Right now they're focused on 2D projects as it's only a 3 person team, but I'm sure as they need to build porting tools for 3D projects they will need to put together 3D examples to work with.
Juan is a very weird guy tho (google him and read peoples impression of him), thats why i never considered Godot unfortunately