Hacker News new | past | comments | ask | show | jobs | submit login
Godot 3.2 (godotengine.org)
366 points by makepanic on Jan 29, 2020 | hide | past | favorite | 138 comments

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...

Y-down coordinates still feel weird to me too, but that's a pretty longstanding convention for screen space coordinates:


(via https://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_Exa...)

Is Unity the odd ball? I've never done any serious game dev but I've done plenty of screen drawing and Y-down is the only convention I've ever come across.

It's more that there isn't a standard, just a bunch of different conventions in different places. Unity is like DirectX, Godot is like OpenGL.

Most content creation software that I've used are right-handed with Z-up, maybe dating back to CAD packages treating floor plans (or other 2D drawings) as XY? Maya is an exception here with a Y-up, and I think SolidWorks might be in that camp as well.


POV-Ray uses a left-handed system with Y-up. I think this is pretty unusual but I always found it strangely intuitive.

ZBrush is Y-up, Z is front-back. It's freaking annoying.

Yes. I think in Unity's case this is a consequence of their 3D and 2D originally (or maybe still?) being the same thing, so they preserved the X and Y axis between them.

2D coordinate systems almost always have top left as (0,0).

Screenspace was always x-right, y-down (aka Cartesian quadrant IV) because that was the convention NTSC used to paint the screen.

3D has not had the benefit of an obvious hardware model to emulate. Y-up, Z-up, Y-down are probably the three most common variants though.

Who else in 3D uses Y-down? I’ve seen Y-up / Z-into-screen (a la Direct3D), Y-up / Z-out-of-screen (a la OpenGL convention), and Y-into-screen / Z-up (top down type games like RPGs, RTS etc.)

I haven't seen Y-down (in 3D space) since software rendering days.

I've yet to meet the monster who would use X-left. :P

I can't think of anything else with Y-down in 3D, but I can sort of see the logic in saying "the vertical axis in screen space and world space might as well be the same."

It's all arbitrary anyway, so why not let one thing be consistent instead of saying "Y is down on the screen, but in the world Y is sideways and Z is up."

(I do still think it's weird, but I'm sure I'd get used to it)

Every game or graphics library i've used had y-down coordinates. It always confused the hell out of me and I'll still make mistakes sometimes. It's the opposite of the machines I spent every day programming. They're all y-up.

I've always found this convention bizarre, because graphs are always drawn with the origin being the bottom left.

I'm not sure where the convention comes from. Maybe CRT screens drawing that way?

Ogre 3D and VTK have a "normal", Y-up coordinate system.

> - 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.

Does this include looking at the [Server] tab in the editor once the game is running? That shows dynamically created nodes at run-time.

Wow, there's a "Remote" button in the scene window which does exactly that. Is this, what you mean?

Thanks! Learned something new!

Yep, that's it! The first thing I made was a roguelike with Godot and I had the same issue w.r.t procedural content and "static" content being disparate.

Someone on reddit showed me this same tip.

You can even change values on the remote tab and have them reflected live in your game, which is fun for prototyping.

I also totally missed this last time i looked at Godot - so off to to play again - thanks for highlighting this.

There's good context/discussion in the PR that implements the game camera override/"hot camera" in 3.2: https://github.com/godotengine/godot/pull/27742

Thanks for this! Didn't realize this was possible.

I second the missing vim shortcuts. At some point I'll probably figure out where the editor source is, mess with it until I have 'i', 'esc', 'd', and 'w' working, then submit an issue on github. I think that sort of pattern is why you see so many open issues - there's just an absolute firehose (dare I say a generation of junior devs) of people looking at this project.

If you search for "vim", you'll find there's already an issue: https://github.com/godotengine/godot/issues/17213 - the latest comment is about a year old and says:

> The current implementation of the text field looked pretty much straight forward and exchangeable. So at anyone reading this, feel encouraged to grab this issue! :-)

FWIW, there is a GDScript syntax highlighter and completion plugin for vim [0], and there was also a GSOC project to add language server support for GDScript [1]. I don't know the exact status of the PRs besides that some parts of it haven't been merged yet, but some did apparently make it into Godot 3.2. I'm sure testing and bugfixes would be appreciated.

[0] https://github.com/calviken/vim-gdscript3

[1] https://godotengine.org/article/gsoc-2019-progress-report-1-...

Language server support is in Godot 3.2, there are extensions for VSCode[0] and Atom[1] currently.

[0] https://marketplace.visualstudio.com/items?itemName=geequlim...

[1] https://atom.io/packages/lang-gdscript

Being in a similar boat, I agree with all of your points. I do think 3.2 includes at least a partial fix for:

> You cannot inspect the scene in the editor visually while debugging.

This video (https://www.youtube.com/watch?v=HuTKFha8QBs) shows how you can override the running game with what is in the scene view.

Aren't top to bottom coordinates actually common in computer graphics?

The reasons seem historic: https://gamedev.stackexchange.com/questions/83570/why-is-the...

Yeah, the screen space in memory started top left and ran to the right horizontally and then down vertically.

IIRC Godot also lets you change the font size, where in Unity it is fixed and awful. I have two 27 inch monitors. Unity looks great on my 4k one, but the UI is basically illegible on my 1440p one because of their janky font handling.

I thought Y up in 3D was strange, coming from Blender/UE4 where Z is up. I was told Y up is coming from OpenGL.

Agreed about 2D being from top left. Makes sense in theory, feels unnatural in practice.

> 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.

Where do the coords start in Unity? Just curious

In Unity up is +y, down is -y.

In Godot it's reversed, I guess because screen updates usually start at the top left corner of the screen.

It's reversed in most places historically. 0,0 is top-left. I think unity is the odd one here

In my teens I used Multimedia Fusion extensively, the sequel of The Games Factory (also called Corel Click & Create?), the sequel of Klik&Play, made by the creators of AMOS and STOS. The three (four?) first uses the same 2D coords orientation, and I suspect also the last two.

Edit: I believe also Scirra Construct uses the same.

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

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?

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.

I'm so happy, that Godot is open source and it's one of the main reasons for me to switch from Unity. Closed source is such a mess, if there are bugs, which never get fixed or features, which are half baked. And there are quite a few in Unity.

They mentioned in the article, that they closed 2000 issues for 3.2 and that's quite an achievement. I simpy hope, that the main maintainers can handle the load. Triage new issues and managing open ones is draining and not a fun task.

I mean to look into the list, maybe find some low hanging fruit, but it costs so much time if you ain't familiar with the engine. Time which could be used to write games... :)

You don't get to ask that question unless you've fixed a few of them yourself.

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!



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

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

*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...

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.

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.

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.

Folks, if you love Godot make sure to support them on their Patreon: https://www.patreon.com/godotengine

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

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

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

They are already paying two full time developers from the Patreon money. There are actually software developers out there (the vast majority of them actually, the US is not the whole world) who do not make 6 figure salaries.

Well maybe this is a good opportunity for those googlers who were writing here about being satisfied with their income but were bored with their job and looking for more meaningful work to contribute to.

In California... In other countries, or many other states in the US, that would be enough. Doesn't mean that people shouldn't contribute, it's a great project!

The developers live in Argentina I believe and it pays for 2 of them. There's a world outside SV...

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.

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).

There is a whole world out there, not only SV :)

International dollars are more valuable than San Francisco dollars.

Don't forget cost of living and lack of other benefits.

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.

If modding is your thing there's a proposal to implement it in a secure way: https://github.com/godotengine/godot-proposals/issues/389

Obviously having full game engines available for free has pretty much usurped modding's place in the games industry but they're still cool and you still get new games based on mods (PUBG is a recent example)

Very cool, thanks for the link!

I am also thinking hard right now about what kind of business model could fit best for foss gaming. That's a whole other conversation though I guess.

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

No they keep saying words about linux support, but their actions don't match. For over two years community forks had more bug fixes for the linux editor than official because they wouldnt accept pr's. Then they refused to make the marketplace crossplatform, and started doing some other things (like Sweeney publicly talking shit about linux coincidentally around the time they made some deals with MS) All in all it felt like a complete bait and switch. You can cross compile for linux, but often with many errors and almost never if you used marketplace assets that werent just models or blueprints.

To be clear, I was talking about two things, linux as a target client platform, and linux as a dev platform.

I can't speak for him but my experience compiling from source wasn't that bad, but if I wanted to use any assets from the store it required having the epic launcher installed on windows, so no download of assets on linux. This was frustrating the first time I showed up to a game jam with a linux only machine, not impossible to use but a pain that felt unnessisary.

No OP, but one related example as a dev, you cannot buy / use anything from their marketplace (like a blueprint plugin) on Linux. There are some hacks out there to load them but you still have to buy them from the Windows client.

Epic just acquired Rocket League and removed Linux support.

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

I'm planning on using Godot for my next game but I hate the scripting language. It feels ad-hoc and I can't stand the absence of anonymous functions.

C# support is pretty great at this point. There are some awkward parts, but overall I don't think you really need to use GDScript. I think GDScript was the biggest mistake Godot made, but they are making strides to make the engine accessible via a conventional language.

Houdini apparently is nice to work with, but IDK how inexpensive it is.

Do you know if Epic scraped the effort to make a parallelized Vulkan renderer in UE?


While it's great that you could move away from it, a lot of in-development games are already stuck with UE, and it's a concern if they won't be able to make well performing Linux releases.

Speaking of Godot, Epic and Linux: in your opinion, would Godot be a good platform to build a Rocket League clone? How good is it at networked games?

I really don't see why it couldn't be done. Take a look at the documentation: https://docs.godotengine.org/en/3.2/tutorials/networking/hig...

To be fair though, in anything where minimal latency is important, the networking comms should probably be done outside the game engine, but I think just doing protyping with the networking api and then seeing if that is needed would be the way to go so you don't create work that isn't needed.

It would take a bit more work in the performance aspect, but entirely doable.

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.

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.

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 :)

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

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.

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

I'm making RoomWithAView [1] in Godot. Not quite a productivity app, more an apartment builder/computer interface. Although on a bit of a hiatus (and a bit buggy) for the time being.

I'm pulling in desktop screens to VR which can be moved and placed as wanted. Working on pulling in individual applications and doing application launching. Aside from that it exposes a good bit of file system access in game. So a decent amount of stuff a productivity app may want to do.

I'm not a Unity guy but I briefly tried VR in Unity and the support seemed quite fractured. SteamVR has multiple versions across stores/github and I wasn't sure which to use, ditto for various tool kits. Godot I just downloaded a sample project and striped it down then worked off that.

The hardest part is doing anything non-gamey. Occasionally I'll make a help post and people will just reply "why would anyone want to do that?" but the C# support means you can use just about any libraries out there, so pretty much anything is possible with enough fiddling. I dropped the idea but even had OpenCV working with the Index's webcams at one point.

[1] https://ark1ve.itch.io/roomwithaview

I built that [1] with it. Getting somehting playable was incredibly fast (but I guess that's not different from unity), and I have not hit any major roadblocks yet. Development was rather smooth. The fact that the hand tracking was supported even before it was supported in Unreal Engine (as far as I know) is also a major plus. A big shout out to Holger Dammertz who did the work on that.

[1] www.vrworkout.at

Just checked out your project's github, very impressive. Can't wait to get my Quest and trying it out, thanks for sharing.

The github page does not yet reflect the very latest release, still have to upload the video (due to lack of time :) ). But the latest version has an additional freeplay mode without music (just the sound effects), that way you can play your own music hit the drum to the beat of the music to tell the game the BPM and then you can play to your own background music.

I’m using it for VR dev on the oculus quest and I think the dev experience in 3.2 is very good. I haven’t actually used Unity, though, so not sure how it compares.

Once you get it all set up, you can just hit the android button and it’ll export the apk directly to the device. Also, you are still able to live view via wifi.

Game engines are not the only path for that kind of app. I have written apps (not games) using just OpenVR and Vulkan. The only questionable choice in that combo was Vulkan - bootstrapping that was a major time sink. OpenVR doesn't have tons of documentation, but when you start out from one of the examples, you should be fine. It is a pretty decent API.

Yeah, there's not a lot of choice in how you represent an API for a VR headset. You have to give the implementing program a position and orientation at some point. And you have to do it fast. So I think most of the APIs end up pretty similar in concepts because of that. In some cases, the data structures are almost identical, other than the names of fields.

That is true. Some of the OpenVR input event handling and compositor interaction is a bit weird, if you need any of that at all. The rest is quite straightforward.

It's not the API itself, but juggling all the different coordinate systems (room, eyes, controllers etc.) that tends to keep things interesting.

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.


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

I, like many hobbyist gamedevs, have: 1) built fully bespoke games, 2) built my own game engine, 3) built games using low-ish level libraries (like phaser.js), 4) used game engines. I offer this history to show that I too enjoy writing my own code.

But I love Godot. I struggled with it too, at first, but probably around hour 6 of messing around, it all just clicked: Godot is actually a visual abstraction of object oriented programming. You get to write and extend visual classes, then instantiate them in scenes.

Once it clicked, I realized this is exactly what I wanted. An engine that knows how to do physics, 2d, 3d, etc, and gives me very fine grained control over how objects in this universe behave (basically, anything you can code, you can attach to a node).

So based on what you wrote above, I think you would actually like Godot. There is a steep learning cliff, but once you get past that Godot lives at just the right level of abstraction. Doesn't do too much, but does the stuff you shouldn't have to worry about.

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.

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

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.

>but I would rather spend time learning an actual universal graphics API that works on all hardware,

Unfortunately such a thing doesn't exist. You either have to choose something that hides the graphics API or use the preferred API of the platform (Metal on iOS/Mac, DX12 on Windows, Vulkan on Linux). If you decide to use a second class API then your UX will be second class but game engines don't suffer from that because they use the platform specific APIs directly.

> an actual universal graphics API that works on all hardware,

Good luck with that, no, game consoles don't do GL, most Switch games use NVN and it remains to be seen if PS5 will have Vulkan support.

These engines and frameworks are welcomed by the industry, because in most studios game development teams, the programmers are a minority, game designers and scripters are who actually make the game.

Anyone that wants to learn how a computer works should learn Assembly and low level coding.

Get a Raspberry PI and do bare metal game coding in Assembly like we used to do in the 80's.



You might want to look at how the editor is built. The editor uses the Godot engine as an "engine" (as opposed to a framework).

So the UI and everything are written in C++.

That seems to be exactly what you are looking for.

I stumbled upon Godot after seeing (and buying) 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!

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

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.

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

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.

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"...

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

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.

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.

It doesn't have lambda, even the bad lambda from python.

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.

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.

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

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?

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.

I've made several small games for fun, and used Godot in Ludum Dare: https://ldjam.com/events/ludum-dare/44/meter-maid-dx

GDScript is very comfortable for doing simple game and UI logic, but it can be problematic that there's standard/easy way to import other people's code libraries besides copy-paste jobs.

When trying to do some sort of complex logic or when I really could use an external library for something, I simply go to C# to scratch that itch, and it's been working out pretty well for me. You can even have the two languages inter-operate to a degree within a project.

I've used Godot to make a few 2D games and the experience was wonderful compared to Unity (for me). GDScript is similar to Python and very easy to learn. Godot also has GDNative that supports bindings to lots of other languages, so you might want to look into that: https://www.reddit.com/r/godot/comments/bbfpa7/what_programm...

GDScript is really easy to pick up, well documented and like any DSL created specifically for one job, it's straightforward without sharp edges. I've used many languages in games including C++ and I find GDScript a breeze.

If you need something only another language has to offer, unless it's a big library, conversion to GDScript is usually the matter of a few hours at most.

Otherwise for 2D another game engine I'd recommend is Love2D.

If you can write Python, you can write GDScript. You'll get bitten very occasionally with the differences, but the core language is extremely similar. As for a package registry...meh. There are a lot of built ins to GDScript that make depending on external code mostly a non-issue.

It's very limiting, and for many other reasons than the lack of a package registry. My advice is to not lose time with it and go straight to C#, unless your projects are throwaway game jam entries.

This is just personal opinion on my part. Godot is a wonderful project and the Godot team have done great work.

I gave up on Game Maker years ago because I realized I was pouring hours and hours into learning a language I would never be able to use anywhere else, and as much as I like Godot (and I'm really starting to like it) I feel like I'm kind of making the same mistake. Even though Godot has support for C# and third party support for other languages[0..5] I have no idea how mature such projects are, or what the long term support prospects are.

Like as not, Godot is built for GDScript, most if not nearly all tutorials assume GDScript, and any plugins you find will probably be using GDScript. You can probably assume that GDScript support is guaranteed for the future, and at best, C# support is probably guaranteed for the forseeable future, though not necessarily at parity with GDScript, version to version.

Oh, and it also apparently Godot has its own shader language so forget about using GLSL as well, probably.

As far as the language itself goes, GDScript has significant whitespace, and I don't like significant whitespace. Its idioms tend to be just unfamiliar enough to me that I keep forgetting things that would be obvious in another language. I really wish it had lambdas.

BUT... it's still a capable language and obviously it does what it says on the tin. I guess you can stick with C# or wait until one of the other language projects matures, or just bite the bullet and use GDScript. The framework itself is so much easier to deal with than Unity IMHO, and for 2D I think it's worth the frustration. All of my issues with the language, thus far, are relatively minor and entirely subjective.







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.

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.

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

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

On a Mac? No.

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

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

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

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.

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.

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.

Good grief, don't look at the UE4 release notes for each release then. It's a C++ game engine, and the release notes go on for pages detailing the new features. You'll have a conniption.



Game engines this size often add many new features with every release, and the target audience (programmers and artists) want to know about all of them.

The release notes cited are models of clear communication. No one encountering them would need to look anywhere else to know whether UE might be of some interest.

Things like release announcements require background knowledge. If you are lacking that background knowledge then ignore them or acquire it. There is no need to baby sit every potential new comer with a pointless introduction that will be skipped by 99% of the readers. Not every tiny blog post is trying to shill a product.

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.


Please don't do tit-for-tat flamewars on HN. They're angry and boring and go against the intended spirit of the site.


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.

Please don't do tit-for-tat flamewars on HN. They're angry and boring and go against the intended spirit of the site.


>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.

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.

> some poking around

It's just one click on the logo to go their home page that says it's a game engine with some big features like being open source.

If you happen to click on exactly the right thing, maybe you get taken somewhere useful. Or, not, as in this case. I needed to do quite a lot more clicking to verify it is C++, and more to find out it (or anyway the part I saw) is C++03. A single sentence in the announcement, or even on the home page, would have saved that effort.

Being mysterious must provide some other benefit, to someone, if it has such vehement defenders. I know better than to ask what or who.

>Being mysterious must provide some other benefit, to someone, if it has such vehement defenders. I know better than to ask what or who.

I don't know what axe you have to grind but what you're doing is basically the equivalent of looking at the fifth page of a bus schedule and then getting angry at not knowing what a bus is even though it is clearly written on page one.

If you want an introduction to a product then go on the home page [0], the features site [1], the Wikipedia site [2], anywhere except the darn release notes. People are getting angry because there are huge big fat eye catching buttons in the header that point to these pages and you're purposefully ignoring them to the point that you're basically trolling.

[0] https://godotengine.org/ [1] https://godotengine.org/features [2] https://en.wikipedia.org/wiki/Godot_(game_engine)

Two out of those three links do not quickly reveal anything meaningful to anybody not already familiar with the project.

Really, what is so difficult about this?

Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact