Godot is not the new Unity – The anatomy of a Godot API call

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • godot-proposals

    Godot Improvement Proposals (GIPs)

  • Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... .

    One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying:

    > As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ).

    It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then.

    Further down though somebody points out:

    > Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects.

    This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places:

    > C# is faster, but requires some expensive marshalling when talking to Godot.

    I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..".

  • godot-jolt

    Godot Jolt is a Godot extension that integrates the Jolt physics engine

  • When the performance of Godot's physics engine has been mentioned before I've seen https://github.com/godot-jolt/godot-jolt pointed to as a drop in more performant solution.

    Haven't tried it in a project yet myself

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • wgpu

    Cross-platform, safe, pure-rust graphics api.

  • I double checked, and our rendering library _does_ partially supports DX11, as well as Angle, which lets you run the GLES3 backend on top of Angle on top of GLES2/DX11. They tend to be fairly buggy and incomplete, though. Arguably only usable for simple 2D games.

    There's been no real demand or contributors to improve it, but it's open source so there's no reason you or anyone else could stamp out the bugs https://github.com/gfx-rs/wgpu#supported-platforms.

  • bevy

    A refreshingly simple data-driven game engine built in Rust

  • If you are using Rust, you should check out https://bevyengine.org which is a rust based game engine with a focus on ECS

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts