
Godot Engine – A decade in retrospective and future - perakojotgenije
https://godotengine.org/article/retrospective-and-future
======
brachi
A very well written and inspiring post. I haven't used Godot much, but I feel
2020 and the next decade is going to continue growing much more :)

> This was an extremely hard decision to make [work full time in Godot],
> because at the time, my experience (...) was paid a lot more, and I was
> receiving extremely good job offers(...). [T]he same happened to Rémi (an
> Energy Engineer), who also changed his life plans and profession to work
> full time for the project.

It really speaks of the love for the project. I hope the motivation and joy
for writing the engine is balanced with the right compensation.

~~~
kroltan
In financial terms, we are sure that each are paid at least 4.4k USD/mo, based
on their Patreon goals. If that is the right compensation is subjective, I'm
not familiar with the market rates for that level of experience.

~~~
allannienhuis
If they were receiving job offers with better compensation, that suggests that
rate is below market, by definition :) .

------
vanderZwan
I wonder if Godot has a chance of becoming the Blender of game engines. From
the way it is growing it's starting to look like a real long-term possibility
to me, especially for the smaller game studios.

~~~
ljm
A real draw for me is working with C++ in it, since both Unity and Unreal
appear to favour managed languages (C#, some JS variant, some weird Python
style thing, etc.)

No real reason for preferring C++ except I want to learn it, and my pet
project is a little game rather than yet another web app/thing that renders DB
records to HTML/thing that takes one JSON blob and turns it to another. I
never did computer science so this sort of trial by fire is super appealing to
me.

~~~
MH15
> yet another web app/thing that renders DB records to HTML/thing that takes
> one JSON blob and turns it to another

Ouch, this is currently my "pet" project. I totally get what you mean though.
I'm honestly not sure if it can even considered a pet project anymore, as it
works way better than I expected.

~~~
vanderZwan
I think it's a rehash (conscious or not) of Thomas Figg's famous _" Webapps,
or as I like to call them: Skins around databases."_-joke that he used in his
_" Programming is terrible—Lessons learned from a life wasted"_ talk from many
years ago.

It's no longer _completely_ true, but honestly it's still kind of true. And
I've been making my living writing them for years now ;)

[0]
[https://www.youtube.com/watch?v=csyL9EC0S0c](https://www.youtube.com/watch?v=csyL9EC0S0c)

------
iamwil
It seems like some of you have some real love for Godot. How come you decided
to use/recommend Godot over Unity when it was less mature? Was it much better
along some axis that Unity didn't provide? What makes it better along that
axis?

Usually happens when something is 10x better at something new that people care
about that the incumbent is blind to or is structurally incapable of
addressing. I'm just wondering what it is in this specific case.

Ease of use? Beginner friendly? Open source so you don't have to pay? The node
system makes it easier to do X?

~~~
MattRix
I'm not a Godot user, I'm a Unity user, but the fact that you don't have to
pay is one of the big draws of Godot. Unity Pro is $150/month per seat.

The fact that it's open source is also big, because there are often bugs in
the Unity engine that I can't fix since I don't have source access.

A lot of devs also like jumping on new technology because it feels good to
learn new things.

Oh and then because it's open source, you can improve the engine and it gives
you the "Ikea effect" where you like something more because you helped to
create it.

~~~
vanderZwan
I know quite a few game devs (side-effect of both living in Malmö and being
active on the TiGsource forums) and if there is one common thing I hear about
Unity it's how it does not seem to care at all about backwards compatibility,
and how upgrades can completely screw over projects.

I don't know what the story is with Godot (beyond the breaking changes between
2.0 and 3.0 that was mentioned in the linked blog post) but if that is a lot
better then I can imagine that some game devs might be more interested in
Godot for that reason too.

~~~
dleslie
Every version change, even minor revisions, come with a real risk of breaking
your compiled asset bundles. From shaders to light maps to referenced classes.
It's a huge amount of effort to keep a project tracking Unity version
upgrades.

~~~
iamwil
What do people do to deal with it? Are there services / libs that help you do
the conversion?

Or is it that you can't fully trust them, and you'll need to do that by hand
anyway, because you might be one of the exceptional cases?

~~~
ngold
From my limited experience, download the version that it was made with. Unity
has a list of older versions right in it's hub.

------
dakom
I am coming back to Unity for a side-gig VR thing after not touching it for a
couple years. Unfortunately the timing is not great since they are still
sorting out all the new offerings (XR Plugin vs. Player settings, Input
systems, ECS from prefabs, etc.)

Is anyone doing VR with Godot? I have a couple questions:

1\. What's the development cycle look like? In Unity I can hit play and put on
the headset (Oculus Quest w/ Link, so essentially a Rift). No need to export a
full build or go through multiple steps. Honestly this is the single most
important factor for me since it allows quickly figuring out other problems.
Does Godot support it?

2\. Unity has made a big deal about DOTS and from initial tests it's legit.
For VR on low-powered headsets (ultimate target is Oculus Go) these
performance savings matter. How does Godot compare?

3\. I don't know C++ and worried that I wouldn't be able to squeak by from bad
usage of it. GDScript looks interesting but in this use case performance
matters. I am doing a significant amount of Rust these days esp for hobby
projects and would LOVE to be able to code in that. Are the Rust bindings to
Godot good? Does it interfere with quick iteration? (looking at the repo it's
hard to see what's going on and what the impact is on a real project)

~~~
blensor
I have started VR development very recently for a small side project and I am
very happy with Godot (I mentioned the link in one of the other replies, it's
calle VRWorkout).

Currently you should use the 3.2 Beta and have to install the
godot_oculus_mobile plugin yourself, but once that is setup, you have an
Android symbol in your Godot Editor and can hit play to get it running on the
Oculus Quest headset.

It's reinstalled for each time you hit play, so that takes a few seconds. I
don't know how unity handles this.

Performance wise you are on your own I guess, so you should know what to do
and what not to do to achieve good performance.

Don't know about language bindings, I am using GDscript as it is close enough
to python to get by.

From my point the whole experience was a breeze, given that's it's free and a
really small download I would definitely at least check it out before trying
something heavier.

~~~
dakom
Cool, thanks for the feedback! I didn't see the source code on your repo -
just release builds... did I miss something or is it closed-source?

Unity also takes a few seconds, it's not instantaneous, but much better than
the proper build/deploy route which can be minutes

~~~
blensor
I only released the first test version a week ago and it's relying on the beta
of godot as well as a patched export template to support hand tracking, that's
why I haven't released it yet. There is currently development going on to
integrate the necessary changes into the godot_oculus_mobile plugin and into
Godot itself to support that. Once it can be run without patching several
different components I will add the source. Or if too many people ask and
giving that explanation becomes more work than actually supporting them to get
it running before everything works out of the box :)

------
arminiusreturns
I've been using godot for about a year now, and really like it. I am really
excited about the upcoming vulkan renderer which should help with my main
gripe which is no ambient occlusion. Some people have found some novel ways
around it but I am choosing to just focus on my gltf assets and work on my
blender skills in the meantime.

Linux native gamedev is possible!

~~~
arminiusreturns
*occlusion culling not ambient occlusion

------
m0llusk
That the Godot scene editor is made with Godot seems to be an excellent
example of how eating one's own dog food can exercise and improve the basic
technology.

~~~
mhh__
It's fairly common practice in compilers (for good reason), i.e. the D
compiler is now written in D and the Rust compiler is written in Rust etc. I
think the first Haskell compiler was written in Miranda but that's before my
time.

You get to test the product without waiting for feedback from the real world
and you also end up with a test suite (in effect) for free.

~~~
Jowsey
How do compilers compile themselves before the first iteration? This always
confused me

~~~
Doxin
You compile the next version of the compiler using the previous version. That
does mean that the _first_ version of the compiler cannot be written in the
target language. Once you've got that working you can write a new compiler in
the target language and compile it with the previous compiler.

Back in ye olden days the first assembler was written in machine code. The
first C compiler was written in assembly, and the first D compiler in turn was
written in C.

~~~
mhh__
The first C compiler was written in BCPL IIRC, the D compiler was written in
C++ up until about 2016-ish

~~~
Doxin
I figured someone would point out that I missed a few steps ;)

The explanation of how a compiler can be implemented in its target language
still holds though.

------
inDigiNeous
I've been using Godot engine for the past two months now, I evaluated both
Unity and Unreal Engine of course, and in the past I've built my own 3D engine
(took me 2 years, C++ with Lua scripting, OpenGL 3.3+).

What got me started with Godot was the fact that it is completely open source,
and I was evaluating also writing my project with Rust, and Godot had already
support for interfacing it's scripting interface NativeScript even with Rust
already (although much work in progress).

Ultimately I decided to develop the project with mostly C++, but during
learning the engine I noticed that GDScript is very capable and seems even
faster than Lua at least according to my 2 month experience, mostly coming
probably from the fact that it has native types like vectors and matrixes and
so on integrated directly into the scripting language and implemented with
C++.

I was pleasantly surprised how easy and logical the engine is to use, they've
made a lot of correct decicions when it comes to the technical viewpoint, for
example getting engine scripts written with C++ was very easy, which surprised
me.

The documentation is also very well written, with up-to-date examples and I
haven't seen any missing information yet.

Only thing I've been missing is more complete examples of games utilizing C++
for example, and more complete projects to be looked at as an example. Most of
the projects I could see were written mostly with GDScript, so I would have
wished to see more indepth and professional examples in how to write
performant projects using Godot.

But mostly GDScript even seems to enough to implement most of the game or
application logic.

For me though, the fact that the engine is open source and that people are
actively fixing issues in it, and I can even contribute myself is a big
factor. The MIT license also grants me to do whatever I want with the end
product, which is a big plus.

I hope to contribute to the project as I go along, been looking at the source
code and it's really readable also, the architecture is pretty solid and clean
at least according to my quick evaluation of the project.

I'm projecting great success for Godot in the next year, especially with the
upcoming Oculus Quest support already well under way, this could be a easy and
more flexible way for people to get into VR development possibly.

------
eatonphil
Trying to find the best way to introduce friends/family (with programming
backgrounds) to game programming for fun. (So not kid-focused stuff like
Scratch or Logo.)

Godot looks pretty good. Is there anything else you've had success with?

~~~
kris-s
PICO-8 might be a fun starting point.

[https://www.lexaloffle.com/pico-8.php](https://www.lexaloffle.com/pico-8.php)

~~~
vanderZwan
TIC-80 and LIKO-12 are pretty decent open source "clones"

[https://tic.computer/](https://tic.computer/)

[https://ramilego4game.itch.io/liko12](https://ramilego4game.itch.io/liko12)

And then there's the BASIC engine:

[https://basicengine.org/](https://basicengine.org/)

~~~
kick
CHIP-8 is really cool, too!

------
danShumway
What's Godot's C# support like nowadays? I remember there being some criticism
of the early implementation, but I haven't checked back recently.

I keep on getting really curious about Godot, it seems like an engine that
should be up my alley, and I really am in the market for Open Source engines.
I don't want to keep coding everything myself.

But I'm a little thrown off by the idea of learning a new scripting language,
and dipping into C++ for an engine like this seems counterproductive. If I
cared that much about memory management, I'd probably write a game-specific
engine again.

~~~
Riverheart
Felt the same way about the scripting language at first but dug in anyway and
it's so close to Python it wasn't too bad to use in practice. Has some short
hand for referencing nodes via $ that C# version didn't have.

------
shafyy
We've just switched to Godot from Unity 2 months ago (we're doing VR), and I
will never go back.

~~~
ljm
I’m curious as I’m playing around with these myself and trying to make a
decision from a beginner’s perspective (right now I’m just rolling my own from
scratch with libsdl, to get to grips with C++ and the fundamental concepts).

What sold you on godot over unity?

~~~
markus_zhang
just curious did you check out the C++/11 binding of libsdl?

~~~
ljm
Oh, I didn't know about this! I've been using the raw library and handling
cleanup myself (and understanding when and where I need to do it). It's
probably a boon I started on PHP4 which basically had a 1:1 C interface for a
lot of things, including manually deallocating variables to save memory and
depending on variables passed by reference, so I knew what to expect even if I
lacked the experience of the underlying system.

Thanks for pointing it out, I'll take a look at it.

(edit: I am using the fancy renderer in favour of the old surface
manipulation; I guess that's a step up, comparing the code)

------
Fr0styMatt88
I keep debating whether I want to commit time to doing a hobby project in
Godot or Unity (yes, I know I should just pick one and do it). Unity has made
massive strides but I just find Godot so damn pleasant to work in, especially
with code editing being built right into the editor and GDScript being such a
nice language.

I can really see Godot becoming the Blender of game engines. Kudos to the
team!

------
kemonocode
I have nothing but love to give for Godot and its incredibly dedicated
community. Sure, it's still rough around the edges, but many of my gripes
(e.g. poor documentation) have been slowly fixed over the years and I've been
recommending it to people new to game dev (although not necessarily new to
programming) in order for them to tinker on and make their first games with.

~~~
puppyprogram
The good thing about having gripes in an open source product is that you can
be a part of the solution!

~~~
kemonocode
I've helped with documentation myself, so yeah, it does feels nice to be part
of the solution!

------
lwb
Great post. Is there a 3-year, 5-year, even 10-year roadmap for Godot? It's a
tool I'm very interested in using but the industrial backing and stability of
Unity/Unreal is hard to beat. Some kind of assurance that the creators of
Godot plan (or at least hope) to keep working on the project for a long time
would go a long way.

~~~
gdxhyrd
If you need reliable support, you have to pay someone. It does not matter
which project you are talking about.

~~~
mroche
[https://www.patreon.com/godotengine](https://www.patreon.com/godotengine)

I can’t remember if the team is getting outside funding from grants or such,
but this is the main payment system I believe.

~~~
vanderZwan
They mention that Mozilla supports their HTML5/WASM efforts, which makes sense

~~~
cpeterso
Godot Engine was awarded $50,000 in 2019 by Mozilla as part of the Mozilla
Open Source Support (MOSS) program. Godot also received a MOSS grant of
$20,000 in 2016.

[https://godotengine.org/article/godot-engine-
awarded-50000-m...](https://godotengine.org/article/godot-engine-
awarded-50000-mozilla-open-source-support-program)

------
csande17
I've been looking for a lightweight 2D engine to use on Android. Something I
can use to build simple 2D games with small binaries that load quickly and run
on lots of hardware. (Like I might use SpriteKit for on iOS.)

Should I look further into Godot Engine, or is it more of a
"heavyweight"/loads-of-features engine like Unity and Unreal?

~~~
modernerd
Godot is worth trying. I found it easier than Unity/Unreal to pick up,
especially for 2D.

Also check out [https://defold.com/](https://defold.com/) — it’s an excellent
game engine that perfectly suits your 2D/mobile/lightweight requirements. The
team behind it (at King) are very active both in listening to the community
and with their release cycle. It has a bunch of features bigger engines still
lack (hot reloading, fast testing cycle and export process).

~~~
mintplant
Last I checked, Defold/King require that you let them collect analytics from
players' devices in order to ship games with their engine (i.e., your game
becomes a trojan horse for their data harvesting regime). It was buried in the
terms and a nasty surprise when I found that out (luckily, still in the early
stages of experimentation). Permanently destroyed any trust I might put in
their offerings.

~~~
britzl
(I'm the Defold product owner)

There's not a shred of truth in the above statement. We offered an OPT-IN
analytics services that provided you, the developer, with install and
retention numbers for your game. No one at King or in the Defold team ever
looked at any data. King has hundred of millions of monthly active players of
their own games. That's enough data. No need to try and steal data from anyone
else...

The optional analytics service along with the optional project hosting was
shut down four months ago.

We do use Google Analytics for www.defold.com and the editor. This is clearly
stated in the terms and conditions. And it's pretty standard stuff in the
industry to keep track of product usage like that.

~~~
mintplant
Um, okay. I'm not sure what I'm supposed to say to that. I remember this
clearly from when I trialed Defold immediately after the public launch. I'm
glad if things have changed, but the analytics were not opt-in back then.

~~~
britzl
I've been with the Defold team since before the public launch, but I'm not
going to debate you over this :-)

As you say, things have changed and we have worked hard since the launch three
years ago to show our community of developers that we are serious about Defold
as a professional choice for game developers and that we do not have any
hidden agenda with giving Defold away for free.

------
makohn
Interesting post. I haven't that much experience with Godot, but I found the
recently published YouTube Video where Juan explains the source code quite
interesting:
[https://www.youtube.com/watch?v=5RIPRlCvRAk](https://www.youtube.com/watch?v=5RIPRlCvRAk)

------
agluszak
It's nice to have a dark editor theme included for free ;) (Looking at you,
Unity. What you're doing is not cool at all.)

------
shmerl
_> The new rendering architecture will also allow companies working on console
ports to more efficiently port the engine and offer our users the possibility
of running their games on the most popular game consoles (something we will,
unfortunately, never be able to offer officially due to legal reasons, thus
forcing us to cooperate with companies porting it on their own)._

I didn't quite understand that part. What legal reasons prevent them from
making ports for consoles? Do consoles ban open source projects?

Also, are they planning to use some translations layers like for DX12 and GNM
from Vulkan when working with Xbox and PlayStation? Would be nice if gfx-rs
could offer a GNM target for the Vulkan portability option.

Alternatively, Sony and MS can of course start offering an option to use
native Vulkan, as they should have from the beginning.

~~~
Negitivefrags
You are not allowed to publish any information about console APIs. That is
part of the agreement for getting access to the SDK.

You can't publish any code that calls non-standard APIs. So therefore any code
that interacts with those APIs cannot be open source.

You would have to publish a seperate extension to the engine that is not open
source and make it only available to those who have signed the Developer
Licence Agreement for the platform. Depending on what licence you chose or how
the code is structured that might break your own open source licence.

~~~
shmerl
_> You are not allowed to publish any information about console APIs. That is
part of the agreement for getting access to the SDK._

Sounds very much like paranoid '80s - '90s approach where everything including
development tools was viewed as some kind of super guarded secret. But I guess
incumbent consoles are stuck in that mindset. They should realize it's been a
different century for two decades already. Hiding an API is not helping
anyone.

------
SquareWheel
I've become a big fan of Godot over the past six months or so. The open
development model is a breath of fresh air compared to most game engines.

The node system seemed weird to me at first, but it's really grown on me. I
can heartily recommend the engine now.

------
benjaminjackman
Does anyone have any experience or knowledge about the process of porting a
Godot game to consoles?

I know it’s not built into Godot because all the sdks/apis are behind NDAs for
the consoles, I was wondering how difficult it is, what it entails and if
anyone has experience going the suggested route of hiring the company on the
Godot site to do the porting.

More so than performance this would be the biggest blocker for Godot I would
think ( not that it’s in any way it’s Godot fault ... it’s consoles being
consoles )

------
spookyBlackBox
As a side project to get me back into lower-level programming, I've had the
pleasure of working on a personal fork of Godot.

The engine's simply fantastic from a programmer's perspective. The code is
readable, the architecture is quite intuitive, and with the exception of a few
engine components, you don't run into much in the way of incomprehensible
spaghetti code.

Adding features is more or less trivial, as has been merging upstream modules
from more modern branches into the project.

I see a bright future for the engine, especially after the 3.1 update, and I
anticipate that it'll start seeing significant commercial adoption in the
second half of this decade (it needs a few more years of refinement and PR).

The release of the Vulkan renderer will be a massive boost to public interest,
and developers will increasingly consider it for their next projects.

That said, I do have a few concerns about its development. I'll preface these
critiques with the fact that I'm working from 3.1 stable, and have only merged
from 3.2 as needed.

There's a wide-spread conception among the Godot community that Godot's
performance (especially in 3D) is abysmal. This has been blamed on a number of
factors, such as the memory model (largely heap-based), and the rendering
engine (it uses quite a bit more cpu time than it needs to).

It is exactly the second-issue that has lead many community members to see the
Vulkan renderer as Godot's salvation. I can't speak to that, but as is, many
of the criticisms Godot faces are legitimate.

But among the projects I've seen where performance has been an issue, it's
largely been the product of a developer's failure to understand how the engine
is processing their content, and by extension their failure to architect their
game around that.

This is an issue many inexperienced developers run into on just about any
engine. Godot also lacks editor tooling that would allow anyone but a
programmer to easily mitigate these issues in a scene, even if they knew where
the performance issues were. This, compounded with the fact that Godot has
largely focused on accessibility first and foremost has resulted in a lot of
inexperienced community members without much understanding of the engine's
internals to discourage people from even trying to adopt the engine for 3D
projects until 4.0.

I hope that 4.0's release will be enough to minimize what I believe to be
largely a PR issue, but I also fear that the inevitable bugginess that comes
along with an entirely new rendering architecture may just exacerbate them, or
that it will simply fail to live up to the expectations of many people who
expect a more modern renderer to somehow fix their poorly considered code.

I'm concerned that this will slow the engine's development with respect to its
tooling, as there are few people really testing the bounds of it's
capabilities and workflows.

~~~
benjaminjackman
> But among the projects I've seen where performance has been an issue, it's
> largely been the product of a developer's failure to understand how the
> engine is processing their content, and by extension their failure to
> architect their game around that.

What are some pitfalls everyone is falling into and what needs to be
understood conceptually about how the engine processes scenes?

I’ve found a lot of good documentation and videos on getting started and
particular workflows (eg animating), but haven’t see any regarding performance
optimization or what Godot is doing “behind the scenes”.

~~~
spookyBlackBox
I'll give you a list of pitfalls I've ran into on my current project.

But I'll also caution you not to worry too much about performance until it
becomes an issue for you. You want to make something, first and foremost. And
a lot of developers just getting into games tend to severely underestimate the
amount of work their processors can do before it becomes an issue.

The most easy two to fall into are improper draw call management (requests
made to the GPU to draw an item), and not accounting for the engine's lack of
native occlusion culling (it ends up drawing items obstructed from view by
nearer or larger objects).

The first is an easy fix. The engine draws objects using two object-types:
MeshInstance, and MultimeshInstance. For each MeshInstance you have, you're
going to have a single draw call to the GPU, and the overhead of that really
adds up in more complicated scenes. It's generally a good idea to batch
multiple objects with the same display geometry into a MultimeshInstance,
which will send a single call to the GPU with a list of transforms to assign
to that specific object. This minimizes the communication overhead between the
CPU and the GPU.

The problem with this is that the MultimeshInstance has (to my knowledge) no
in-editor tool for managing its transforms. It has to be done through a
script.

For the time being, I've written a script that enumerates all MeshInstances in
my scene that share a material and display geometry, and assigns them to a set
of evenly spaced MultimeshInstances based on their position in space (this
prevents the GPU from attempting to render too many instance elements that are
off-screen).

Occlusion culling is trickier, and outside of manually setting your own
visibility lists for objects, and deactivating them via script at runtime when
they're out of sight, there's not too much to be done other than to keep
overdraw in the back of your mind right now.

Less specific to Godot, there are a number of optimizations you can make that
work well in any engine.

\- LOD (level of detail) geometry:

Godot doesn't natively support object LODs (different resolution versions of
objects displayed at difference distances). This can be rectified fairly
trivially by toggling different MeshInstances at different distances from your
parent object, and can go a long way to reducing the amount of rendering
overhead in your scene.

\- Shadow casters are expensive:

If you're got a light that casts a realtime shadow in your scene, you might as
well be rendering the scene twice (especially in Godot, since there's no
occlusion culling). Even if you don't have a LOD system in place, I recommend
using a lower-resolution version of your scene to cast shadows, and even
disabling shadow-casting on smaller objects. This can be done by adjusting the
visibility mask in your shadow caster.

\- Minimize Texture Sampling:

If you're writing your own shaders, keep texture lookups to a minimum,
especially on large objects.

\- Adjust the physics tick:

The physics simulations in most modern game engines run at a fixed rate,
usually somewhere between 30 & 60hz. This is (mostly) decoupled from the
game's frame rate. Godot lets you set the update frequency from its project
settings, and I recommend you play with that number until you find the minimum
value that works for your title.

\- Stagger object updates:

If you can get away with running an update less frequently than other elements
in your game, do that. A good example is running the decision loop for your AI
every nth game tick, or every nth second. Batch your AI into n groups, so you
end up doing 1/n amount of the processing you otherwise might have been doing
per-frame.

\- Try to offload purely visual things to the GPU if at all possible:

I've seen a few people writing scripts to add real simple motions to visual
elements that weren't directly related to the game's simulation. A good
example would be a quest marker bobbing up/down above a character's head. This
is something that could easily be done on the GPU using the vertex function of
a shader, and represents an absolute waste of CPU time.

\- If you can get away with it, lower the visual fidelity in your project
settings:

Pretty self-explanatory. Especially when editing your project, you'll
experience a much lower (nearly half) the frame rate you'll see at deployment
at runtime. It's to be expected, you're running debug code, and an editor.
Disable some of the extra visual features if they're only icing on the cake of
your game's aesthetics so you can get a better idea of your title's actual
performance.

------
inDigiNeous
Anyone have some good example project online, that utilizes more C++ scripting
or custom Godot modules even ?

This was the only thing I could not easily find when trying to peruse the
projects utilizing Godot online.

------
spapas82
Any recommended learning resources for Godot?

~~~
wastedhours
Gamefromscratch [0] has a decent series, as does GDQuest [1]

[0] [https://www.gamefromscratch.com/page/Godot-3-Tutorial-
Series...](https://www.gamefromscratch.com/page/Godot-3-Tutorial-Series-
Index.aspx) [1] [https://www.gdquest.com/](https://www.gdquest.com/)

------
fizixer
Isn't Unreal Engine an alternative in 3D space?

~~~
protomikron
Unreal is not really open-source and has a restrictive license.

