98
votes
Godot Engine
So, by now everyone knows about the big outcry over Unity's big runtime fee. Even if they backtrack, I foresee MANY developers leaving Unity because the trust has been damaged. So there are two options to look at now: Unreal and Godot. I have no experience with Godot personally, but I know there are people on here who do.
So, to those with experience with it, here's the chance to share your expertise and knowledge! What do you want new users to know about it? What do you consider its strengths and weaknesses? What resources would you recommend for new users? Any particular tips and tricks? And also, what are some games you know made with it you'd recommend, either to give people ideas of its capabilities or just because they're good games?
Godot is amazing.
I have been doing game dev for around 3 years (starting with Dreams on ps4) but switched to godot in the last year.
Strengths:
Weaknesses:
Miziziziz thoughts on godot vs unity: https://youtu.be/U3TI2lleCYU?feature=shared
In terms of resources, start here: https://www.youtube.com/watch?v=nAh_Kx5Zh5Q
Game made in godot: https://www.youtube.com/watch?v=UAS_pUTFA7o
I've been developing a game called 'The Garden Path' in Godot since 2018 and inching slowly toward release. It started as a passion project and has now become something of a full time job (moreso in terms of hours than pay!)
I come from an art background and Godot was my first toe dip into games programming. For simple 2D games I couldn't recommend it enough, and GDScript has been a great language to learn. If anyone wants to try Godot to start game dev as a hobby then I wouldn't hesitate, it has a great community surrounding it.
Same for me! I'm a full-time artist and don't have much of a programming background. I know a bit of basic HTML/CSS/PHP/Python, and I found GDScript easy enough to learn. I think it'll be very approachable for anyone who has at least a basic grasp of programming concepts like data types, variables, if/then statements, loops, and functions.
I started in January this year and it took me about a week to learn the basics of Godot from youtube tutorials 😊 I now have a few tiny cozy games up on itch.io. I'd say these are in the "prototype" or "early access" stage, but they're playable!
For new users I'd recommend this youtube tutorial:
https://youtube.com/playlist?list=PL9FzW-m48fn2SlrW0KoLT4n5egNdX-W9a&si=97uT8x5yC1obNTMl
A few tips and tricks, especially for others like me who don't come from a programming background:
This isn't a big deal, but I believe the reality is a little more specific than that. Methods and properties are functions and data that belong to an object. So while it's true that methods are functions and properties are data, not all functions are methods and not all data are properties.
Glad you're enjoying Godot! I'm just a hobbyist myself but I love it. FOSS is the best.
Nice, thank you for clarifying that! :) And yes I agree re FOSS!
In your experience, did you find yourself getting more responses to inquiries for guidance on the GD Quest Discord better than the official, with hands-on feedback? I had attempted to get answers when trying it out a few months back on the official Discord and never got a response - and really neither was anyone else I saw posting there. It's really quite the change to the experience I had getting help building a TTS mod I did with scripting; they had several folks in there regularly throughout the day helping out.
The reason I'm asking is two-fold:
I have a very specific desire to create a game that is not covered in tutorials by GD Quest. There's a very few scattered tutorials which do vaguely close to what I want, but not exactly, and their explanations in the videos are, put politely, very difficult to follow, due to what I assume is their eagerness to share, but lack of experience in knowing how to teach. (No shaming for this btw, but it's definitely frustrating.) My vision is, using 2D, utilizing 2d sprites for the creatures and an isometric view for the background. Motion would be akin to something like Mario Party where the players only move at their turn, and only move onto pre-set spaces. The spaces would be fine to all be equidistant away, so long as they can be marked to hold data that is specific to them to be interacted with by the player and creatures. I've just had a bear of a time finding a tutorial to do this that actually takes into consideration the concept of interacting with the spots. I really don't really want to do 3d, because not only am I already very weak with math to begin with (3d movement just is not going to be in my wheelhouse, lol), but also because I just want to get off the ground without worrying about having to learn something else I don't desire to learn like Blender just to eventually make the assets skinned as I want them afterwards. I am very familiar and comfortable making 2D and flat stuff, so it's really natural to just want to extend that.
To be honest, I don't find the way GD Quest teaches to be very intuitive for me. Danger here would be that the people there might be difficult for me to follow if they are giving me instructions in the same way, haha.
I've kind of prattled on long enough though, just wondered if you have any experience in comparing the support you got. :)
In the GDQuest discord, I would get help in the #godot channel under the "learn" category. There's also a #godot-questions forum in the same category but I think the #godot channel is more active :) I also don't follow the GDQuest tutorials much (though I haven't tried any of their paid ones), but I don't think that's affected my experience on the discord.
For your game idea I think you could do this using Godot's built-in isometric tilemap. My game doesn't use a tilemap but does have a system for interactions between units and different types of terrain. I have the unit detect when it enters a terrain's area so it can have specific effects/behavior based on the terrain type.
Awesome thank you for the tips. I guess I can try finding some more material again. It's the third time I've tried to start, but without formal training, and a very particular vision in mind, it's pretty difficult since I'm pretty decent about figuring out what I should be planning for when coding, but the how part has me hardstuck atm, lol. Once more unto the breach... :)
Yeah I can totally relate! Coming from a non-programming background, I usually only have an idea of what I want the code to do but then I don't know the exact terminology I need to look up to do it.
+1 to what @feanne said. In addition, each tile in a tilemap can be accessed by using the layer and the xy coordinate. To store data for each tile I'd simply create a dictionary where the key is a Vector2i and the value is a struct/class containing your data. Note that assuming you havr a dense square grid, a 2d array would be the best solution. But I find it quicker to bang out code with a dictionary.
HTH if you have further questions.
I really enjoy "Air Garden"!
So happy you enjoy it, thanks so much! It's under active development :D
I love the art style of your game!
That game looks incredible and your illustrations are simply gorgeous ^.^
Have you reached out to any publishers to get this on the switch or other platforms?
Thank you! And yes, I reached out to a publisher in 2021 who helped run the Kickstarter. I've been spending much of my time this year optimising the game for the Switch.
I've only worked with it on game-jams but at least for small projects it's quite good. Tons of features and it's constantly improving. The tutorials and in-engine descriptions are really good at getting started however finding example solutions to issues outside of the official documentation is tricky since it can be so quickly outdated. It doesn't have anything near the quantity of 3rd party assets that you might find with unity/unreal but it is getting better.
A few minor issues aside it is an entirely FOSS game engine and nobody will be able to change the rules or pull the plug on your project. Definitely check out the showcase to see some of what has been done with it already. I expect that list to look a lot more impressive soon as a whole bunch of great features were only added in the last year or so.
I am only a programming hobbyist, and not a very persistent one (too many other hobbies), so this is from the perspective of someone who is only mildly conversant with programming.
I tried to get into Unity a few times, but I bounced off of it every single time for these two major reasons:
The workflow involved jumping back and forth between scripting and making changes directly in the Unity editor. Despite not being a very good programmer, it was actually the latter I had trouble with. I found it fiddly to use the editor, and it was hard for me to remember how to do things. I preferred scripting because I could trivially refer back to things I'd done in the past if I needed to do them again or I needed to tweak the process.
It was hard to find information. Unity has a very huge community with tons of tutorials/discussion/etc., but much of it was outdated or otherwise irrelevant to my projects, so whenever I hit a snag (which was often) and needed to Google how to proceed, I really struggled to separate signal from noise.
When I tried Godot, I found it much easier to get into:
The workflow allows for a more heavily script-based approached. Things you can do in the editor, you can just program instead. I find this extremely helpful, especially when going back to old projects I haven't touched in a while.
The community is much smaller and quieter, but I find that I do not not need it as much. Godot's way of doing things feels more intuitive and consistent to me, so when I do need help, it's usually only very basic information I'm hunting down (like how to use a particular Scene type), which is easy to look up. I feel much more self-sufficient with Godot, and this in turn has made my projects go way smoother, faster, and more fun.
That being said, there is one really huge thing that has made it hard for me to stick with Godot: it technically supports other languages, but GDScript is really what you're going to want to use, and it's based on Python. For whatever reason, I have a hard time grasping Python. It's probably just because I'm not that great at programming, but I find C-like languages much easier to pick up.
The thing I struggle with most in GDScript is dynamic typing. I'm sure this would be fine if I were a more experienced programmer, but as a relative newbie, I really struggle to understand my code quickly when the type isn't explicitly specified. However, GDScript's developers have been implementing static typing as an optional feature, and I have found myself getting into GDscript a lot more now.
As for how to learn Godot, I can't recommend GDQuest's Learn to Code from Zero enough. It's not free, but it is substantially better than any free material I have found so far, at least if you want to make unique projects that don't fit neatly into established genres. I use Godot to make non-game tools, so I really wanted some guidance for understanding how the engine itself works, not just step-by-step instructions for making a platformer or whatever. And buying GDQuest courses helps fund further Godot development, so I see it as another way to support open source software.
I might just be interpreting your comments about static typing incorrectly, but to be clear for readers: static typing in GDScript, while optional, isn't some young, half-implemented feature. I also use it all the time because I like autocomplete and faster code and the only notable place where I don't believe it's usable is in loop variable declarations.
Static typing is a recent addition.
It is still not fully implemented yet, but it is entirely usable now: upcoming changes are now mostly just under-the-hood features (namely performance boosts for using static typing).
At the risk of devolving into semantic squabbles, how recently do you mean when you say "recent"? I'm fairly certain static typing has been present in GDScript in some capacity for at least three or four years. I'm going off my memory of using it a specific project I was working on around that time.
I definitely don't dispute the assertion that they're still working to improve it, though!
I think it was initially introduced (in a rough state) in 2019? I don't know exactly when static typing reached its present state – I am very far from a consistent user of Godot, as it's just something I've been using on-and-off for small projects for a number of years – but there was definitely a period of time where it went from not existing, to being there but not that great (at least for a programmer of my caliber), to being good (though I do prefer the more concise syntax used in C-like languages).
However, I do really wish I could enforce static typing (throwing an error if I forget or if I copy/paste example code that doesn't have it). I'm crossing my fingers that this will come in time. I never, ever want dynamic types in any project I do; I just make a mess of things.
Got it, thanks for helping me understand what you meant.
I had some experience many years ago writing (simple) games without an engine and man was it complicated. To get anything decent to happen you had to write assembly language or at least C and you had to understand the hardware level very well.
I've used Godot for a few games and it's really a treat. It's hard to believe how much the engine takes care of physics and you can isolate control and behavior at the object level rather than in some outer game loop.
So I can't compare Godot to any other engine, but it's free and if you have any interest in writing a game you'll be amazed at how easy it makes it especially if you've ever tried writing something yourself in the old days in C or Basic.
For those worrying about the (relatively) smaller community compared to Unity: don't. While not a professional, I am entirely self-taught and have sought help from YouTube, Reddit, and Discord innumerable times and have rarely been unable to get answers. Just yesterday I got on the Discord at 2am EST and had someone answering me within a minute. I literally started a Discord server for the students in the online data science degree program I completed recently specifically because I realized how helpful it would be after my experience with the Godot community.
As for tutorials, while there are certainly fewer than for the behemoths like Unity, there's still plenty of them. Again, I'm only a hobbyist, but I've rarely if ever been unable to find material on something I wanted to learn. The docs themselves are great, and they're accessible and searchable offline right in the editor.
Others have mentioned GDQuest as a resource, and I'd agree that they're a good place to look. Their teaching can be hit or miss and I personally struggled to understand their projects' code, but if you're someone with more programming experience, they're probably an excellent option. I very briefly worked with them and Nathan's a great guy with a great vision for the team. They're going to do amazing stuff for this community (and already are in many ways, they're also contributors helping to drive development).
I will say that I have a negative impression of the user KidsCanCode. I only mention this specific person because they have situated themselves as a teacher within the community so you're likely to encounter them. While their tutorials are pretty good, they often come off as snide or condescending to beginners which, as a teacher, is just weird to me. They do very much seem to be an outlier among the community however, so don't think that most Godot users are that way!
2 released games I know were made in Godot are Brotato (A Vampire Survivors style game) and Murtop (an arcade style game inspired by Dig Dug and Bomberman).
I recommend checking out r/godot or Godot on Lemmy to see tutorials, people's project showcase videos, free assets and plugins made by people for your projects, and all sorts of stuff. Right now, thanks to this Unity fiasco, the Reddit page is full of memes, but there's lots of great content there!
Two 3D games I saw mentioned on Reddit that are made in Godot:
Penitent by devmar
Normord by DJMaesen
A video compiling 5 cool Godot games that someone posted on Lemmy:
5 Games Made in Godot To Inspire You
Two other games I know of made in Godot that were really great were Cassette Beasts and The Case of the Golden Idol.
I have done a few game jams using Godot, and it is very strong and easy to use. There are a few things holding it back from larger studio adoption though, as it is tricky to have multiple people working on the same thing.
And Cruelty Squad!
Godot has a showcase of the released games that use it - there's quite a few considering how young Godot is.
https://godotengine.org/showcase/
I'm not familiar with game dev, but in other spaces there is such a ridiculous amount of inertia behind software from shitty companies.
Will the industry really be willing to just change over all new projects overnight, or is this just wishful thinking from those of us wanting to see FOSS rule the world?
It wont happen overnight but it can slowly happen. Look at the success of Blender and how many other modelling apps it dethroned for game asset production.
How big is Blender in professional environments these days? The last time I checked in everyone was using Maya with some switching to zBrush.
Anecdotal, but at my studio a majority of the 3d artists have switched to blender from Max or Maya. I think the character artists still uses zbrush and the animators motionbuilder.
I am not in that field but my understanding is that Blender has been leading the market for a good while now. I've heard of its use in animation, game dev, modeling and hobby projects alike.
Game engines can all be very unique in terms of features and UI, so changing it always involves a steep learning curve. Migrating games to other engines is also pretty tedious and time-consuming, and not exactly feasible depending on how far a game is into development.
That said, if you haven't heard about the current Unity debacle, please take a look at the Tildes thread about it. To summarize as simply as possible: starting January 1, 2024, Unity intends to start charging a fee for any downloads of games with at least $200k revenue. Not purchases, downloads. If a player buys the game and installs to two devices, that counts as two installs. Player reinstalls after deleting the game, developer is charged. They also announced this would apply retroactively to existing games, so any downloads after January 1 would be charged.
There are many, many, MANY issues with this and ways it can be abused by malicious parties who want to harm smaller developers. There are many questions and concerns about how the heck this works, as well as about whether the retroactive bit is even legal. I think Unity has already backtracked on at least some of it, but the damage is done. The fact they intended to have it apply retroactively to games made YEARS ago, BEFORE this new fee policy was announced, has completely obliterated any trust in the company and their intentions for the future.
This isn't really about a wish for FOSS to succeed, so much as acknowledging that people WILL be leaving Unity. Unity is basically a liability now because we just can't trust them to not try anything else like this in the future. If they're willing to change the rules for games that predate those rules, then there's no telling what else they'd try.
The other big name in the developing scene is Unreal, which is most certainly not FOSS. It's also radically different from Unity, so this is an opportunity for people to look into other engines as well. Godot is the second one people are floating as an alternative. The fact it's FOSS is just a nice bonus since Unity's actions have shaken indie developers' trust that other engines won't try to screw them over too.
I have no formal programming training to speak of - I'm self-taught, and understand a lot of the basic principles well enough that I can adapt and do reasonably simple things in a handful of different languages fairly easily (Lua, Python, Ruby, SourcePawn (niche, but still), 68k Assembly, and IIRC some C++ and Flash stuff when I was younger). I've only dabbled in Unity and Unreal very briefly many years ago, and didn't have much luck with them, really - Unity had me confused and overwhelmed, and Unreal was mostly done following a lesson course, IIRC, so I didn't really do a whole lot beyond level design.
While I don't have a lot I can really show for it yet, beyond a sample test that loads level files from an old indie puzzle game series and generates the world mesh appropriately, using Godot has been a pretty pleasant experience overall, for me. As someone who's probably dabbled in Python more than any other language, adapting to GDScript was relatively painless - hell, just transitioning from Godot 3 to 4 probably gave me more trouble than getting used to Godot 3 in the first place.
My biggest issue with it so far is probably just the audio system - I haven't had much luck in getting results with it that I'm happy with, but to be fair, 1) I'm not an audio/sound person in the first place, and 2) I still haven't done a lot of poking around at it compared to some of the other systems.
But, yeah - as a hobbyist, overall, I've been really happy with it. I've had a hypothetical project in the back of my mind for a couple years now that I was originally envisioning as a Ren'Py project, but after a bit of playing around with Godot, I'm almost certain I'm going to be using it instead, even if that means I have to do a lot of busywork for it myself. It's just really intuitive and nice to use, IMO.
Godot offers everything for you to create a great game. You can also use C#, so you don't have to switch from what you have used in Unity. Unreal is significantly harder than both Unity and Godot and you'll have to use C++ (which is hard to get into).
From the perspective of a programmer that has spent the last 10+ professional years in a proprietary engine and want to make smaller hobby projects Godot had been a breeze from all perspectives really.
I've used unreal less, but from what I've seen and heard it's great for art and such content, but when it comes to code you better hope that you'll be able to stay in the blueprints, because working with their c++ is slow, and from what i understand often pretty frustrating.
I don't do much game development, if ever.
But I was pretty interested in Godot for a while, because I wanted to understand the engine a little better.
It's entirely node based, everything in the project is a hierarchical structure and that's something to get used to. This means there's no entity component system (ECS) like in Unity, but this makes it easier to get into than Unity.
But because of that I wouldn't use Godot to make the next big Warhammer
or Risk of Rain 2clone. It simply lacks the systems for performing well with huge amounts of objects like thatThe main loop is also fairly interesting, it makes use of
serversto do different processes like physics and rendering in parallel.Afaik it's possible to build on top of Godot and add your own ECS if you need one (very complicated!).
ECS is a very nice thing for the rare very complicated project, but I think it’s a bit of a stretch to suggest you’d need it to make a Risk of Rain clone, no? I mean, I’m all but certain even Risk of Rain itself doesn’t use ECS.
Of note, Godot has an official blog post regarding ECS from a couple years ago that’s worth a read for those who haven’t seen it.
You're correct. Risk of Rain was made in GameMaker, which does not support the ECS pattern. Though they did switch to Unity for the 3D sequel.
That makes me wonder what they'll be using for the RoR1 remaster. Maybe an update to the latest GameMaker version?
I was actually thinking of Risk of Rain 2 when I wrote that. To my knowledge, ECS still isn't terribly commonly used even in Unity development, and it was even less so back when that game released.
The reality is that while ECS is a very nice tool, it's not one that needs to be used for most projects. Combine that with Unity's tendency to half-bake most of their stuff and it's no surprise it didn't get utilized much.
Sorry, I did mean Risk of Rain 2, which was made in Unity.
Also, I assume they were working in Unity for the remaster. But now who knows lol
I think it's still fair to point out because your development will feel different from Unity. And to be aware that depending on the project you're trying to develop, the performance ceiling is different.
It really depends on your project's specific needs. Most Unity projects as far as I'm aware, even now, don't really use ECS much if at all, so the difference isn't as stark as it looks. It's something that gets more attention than it does use, really; unless you're making something that needs to track many thousands of objects at once, ECS isn't generally necessary. Neat – and I do like the pattern – but unnecessary.
Humble Bundle has a series of digital learning courses for Godot on sale as a bundle right now.
I have no idea of the quality of them or whether they’re worthwhile, but I figured it’d be worth mentioning here in case anyone’s interested.
I never used Unreal or Unity, so can't say how Godot compares. But I like the engine a great deal. It just feel so neat and smooth, and the Python-like language is quite nice. The VR is super smooth, my notes on how to get a VR project up and running is only a single page. On the negatives, it is hard to find any instructions on how to use the various part of the program; everything seems to be tutorials on "How to create a [game genre] in [x] minutes". Also, I'm a bit disappointed that 3D audio isn't supported, and the shortcomings in the web export (which is unlikely to be fixed anytime soon because they insist it is the responsibility of whoever coding the web browsers). But even with that, I like it a great deal.