Godot, the open source game engine has released the first 3.0 Alpha

That's great. The Python part is what i like the most. I don't know much of it, but i prefer to use Python over GDScript, as it's a "real" language.

I've started using GDevelopp recently, unlike Godot no code is needed, check it too if you like this kind of stuff.

Yay, it's time to test some PBR in new renderer.

QuoteThey say they have no plans for Vulkan right now

Of course, one of the beauties of open source is that someone could step in and contribute at any time.

I wish they had gone with squirrel script instead, it's small, and damned fast but still has a lot of powerful features. If they're using the Python interpreter.... it's slow.

Quoting: TcheyI don't know much of it, but i prefer to use Python over GDScript, as it's a "real" language.

I know what you mean, but I can't help but imagine all of the older programmers out there spitting out their drinks at the sight of anyone calling Python a "real" language when it uses an interpreter. ;)

Everything is relative I guess.


Last edited by Hamish on 27 July 2017 at 11:35 pm UTC

I know GLES3 is mentioned in the article, but this version has more than just a GLES3 backend since a lot of work has gone into also making the renderer photorealistic. I would personally add "New Photorealistic renderer using OpenGL ES 3.0" as a bullet point. This seems to be where a huge chunk of the time and energy that the lead programmer, Juan Linietsky, was spent.


Last edited by natewardawg on 28 July 2017 at 2:07 am UTC

Python isn't as fast as C/C++, but it isn't slow either. It depends a lot on how you use it, and modules can easily be precompiled leaving a binary .pyc file beside the .py file.

A minimal language intended for scripting only will probably be faster, but python is a general purpose language, so you can generally do more with it, with less, or more readable code.

Quoting: KetilPython isn't as fast as C/C++, but it isn't slow either. It depends a lot on how you use it, and modules can easily be precompiled leaving a binary .pyc file beside the .py file.

A minimal language intended for scripting only will probably be faster, but python is a general purpose language, so you can generally do more with it, with less, or more readable code.

Agreed. I don't personally use Python very often, but in addition to what you said, even if it were *very* slow it wouldn't be a problem in most cases because the most computationally heavy code is within the engine itself. So your *slow* Python code would be calling into the fast C++ code anyway.

There are obviously cases where you need fast scripting, but I find usually scene and algorithm optimizations are the main need in optimizing a game, not for more code performance. For instance, having too many collisions in your game or too many draw calls (objects/passes/lights) will kill performance long before your scripting will. For algorithm, an obvious example would be using a merge sort over a selection sort which will dramatically speed up your code. Even fully optimized C++ while using a selection or bubble sort will be slow as molasses. Maybe a more game specific optimization would be to check squared distances instead of square rooted distances when checking lots of objects and all you need to do is find which one is closer. These examples have nothing to do with code performance but can be done in all languages.

I've cone across it at some point but never tried it. Having some real language support is usually better than some custom language. Whether Python 3 is a good choice I don't know. Python shines because it has a ton of libraries available. Whether this is true for Python 3 as it is for Python 2 I don't know. When it comes to performant scripting languages it's hard to beat LuaJIT though.
I wish them luck, but my impression is that they try creat a Open Source Unity and that they likely have bitten off more than they can chew.

Quoting: Hamish

Quoting: TcheyI don't know much of it, but i prefer to use Python over GDScript, as it's a "real" language.

I know what you mean, but I can't help but imagine all of the older programmers out there spitting out their drinks at the sight of anyone calling Python a "real" language when it uses an interpreter. ;)

Everything is relative I guess.

I think he means that python is "real" in that it is not specifically made for & only used in Godot. Adapting to a new scripting language isn't hard but it is still a pain an inconvenience.