
Godot 3.2 - makepanic
https://godotengine.org/article/here-comes-godot-3-2
======
zubspace
Been playing around with the Release Candidate, coming from Unity. Here's a
list of things which I like / dislike:

++ Open License and friendly community.

++ The scene graph (node tree / prefabs) is well done, better than Unity. You
can easily switch between scenes (Prefabs) through tabs and convert subtrees
to separate scenes. Nesting scenes works really well.

++ The inbuilt scripting documentation is great.

\- C# is not fully there, yet. No Visual studio integration. Debugging through
VSCode is a pain. WebAssembly Exports are not optimized yet. That's why I
sticked with GDScript.

\+ GDScript is a nice language with optional type hinting. But refactoring can
mostly be done through search/replace.

++ Windows and HTML/WebGL exports are super fast. I did not have problems
since the RC.

\- The inbuilt editor for GDScripts is ok. But I'm missing my VIM shortcuts...

\- Arrays, dictionaries are not generic. Enums are not typesafe either. Bit me
a few times.

\- You cannot inspect the scene in the editor visually while debugging. This
is what I miss the most coming from unity. Some things are really hard to
debug this way, for example if you use procedural generation.

\- 2D coords starting at the top left corner of the screen and increasing
right/down is really confusing. If the player jumps, y goes down. It's a bit
strange.

\- I'm a bit afraid regarding the +5000 open issues on github. I wonder, how
they will handle that in the future...

~~~
vfclists
concerning the +5000 open issues on github, when are you going to pick a few
and see what you can do to fix them?

~~~
MrGilbert
Why should he/she? If I support Godot financially, I'm not going to pick up
issues. Yet, I should be allowed to raise concerns, shouldn't I?

~~~
imtringued
You are allowed to raise concerns at any time even without financial support.
However, it is considered poor form to waste the time of someone who is
working without payment.

------
electronstudio
When I started developing RetroWar[1], I found Unity quite a disappointment,
and so I developed my own custom engine in Kotlin. It works very well, but it
took several years.

Recently I tried Godot because I was looking for something simple I could
teach to kids[2], and I was amazed how easy it makes game creation. I made
these games with no experience in just a couple of days!

[https://github.com/electronstudio/godot_racing](https://github.com/electronstudio/godot_racing)

[https://github.com/electronstudio/godot_space](https://github.com/electronstudio/godot_space)

GDscript is great. It's similar enough to Python that kids who know Python
won't notice much difference, and it actually simplifies things for beginners,
e.g. you can use objects without the need to define classes because they are
created automatically when you create a script.

Godot is still a little rough around the edges, e.g. not everything has
keyboard shortcuts, sometimes it crashes, some of the built in tools like map
editor are very fiddly to use. But it's open source so I'm sure they will be
fixed eventually (and if they aren't I can always do it myself.) The only
major issue I can see for the future of Godot is the lack of exporters for
Xbox, Playstation and Switch.

[1] [http://retrowar.net](http://retrowar.net)

[2]
[https://loughton.me.uk/2020/01/22/godot.html](https://loughton.me.uk/2020/01/22/godot.html)

~~~
olsonjeffery
*lack of public exporters. Because of the NDAs around shipping for these platforms, no one can "advertise" that they have the exporters, but the truth is that there are consultants/gamedev shops who have done this work for all of the current platforms. You just have to get in touch with them via the community.

EDIT: This page has some backstory:
[https://docs.godotengine.org/en/3.0/tutorials/platform/conso...](https://docs.godotengine.org/en/3.0/tutorials/platform/consoles.html)

~~~
electronstudio
Sure you can hire someone to do the port - they do advertise it on that very
page.

But there is another open source game library, Monogame, that distributes
their code for free for consoles. You just have to vertify that you are have
signed the NDA before you get access to the code. They advertise this. So
there is no reason that Godot couldn't do the same if they wanted to open that
code.

~~~
olsonjeffery
A lot of assumptions going on in this comment. You should actually consider
testing some of them to see if they're true or just mistakes on your part.

Putting that aside: developers who do this kind of (difficult, tedious and
thankless) work are entitled to ask compensation for their effort, on top of
everything else they do for free.

~~~
electronstudio
Yes people are entitled to sell proprietary forks of free software - it's a
non-copy left license so perfectly legal. However it puts Godot in a poor
position relative to competitors. If you want a free console game engine you
could use Monogame. If you want a non-free console game engine then you could
use Unity or Unreal and you would have the advantage that you know up-front
what it will cost and you know that it will be well supported by well-known
developers throughout the lifetime of the console. Godot is a very compelling
choice for PC and mobile, but the current situation of “there is console
support but it’s a secret so we can’t tell you who makes it, how much it costs
and how long it will be supported in future” makes it very difficult to
recommend Godot over those alternatives to anyone developing console titles.

------
shafyy
Folks, if you love Godot make sure to support them on their Patreon:
[https://www.patreon.com/godotengine](https://www.patreon.com/godotengine)

(I'm not affiliated with Godot, I just use it and love it)

~~~
SeekingMeaning
They’re currently at $10,000 a month, or $120,000 a year. That’s really
amazing!

~~~
indigo945
That doesn't even pay for a single developer if factoring in taxes and other
costs of employment.

~~~
nameless912
I think there's only two full time developers on the project, and both are
based in Brazil, so this actually goes a really long way.

~~~
NilsIRL
Akien (project manager) isn't based in Brazil, he's French. And Juan (project
manager) lives in Argentina (according to his GitHub).

George however, who has been employed only recently does live in Brazil
(according to his GitHub).

------
arminiusreturns
Godot has been a breath of fresh air for me lately (been running master branch
for a while) and I know that it is going to only get better. I can't wait for
the vulkan renderer to be ready, I think it's going to a game changer for
godot.

After Epic originally promised to make linux a first class citizen, I went all
in ue4, but they lied and went back on all those promises, and I have since
moved to a completely open source gamedev pipeline and I think it's the
future.

For example, think about how much mods make or break game longetivity and
communities. If valve hadnt given us world hammer, there would be no
counterstrike, no tf2, no garrys mod, no age of chivalry and ergo no chivalry
medieval warfare. The residual effects of modding capabilities are huge, and
having formats that are easy to work with with normal tooling (like gltf) mean
open source gaming in a game engine like godot (or a few others, armory3d is
another) could be a sleeping giant just in the early stages of waking.

~~~
diegoperini
Did they ditch the entire idea of having Linux support or is it just that they
were slow on improving the compatibility?

~~~
EamonnMR
Epic just acquired Rocket League and removed Linux support.

~~~
simcop2387
and macOS support too, [https://www.polygon.com/2020/1/23/21078948/rocket-
league-mac...](https://www.polygon.com/2020/1/23/21078948/rocket-league-mac-
linux-support-final-patch-march-features-online-offline)

~~~
EamonnMR
Especially annoying because we used to play it all the time at the office and
we've all got macbooks.

------
diegoperini
I loved the tone of this article. The parts where it says things like
"Bastiaan did this, Yuri did that..." is what I always want to see in these
kind of technology news.

------
blensor
Thanks to the Godot devs. I've been using the 3.2 betas over the last months
and I was totally happy with the experience. But I am happy that I can work
with an official release version now which makes it easier to have others use
the codebase as well.

------
nnq
Anyone here using Godot for VR/AR dev? ...curious what's the story here and
how it stands against Unity on this front since I'm lately interested with
developing VR productivity apps and using a game-engine seems like kind of the
only viable cross-platform solution for this, the path that others have taken
too.

But which engine... that's an open question, and I'm not that fond of Unity :)

~~~
shafyy
I can recommend Godot for VR. I switched from Unity to Godot a couple of
months ago and haven't looked back. I'm developing for the Quest on Mac and
Godot is significantly faster in building to run on your device. Plus, the
hot-reload feature means that you don't need to rebuild every time (although
once your Quest goes to sleep you need to rebuild). Other than that, I love
Godot's node system, that it's compatibile with a mulitude of languages
(although GDScript is awesome and I didn't need to add C# or something as of
yet).

If you're looking at the Quest, Holger Dammertz is doing an awesome job with
the Oculus Quest Toolkit[0] where I'm also a contributor.

[0]:
[https://github.com/NeoSpark314/godot_oculus_quest_toolkit](https://github.com/NeoSpark314/godot_oculus_quest_toolkit)

~~~
nnq
Thanks! My dev setup would also be "for Quest, on a Macbook" 80% of the time,
so it means a lot if you found the very same scenario to work :)

...still hacking around with Unity, but after I get a basic PoC of what I'm
doing I might switch to Godot (with C# as the language) for developing the
actual MVC.

~~~
shafyy
Sounds good. Let me know if you have any questions =)

------
jokoon
I tried to learn it a little but I did not manage to understand how it works,
I don't really like the whole WYSIWYG thing, it forces the developer to
surrender control, and you waste a big amount of time teaching yourself how it
works internally, time that could be spent being productive with a simple
renderer.

It also seems to support c++ as "gdnative", although it requires another
compiler to link against godot's binaries. It seems awkward because you still
need to use the godot editor, and there is still a lot of interfacing to
write.

It seems like a good alternative to unity, but in the end, all I want is an
engine, not a "framework" or some awkward scene editor with some kind of Node
hierarchy/interface.

I could say the same thing about UE4. I hear everywhere that's it's the place
to go, that "everybody uses it and it's the norm in the industry if you want
to make a game from scratch", but the reality is that those frameworks are too
big and too feature rich. It sounds like they want to attract young developers
to lock them into those awkward frameworks, because they advertise it as being
full-featured engines, but small developers might not really need to focus on
bleeding edge rendering, so it doesn't make sense.

I know there are engines like Ogre3D, but I would rather spend time learning
an actual universal graphics API that works on all hardware, which has more
value on a resume, and I can just use what I need. All other things like
audio, animation, inputs, physics, etc are available as C++ libraries.

Those frameworks are saying "see? you can make your own game with those
tools!", but when you actually learn how a computer works, and know how to
write code, you realize you want to avoid those frameworks because they
conceal too much from the programmer, and usually you don't want a developer
to not understand what the framework is doing. I guess this is why people have
a problem with certain object-oriented practices and abstraction.

EDIT:

Here is a nice video which benchmarks unity against a simple, very similar
from-scratch equivalent.
[https://www.youtube.com/watch?v=tInaI3pU19Y](https://www.youtube.com/watch?v=tInaI3pU19Y)

~~~
unknown2374
I think you are missing the fundamental purpose behind game engines. Game and
graphics programming is really hard, and at times unapproachable to a lot of
people. Moreover, in the real world, even experts prefer to use game engines
just due to the fact that it is almost guaranteed that a raw renderer you
write yourself is not going to be as good and optimized as a game egnine's
renderer.

Using game engines may not suffice to your use case, but for a lot of people
that's the best way to develop games. This argument is similar to using a
systems level language vs a higher level language.

I myself prefer game frameworks over either raw graphics APIs and game
engines, since it provides me with my preferred level of control while meeting
my particular needs. I can see where you come from, if your goal is to learn
and highlight that in your resume, writing and experimenting against the
graphics APIs are likely the best bet. But for a lot of people, their main
goal differs from yours, which is to... make a game.

~~~
jokoon
If one doesn't understand how a game works, a framework is not going to help.
This person will probably shoot himself in the foot.

Here is a good video about benchmarking unity
[https://www.youtube.com/watch?v=tInaI3pU19Y](https://www.youtube.com/watch?v=tInaI3pU19Y)

~~~
mntmoss
Most of the effort that goes into a large game project is not in the runtime
code, but in content creation: you probably only need one renderer or one
physics system, but lots of levels, lots of characters with unique behaviors.
So what does every one of the top general-purpose game engines provide? An IDE
geared around content creation.

It is no surprise that you can find a benchmark where a general-purpose engine
is slow. If you do nothing you go fast, but if you are supporting general-
purpose use cases you add a lot of feature overhead, so you become slow. Why
do pros use it, then? Because - if the engine is sufficiently extensible -
they can use the built-in stuff as a placeholder and replace that subsystem
with a custom one later. Project ships, everyone's happy.

With microbenchmarks based around scaling simple elements like "thousands of
bullets" like the one in the video this point on general-purpose elements is
especially important. As soon as you want to add any additional behaviors to
those bullets your performance is going to plummet. And from a game design
perspective, scale becomes boring very quickly. A player cannot really
appreciate seeing more than a few hundred things on-screen at any moment.

So the way scenes are actually benchmarked in industry is by building out more
of the behavior, adding placeholder assets at the estimated level of detail,
seeing what frametimes result, and developing a scene budget around that. It
all feeds back into the content creation pipeline again, because an optimized
scene will have more care given to each of its assets.

------
cdiamand
I stumbled upon Godot after seeing (and buying)
[https://store.steampowered.com/app/1189230/Door_in_the_Woods...](https://store.steampowered.com/app/1189230/Door_in_the_Woods/)

It's an ascii roguelike with a neat 3d aesthetic.

Godot was a pleasure to install and play around with it. I recommend taking a
look!

------
edf13
Congrats to all 450 contributors who worked on this over the last 10 months!
GoDotEngine is something on my list of things to get into as soon as time
allows.

~~~
jhauris
The amazing thing to me is that 300 of those contributors were contributing
for the first time.

------
xwowsersx
My son (10 years old) wants to learn how to make games so we sat down together
and went through the tutorial from the beginning. Very enjoyable.

~~~
keyle
Nice! I made a tiny game with a car for my 3 year old and he's already asking
me "how do I do this too"...

~~~
xwowsersx
Awesome! Nice to be able to share the joy of programming using an activity
kids already love.

------
disease
Supporting the web target for c# is a HUGE deal for me as someone that makes
hobbyist game jam projects and doesn't want to learn another language (already
know c#, not thrilled about learning GDScript).

I can't understate how much of a big deal the growing support for c# is. Both
for non-game devs who want to dip their feet in making games and also luring
in current Unity developers.

~~~
csdreamer7
GDScript is just Python that has some tweaks.

For example to preload a child node you put this in a node's member space.

onready var enemy = $Enemy

Variables needing to be declared with the var keyword is the biggest change in
the language.

var flag = some_function_result()

Other changes include expanding Python with more keywords useful for the
editor and game programming.

It is very nice for prototyping. Still looking forward to that C# AOT support
in later releases.

~~~
vincent-toups
It doesn't have lambda, even the bad lambda from python.

~~~
aaronsnoswell
This is an intentional design decision in the language - not having lambda
functions / functions as first-class citizens makes the code easier to
optimize internally.

~~~
vincent-toups
It also makes me feel like I'm programming in 1987. LuaJIT does fine with
lambdas and I'd bet good money chibi-scheme is faster than GDScript. Its not a
really good excuse.

------
somebodythere
I am refreshed by Godot's versioning scheme. Point releases are something to
get excited about.

------
Kiro
I make 2D games and it seems that Godot is good for that. I'm scared of
GDScript though, e.g. not being able to use a package registry that normally
comes with standard languages. What's everyone's experience?

~~~
willis936
After looking into as many engines as I could find, I chose godot for a 2D
game. I don't have significant game creation experience, but I've consumed a
lot of media and pay close attention. While I'm not neck deep in development,
GDScript seems perfectly reasonable. Most of what it's used for is in making
things that are somewhat custom/demand labor anyway. Menus, object
interactions, etc. It just takes a few days of playing around with test
scenes.

What I have yet to try to tackle is the C import tool. Let's say I have a grid
of many objects that interact with each other. I don't necessarily want
GDScript to be running the logic for 10,000 objects (an extreme number, I'd
likely limit it to less, but I still like the idea of keeping performance in
mind). So C is a good choice. But suddenly I have to establish and maintain a
big connection between GDScript and C. Everytime a feature is added it has to
be added in several places. Maybe this is just the way things are done and I
should just do the work. I'm worried it is the wrong way to do it.

------
WillYouFinish
I feel like I used Godot wrong when I read these comments. I did three small
games and it seemed to me that everything in Godot was put on the same
complexity level. Everything is simple, but super simple tasks have become
harder. And then there are inconsistencies like the sprites are not in the
node tree but in another space. I don’t get it. I found it really hard to get
my ideas into the engine. The low level approach would take just a fraction of
the time for me.

------
eli_gottlieb
This looks really nice. Every time I see Godot, I tell myself that one day
I'll get around to making that game I dreamed up in undergrad.

------
rcarmo
Need to try it ASAP, although I see the issue that prevented my kids from
using it
([https://github.com/godotengine/godot/issues/24890](https://github.com/godotengine/godot/issues/24890))
is still open - managed accounts present a few challenges, but I hope this has
been sorted somehow.

~~~
klohto
Would running it inside a container and creating shortcut for your kids be a
possible workaround?

~~~
rcarmo
On a Mac? No.

------
woollysammoth
I've been working with Godot/Websockets lately and it has been really
enjoyable -- excited for Juan's 4.0 vulkan work!

------
malkia
The UI looks really polished, but it's missing one crucial feature - multi-
monitor ("window") support - with docking.

------
phn
Just in time to try it on the global game jam next weekend!

------
legostormtroopr
I've been waiting for this! My friend and I were starting to doubt it would
arrive.

------
ncmncm
It took rather some poking around the site to discover that Godot is
(apparently) a game engine coded in C#.

Hint for people posting release announcements: you could save a great many
people quite a lot of time, cumulatively, with just a single short sentence in
the first paragraph of your announcement. You probably would pick up some new
participants who would have given up in disgust before they could discover
what the hell the thing is.

~~~
DisownedWheat
It's not coded in C#, it's written in C++.

Release notes for a new version are not the place to list all the features of
the engine. You can literally click on the home page and see "Object-oriented
API with language options such as GDScript, C#, C++ and visual scripting.".

If people give up "in disgust" because they can't find what language the
engine uses for scripting immediately in the first sentence of a release
announcement then they're probably not cut out for making any kind of software
which requires digging through documentation.

~~~
ncmncm
So even looking around and following links, I still guessed wrong about what
the hell it is.

 _Nobody_ asked for, or needs, a list of "all the features" in a release
announcement. Saying what the project is (such as that it is some kind of
"engine", and maybe even what kind?) would have been a completely different,
and much shorter and overwhelmingly more useful statement.

What should motivate a reader who cannot even tell what it is to spend time
groveling around to find out whether they might be interested in the thing?
Hint: most projects are not interesting to most people. Forced to guess, the
best guess has to be "no".

I am repeatedly astonished that such elementary reasoning seems beyond so
many.

As it happens, for example, a game engine in C# is of zero interest to me, but
one in C++ could be quite interesting. I dismissed it as a direct consequence
of the failure of the announcement to give me any reason to pay it any more
attention.

~~~
DisownedWheat
If having to click on the logo to go to the home page sends you into such an
apoplectic rage then I don't know what to tell you. If you look at, for
instance, the .NET Core 3.0 release notes[1] there is no mention in the first
few paragraphs of what it is. You have to click away to see it.

"I am repeatedly astonished that such elementary reasoning seems beyond so
many." Perhaps you're just wrong? If everywhere you go smells like shit you
should check your shoes.

[1][https://devblogs.microsoft.com/dotnet/announcing-net-
core-3-...](https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/)

~~~
ncmncm
I realize that by now I should not be astonished, only disappointed. It is
probably not your fault; education has been in decline for a long time.

I feel no slight temptation to look at .NET announcements, nor to draw
conclusions on good practices from them.

But all of the apoplectic rage is clearly on your side.

~~~
imtringued
>education has been in decline for a long time.

Is this supposed to be a joke? The information exists but you didn't try to
find it.

~~~
ncmncm
I was specifically offered no reason why I should have any desire to dig
around and find out more. That is the problem.

It is the entire topic of my original post.

Really, what would be so terrible about a short sentence in an announcement so
that people who don't already know all about it get some hint at what it is?
No one has suggested anything like an answer. Instead, I find rage that I
don't, what, just automatically go digging deep into project pages for _every
single new thing_ announced, just in case whatever it is might turn out to be
interesting?

Everyone has a lot of demands on their time and attention. A person writing an
announcement is necessarily trying to communicate and engage. Concealing the
topic sabotages the effort, right out of the gate.

