Godot 3.0 game engine released
godotengine.org
godotengine.org
You can also use C++, C# and a visual scripting language to make stuff. There's also community support for python and some other languages.
It's hard to believe that it's a 20mb when Unity is 1.5gb.
There appears to be semi-official support for D[1] and Rust[2]. I also found some bindings for Nim[3]. However, since c# is supported, you can probably (?) also just use any language that runs on .net[4].
1: https://github.com/GodotNativeTools/godot-d
2: https://github.com/GodotNativeTools/godot-rust
But the real dealbreaker was not being able to use the pydata stack, as much of the power of python is its rich library support. If I can't use SciPy to do the heavy graph algorithms and voronoi calculations and statistical models, what's the point?
That said, the introduction of GDNative and touilleMan's godot-python extension is a game-changer (pun intended), and I'm looking forward to diving in now.
Some could claim that that is not really what 3D engines are for.
Large systems are better built from distinct parts. A large statistical calculation would not be a graphics computational job (unless you load it to the GPU).
And then there's stuff like PyTorch or scikit-learn for building higher-power AI, or even just basic clustering and classification.
Being able to use the full depth of libraries in the python ecosystem is the reason I've been looking for a game engine that supports python. The ones where the entire engine is written in python just don't cut it and lack documentation/features, and now that Godot finally has python support, it's a winner.
Games don't need advanced statistical models to be entertaining. Rather, simple-and-tweakable-for-entertainment is generally the norm.
This is what I mean:
https://www.polygon.com/2017/9/2/16247112/video-game-develop...
https://www.rockpapershotgun.com/2017/04/03/why-fears-ai-is-...
I'm not saying you couldn't use advanced scientific and engineering tools to do games but that generally people don't.
I agree that 3D first person shooters aren't a good fit for complex simulations. Complex simulation games, however, are. The AI for those tends to be really bad, and this makes them nothing more than rote optimization tasks, and not that fun. There is a lot of room for these tools in the strategy market for these tools, and "the norm" is predicated on those things not being available.
Recent advances in machine learning such as style transfer have huge applicability to procedural content generation in games, but you better have access to python. With 99% of the games on steam being some lame platformer or survival clone, I do think these tools are needed so that progress can be made, so that better games could become the norm.
Is the iOS support good?
If you're a Linux person using Unity, double-check if your version of Unity has fixed the VSync bug.
99% of all Unity games max out one core for me all the time, even if they are static sprite games like Desktop Dungeons, due to that really dumb bug of theirs. Unity games are basically a no-go on my laptop, draining the battery like crazy and heating it up tremendously.
Well it's officially supported so I'd imagine so.
Can anyone comment on how seamless the transition from Python to GDScript will be? And how performant is GDScript?
It's a shame Unity dropped Boo but I think it was due to lack of interest as much as lack of support. There is no much code in a game (or "game-like thing" - I'm more interested in VR experiences etc) that doesn't need to be performant that two levels of code access is desirable. A fast language and a nice language...
I'm warming to C# but that's probably more down to Stockholm Syndrome than any innate pleasure in using the language. When I switch back to Python I feel all warm and fuzzy again.
There isn't the same depth of library support as Python for obvious reasons, which makes the experience different even though the syntax is pretty close, but it's not worse at the task of doing things with the engine, in fact it's better at that because it's more deeply integrated(which is the point of having a custom language). It's aware of engine core stuff like e.g. geometry vectors and the scenegraph, and the built-in IDE supports working with GDScript directly with no configuration step needed - edit/test/debug all done exactly like it should be.
Performance-wise, it's fine for what it's intended for - running gameplay logic for a game of small-to-midsize scope(think ~$5mm budget) that isn't trying to drive tens of thousands of entities or run parts of the rendering from script. Smaller games can get away with optimizing hotspots, and a bigger game can start to justify having someone forking the engine and poking around in the internals to optimize whatever part of the architecture starts falling over.
For the use-cases of running a specific task that's more intensive or bolting on some additional dependencies, the new GDNative support is compelling. Godot's stated aim is for convenience over optimization but the optimization is definitely present in critical elements.
http://docs.godotengine.org/en/3.0/getting_started/scripting...
To see a glimpse about performance with GDScript: https://github.com/cart/godot3-bunnymark
Why is unity 1.5gb anyways?
Can target OpenGL, OpenGL ES, Metal, Vulkan, DirectX 11, DirectX 12, LibGMN, NVN.
Has graphical debuggers for shader development, a 2D GUI engine, a 3 engine with VR and AR support, asset pipelines for integration with studios workflow, and lots of features that Godot might one day have, but aren't on 3.0.
Kudos to Godot developers for what they achieved, I am also impressed with their work, but Unity devs aren't putting bloat just for fun.
In fact, any engine with similar laundry list of features has a similar size.
The download is large because it has example scenes included.
« Console ports of Godot are offered via third party companies (which have ported Godot on their own) and offer porting and publishing services of your games to consoles. »
It would be an endless effort to modularize everything down to that level, and probably not many devs would take advantage of it, thus being a waste of money.
So the installation options are just tailored down to getting everything for a specific target system.
I used GDScript and didn't have any issues with using it, I'm sure everyone wants to reuse the millions of Python libraries available but they're not built for Godot. However, using GDNative I'm pretty sure one could put Python support into Godot, as a Godot native plugin that then runs your Python code. It wouldn't be as efficient as just using GDScript though.
It also locks your code into their ecosystem, albeit to a much lesser degree than, say, GameMaker and GML because Godot is open source, and allows support for other languages.
Unless anyone is going to use GDScript anywhere else as a general purpose language, it's as useless to learn in the long term as GML or Boo for Unity.
That said, Godot looks nice and I look forward to trying it out. But I do believe that, in general, game frameworks should stop rolling their own custom scripting languages.
>[...]
>I'm sure everyone wants to reuse the millions of Python libraries available but they're not built for Godot.
Yeah, it is one of those tradeoffs you have to weigh up, I guess. After thinking about it some more, I think that keeping Python as an optional, community project is far saner for the core devs. They can focus time on the important part (the engine, UI, etc) and not on trying to get a 3rd-party language to work correctly.