I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4.
All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo.
There are only two caveats: understand what Godot is not good at, 3D open world / large landscape, and console development.
Godot 4.0 was a total mess the last time I tried it though. The Vulkan stuff was completely half baked and the UI was acting out. Godot 3.2 though, solid fun.
I've had a similar experience. Godot is a fantastic 2D engine, and a capable 3D engine. If your goal is shipping a fully featured 3D game I'd still recommend Unity or Unreal over Godot, unless you're comfortable with it not being an industry leader. For 2D however, I'd recommend Godot above anything.
Godot 4.0 still has a long way to go before it's ready for everyday use fortunately, not even in alpha state yet so I wouldn't judge it too prematurely.
To be fair, it's perfectly fine for 3D, such as traditional "isometric" style 3D. It suffers more with the lack of clever culling in first person style cameras, especially near large objects (it renders the whole object, even if 5% of it is seen).
> They even had hand tracking on the Oculus Quest before Unity and UE
facebook is a large financial contributor to the godot project. I think they do some dev work too.
I get the impression they really want more VR games to exist, and work well on their device, no matter how they get there.
Yeah, FB/Oculus has quite the interest in Godot. But at the moment there is no official Quest game made with Godot yet AFAIK.
So far we made it into AppLab with VRWorkout, but the store is a completely different story
It seems as though this is kind of a common paradigm for game engines. Because the tech and/or best practices move so quickly, trying to lock in full backwards compatibility becomes a burden and thus engine devs fall back to "If you started your game on 3.x then it's probably best to stay there. Your next game can start fresh on 4.x"
It'll take some time before you can confidently make that assessment, though. It took ten years for Perl 6 to come out, and then actually it didn't come out as Perl.
Because I worked with Perl and got burned a bit so it came to mind. I understand game engines are different and people build against stable versions for years sometimes.
In my experience Godot is a significantly more coherent 2d engine. In Unity a 2d game is running in its 3d engine, and useful functions will often be limited to operating on different pairs of dimensions ((x,y) (x,z) (y,z)).
Sure, but as someone working on a moderately sized 2d game in Unity - I’ve never really found that to be anything more than a minor annoyance. At most it’s just an extra cast here or there.
Are there other examples of it being better for 2d?
One thing that makes Godot smoother in my experience is its project structure. It doesn't use traditional ECS, but relies on inheritance and composition. Combined with the "everything is a node" mindset, it makes it much easier to maintain a mental map of the game. The node hierarchy tree is much more revealing than in Unity atleast (I've dabbled in both).
EDIT: This doesn't just apply to 2D, so maybe it's a weird reply.
It uses pixels as its units for 2D, which is the main advantage over Unity, depending on your use case (ie, it's very good for pixel perfect 2D games). If you want to move your sprite 33 pixels, you just add 33 to the translation. This also applies to physics, GUI elements, etc. You can also combine the separate 2D and 3D renderers, while maintaining 2D pixel vectors for your 2D objects, and 3D unit vectors for 3D. Yeah, there are pixel perfect cameras and so on for Unity, but it's so nice to be able to just work in 2D as if it were actually 2D. Simple things in 2D renderers like alpha handling and overdraw was slower in Unity than Godot for that reason when I last used it, since it's more complicated to render those things in a 3D engine than a 2D one (admittedly, I last used Unity properly at least a couple of years ago, may have changed).
It has parallax scrolling features built in. Small thing, but there are lots of little features like that scattered in the default tools that just don't exist in Unity without writing your own, or paying for an asset. In Godot you just drop the node in and you're away. Godot has an asset store too - where everything is free and open source, and linked to their git repositories. For example, you can add a minecraft-like voxel engine, dialog editors, a Redux-like store, shaders, new GUI elements, and so on in Godot for free, in a click, without an account, or a single webview or browser page in sight. Granted, this means that older assets may no longer work or be maintained, but the same can be said of Unity (and my experience with the Unity asset store is that half the time, nothing works out of the box anyway even when you've paid a chunk for it, and rarely does a tool just do the simple thing that it says it does, and therefore takes a bunch of work just to get the thing to play nice with your code).
The recent 3.3 release added a bunch of 2D renderer improvements such as BVH partitioning/batching for rendering and physics, vertex pixel snap on the GPU,
The only thing that Unity has over Godot in terms of 2D imo is the Box2D physics engine (Godot uses its own 2D physics implementation that, while adequate for a lot of games, isn't quite as flexible as Unity). That said, there are at least 2 Godot plugin modules that add (partial) Box2D support just from a brief Github search.
Moving away from 2D specifically - the animation player/controller in Godot is amazing - you create an animation player node, and you can then key in literally any property of any object from the editor to be animated, and draw out animations with bezier curves and so on, animating multiple properties at once, which you can then play back with a simple call to `AnimationPlayer.play("name");`. You can use a single animation to animate vectors, enums, bools, simultaneously by just drawing them into the animation editor. Last I checked Unity didn't have anything like that. You've got a complicated mesh structure with layers of materials and shaders, and you want to interpolate various properties on various materials of those mesh structures, it's as simple as creating the animation, going to the materials, and hitting the key button on the properties you want to alter.
From a general design perspective, Godot's scene tree works kind of like Unity's nested prefabs - a feature they implemented long after Godot had nailed this kind of structure, and it still does it in a much simpler and less hacky way than Unity. Everything in a Godot game is already essentially a nested prefab, without the clunk of having to distinguish between regular prefabs holding nested prefabs, or ensuring your modified prefabs are in sync, and so on. You can create simple components composed of complicated structures of nodes, save them into a new scene file with a click, and drop that anywhere else in your scene tree wherever you like, as a native and expected behaviour. It's a bit like React components in that you can very easily combine and produce new combinations of your existing work, even at runtime. You can then easily share these nodes between godot projects, or even write a simple plugin to add them to Godot's list of built-in nodes.
Oh, and all of those scene, node and resource files are just plain text files, easily editable in a text editor, and extremely friendly to VCS.
Besides all of this, if you write a game in Godot you own 100% of the source code, both your game code and the engine supporting it. No licensing, no pricing plans, no salespeople. No official support, yet the community and contributors are extremely helpful. Engine doesn't do something you want? You can patch it and recompile, and add new third party C++ modules (eg, you can add full Javascript/Typescript/Rust/D/Python/Nim scripting support this way, as well as new engine features with native speed) by dropping them in the modules folder of the engine source. There's a legendary talk at GDC by Jeff Vogel, who's been writing obscure, ugly RPGs as Spiderweb Software since the mid-90s. One of his points is that if you want to make a living writing indie games as a solo developer, owning the source code is one of the best things you can do, since 20 years down the line you can still update and compile it, remaster, and sell more copies of work you finished long ago (which Jeff has done many times, and is still now writing those obscure games and supporting his family from it). Good luck getting Unity 2020 to work, build your game, and have the license to use it commercially in 2040 ;)
But that's how 2D games actually work. They're really just 3D games with an orthographic camera. It doesn't really make sense to have separate 2D and 3D engines.
Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on, which makes life a lot easier for many 2D games.
Plus, you can support a much larger range of hardware with a true 2D renderer that targets specific 2D graphics APIs, than with a cutting-edge 3D engine hacked to look 2D.
There used to be a time when we had accelerated 2D graphics cards, even with support e.g. GDI, and then the 3D graphics accelerator was an additional card.
So there was a transition period when GPUs were still 2D accelerators that could do some 3D on the side.
Then graphics cards got the ability to do matrix operations in hardware, this was still mostly 2D with 3D super powers.
However then shaders came into the picture, as consumer hardware finally became cheap enough to adopt capabilities of graphics workstations hardware.
First only Assembly language for GPUs, but by the time DirectX 8 and OpenGL 2.0 became widespread, we got C like shading languages.
GL ES 2.0 is basically OpenGL 2.0 only with shaders and hardware transform and lighting removed.
If you want to make best use of the GPU there is no way around writing shaders, regardless of it being 2D or 3D graphics engine.
In fact you want to code most of the typical 2D effects as shaders running directly on the GPU.
Ah, thanks for your explanation - I'm with you now. I've done some shader programming myself, both "from scratch" and also in Godot, but I'm not an expert. So if you're using a 2D transform type, on the hardware it's still using a 3D/quaternion transform? Interesting.
And so even if I was careful to write shaders that efficiently operate in 2D space, those efficiencies would be trumped by the hardware converting it all to 3D space anyway?
I guess my intuition was that if you have a full 3D shader setup, eg the Unity renderer, that you add a layer of new shaders on top of to give a friendlier 2D API, that's going to be slower than just writing the 2D API on its own.
Core engines no, but Godot scene model overall fits very well for making 2D games. You end up using naturally named things, composing stuff on a 2D plane, etc. I'm sure an experienced unity user can cut through the noise.
Architecturally it's perfectly fine, designing the 3D world is just as capable as the 2D world in terms of tooling. It's more a performance concern. The biggest pain is the lack of proper face culling. It does object culling, meaning if you don't see it at all, it's culled. However faces, not quite.
So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you run your framerate down to the ground if you render even only 5% of it, as it renders everything else as well.
You can mitigate that to some degree by breaking up objects, but even the shell being plain would still cause massive issues.
For first person, open world, or large environment type game, I'd recommend Unreal. For 3D isometric style games, it's perfectly suitable with knowing the caveats and minimal adjustments from an asset creation perspective.
> So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you run your framerate down to the ground if you render even only 5% of it, as it renders everything else as well.
There is limiting of overdraw (not rendering the same pixel multiple times) which is easy with Z-buffers. There is frustum culling (not rendering triangles that are outside your FoV or facing away from you) already of course.
The final type of culling is occlusion culling which is avoiding rendering that starship because it's on the other side of a planet from your viewpoint (for example). That's not a feature of 3.X but it's a feature of 4.0. The technical details are pretty interesting, it uses Intel Embree (the raytracing library) to do a low-res raytrace to find the occlusions.
AFAIK neither Unreal nor Unity will frustum cull the triangles of a model out of the box and although both offer some other forms of occlusion culling they also only operate at the whole model level.
This is wrong. Unity has frustum culling enabled by default. You are correct that it only operates at whole model level though.
Occlusion culling in Unity is fairly straightforward. Simply requires a bake. It also supports 'occlusion areas' where you can give it a hint to do a higher resolution occlusion bake e.g. if you think the player will likely be in that area.
Edit: originally misread parent as stating Unity didn't frustum cull by default. Parent comment is correct.
I’m not wrong just being more specific. All three engines frustum cull by default and all three do it at the level of the complete model. I said Unity and Unreal don’t frustum cull at the level of the individual triangle which was the factor the person I was replying to insinuated Godot lacked.
Godot wasn't intended to be used for 3D at all, it started as purely 2D engine.
The 3D it can do is kinda... "shoved" into it. It works but it wasn't designed from the ground up like other native 3D engines are.
Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
> The 3D it can do is kinda... "shoved" into it. It works but it wasn't designed from the ground up like other native 3D engines are.
I mean, yes and no? In that the 3D renderer is a completely separate system to the 2D renderer. But, that means that the 3D renderer... was designed from the ground up to do 3D. Unlike the other direction with Unity, where 2D support is a hack of the 3D engine.
I've been using Godot 3's 3D features for quite a while now, and obviously as a single indie developer I'm not using it for AAA features, but it's still as competent as any other renderer I've used for my use cases.
> Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
You're going to have to be more specific about "advanced 3D scene editing features", as the editor is actually very good, besides which, I compose most of my 3D scenes in code. Meanwhile, Godot supports everything needed to stream assets at runtime, from multi-threading support, to async resource loaders, LOD, and so on. Granted, you have to kind of roll your own.
The main issue people bring up for large, open world 3D games (which may be a dream of most developers who've not really made a game yet, but in any engine quickly becomes a "one day" project and not something feasible for most people) is the 3D renderer itself, which doesn't have occlusion culling, but again in most realistic cases you wouldn't ever notice this (and it has been added as a feature to Godot 4 already).
For example, recently I was messing around with voxels, and recompiled the engine with a C++ module called "Voxel Tools"[^1]. This supports level streaming and movement throughout large levels without floating point errors (ie, you have a VoxelViewer node that gives the illusion of moving through a large space, while actually not moving further from the origin than you can see).
It was a little of both, but it's not really a valid complaint any more. When Godot first open sourced, it didn't have features like culling meshes that the player couldn't see, and the lighting implementation was pretty basic. The default language in the engine is basically python, so it could cause a performance bottleneck. Now it has a lot of the 3D performance features it was missing, and it has first-class C# support if the default language is causing a bottleneck.
I tried Godot again like ~8 months ago and the C# support was still awful to the point that I'd consider 'first-class C# support' an outright lie. It might be 'officially supported', but it's in 'late alpha' since 2018 and is very obviously a second-class citizen, which should be clear just from the bad state of the C# docs. Community resources for C# are also much more sparse (subpar support probably contributes to this).
It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.
Keep in mind that I'm obviously quite soured by the experienced - Godot might still be the right choice for anyone who is considering. I'd just recommend anyone to factor the very rough C# support into their choice, especially for anyone planning to use it for a more involved project.
I've been using C# in Godot for all of my latest projects of the last ~year and have had absolutely no issues at all. Most of the docs these days have a "GDScript/C#" tab selection, and the intellisense support is so good that I rarely even have to check.
Now, I did already know the Godot API quite well when I started using C# so that contributes. But I haven't found it to be a second-class citizen at all, and in fact allows me to use features that I wouldn't have been able to in GDScript (native event handling, offloading to native data structures for computation rather than using the Godot API for them, nuget packages, and so on). I can also use eg Jetbrains DotTrace to profile code in much more detail than GDScript, and edit and launch my game code from an IDE without ever opening the editor.
You can also opt to use the dotnet-core compiler instead of the bundled Mono one these days which allows you to use some more modern features.
The only clunky thing I've found is that trying to use a native C# data type in a Godot Node object causes marshalling errors, but I'm pretty sure that would apply to nearly any Mono game engine and that Unity has similar issues (having to wrap things in MonoBehaviours etc- it's been a while so this may be inaccurate). The simple workaround is just to use the Godot API for things that are in the scene tree, and native types when you need to compute stuff with better performance.
I'm curious as to what actually felt rough to you in C#?
Yeah, no idea why C# was introduced other than to appeal to people with zero game dev experience who might be lured in by thinking their knowledge of C# is going to matter.
Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.
> Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.
You're going to have to know that stuff for any game engine that isn't just a pure C# framework. Unity is no exception afaik, you have to use the Unity API Job system to be able to run threads safely. I use async/await in Godot C# all the time. Threading requires using the Godot API, sure, that's natural, since threading can be a mess in video games.
"It uses a syntax similar to Python (blocks are indent-based and many keywords are similar)."
And[1]:
"If you've ever written anything in a language like Python before then you'll feel right at home."
So it's more than just whitespace.
I seem to recall it being acknowledged that Python was a big influence on GDScript's design and in a number of cases "How does Python handle this?" drove some of the design decisions.
You are not wrong, but the original point was that GDScript is slow because its syntax is similar to Python's and Python is slow. That just doesn't make any sense.
> The default language in the engine is basically python, so it could cause a performance bottleneck.
python is slow because the extreme flexibility of the language makes it very difficult for compilers/interpreters to perform analysis that could allow optimisations
this doesn't have anything to do with the syntax. we could completely replace python syntax with e.g. pyc bytecode or serialised AST data but the language would still be challenging to execute efficiently as the language is still exactly the same
one can get a few ideas of how python could perhaps be made faster by reading about all the restrictions that rpython imposes
But why did they chose to invent GDScript and not chose to use/embed python itself?
Using a newly invented special purpose language is something that often discourages me from considering a tool/framework.
I can’t tell if the Godot team is serious about commercial viability.
My company cannot afford to wait until Godot 4 to build product. And since we’ve got a big investment in prior work, there is little chance we will switch that work over to a platform that will be brand new in a short period of time.
Well you're welcome to hire some extra engineers on Godot's behalf. They can only go so fast with shoestring budget. If it doesn't meet your requirements, consider alternative engines such as Unreal.
Don't get me wrong, I'm not saying you have no right to complain. But the way you're going about it is off-putting. Godot's devs are working hard and what you're saying isn't constructive.
> I can’t tell if the Godot team is serious about commercial viability.
I mean, it's MIT licensed. So no, not really. It's designed to make games, and the commercials are left to you.
My advice: don't bother waiting for Godot 4 just because it sounds nice. You'd be surprised at how many of the "limitations" of the 3.x branches are not actually problems at all for most use cases (granted, your company may have a very niche use case...)
With regard to 3D indoor scenes, performance is entirely related to the complexity of the scenes & how much effort is put into loading/unloading non-visible areas etc.
For a couple of data points, here is the official Godot third person shooter demo:
Various people have experimented with voxel worlds and other things which push the limits of the engine & are viewable on YT.
In short, with 3.0, Godot isn't competing with, say, Unreal in the 3D realism stakes but it still has more 3D capability than most people who start to make a 3D game will actually hit when the scope of the work required becomes apparent. :)
Any game where camera frustum culling can easily cull the number of object rendered. So when the camera is pointing in a fixed direction and you have control what moves in front of it.
I was starting to make a 3D game for mobile and was planning on using UE4, but I've heard a lot of good things about Godot. Are there any pain points or blind spots in Godot's feature set?
In general I'd say Godot is excellent for the average indie game. It might not be the best choice for cutting edge AAA rendering or performance. In my experience the most important aspect of an engine for a solo/hobby developer is the ergonomics and the workflow. I've found Godot to be a breeze of fresh air in this respect compared to the much more clunky Unity or UE.
Yes GDScript. Very few gotchas, very easy to learn and maintain in my head. I believe I had to recompile the engine a few times for various things, which took a bit more, but the game can be shipped entirely with GDScript.
Having used C++ and Blueprints extensively, GDScript is really a breeze. Of course games perform better if made entirely in low level C++, but as an indie you have to make a choice and you have to ship a game.
Curious if you had a direct experience with the console side of things with your game?
Also, can I provide you an opportunity to promote your game by asking you to tell us more about the game you shipped? :)
(The rest of this isn't directed at you but more trying to clarify the Godot console situation for anyone else interested.)
I've noticed there seems to be a lot of misunderstanding (particularly by "less commercially experienced" game devs) in relation to Godot's "console support" or apparent lack thereof.
Godot do now at least have a page[1] to directly address the issue and clarify the situation which can be mostly summed up with:
"... there is no engine that is legally allowed to distribute console export templates without requiring the user to prove that they are a licensed console developer."
and:
"Console ports of Godot are offered by third-party companies (which have ported Godot on their own)."
I seem to recall there was one FLOSS game engine that got a grant or something to incorporate support for some XBox initiative (that wasn't "full devkit support" level) but for every other major console there's no engine that has FLOSS code supporting it--and if it did then no one could probably tell anyone about it because of NDAs. :D
As a side note[0]:
"Additionally, there is some unofficial third-party work being done on building for some consoles. However, none of this is included in the default build scripts or export templates at this time."
The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":
I shipped a game exclusive to PS4 using UE4 about 4 years ago.
Godot by default does not support consoles. Yes, you can to employ another company to port it for you, but that is a no go for me. UE4 on the other hand you can do it all yourself once you get the developer kit and access (legally) to the platform of your choice.
On the other hand you can easily do mobile with Godot.
Any idea why Godot does not do consoles? Is it a licensing problem, resources problem (ie technical difficulty), or..?
I'm curious because i'm dabbling in some gamedev and wanting to eventually ship mobile and console. I'm more focused on bleeding edge tooling though, Rust gamedev specifically, but i'm curious if the reasons Godot doesn't ship to console also means any Rust project won't be able to ever, either.
Is there something preventing opensource lowbudget projects from shipping to console? Are you forced to go UE4/etc if you want to ship consoles?
Someone else already answered with the link to the official Godot information page[0] which can be summarized as:
* Godot dev team isn't a commercial entity with console development license agreements.
* Even if they were, the console support couldn't be truly Open Source due to licensing & NDA agreements with the console manufacturers.
* There are third parties who have ported Godot to consoles who may work with you port your own Godot game.
* You could always port it yourself.
Another aspect that they don't mention is that for the Godot dev team themselves to support consoles they'd essentially have to create an entire parallel development infrastructure (repo, issue tracking, CI etc etc) per console to maintain the NDA confidentially requirements.
In regard to Rust, they were another example I mentioned up thread about this very situation:
"""
The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":
So, the "something" that is "preventing opensource lowbudget projects from shipping to console" is manufacturer license agreements/NDAs that are the antithesis of & a barrier to cross-company Open Source development. :)
I was curious how Heaps.io could be an Open Source project while also supporting consoles (PlayStation, XBox, Switch) so researched it a bit.
The key aspect seems to be that there's a commercial entity behind the project who presumably has console development licenses.
AFAICT none of the console specific source is Open Source but the implication seems to be that the source is (freely?) made available to registered console developers due to the fact the developer of both is a licensed console developer and has decided to make it available to others.
Console development/distribution is mentioned in a couple of places in the documentation[0]:
"The hello.hl file contains bytecode that can be run with the HashLink virtual machine using hl hello.hl. It does give quite good performances and have been proven by successful commercial games such as Northgard or Dead Cells.
However, it is also possible to compile the HashLink code using a native compiler. This allows to compile for consoles and mobile.
This will create a directory out containing a lot of generated C code that needs to be built using a native compiler and linked to the same HashLink runtime[...]"
With regard to console support it says:
"... for Consoles (Nintendo Switch, Sony PS4, Microsoft XBoxOne), please contact us at nicolas @ haxe.org if you are a registered developer for one or several of these"
And here[1]:
"The final resulting shader will then be compiled to the target platform native shader language (HXSL currently supports GLSL for OpenGL, HLSL for DirectX 11+, AGAL for AdobeAir, and PSSL for Sony PS4)."
Also, this post[2] describes how the lower level parts (using Haxe/hashlink) integrate with native (i.e. console) platforms:
"The game gets compiled to a cross-platform .hl file that can be run with HashLinkVM JIT. It can also be compiled to C directly and compiled using any native compiler, which we are using for our console ports on PlayStation, Xbox and Nintendo Switch."
"We also have additional platform API libraries for Steam, as well as console integration libraries that are only accessible if you have a registered developer."
In the same post the Heaps.io console implementation is described:
"This architecture allows us to integrate new renderers or platforms by just porting a few classes given that the native libraries are been made available in HashLink. Heaps.io supports the following plaforms/renderer:
[...]
HashLink/C with NVN (Nintendo Switch SDK native graphics API)
And, if you're a weirdo like me that likes trawling for small console development details (e.g. they treated as ~BSD system) in the code base check out these:
Interesting. They mention porting is possible - what would that look like i wonder? Would you make your game run under both UE4 and Godot? Or do they attempt to put a layer between whatever engine you use and the actual console APIs?
* Support the platform native C compiler. (e.g. convert your build system & any idiosyncrasies in your/their code).
* Support the platform OS.
* Support the platform native graphics API.
And, yeah, the easiest way to do this (while still maintaining cross-platform compatibility) is to have an abstraction layer of some sort between the game engine & console specifics.
And, Godot does already have this abstraction layer to support multiple platforms, it's just that everyone who wants to use it on consoles has to reimplement it themselves--unless they work with a third party who has already ported it.
(AFAICT there's nothing that would stop a company from doing a console Godot port and then saying "We can't Open Source this code but will license it freely to anyone who can prove they're a registered console developer" but I'm not sure what the commercial incentives for that might be.
It'd reduce unnecessary duplication and could in theory allow for (licensed developers) to improve the code base in cooperation but would be quite the undertaking & also a significant but also necessarily invisible community contribution!)
And, yeah, that's fair enough--although I imagine if you offered one of the companies enough money they might be willing to license their port under similar terms to those Epic offers UE4 console support under. :D
(And given at least two companies have apparently ported Godot so far, porting it oneself is presumably also an option & one would have full source to work with.)
I’ve been using Godot for the last month. It’s been so fun to get back to game development as a hobby (it’s how I got into software development). I’ve tried many other game engines in the last few years but Godot just really ... works for me. It just clicks. Love it. Excited to try the new version!
Udemy has a few good tutorials, but on Youtube check out Tutemic's code architecture course[0], HeartBeast[1], GDQuest[2], GameFromScratch's Godot tutorial series[3] and CodeWithTom[4].
And of course on the blue website /r/godot and /r/madewithgodot
I'll also add in the Godot recipes by Kids can Code, don't let the name fool you they have great miniature tutorials for implementing all sorts of common things in Godot https://kidscancode.org/godot_recipes/
https://youtu.be/SQ7soQ-N-eQ this is the series I started out with. Would recommend it as an easy intro to 3d. I had tried pygame and pandas3d before but none of them clicked like Godot
It was a very simple process, there were one or two typos I found in the code that an experienced programmer should be able to resolve themselves if they haven't been fixed yet.
I haven't done more yet since but would like to. Unfortunately playing games is too fun.
That's exactly my thoughts on Godot. It's not just fun the first week, it stays fun with a large game as well. Refactoring is not bad at all and it's really easy to maintain all the knowledge in one's head.
Looking forward to checking this out. I've been playing around with some physics based ideas in Godot but had issues with collisions. Hoping that the collision fixes mentioned in the changelog applies to what I'm doing.
I'm very impressed with the quality of Godot and its continuous improvements.
I'm guessing I'm doing something wrong on a basic level, but I couldn't get collision detection working between a KinematicBody and a RigidBody. In the game my character (the kinematic body) would walk into the object and it would be pushed as expected, but the kinematic body would not register collisions.
I haven't played around with other engines that much so I can't comment on how they work.
I picked up Godot years ago, and played with it on and off, because I am only a hobbyist. I have been spending time in Godot and in Stride[0], an opensource Unity-like 3D GE, but with a lot less clutter and fantastic C# and VS/VS Code support. Stride also has a lot of great documentation and examples, and you can utilize C# scripts from Unity with some tweaking. The visual effects program vvvv, has a new product gamma based on Stride[1]. When and if Godot gets stronger on 3D, I may switch completely to it, although I wish it had a Lisp/Scheme for the scripting language...maybe Janet[2] could be used! Like I said my wish list. I am so happy there are so many choices available. I started programming in 1978, so things have come a long way for sure!
>Fabio Alessandrelli (faless) has done a lot of work to enable running the Godot editor on the Web, using the same export code as for Godot-made games (since the Godot editor is developed 100% with the Godot API).
This feels so satisfying for some reason, it feels like it set ups a great feedback loop where improvements needed to improve the editor also result in improvements to the whole platform
Godot is a really good engine but there's one thing which I cannot get to work properly: UI font rendering. The interface font is blurry across platforms. I hope they introduce a fix for it.
I seem to recall there being some hiDPI setting in the project options that fixed the blurry fonts for me (on Windows). I think the problem is just that on hiDPI screens everything, including text, is still rendered with whatever size the programmer picked and the result is just naively scaled according to the OS settings (which works ok-ish for non-text graphics). The hiDPI setting removes the automatic scaling, so developers have to account for hiDPI screens themselves (not making everything too tiny).
There's a pull request for SDF based fonts that should make the labels really good all the time.
I have no issues with current fonts. Enable filter in your font settings, can try importing at a massive size designing at a high render scale, and using the viewport scaling to scale it down.
Native viewport (no scaling) and using no scale on your labels should make it all render as you'd expect, however.
I have been using Godot extensively for the last couple years and it's an absolute joy to use.
Documentation had some holes at the time I started, but it was not very difficult to figure everything out by looking at the demo repository. After that, doing stuff like procedural textures or sound effects was almost too easy.
The UI widget support is excellent. It's so easy to put together and add logic to any display or interface element I could think of, even when making them adaptive to screen resolution. Whenever I have to do something with GTK or QT or other widget libraries I kinda wish I had as much as a fun time as putting interfaces together with Godot.
The animation support is also excellent, allowing to key every node property and even adding code calls perfectly adjustable in the timeline. I never used Flash to create things myself, but I hear people comparing Godot to it in terms of being able to do stuff. And from my own experience I believe it.
For 2D games I can't quite think of anything better. My own stuff has plenty of 2D visual effects (think of a discount version of the Super Robot Wars series in terms of looks), shaders, a zillion explosions and even my former computer (already a toaster circa 2014) barely registered CPU activity. 3D wasn't as good, although I was able to do little things that looked fine and performed okay in my former computer, it was noticeably more intensive, and the 3D demos by other people with full effects and high poly counts went at like 5FPS (they run smooth in my new machine, but gotta think of the weakest link). Godot 4.0 promises interesting upgrades on that field, though.
Since my game is going to need 3D for dungeon navigation I think I'll try to wait until 4.0 is released to finish that part, even if I have to port my code to accommodate for breaking changes. I did it with an earlier game in the transition from 2.x to 3.x and was a bit tedious but not really difficult. I'm not in a hurry and I can improve plot and features while at it, I'm just going to release it as FOSS when done, so I can wait and see if the improvements are worth it.
I'd love to create a game but the sheer amount of time and effort to build something is insane. And then you have to hope you are really good at marketing or you hit the social media lottery.
Perhaps make something small for yourself or a loved one in your life? It feels great to finish something, however small! And people who aren't programmers are super happy you made a game for them.
Is anyone aware of any serious(ish) open source game projects using Godot? I very much like the idea of game development as a hobby project and I'd think that contributing something small to an existing project is a better way to learn the ropes than just making an entire game by myself.
If you're just in the beginning stage of thinking about game development as a hobby, I highly recommend just jumping on a project without getting too hung up on the engine. I've shipped hobby games using Unity, RPG Maker, and UE4, but I've also shipped a (crappy) ASCII platformer on top of ncurses. The highest value from the exercise is just jumping in and figuring things out.
That's a preamble to recommending to check out popular open source games like OpenTTD, 0 A.D., or Cataclysm: Dark Days Ahead. None of them use Godot, but they all use game development principles that you would apply in Godot if you were using it.
I was reading this post and salivating. Delicious. Godot is my favorite engine right now, and for me the very best. It just clicked with me. I tried pretty much all of them. And did my fair share of personal engines through the years. Godot has it all covered.
Godot looks awesome but what keeps me from using it is the lack of console support. Does anyone know why that is? I’m guessing licensing and stuff like that.
Might be third party companies out there that could be hired to do the porting, but I don’t know.
I get worried when people tell me an upcoming release (4.0) will be compatibility breaking. I really like Godot, it is so conceptually clear and easy to work with.
This is an open source project, so they can do what they want.
Having been trying to using this, but strangely found that there is no c++ version available for Windows, whereas it is the preferred version in linux. Is this the case?.
I'm not sure what you mean. The engine is written in C++. There is the standard build which comes with GDScript and the Mono build which also has C# support. Both support dynamic libraries. You can download the source and compile it very easily on any platform if that's what you're after?
All builds (except for server/headless build which is Linux only) are available for Linux, macos and Windows as binaries. This includes the standard build and the Mono build. All builds are also capable of loading dynamic libraries at runtime which you can write in C++.
I think you are misunderstanding. Just go to the webpage, select download, and from the windows tab download the "standard version" and you're good to go.
I don't even see what you mean by it being "a c++ available for linux". You got the same choices for all systems. Just download the editor/engine and start programming. No need to compile anything, except your own scripts/logic if you choose to use a compiled language.
I have done c++ Godot development on windows and Linux. They are equivalent. Only difference is the massive PITA that setting up your windows environment is. (Python, scons & msvc)
All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo.
There are only two caveats: understand what Godot is not good at, 3D open world / large landscape, and console development.
Godot 4.0 was a total mess the last time I tried it though. The Vulkan stuff was completely half baked and the UI was acting out. Godot 3.2 though, solid fun.