Godot Engine Reaches 1.0

[PhilipLB]

This looks quite interesting:
http://www.godotengine.org/wp/godot-eng ... st-stable/

They say they have a lack of a renderer. Could Ogre3D a choice here? This would be brillant as the editor looks decent.

[Kojack]

It's definitely interesting. Single 23MB executable with no installation is the entire engine: IDE, scripting, debugger, game editor, 2d and 3d graphics, 2d and 3d physics, etc.

They say they have a lack of a renderer. Could Ogre3D a choice here? This would be brillant as the editor looks decent.

They already have both 2d and 3d engines built in:

Create realistic looking 3D games with the dedicated 3D Engine.
Import 3D models from Max, Maya, Blender, etc. with full animation.
Supports skeleton deforms and blend shapes.
Several light types, with shadow mapping.
Flexible shader & material models.
Render with HDR, anti aliasing and linear color modes.
Post process fog, glow, bloom, color adjustment, etc.

There's two things that make me wary:
- custom python inspired scripting (I don't like python, I'd prefer Lua or C#)
- custom physics engine (how does it compare with bullet/physx/havok/newton?)

[Zonder]

It's definitely interesting. Single 23MB executable with no installation is the entire engine: IDE, scripting, debugger, game editor, 2d and 3d graphics, 2d and 3d physics, etc.

They say they have a lack of a renderer. Could Ogre3D a choice here? This would be brillant as the editor looks decent.

They already have both 2d and 3d engines built in:

Create realistic looking 3D games with the dedicated 3D Engine.
Import 3D models from Max, Maya, Blender, etc. with full animation.
Supports skeleton deforms and blend shapes.
Several light types, with shadow mapping.
Flexible shader & material models.
Render with HDR, anti aliasing and linear color modes.
Post process fog, glow, bloom, color adjustment, etc.

There's two things that make me wary:
- custom python inspired scripting (I don't like python, I'd prefer Lua or C#)
- custom physics engine (how does it compare with bullet/physx/havok/newton?)

I read somewhere on the site yesterday there current 3D render was very simplistic.

Also as it's open source you could probably alter the scripting engine. Physics possibly depends if they abstracted it.

[PhilipLB]

About the scripting, this is some reasoning behind it why they have written their own language and how everything is architected so you could exchange it. Wheras I think, too, stuff like scripting belongs to one of the established, existing languages.

Initially, Godot was designed to support multiple scripting languages (this ability still exists today). However, only GDScript is in use right now. There is a little history behind this.

In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.

The last third party scripting language that was used for shipped games was Squirrel, but it was also dropped too. At that point, it became evident that Godot would work more optimally by using a built-in scripting language, as the following barriers were met:

• Godot embeds scripts in nodes, most languages are not designed with this in mind.
• Godot uses several built-in data types for 2D and 3D math, script languages do not provide this, and binding them is inefficient.
• Godot uses threads heavily for lifting and initializing data from the net or disk, script interpreters for common languages are not friendly to this.
• Godot already has a memory management model for resources, most script languages provide their own, which resulted in duplicate effort and bugs.
• Binding code is always messy and results in several failure points, unexpected bugs and general unmaintainability.

Finally, GDScript was written as a custom solution. The language and interpreter for it ended up being smaller than the binding code itself for Lua and Squirrel, and equally as functional. With time, having a built-in language has proven to be a huge advantage.

https://github.com/okamstudio/godot/wiki/gdscript

[TheSHEEEP]

Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code.

I can not agree with the slow and complex portion of this.

Here is the amount of code it takes to export one of our classes to Lua (using OOLUA, in case it was not obvious ):

Code: Select all

OOLUA_PROXY_CLASS(Actor, CallbackTarget)
    OOLUA_TYPEDEFS
      No_public_constructors
    OOLUA_END_TYPES

    OOLUA_MEM_FUNC(void, setTransform, const LuaVector3&, const Orientation&)
    OOLUA_MEM_FUNC(void, setPosition, const LuaVector3&)
    OOLUA_MEM_FUNC(void, setOrientation, const Orientation&)
    OOLUA_MEM_FUNC(bool, setupGraphicsModule, const std::string&, const LuaVector3&)
    OOLUA_MEM_FUNC(bool, setupPhysicsModule, const PhysicsModuleConfig&)
    OOLUA_MEM_FUNC(bool, setupSoundModule)
    OOLUA_MEM_FUNC(bool, setupGenerationPriorityModule)
    OOLUA_MEM_FUNC(bool, setupCameraModule, const LuaVector3&, const LuaVector3&, const Orientation&, bool)
    OOLUA_MEM_FUNC(void, playSoundEvent, const std::string&)
    OOLUA_MEM_FUNC(void, move, const LuaVector3&)
    OOLUA_MEM_FUNC(void, activateCamera)
OOLUA_CLASS_END

If that is complex, then I don't know what simple is
OOLUA is very easy to compile and link against. And afaik the fastest Lua binding solution.

Custom languages are a reason not to touch something, IMO, from a game producer point of view.
Nobody knows how to use the language, everyone has to learn something completely new.
The code can never be re-used or serve for a project which may use a different engine.
Custom languages are always subject to heavy changes.
If you end up deciding against the engine in the middle of production for some reason (can happen, even if it should not), you lose everything.
All of this would just ring some alarm bells in my head if I was deciding on an engine.

What I do agree with is multi-threading. Lua is not thread-safe and you cannot make it thread safe (its amazing speed is related to that). In the end, each thread that uses Lua will have its own Lua state.
That is a problem that you have to design the rest of the engine around.

[c6burns]

I've never been disappointed by Lua - it's my default choice - but to each their own I suppose. I don't like python, but it's not popular for no reason.

[Kojack]

As far as I know, Falcon (scripting language) is thread safe.
It's also (mostly) hit 1.0, Giancarlo is working on docs now or something.
(Falcon is my favourite language that I never use. I love it's features, but I've been waiting for 1.0 before investing real time in it)

A lot of the scripting choice is also affected by the need for apple app store compatibility (they don't like various JIT style things). My answer to that is drop iphone support.

Here's a small section of Godot's scripting language:

Code: Select all

func _integrate_forces( state ):

	var lv = state.get_linear_velocity() # linear velocity
	var g = state.get_total_gravity()
	var delta = state.get_step()
	var d = 1.0 - delta*state.get_total_density()
	if (d<0):
		d=0
	lv += g * delta #apply gravity

	var anim = ANIM_FLOOR

	var up = -g.normalized() # (up is against gravity)
	var vv = up.dot(lv) # vertical velocity
	var hv = lv - (up*vv) # horizontal velocity



	var hdir = hv.normalized() # horizontal direction
	var hspeed = hv.length()	#horizontal speed

	var floor_velocity
	var onfloor = false

	if (state.get_contact_count() == 0):
		floor_velocity = last_floor_velocity
	else:
		for i in range(state.get_contact_count()):
			if (state.get_contact_local_shape(i) != 1):
				continue
			
			onfloor = true
			floor_velocity = state.get_contact_collider_velocity_at_pos(i)
			break
		

	var dir = Vector3() #where does the player intend to walk to
	var cam_xform = get_node("target/camera").get_global_transform()
	
	if (Input.is_action_pressed("move_forward")):
		dir+=-cam_xform.basis[2] 
	if (Input.is_action_pressed("move_backwards")):
		dir+=cam_xform.basis[2] 
	if (Input.is_action_pressed("move_left")):
		dir+=-cam_xform.basis[0] 
	if (Input.is_action_pressed("move_right")):
		dir+=cam_xform.basis[0] 
		

It doesn't look too bad, other than the python style white spacing crap. Oh, and all those colons seem annoying.

[Klaim]

I do use Falcon but it was the old version for this: https://www.youtube.com/watch?v=VHFu6q1twtE

I'm waiting for the release to re-integrate the new 1.0 version in the new version of my game (I did try to integrate before but hit bugs which I reported and provided patches then didn't have enough time to continue).
At some point in the development they said it was most of the time as fast than Lua, but thread-safe (also now doing generative code or something).

I did'nt check yet how the binding works in Falcon 1.0.

I also like ChaiScript a lot for it's simplicity of use but didn't use it in a real project yet. Certainly the next C++ one.

[Zonder]

First time I have heard of falcon it does indeed look ok.

[hedphelym]

One thing I really like about Godot is their light baking.

It's a lightmapper, but not really a lightmapper. It bakes light but not to textures. It can handle direct light, diffuse light, specular light, reflections, translucent objects, radiosity, anything! It writes the light information to a compacted octree stored very efficiently inside a texture.

What's the advantage of doing this? that you don't need to do any UV mapping to the objects, you don't have to adjust lightmap resolution for each, you don't have to worry about self-intersection geometry that might bleed light or darkness.

Pictures and details:
http://www.godotengine.org/forum/viewto ... ?f=7&t=665

Video:
https://www.youtube.com/watch?v=UXFXTgy439s