A New Open-Source Game Engine Being Released

[Juan Linietsky]

This looks incredible guys and thank you for putting the effort into open sourcing it, I can't wait to check it out!

Please don't make it (L)GPL, no one will use it then outside of the GNU community. BSD/MIT/ZLIB and now Apache 2.0 are probably the only ones to consider.

MIT wil be the license.

The biggest strength from the screenshots is that it looks mighty impressive as a flash/AIR replacement for the web if it can export to HTML5/WebGL, I'm guessing through Emscripten? The editor sounds like it could be bundled with a released game itself without licensing restrictions which is great for releasing a runtime moddable game.

Emscripten+asm.js export works rather well. It's perfectly smooth under firefox, pretty good under Chrome (with regular small stalls due to deopts, but there's a bug filed and V8 authors promised to fix it), and not as good under IE11 but at least it works.

How does the 3D physics work, is it based on Bullet Physics under the hood? The animation system and editor by what I've read and from the screenshots looks incredibly developed, are there exporters for programs outside of Blender, do you support FBX or Collada import?

Godot has it's own physics engine, which focuses more on precision instead of speed. Unlike PhysX/Bullet, you can make a dynamic character controller that works really well and has none of the downsides listed here:

https://developer.nvidia.com/sites/default/files/akamai/physx/Docs/CharacterControllers.html

Collada is supported for import, and I hope someone contributes a FBX importer, now that the format has been finally reverse-engineered by the Blender guys.

I'm really interested in the rendering, from what I read the engine focus is around the ES 2.0 API and the editor control looks quite high-level on top of that. Can you get into the guts of the renderer at the shader level and render stages via a script/data-driven approach for if you want to make something like a deferred renderer or is it too high-level and you'd need to implement that kind of stuff at the C++ level with separate shaders for the targeted backends?

The rendering engine has a different philosophy to other engines as it does not allow meddling too much into low level stuff, in exchange it will try it's best to look good on different platforms. It's programmed with a built in, simplified, shader language, than then becomes compiled to different backends. Right now the GLES2 backend only does forward rendering.

A GLES3 backend with more complex rendering techniques will probably done during the year, now that there are devices available which support it.

Still though, the rendering backend is abstracted and it's easy to write a new one in C++.

Is the engine largely single-threaded? Are scripts interpreted at runtime or can they be JIT/AOT compiled at runtime? AOT would be great for iOS where you can't execute JIT things, and on HTML5/javascript which would be horrible for performance I'd imagine if it were interpreted at runtime...

The engine is mostly single threaded, but rendering, physics and other stuff can be moved to threads. The scripting is dynamically typed and it's not that fast, but it's really, really easy to extend the engine using C++ if more performance is needed. At some point I want to add optional static typing to it to improve performance. Also, I'd like to add Mono support if I could, but the license is pretty restrictive. The scripting supports multi threading though.

The performance of asm.js in Firefox and Chrome is actually amazing by the way (specially Firefox), I admit I didn't really expect it to be nearly as good as it is.

[zester]

Here's screenshots of the 2D editor editing different types of scenes and nodes.

This is a complex 2D cutout animation rig:


This is a tilemap:



This is a user interface:



Unlike other engines, Godot does not have special editing modes and screens. Everything is managed by plugins that know how to edit different types of nodes, so it's really easy to create custom editors and custom nodes using the plugin API.

For example, the 2D tile editor is a node of type TileMap, that stores and draws a tilemap. It is edited by another object, TileMapEditorPlugin, which becomes visible when a node of type TileMap is selected.

The animation player is a node of type AnimationPlayer, and the editor is a plugin, AnimationPlayerEditorPlugin.

This architecture allowed to extend and add plenty of features to the engine without bloat.

You need to be using a "constrain solver" for you widget layouts, if you are its not very good. But anyways if you don't have any issues with the LGPL
then I would use Cassowary ...

http://en.wikipedia.org/wiki/Cassowary_(software)

Updated source is found here:

https://github.com/starseeker/cassowary

[Marc Driftmeyer]

BGE as we know it is being deprecated last I heard. And is going to become what Ton is calling "Interaction mode".

That's right. Forgot about that note in June.


For those that aren't current, Ton's proposal:

http://code.blender.org/index.php/2013/06/blender-roadmap-2-7-2-8-and-beyond/

makes great sense: Leverage mature and commercially viable game engine systems from within Blender once BulletPhysics is fully integrated and much more.

Blender Game Engine

With work being done on threaded drawing and updates, viewport (compositing) effects, unified physics, node based animation, and everything that?s currently real-time in Blender already, I also propose to refocus the current game engine to re-use much more of this work.

Or more radically worded: I propose to make the GE to become a real part of Blender code ? to make it not separated anymore. This would make it more supported, more stable and (I?m sure) much more fun to work on as well.

Instead of calling it the ?GE? we would just put Blender in ?Interaction mode?. Topics to think of:

• Integrate the concept of ?Logic? in the animation system itself. Rule or behavior based animation is a great step forward for animation as well (like massive anims, or for extras).
• Support of all Blender physics.
• Optimizing speed for interactive playback will then also benefit regular 3d editing (and vice versa)
• Singular Python API for logic scripting
• Ensure good I/O integration with external game engines, similar to render engines.

What should then be dropped is the idea to make Blender have an embedded ?true? game engine. We should acknowledge that we never managed to make something with the portability and quality of Unreal or Crysis? or even Unity3D. And Blender?s GPL license is not helping here much either.

On the positive side ? I think that the main cool feature of our GE is that it was integrated with a 3D tool, to allow people to make 3D interaction for walkthroughs, for scientific sims, or game prototypes. If we bring back this (original) design focus for a GE, I think we still get something unique and cool, with seamless integration of realtime and ?offline? 3D.

Ton Roosendaal
June 2013

[PyroDevil]

Very interesting project.
But isn't "Godot" the perfect name for vaporware?
I hope we will not be waiting for Godot for Godot

[mrugiero]

Very interesting project.
But isn't "Godot" the perfect name for vaporware?
I hope we will not be waiting for Godot for Godot

I know you are kidding (I hope), but it doesn't look like vapourware to me. Juan Linietsky has several talks in congresses in Argentina (I've found some on youtube, one of them in a reputed engineering university) about the engine. Usually, for this kind of talks they check you are not selling vapour. There are also actual games using it. At most, he could not release it to the public (which I seriously doubt), but it can not be vapourware because it actually already had real world usage.

[sgifan67]

question about godot GUI features

I'm seeking a free and portable hardware accelerated GUI framework that
would allow having alpha blended gui elements to be displayed over some
content to be edited (mostly images).

I means a desktop GUI, not a game GUI, so I focus on knowing the features
of the GUI you used for your IDE.

Here are some questions to the authors of the engine centered around the possibility
of this GUI:

- is xml description useable to define user interfaces like the one used in the godot engine ide
- is some skinning support in there
- are 9 patch textures allowed for redimensionning of gui elements like buttons
- what controls are available (would be interested in color selection, font selection, file system navigation)
- are gui element attributes animatable
- is there a way to support vector graphics in the engine



PS: Why just not post a binary of your tool for people to check it out before the open source release.

thanks

[Juan Linietsky]

I'm seeking a free and portable hardware accelerated GUI framework that
- is xml description useable to define user interfaces like the one used in the godot engine ide
thanks

No, but the engine includes an xml parser.

- is some skinning support in there

Yes, everything can be fully skinned.

- are 9 patch textures allowed for redimensionning of gui elements like buttons

Yes

- what controls are available (would be interested in color selection, font selection, file system navigation)

Yes, pretty much everything (all you mentioned and everything common used in GUI development)

- are gui element attributes animatable

Yes, every single of them using a flash-like animation editor.

- is there a way to support vector graphics in the engine

No, If you mean something like SVG, probably not, unless there's a library out there that can convert it to geometry.

PS: Why just not post a binary of your tool for people to check it out before the open source release.

sure, drop me a mail to [email protected]

[mrugiero]

Juan, is Godot suitable/has been used for top-down, tile-based RPGs? I want to do a hobby project with some friends and we are looking for an easy to use (I'm the only one of the group who knows programming, so this is vital) engine, and yours seems to provide quite good tools.

[Juan Linietsky]

Juan, is Godot suitable/has been used for top-down, tile-based RPGs? I want to do a hobby project with some friends and we are looking for an easy to use (I'm the only one of the group who knows programming, so this is vital) engine, and yours seems to provide quite good tools.

There grid-based tile editor (which I guess would work for something FF6-like), and then just the standard 2D tools for placing and animating things. I suppose the particle system editor for 2D would be nice for spells since it's pretty powerful and you can animate the parameters over time.

[IanS]

It's been about a month since the original announcement, is there any chance that you have a better idea of when we can expect to see the release? I'm not asking for an exact date, unless you have one, but just generally along the lines of: in a few days, a few weeks, or closer to the end of the month.