Godot 3.5 | Hacker News Reader

Godot 3.5

godotengine.org

179 pointstmstieff115 comments

I've been part of shipping one of perhaps the largest used Godot projects in production. It's not a game, and you may not even realize it's Godot. Godot is below average in quality compared to Unreal, and probably about on par with various idiosyncrasies that Unity has.

Unreal is winning the technical race because they ship projects and games themselves with their engine. Unity does none of that, at least nothing that counts. Godot is a bit better than Unity because it's open-source so contributors are often contributing to things they use and want to improve, but it's still got weird opinions at a maintainer level and severe performance downfalls from those opinions.

We're considering another renderer, but for the time being we're still tepidly okay with Godot.

How is Unreal on mobile and VR these days? The new UE5 tech doesn't seem to run on it. I can't really speak from experience but it always felt like mobile dev was a much higher priority for Unity than Unreal. Is that still the case?

It works for mobile. Likely not one of the primary use cases though.

VR support is there. Again, I think not the engine's priority. Last I checked some of their new core tech behind ue5 (lumen, nanite) didn't work correctly in VR, though that was around launch time. I would probably start a new VR project in Unreal, and Godot for mobile.

edit: the RE4 VR remake was in Unreal for example

Can I ask what it is you're using godot for if it isn't a game?

You can build really fancy UIs in it so you can use it for basically anything.

what's the lowest hardware requirements you would say you could run a Godot built UI on (not necessarily your product, just generally?)

Think folks have used in on a Raspberry Pi

Godot doesn't really export for ARM though, are you sure?

Is that so? Well there you go, something for me to contribute!

There's absolutely no problem to run Godot on ARM (or other architectures). I can run the whole editor on my phone. It's even in Debian repos.

Yeah I can find the armv7 and v8 build options under Android APK export, but not under generic Linux. At least none I can find under presets.

I suppose you could run Android on the Pi instead though, which might be what they did.

You can easily build export templates for any platform by yourself. My phone doesn't run Android, but a regular aarch64 GNU/Linux distro.

Oh I'm sure you can compile your own support for it yourself, it's open source code after all. But there's no way to do it as-is in the shipped editor.

Sure, but that doesn't make running Godot games on a Raspberry Pi any problem, which was the clue of this thread.

Not OP but educated guess: Tesla's mobile app. https://twitter.com/AlexGuichet/status/1528149807709048833

You’d be right, and we’re hiring to invest more in 3D visualizations in the app. https://twitter.com/alexguichet/status/1549492941202137088?s...

Interesting. What do you think of Flutter? It's in a similar space of building mobile apps, not sure how well visualizations work in Flutter though.

It's probably worth mentioning that the Godot Editor itself uses the Godot engine.

It's small enough of a code base that you can change things to suit your needs, too. Godot is definitely going to win the race long term, just like blender. People can use whatever they like, of course, but if you want future developer talent, youre going to need to use Godot.

That's a very bold statement, what has Godot done to warrant it?

It's not even the most advanced open source 3D engine right now, considering O3DE (a fork of CryEngine) is open and backed by a fair few big players.

Usability. For artists and non professional programmers, those options are fairly inaccessible.

Is it usable because it's... usable, or is it usable because it's barebones? It can be hard to tell the difference when it's pretty far from feature parity with the competition.

FWIW, I don't think cornering the non-professional developer market will lead to market dominance. GameMaker is even simpler, and even if it were open source, hobby developers will not be competing technically against thousands of full time, professional engineers working on an engine.

O3DE requires "40-100 GB of free disk space" and a separate compiler.

Godot (3.5) on the other hand requires a paltry 72.6 MB. Even less if you go for older versions or recompile it without certain features. It comes fully featured with it's own scripting language (or C# if you prefer but that requires extra disk space) and pre compiled builds for distribution with the final product. You can still use C++ if you wish however I've personally never needed to.

Godot may not be the biggest and flashiest engine out there but I find that it uses what it has got very effectively. It's extremely easy for newcomers to set-up (Just click the executable and you're all set. It even has it's own IDE.) and comes pre-packaged with the majority of features that your average developer will need.

For comparison, I'd say that it's the game engine equivalent of "QBE" or "tcc" to O3DE's "LLVM". It packs most of the punch of the latter in a neat little package.

But I was responding to claims that it will be ubiquitous in the industry, not that it's easy to get started with.

> pre-packaged with the majority of features that your average developer will need

From my minimal experience with it, I'd disagree. What's the biggest (3D) game built with Godot?

My point is that an engine with easy onboarding and relevant functionality would address most developers' requirements and likely earn it a place in many companies' toolboxes but to address your second point, off the top of my head I believe that game would be the Sonic Colors remake.

There were certainly teething problems with the Switch version but I definitely think it's a good sign when people contracting for a company as big as SEGA are using it.

In that vein however, I ask this: O3DE is a fork of the Amazon Lumberyard engine. Amazon Lumberyard has not been very successful with only a handful of companies using it, mostly Cloud Imperium and Amazon themselves. How do you forsee O3DE changing this pattern?

Godot does not have relevant functionality though, out of the box, 3.X version are missing many features which prevent it from being easily considered for a major 3D game. I can see it being picked up at even AAAs for prototyping yes, but for full production, not in its current state no.

Sure, Sonic Colors is a decently sized game, but it's really the only notable one (in commercial terms), and a recent release. This is for an engine that is nearing 8 years old.

O3DE is a fork of Lumberyard, but Lumberyard was itself a fork of CryEngine, which should need no introduction. It actually already has a game using it too, listed on Steam - https://store.steampowered.com/app/1142050/Deadhaus_Sonata/ Lumberyard was used mostly for internal projects, but that's because it wasn't meant to be generally available. Amazon is still backing O3DE with many full time engineers, while having notable partners, some of them big game development studios or tools, suggesting unannounced projects are picking up the engine too.

Now, as to why I believe O3DE will succeed - it's got AAA roots, but it's also being rapidly reinvented, while being steered by ongoing in-house projects. The value of major projects being undertaken in-house can not be understated - Unity praised their first big project for providing immense amounts of feedback (and promptly fired the team later...) Amazon can simply afford to throw money at O3DE till it's competitive, while Godot targets a less lucrative demographic.

Look, if Godot 4 turns out to be amazing and competes with Unity and Unreal while being super user friendly, I will be over the moon. Maybe I'll have to re-learn a bit of game development, but that's no biggie. For now, I've tried Unity, then Godot, and then Unreal, and Unreal was the first one that felt feature complete, at the cost of some user friendliness. If I were to run around implementing basic things like I had to with Godot, I would maybe get a game done in a decade or two. I'm trying to maximise the efficiency of my labours being conscious of the limited earth time we all get.

How relevant O3DE is in practice though?

More relevant than Godot was at a similar age. Just look at the partners, for example. If the engine picks up steam, could easily see it becoming huge - at least as a base for in-house forks for studios.

https://www.o3de.org/

Partner list doesn't indicate any kind of relevance, and Godot's history is very different, so you're comparing apples to oranges. How many teams are using O3DE to build stuff? How healthy is the user community? How hard is it to find outsourcing and porting houses that work with O3DE? Learning resorces? Extension and asset market? Do you personally know anyone who works in it? Those are all things that Godot does reasonably well these days, while I don't know the answers for O3DE without actively searching for them despite of being in the industry for years and knowing about O3DE since its announcement, hence my question.

O3DE was a code drop that needed to pick up steam almost from scratch, while Godot has already acquired it over years. Also, they're not exactly targeting the same market segment, O3DE being more of an Unreal Engine-wannabe, which is much more challenging. I wish it well, but it doesn't seem like it's anywhere near "relevant" just yet. It's more like a last chance given to Lumberyard to not fall into total obscurity.

Please re-read the context of the conversation you're replying to - if Godot is not targeting the same market as Unreal, then you're agreeing with my point, not disagreeing. I'll recap anyway.

> Unreal is winning the technical race because they ship projects and games themselves with their engine.

> Godot is definitely going to win the race long term

> what has Godot done to warrant it?

---

It's been open source for around a year. It doesn't take a genius to figure out it's not ready for prime-time, and does not have a community built around it yet. You're also dodging the question of what the biggest game built in Godot was, considering Godot has been around for so much longer.

Deadhaus Sonata is using O3DE, and already looks bigger than any game on the Godot showcase page.

> O3DE was a code drop

With mostly Amazon working on it currently, it's got around the same LoC changes being made to it currently. There's others working on it too, and as more games start using this engine (announced just over a year ago, mind you), the contributors will increase. Games take a long time to even announce - a few years after the start of the project is the typical time-frame. This excludes indie games that Godot typically targets of course.

It's totally bizarre to compare Unreal Engine with Godot. One is a AAA 3D game engine with awful support for 2D games, the other is a superb 2D game engine with modest 3D capabilities.

There's just very little overlap in sensible use cases, they barely even count as competitors.

It's not a direct comparison, but there are definitely many games that could be feasibly built in any one of Godot, Unity, or Unreal. There's a lot more to consider beyond just the engine features, such as the asset pipeline, the tooling ecosystem, and the availability of third-party assets and scripts.

Godot allows for very quick development compared to Unreal. The learning curve is shallower and the developer experience is much better.

Unreal, of course, has more features and is more powerful.

Choosing Godot means you are more likely to actually finish making the game. Choosing Unreal means you can potentially make a better game. For me, that's a tough choice, and I often have trouble deciding between one and the other (for 3d games)

> It's totally bizarre to compare Unreal Engine with Godot. One is a AAA 3D game engine with awful support for 2D games, the other is a superb 2D game engine with modest 3D capabilities.

There is a vocal amount of people (can't say whether they're a minority or not) that tout/desire the major open source engines to be a valid replacement to the commercial ones. This is also happening in Rust, where Bevy is extremely hyped.

So, while it's absolutely true that comparisons don't make much sense, practically, there is a lot of talk about such comparison, so it does make much sense to make this very clear, at least in order to inform developers.

Hey, I'm curious to know what are some of those "weird opinions at a maintainer level". I would love to know more about your experience using it at such scale.

> Physics interpolation in 3D

This is huge. Initially, Godot didn't support any interpolation, which meant you either ignore fps altogether (and your game literally plays slower, and therefore differently, if the game slows down from 60 to 30 fps), or you move physics code to the _physics_process() and suffer from stutter/jitter because the physics code and the rendering code slowly drift out of sync. Amazing!

EDIT: I forgot to mention the _third_ possiblity, which is that you write a bunch of custom code in GDScript or C++ which attempts to do the interpolation.

Why couldn't you just run physics at the graphics frame rate (or double it if the graphics becomes too slow)? I don't think many games need fully deterministic physics do they?

    x += v * dt
    draw(x)

Or is that what this does?

Collision detection is a major reason. If you only sample positions at the frame rate, you're going to have bullets go through walls without hitting anything.

Also, physics is costly to run, so usually it's not run on every frame.

And you really want your collision detection to be reasonably deterministic. Reasonable frame rates range from 30fps to 240fps, which is nearly an order of magnitude, and you want your bullets to behave the same over that range.

You only need physics to run at a "fast enough" rate. Let me rephrase:

Why not just snap physics frames to graphics frames?

Frame rate is variable.

Not entirely true. For a long time Godot has had Engine.get_physics_interpolation_fraction, which permits smooth interpolation of visual bodies ticking at render rate while their physics bodies tick at the physics rate (2D or 3D). I can run my physics at 2 fps (or any increment) and an object will smoothly move from A to B, because rendering is happening in _process and target positions are being calculated in _physics_process.

Placing a camera under the control of a physics node is just the way most people do it because they don't know any better. Decoupling an object's physics representation from visual representation is something many devs never learn, and they pay the price with frustrating visual stuttering under any engine -- as I did for many, many months back in the day under Unity until figuring it all out.

I'm looking forward to playing with the new baked-in physics interpolation (albeit only for 3D so far) with 3.5, but this has been easy to implement in 3.x for anyone familiar with "get_physics_interpolation_fraction".

Not my field of work, but I'm curious.

From what I'm hearing Unreal is establishing a big lead over the competition with things like Lumen, face model generation (Metahuman?), asset libraries, ML assisted images/video to model converters, very polished editor tooling ,world builders, ...

All things that take a lot of money to make.

Is there any chance to compete in the near or medium term for things like Unity or Godot? Outside of small indie studios or hobbyists that is.

> All things that take a lot of money to make.

Untrue, as shown by numerous FOSS projects run by volunteers.

I’d say Godot is the best FOSS can offer and it is clearly behind Unreal. This, True.

Blender (and Linux) is possibly the best thing FOSS can offer.

Unreal is ahead for a couple of reasons (mainly historical + money) and they target industries outside of games as well now - namely film productions.

With that said most big AAA companies still use their proprietary game engines and I don't see that changing. General purpose engines like Unreal/Unity/Godot have their place of course, but to use the full set of features of Unreal you need a big team anyways, so comparing it to Unity and Godot doesn't seem right to me at least. Godot is slowly eating Unity's lunch though. Especially given the direction that Unity has taken after their IPO they might be in trouble in the near future.

Also there are some crazy people (like me) that just write their own engines for the projects they are doing and here's hoping that in time our number will actually grow. It would be very sad if the game engine world ends up like the OS or browser world for example.

I am not sure about the "I don't see that changing". CD projekt red has adopted unreal engine leaving behind the engine they built AAA games such as The Witcher 3. I can see a future where more gaming houses adopt the engine as well.

There are good arguments from both sides of the fence in the “generic solution” VS “custom solution” debate. I think the decision should be made on a case by case basis after sufficient analysis has been conducted. For example, I wouldn’t do an RTS/Total War type game in either of the 3 aforementioned engines. Also it should be noted that sign of the times is that we’ll be getting less AAA games, not more. It’s clear that those huge budget games carry substantial risk if not successful (hence early incremental updates, DLC, mico-transactions etc.) and studios are weary of that.

For CD Project the move to Unreal might make sense just from labour market perspective - it’s easier to hire programmers for Unreal than to train programmers to learn and develop your own in-house engine. Larger community and support already exists for Unreal etc. That move will affect their bottom line on their next games though. 5% is nothing to scoff at for a big product from a big company.

In any case, I’d advise caution to companies relying entirely on a single platform for their business. To echo my previous statement choosing only between Android and iOS for mobile is an illusion of choice. If you’re a mobile game dev your entire business relies on two relatively hostile companies.

Crazy people writing their own engines—growing in absolute numbers, shrinking in relative numbers.

Not my field of work either but my understanding is that Unity, as a public company, should have no trouble competing with Unreal where cost is the limiting factor. They’ve got plenty of resources. Godot on the other hand has a totally different audience. So while they have far fewer resources/staff to throw at their product, they don’t need to try to achieve feature parity with Unity and Unreal. Part of why hobbyists and small studios enjoy working in Godot is its simplicity.

Unity is still extremely popular. The Unreal vs Unity engine debate has raged with plenty of people on both sides for years now all over game dev forums.

I don't have any exact stats offhand, but I believe there are plenty of big games recently published that were developed on Unity. The only examples I remember rn are Fortnite (Unreal, but sort of doesn't count because it's made by Epic Games, the makers of the engine...) and Fall Guys (Unity).

Unreal may have an edge on certain areas, and might have a slight edge with AAA level game producers that haven't built their own engine... but Unity has a possible edge in ease of use, a very popular asset store ecosystem, etc that make it arguably better for certain projects. See above examples, Fortnite and Fall Guys both chose their engines appropriate to their teams and project sizes.

Godot is for sure more indie, but has a pretty good trend upwards. Unity had some bad press recently after the merge / acquisition that may push a percentage of their market share towards Godot.

As someone who's been following that debate since the Unity 2.x days, I'd say Unreal might start to pick up steam once "Verse" drops

That's their purported scripting language for Unreal. By far the most "serious hobbyist" unfriendly aspect of Unreal has always been the heavy macro based C++. They tend to be people who don't like the idea of visual programming, so hate Blueprints (no hat in this race, I think they're ok), and have come from the cushy tooling you get with C# like Rider

Verse has a good chance to give Unreal a fresh start with some tight focused tooling and good ergonomics.

It's also a little ironic to say that since that's the opposite story of Unity, which dropped Boo and "Unityscript" to great effect... but that's how daunting C++ is for some people

IIRC the early versions of the Unreal engine used another custom scripting language, UnrealScript. It's interesting how engine developers go back and forth on the costs/benefits of embedded scripting languages. I think something similar happened with the Quake engine too (Quake 1 had QuakeC, whereas Quake 2 onwards was C/C++ all the way down).

Unreal has titles like Borderlands, Street fighter, Kingdom Hearts, and XCOM

List https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games

I would assume Unity has something in the works internally, but it looks like someone is creating a Nanite/Lumen equivalent for Unity here:

https://www.indiegogo.com/projects/the-unity-improver-nano-t...

As for Metahumans, Unity has started on an equivalent of that too:

https://assetstore.unity.com/packages/essentials/tutorial-pr...

Character Creator is also looking like they're stepping up their game to match Metahumans:

https://www.reallusion.com/character-creator/default.html

That said, I'd love to see these things come to Godot specifically, including performance on the level of Unity ECS/DOTS.

This is kind of like looking at a race car and wondering how anything else can compete. First off, Unity and Godot have different license models from Unreal. There's room just based on that. Moreover, a lot of the fancy new stuff doesn't run well or at all on mobile, a huge segment of the market. I'm not saying Unity or Godot have it easy but there's still a lot of room in the market.

>This is kind of like looking at a race car and wondering how anything else can compete

Sorry I have nothing else to add to your comment, but I just wanted to say I love your analogy. I am stealing this one.

The race car analogy can be extended in that UE4 doesn't even give you a competitive F1 car but it's marketed as such. AAA companies outside of Epic using UE4 have spent a kings ransom on customizations to tailor it for console. Much like top F1 teams just getting an engine doesn't put you out front without a bunch more work. Nevertheless, this is only a problem if you think you can take UE4 and a small team and make a AAA game that's pushing lots of polys on older consoles at high fps without extra work.

I'm a little surprised you're being downvoted. There might be a bit of hyperbole in your words, but no game engine is entirely off-the-shelf per-game. Or, idiomatic code suited to an engine always requires a bit of elbow grease to be ready for shipping.

I'm being downvoted, likely, by people with little experience in this particular area I guess... There is a real actual gulf between a fully tuned AAA game engine and what you can buy.

I've been hearing so much about Godot recently that I'm going to try it out. I'm not even a game developer.

Good marketting I guess!

Godot is becoming the game engine of the internet. It checks all the boxes.

- Open Source

- Cross Platform

- Frequent updates

- Easy to learn in a weekend

- You can use almost any programming language with it

- Godot 4.x has beautiful graphics

- Godette

> beautiful graphics

Doesn't that depend entirely upon the artwork used in the game?

A lot of it depends on shaders and lighting.

This is only sort of true. If you load any 3D model into Unreal Engine for example, the lighting and shaders will make it look pretty good without much modification. Godot is getting a big upgrade to its lighting and shader engine in 4.x

If you have a nice engine that helps with beautiful lighting / shadows, dynamic range, good animation rigging, or other useful tools related to graphics and visuals, it will be easier for you to make a "beautiful" game with less work than if you have to try and bring some of those things yourself.

It is true that people make stunning games even with janky engines by using great art and design. But the easier it is to implement your vision for graphics, the more likely you'll reach that level.

I think three.js is that.

- All of the above except language

- Library rather than engine

I've had really good luck with it versus Babylon or Unity.

> I think three.js is that.

three.js doesn't produce native multi platform apps for desktop and mobile.

The mobile builds are its killer app, in my view as a gamedev. Unity has lost the plot in many ways. Desktop builds are important too, but there's competition there if you consider browser/electron as a desktop platform, plus Unreal. But Godot is the exclusive up-and-coming competition in mobile builds (that I am aware of; granted I am not a mobile dev).

Three.js is a 3d graphics library, not a game engine. You can use it to render your game but it doesn't bring the same things as Unity or Babylon.

I have often worked directly with an html canvas and some javascript to make 2d web games. It works well for me and I enjoy it, but I wouldn't call it a "game engine" either.

Let's be fair to three.js, the comparison would be to aframe.

https://aframe.io/ or similar projects.

(Godot Engine Maintainer)

Thank you so much for your work on Godot.

You are right, though I think all three can be compared, depending on the type of project. Unity is on the decline and I would be happy for Godot to become the future for those types of games.

Now that Godot seems to be getting much hotter, I feel like I am having to update my game engine more and more frequently. It's great to see then update the navigation system, but will it break my game? I worry it could be heading to the same problem I see with Unity where things are constantly getting updated and re engineered. I have seen professional teams working in Unity be many version behind because they dread the work of updating.

Plus, I don't know how many more integrations I want to do on 3.x before 4.0. I am hoping that the move to Vulkan will give me better 3d performance on mobile

Unless Godot has solved the problem of forward compatibility of binary asset bundles with compiled assets, then what's true of Unity is true of Godot: the cost of your engine upgrade is proportional to your reliance on existing assets.

It may just be a recompile. It's may be that the upgrade requires more, a whole art pass before recompile. Maybe there's mods you don't have the source for, that you can't upgrade at all.

Hopefully the incentive schemes help with this: part of the reason for Unity’s feature churn is that they’re more incentivized to create new features (to acquire new customers) than maintain old ones. You’d think this approach would backfire, but with the amount of lock-in engines have they can afford to piss off current customers at least up to a point.

Godot, not being beholden to shareholders and quarterly growth targets, can hopefully make more clear-headed decisions around product roadmap.

Unity needs existing customers to continue their pro subscriptions; and game developers are notorious for throwing everything out and staying afresh on every project. The new features are as much for existing customers as they are for attracting new ones.

That said, Unity ads is where the real money is at.

With Unity the general wisdom seems to be to lock in one version for each project, and only update when you start a new project.

Which I guess isn't the worst? Sure, better forwards and backwards compatibility would be better, but this way you get more features quicker and more coherently, at the downside of not getting any improvements during development

>Internal Server Error

Huh... looks like it did stop

Came to testify the same, lol)))

same here, the hug of death from HN I guess

Here's a Wayback Machine link of the article, just in case: https://web.archive.org/web/20220805154013/https://godotengi...

Stoked! I think I'll continue on my Godot VR Project now that Label3D and Textmesh are implemented - Text within the scene is vital for VR Debugging.

I've looked at 3.4, 3.5 and 4.0a ... and while 4's scripting engine is definitely faster than the others before, it's still way too slow to consider using it.

I can concur - the stated position is that GDScript should only be used for non-performance-critical tasks, but even with a hundred objects running a simple script every frame, performance absolutely tanks in 3.x. The performance wall is so easy to hit that GDNative is almost a requirement to get good performance in non-trivial projects.

Is it Go Dot or Go Dough? Asking for a friend :)

the latter

https://en.wikipedia.org/wiki/Waiting_for_Godot

Actually neither, it’s “Guh-doe”.

Actually not, it's

/ˈɡɒdoʊ/ GOD-oh

pronunciation is where phonetic alphabet shines[1] and English totally sucks [2].

[1] https://en.wikipedia.org/wiki/International_Phonetic_Alphabe...

[2] https://jakubmarian.com/english-words-spelled-the-same-but-p...

Either, but the developers aparently say "go dot"

Their logo is a robot. "Go dot" rhymes with "robot". I always assumed that it was a purposeful misdirection using the popularity of "Waiting for Godot" to lead people to mispronounce it as "guh-doh". I know I'm wrong, but I like that story better than the real one.

/ˈɡɒdoʊ/ (read like GOD-oh)

see https://news.ycombinator.com/item?id=32358256

I always thought it was a play on the play, "Waiting for Godot"

https://en.wikipedia.org/wiki/Waiting_for_Godot

TLDR: The problem with Godot is that it tries to be everything to everyone.

They made an engine, an editor (a text editor, resource editor, debugger ...), invented a new language. They "support" export to almost all popular OS platforms. But in my opinion it's lacking in quality. The engine is slow (old style based on OOP), the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.

But it's certainly good for rapid prototyping and learning.

> The engine is slow

doesn't really seem that slow for me (but of course, i haven't used it in anger yet).

> the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.

the editor is enough for small scripts, but you can also choose to use your own native editor, or switch to the C# version (and use visual studio or jetbrain rider).

I don't find the scripting language any worse or better than any modern script languages. What are the missing features?

>I don't find the scripting language any worse or better than any modern script languages. What are the missing features?

lambdas, closures, support for error handling, constructor overloading, list comprehension, packing/unpacking (arguments/lists), varargs

I guess most of these are syntax sugar or quality of life stuff.

Gdscript is a lightweight language, it wants to be fast. They explain the goal of the language in their doc and why they didn't use something else.

I'm seriously considering trying it out. Is support on C++ development very good? Because I don't want to learn the scripting language.

Fwiw the scripting language is pretty nice to deal with and quick to pick up. Great for getting things moving quickly

Anything beyond surface level is difficult to extract from the documentation and that hurts a lot. From the new user experience, the Godot IDE still feels buggy. Features (like the inspector) populate with values from code sometimes and sometimes not, because of complicated rules or you get the fun blank file script names or dupes when resources are changed/moved/deleted.

In 3.4 I could not get in-app purchases working for iOS apps. Is it fixed now?

How is the support nowadays to export your game to mobile, anyone knows?

Anyone else getting server errors?

Godot is a fantastic project.

But, I really wish it was written in something other than C++. I really can't bring myself to go back to programming C++ again after a decade away using more recent languages like Go and Rust. I even find deciphering the types of variables to be painful when reading C++ code these days.

IMO the issue is not that Godot uses C++, it's that they refuse to use a standard more recent than C++03.

Being able to use `auto` would make the code already a lot less verbose IMO.

Godot uses c++ 17 in master.

Autos and lambdas are not allowed from a style guide decision.

I can't tell if this is a GPT-3 comment or not.

Well, that comment is definitely GPT-3.

Please don't cast GPT-3 aspersions on people or posts, they add nothing to the discussion and are rarely if ever correct. This one certainly is not.

The commenter is lamenting that they don't feel comfortable contributing to an open source project that they use because of the language choice of the project. It's far easier to simply write the couple of sentences involved than to coax GPT-3 to do it. Your apparent inability to understand the commenter's point doesn't make the commenter an algorithm. The correct response, if you are puzzled by a comment, is to ask a respectful question about the comment.

"Assume the best interpretation of a comment" is a core assumption that HN readers are asked to make when reading and commenting on threads, and it's a remarkably good place to start here.

Why are you worried about the language it's written in? You have a few options when it comes to which languages to use when working in it.

I mean to contribute.

You might want to check out the code. I was unsure at first, but have found the code to be well structured, commented, and formatted such that it is relatively easy to see what is going on and make significant changes.

You don't need to program in C++ to use Godot. It has its own scripting language (gdscript) and you can use C# as well.

If you're looking to an up and coming game engine project, there's "Bevy", which is an ECS game engine (like Unreal) that's also open sourced, which is Rust based:

https://bevyengine.org/learn/book/introduction/

They aren't at first release yet. I think they're at 0.8, and I'm unsure as to their contribution structure, but read their documentation. It's in there I hope.

I've contributed to bevy, you can just make a PR for something small, or an RFC for something big.

While I'm here, I might as well give my $0.02 about bevy. It's got an amazingly sturdy foundation, but it lacks essential game engine features like asset preprocessing and render postprocessing stacks. Those are both slated to land in time for 0.9, which should put it ahead of most OSS engines.

Currently, there's also some very annoying stuff related to managing when and in what order systems run. There's a mostly-done big refactor called "stageless" which totally fixes this, but it touches a lot of code and needs to be merged. I'll quite be happy if that makes it into 0.9 too.

There are lots of other features missing, like everything UI, but these are the near-term changes and should put it in a good place for future growth.

Reply on news.ycombinator.com