Godot 4.0 beta 16: Initial .NET 7 support(godotengine.org)
godotengine.org
Godot 4.0 beta 16: Initial .NET 7 support
https://godotengine.org/article/dev-snapshot-godot-4-0-beta-16/
34 comments
What are your thoughts on GDScript?
The reason I ask is I do a lot of work with Python these days and I like it most of the time. So I've been curious about a high level dynamic typed language for game dev. I have played around with Unity in the past and picked Unreal for my current project this time but kinda regretting that. I'm not doing anything technically impressive so I thought blueprints would help speed things up but I'm less than impressed.
GDScript is awesome to use from a developer experience perspective. The documentation for everything being built into the editor (F1!) is pretty awesome. The api that is provided to GDScript for everything from strings to file operations to url requests is pretty great.
That being said, GDScript has some flaws: it's performance is bad, the typing system needs work, it doesnt allow cyclical references of classes and the coroutine API is not greatly designed.
But for prototyping game code it's pretty hard to beat for developer speed.
For UI code it's top tier.
I think you'll like Godot. I generally find it faster to develop things in than either Unity or Unreal.
I've got a pretty huge toolbox of custom modular scripts for adding functionality to UIs, and a pretty solid theming and layout system.
That being said, GDScript has some flaws: it's performance is bad, the typing system needs work, it doesnt allow cyclical references of classes and the coroutine API is not greatly designed.
But for prototyping game code it's pretty hard to beat for developer speed.
For UI code it's top tier.
I think you'll like Godot. I generally find it faster to develop things in than either Unity or Unreal.
I've got a pretty huge toolbox of custom modular scripts for adding functionality to UIs, and a pretty solid theming and layout system.
Fortunately, those concerns are all, if not fixed, then much improved in Godot 4. Just a couple weeks ago, they increased GDScript 2.0 perf by a lot, the type system is much more present (typed arrays, real enums, exported custom resources), cyclical references got merged in a month or two ago, and they've done some work on coroutines with the new await syntax.
I'm looking forward to 4.0 coming out (well, 4.1) when they go back to smaller incremental updates and a higher focus on stability, so I can start using it for more projects. If the web builds weren't so broken I would have used it for ludem dare this month, but I went back to 3.5 and sorely missed the new features.
I'm looking forward to 4.0 coming out (well, 4.1) when they go back to smaller incremental updates and a higher focus on stability, so I can start using it for more projects. If the web builds weren't so broken I would have used it for ludem dare this month, but I went back to 3.5 and sorely missed the new features.
They recently posted a forward looking article about what key features 4 is still missing: https://godotengine.org/article/whats-missing-in-godot-for-a...
Maybe some of that comes in 4.x work, maybe some has to wait until 5. Most of it sounds like feature additions instead of things that require rewrites of existing 4.0 code.
Maybe some of that comes in 4.x work, maybe some has to wait until 5. Most of it sounds like feature additions instead of things that require rewrites of existing 4.0 code.
If I was triple A I'd still consider Godot.
It wouldnt be hard for a AAA shop to use Godot for the editor and use GDScript to build UIs, VFX (visual effects) and DSL (domain specific language) type stuff.
Writing all your simulation and netcode logic in c++ makes 'godot' pretty unlimited.
AAA would want to completely replace Godot's renderer, but that is 100% feasible for a big studio with talented graphics engineers.
It wouldnt be hard for a AAA shop to use Godot for the editor and use GDScript to build UIs, VFX (visual effects) and DSL (domain specific language) type stuff.
Writing all your simulation and netcode logic in c++ makes 'godot' pretty unlimited.
AAA would want to completely replace Godot's renderer, but that is 100% feasible for a big studio with talented graphics engineers.
What do you think of using Godot for non game apps? Like learning apps for kids,simulations, or data visualization for business with a lot of interaction?
Godot is a pretty good cross platform C++ framework for lots of things. I think it's probably competitive with the heavy hitters (QT, GTK, React Native) for certain application designs. The visual editor for laying out UIs is a pretty killer feature. GDScript is honestly a pretty killer feature (hot reload, super easy to write, the documentation is built into the editor, available offline).
not OP
I used it to build a multiplatform (including mobile) radio app similar to nightwave plaza (https://plaza.one/) and it worked remarkably well
also Pixelorama was built using Godot
https://github.com/Orama-Interactive/Pixelorama
I used it to build a multiplatform (including mobile) radio app similar to nightwave plaza (https://plaza.one/) and it worked remarkably well
also Pixelorama was built using Godot
https://github.com/Orama-Interactive/Pixelorama
Hey so I was trying to make a Stick Fight clone with my son. I got a good start but what I was really interested was the skeletal system for physics so I could try to really emulate it.
Do you have any thoughts on the skeletal system and has it improved in Godot 4? I sort of got it to eventually work, but it was really tedious. Have you ever used it and do you know if it has improved in 4.0 that makes it more viable to use?
Do you have any thoughts on the skeletal system and has it improved in Godot 4? I sort of got it to eventually work, but it was really tedious. Have you ever used it and do you know if it has improved in 4.0 that makes it more viable to use?
Haven't used it. The system itself might be decent but the editor for it is probably bad. Lots of things in Godot like that.
We bought a license to Spine from http://esotericsoftware.com/
It has a godot runtime SDK.
We bought a license to Spine from http://esotericsoftware.com/
It has a godot runtime SDK.
I have a lot of experience messing around with these. It looks unchanged from godot 3.5 to 4.0 for the skeleton things. I actually wound up writing my own, which just copies rigid bodies matrix to each bone manually using gdscript.
As someone who has no idea about gamedev, I'm wondering about why gamedev in NET is not only possible, but encouraged, while being "nearly impossible" and discouraged on JVM. I mean, both have garbage collection, both are JITed, both have nearly the same feature set.
Why is it that C# is that popular for gamedev, and only a few titles use JVM?
Why is it that C# is that popular for gamedev, and only a few titles use JVM?
While the sibling comment regarding better control over memory layout is right, here we mostly talk about scripting a game engine where the performance critical part is largely inside the engine. So the reason is more likely simply “history”.
But actually, C# was always meant as a “managed c++” in a way, while Java rather optimizes on the runtime level (which is helped by less control by the developer). Nonetheless, Java is more than fine for game development, besides the obvious Minecraft there are plenty small to big indie games written in Java.
But actually, C# was always meant as a “managed c++” in a way, while Java rather optimizes on the runtime level (which is helped by less control by the developer). Nonetheless, Java is more than fine for game development, besides the obvious Minecraft there are plenty small to big indie games written in Java.
> Why is it that C# is that popular for gamedev
Unity.
edit: also C# allows precise measurement of memory usage and padding, while in Java one can only guess
Unity.
edit: also C# allows precise measurement of memory usage and padding, while in Java one can only guess
XNA?
> I mean, both have garbage collection, both are JITed, both have nearly the same feature set.
There's one big difference in the feature set: unless things have changed very recently, the JVM lacks value objects.
There's one big difference in the feature set: unless things have changed very recently, the JVM lacks value objects.
Value objects (and more) are a part of Project Valhalla: https://openjdk.org/projects/valhalla/, and Kotlin allows using them today, although with some hacky annotations.
That is very true, but C# has had value types since its inception, so a lot of tooling exists to deal with them, both in the language and in third party code (libraries and engines)
C# has evolved in recent years to let you do fun stuff that sidesteps GC and JIT a lot of the time. There's proper AOT compilation now, mostly, and you can cut down on ref allocations massively if you know what you're doing.
JVM also has off heap memory allocation to skip GC, and also has native AOT through GraalVM
Game dev here. The reason is simple - performance. Unlike Java, C# has zero-overhead structs (custom primitive types if you will), so say a Vector3f is just 3 floats in memory, 12 bytes, no object overhead, no pointer indirection. This is a BIG deal. Array of vectors can be just raw data in C#, not an array of pointers like in Java. You can fairly easily map C# structs to C/C++ structs that GPU drivers need. C# even allows fixing struct fields to certain offsets to ensure identical memory layout with other languages.
Other features are also critical to performance such as true generics. Say List<Vector3f> in C# is specialized for that type, no overhead from objects, no extra pointers, no casting.
In C#, if you are very careful, you can get close to the performance of C++. I don't think the same can be said about Java, because the language does not give you the tools to achieve that.
Other features are also critical to performance such as true generics. Say List<Vector3f> in C# is specialized for that type, no overhead from objects, no extra pointers, no casting.
In C#, if you are very careful, you can get close to the performance of C++. I don't think the same can be said about Java, because the language does not give you the tools to achieve that.
Yeah, Java's reply to performance was "let's make the GC better", C#'s was "let's make the GC optional". I don't think it was a strictly conscious decision (generics were reified long before XNA was even an idea), but for low-level game development it is imperative to have predictable memory usage and control.
.NET has the first class support of value types and generics. JVM is behind .NET in those aspects to varying degrees.
Not as important, but still: C#, as a language, became pretty sophisticated during the recent years. It picked up quite a few functional idioms from OCaml, F#, Haskell and other functional languages, so you have pretty decent horsepower under your fingers. For instance, it can validate for possible null reference access during compile time now, thus nearly eliminating NRE (NullRefenceException) bugs in run time.
Not as important, but still: C#, as a language, became pretty sophisticated during the recent years. It picked up quite a few functional idioms from OCaml, F#, Haskell and other functional languages, so you have pretty decent horsepower under your fingers. For instance, it can validate for possible null reference access during compile time now, thus nearly eliminating NRE (NullRefenceException) bugs in run time.
True, C# is a nice language, but so is Kotlin. Java support for value types is being developed and has a dedicated JEP 401 [1]. Kotlin allows to use value types today, it also has nullable types. I'm not convinced if functional features are really a factor that decides what is popular or not; it can be attractive for hardcore programmers, but most of programmers are not that.
[1]: https://openjdk.java.net/jeps/401
[1]: https://openjdk.java.net/jeps/401
[deleted]
It has more to do with how game engines are built, making embeddability be the most important criteria.
Most game engines are written as a large chunk of C++ code that runs each frame's timing, and the big subsystems like physics, particles, sound, and the scenegraph. All the important engineers will be dedicated to working on this engine and it behaves like a framework. The "game logic" is generally considered to be a minority of the code, and because less-technical people generally author it, it gets written in a higher-level "scripting" language.
This creates some serious constraints on that language. It must be possible to call into the scripts from the main engine and the overhead must be low. The scripts often have to make calls into the data structures of the main engine (e.g. for physics queries) and the overhead of that should be low as well. It should also be possible to control the scripting language's GC because the main engine is pretty timing-sensitive. Memory consumption is pretty important as well.
All these requirements point towards two implementations specifically: Lua (and LuaJIT), and Mono. Those two runtimes go out of their way to make it easy and fast to embed. A third option which a lot of engines pick is to write their own scripting language where they control everything about it. Any other language you can think of (with the possible exceptions of Haxe) will have some major hurdle that prevents easy embedding. The fact that you can compile multiple languages to Mono bytecode pushes some folks in that direction; if you're planning to write a lot of code in the scripting engine (not all of them do! See: Unreal) that's nice flexibility to have.
Most game engines are written as a large chunk of C++ code that runs each frame's timing, and the big subsystems like physics, particles, sound, and the scenegraph. All the important engineers will be dedicated to working on this engine and it behaves like a framework. The "game logic" is generally considered to be a minority of the code, and because less-technical people generally author it, it gets written in a higher-level "scripting" language.
This creates some serious constraints on that language. It must be possible to call into the scripts from the main engine and the overhead must be low. The scripts often have to make calls into the data structures of the main engine (e.g. for physics queries) and the overhead of that should be low as well. It should also be possible to control the scripting language's GC because the main engine is pretty timing-sensitive. Memory consumption is pretty important as well.
All these requirements point towards two implementations specifically: Lua (and LuaJIT), and Mono. Those two runtimes go out of their way to make it easy and fast to embed. A third option which a lot of engines pick is to write their own scripting language where they control everything about it. Any other language you can think of (with the possible exceptions of Haxe) will have some major hurdle that prevents easy embedding. The fact that you can compile multiple languages to Mono bytecode pushes some folks in that direction; if you're planning to write a lot of code in the scripting engine (not all of them do! See: Unreal) that's nice flexibility to have.
I am very grateful for Godot v3, since it is used to program:
https://github.com/derkork/openscad-graph-editor
What other instances are there of non-game usage?
https://github.com/derkork/openscad-graph-editor
What other instances are there of non-game usage?
Oh damn, that's fascinating.
Tesla uses Godot in their mobile apps to do some rendering: https://twitter.com/MFrunker/status/1430922577309011976
Tesla uses Godot in their mobile apps to do some rendering: https://twitter.com/MFrunker/status/1430922577309011976
There's Pixelorama[1], a web-based pixel art editor. Haven't really used it but it looks pretty impressive.
1: https://orama-interactive.itch.io/pixelorama
1: https://orama-interactive.itch.io/pixelorama
I was playing with earlier betas of 4 but got busy. I need to get back to trying it with 16, hopefully their documents/tutorials have been mostly cleaned up at this point.
I like Godot but the development process really sucks. Godot 4 has been in development for so long that it feels like vaporware. 3.5 is nice and stable, but has shortcomings that are only being addressed in Godot 4.
So, my screen had scrolled so that only half of the title was visible. My brain, being the doom-chasing pessimistic wasteland that it is, filled it in as "NFT Support" and oh no
uhhh, I've been waiting for this. ba-dum-tiss (=
Godot 3 is good. I use it professionally every day for 2 years. AMA.