This is sick! It's eating into my Blender territory, where I may just use Godot for a whole lot more than games. CSG, animation tools, shading tools, etc.
Blender is still great for modeling, animation and rendering. Godot is what I had hoped the Blender Game Engine (BGE) was going to become.
Reading through the OpenGL support mini-saga, I was left wondering if this can target a Metal/Vulcan/etc., since graphics stacks seem to be fragmenting again.
But the new visual editors look great, and MIDI input is intriguing to me. The only downside (in terms of learning curve) for me, personally, is the proprietary scripting, since I have been put off Unity time and again because of C# (I have been writing more of it over the years, but it feels too convoluted at times) and I would rather do Lua or Python or something else both dynamic and straightforward enough...
Vulkan is on the roadmap for 4.0 which should arrive in approximately one year.
As for languages, you could try https://github.com/touilleMan/godot-python
Godot makes it easy to write modules in various different languages such as Rust, D, C++, etc.
FWIW GDScript is modeled after python. It's a good scripting language overall. The only thing clunky to me is the way they do callbacks, which they call signals.
From what I read their next major goal is shipping Vulcan support.
Contrary to urban myths, OpenGL never was a thing on game consoles.
Then OpenGL itself is myriad of optional extensions, driver and GPU quality issues, with around 30 years of history, which means that any GL engine is full of multiple execution paths, hardly any different from supporting multiple APIs.
In any game engine, rendering code is a very tiny portion of the monolith.
They seem to plan more support for optional typing, though, which I would count as a bonus vs Python et al.
For Godot 3.1, optional typing is a parser-only feature. The plan is, afterwards, to include typed instructions in the state machine to greatly optimize performance.
Yes, and typing will help towards AOT compiling and performance, etc., but I would really like to just dive in and write code in a language I already use or that can be shared among engines (there is a lot of Lua code out there in the game dev universe, for instance).
Having to learn another language (no matter how simple) for a specific runtime is the sort of time investment one should ponder carefully (I’ve written code in dozens of languages, and the learning curve until being productive matters a lot when you move across environments, frameworks and runtimes).
Use C# with Godot. I am personally looking forward to F# with Godot. GDScript is close enough to Python for me, I had no problem with if from the start, and it integrates really well with Godot.
That is an additional point I wasn't fully aware of. I've tinkered with Unity and they address every platform with every supported language.
Whereas I can do some desktop animation stuff with Godot without caring much (that's one of the reasons I'm interested in MIDI support), if I were to go beyond the hobby phase I'd definitely target iOS first...
It's on their list, and at the rate that they are moving, it will be there soon. It is based on Mono, so there shouldn't be too much friction there. Unity is good, but for Android and iOS I play with Raylib in C.
Using Godot 3.0 right now, Godot has been great and amazing considering its open source game engine. I'm amazed at what the developers have been able to do. Great job guys!
This is really a very complex question. For what kind of game? For which mobile platforms? What is your past experience? Have you made a game before? What languages have you worked with? etc etc etc.
Godot uses it's own scripting language, or C# as a second class option. Are those languages you want to work with? Would you rather make the game from scratch? Would Unity or Unreal be better? Would a framework like monogame be better? If you are just targeting IOS maybe using Swift or Objective C would be easier and perform better.
It's true that GDScript is inspired by python, but I think it's a big stretch to say it's almost identical to python. You have to squint VERY hard to make such a claim, or not know anything about python. No generators, no context managers, classes are fundamentally different. The clearest similarities are also the most superficial, such as continuing to use whitespace for scope, or the 'pass' keyword for empty blocks. I like that gdscript is duck typed, but that's hardly a distinctive python feature.
Overall, it's more pleasant than using C++ or C#, but it is very different from python. However, what you can do is use godot-python, a native python binding extension made after GDNative was added in 3.0. Doing this gives you the most important feature of python: access to the package ecosystem. It's not like python if I can't use libraries like scipy or tensorflow for advanced math operations.
I don't disagree with you. I meant in the context that someone with a passing familiarity with Python can generally jump right into GDScript and get acquainted very quickly, which reduces the learning curve.
When I last tried it around 3.0, Godot didn't do a lot of the boring platform-related stuff that Unity does and there wasn't enough community momentum to help answer questions. Without an asset store you won't find a ton of "Easy Google Play friend list" plugins or anything like that. IMO that's what makes the other engines more mature, moreso than the renderer.
Blender is still great for modeling, animation and rendering. Godot is what I had hoped the Blender Game Engine (BGE) was going to become.