I don't have much valuable to add here, but I'm glad to see more serious open source success stories. Godot seems like it has a lot to offer developers and it's great that it's open to everyone to play with, as opposed to being some proprietary code behind the fences of some organization. The Patreon model of developing software could have a bright future, perhaps.
This looks like a really cool tool based on their website -- has anyone here had any experience with it? How does the developer experience compare to, say, Unity?
I've used both for hobby projects and Godot is superior in my opinion because of the scripting language, the open sourciness and the small package size.
Because it targets all Sony, Nintendo and Microsoft consoles, OS X, iOS, tvOS, Windows desktop, UWP, Android and GNU/Linux. With binaries for every architecture being part of it.
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.
Sure, but one is not selecting each single feature individually.
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.
GameMaker Studio used to do something like that. You started off with a specific version and then could buy plugins for additional features like compiling for consoles, Linux, etc. I haven't looked at the GMS2 pricing model so I'm not sure if they still follow that though.
« 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. »
I can't say enough good things about this project. In particular I love GDScript. It's a lot like Python and it makes the cost of learning the engine negligible.
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.
It's first-class. They don't exactly encourage scripting in it (which makes sense I think) but you can do what you want really. The engine itself is written in C++, and you can extend/modify it if you want since it's open source and all.
> There's also community support for python and some other languages
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].
Not just Rust and D but through GDNative you can load any native code from any language that compiles natively and run it as a "plugin" hence D and Rust were added in by community members.
I'm a python programmer, and I've tried GDScript, and the extent to which it's like python was disappointing and superficial. It's missing most of the features which make python worth using, such as decorators, generators/coroutines, comprehensions, context managers. Especially the lack of generator-based context managers was a big deal.
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.
"If I can't use SciPy to do the heavy graph algorithms and voronoi calculations and statistical models, what's the point?"
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).
GDScript has nothing to do with graphics. It is for building game logic, and having access to powerful math libraries is important for things like map representation and pathfinding (voronoi and graphs), or running the game simulation without having to naively step through every actor (statistical models).
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.
Generally, studios don't do it because it costs too much to hire those skills. Having advanced libraries available would open up what people can do without needing to hire PhDs, since it is much more demanding to hire someone who can build this stuff from scratch than someone with enough working knowledge to apply it.
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.
I think the best thing for people to do is to program a simple game or two and see that the need for full python support is really not needed. In Godot you are scripting elements.
From what I recall they decided against full Python support in favour of a C "API" that people can bind their favourite languages to. There's already Python, Nim, and D as well as some early support for Rust.
Happens at a perfect time for me. I was wondering about a project I want running on smartphones and web and was pondering restarting a unity project (which meant begrudgingly reboot to windows, the linux IDE is not there yet). Now I'll give godot a try.
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.
Very interested in it for GDScript's alleged Python-ness.
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.
If you want to use pure Python for your project, a binding using GDNative exists, although it seems quite new at the moment...
https://github.com/touilleMan/godot-python
I worked on a small project in Godot and I found the transition from Python to be pretty natural. Here's the GDscript primer if you want to take a glance:
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.
Not mentioned in any of the changelogs: I implemented color blending utility functions like darken and lighten from SASS/LESS for GD Script. So now ie blending your characters color based on damage received is ~1 line of code.
GDScript is pythonesque enough to where that's alright. By having made their own scripting language it allows for it to flow better with their engine, at least that's my opinion.
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.
> By having made their own scripting language it allows for it to flow better with their engine, at least that's my opinion.
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.
>By having made their own scripting language it allows for it to flow better with their engine, at least that's my opinion
>[...]
>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.
41 comments
[ 3.3 ms ] story [ 30.8 ms ] threadWhy 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.
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.
« 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. »
The download is large because it has example scenes included.
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
3: https://pragmagic.github.io/godot-nim/v0.5.2/
4: https://en.wikipedia.org/wiki/List_of_CLI_languages
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.
[0]: https://github.com/touilleMan/godot-python
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.
https://godotengine.org/article/beta-release-python-support
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.
To see a glimpse about performance with GDScript: https://github.com/cart/godot3-bunnymark
http://docs.godotengine.org/en/3.0/getting_started/scripting...
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.
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.