10 ms·

The site is totally hammered right now but I managed to grab a copy and get a feel for what's in this. There's some truly exciting stuff to comb through since i

by chipsy 13y ago

The site is totally hammered right now but I managed to grab a copy and get a feel for what's in this. There's some truly exciting stuff to comb through since it's a well-used engine with a lot of history, not someone's hobby hack. What I've seen so far: A custom scripting language(GDScript) which is roughly Python-esque. The wiki explains that after trying the other common choices(Lua, Squirrel, Angelscript) over a period of years, they rolled their own solution that could be more closely integrated to the engine. An in-editor help, it has some API docs. Classes for GUI controls, including layout containers. A fairly rich audio API, including positional audio, streamed audio, common sample playback controls(pan, volume, pitch, looping), and some effects(reverb, chorus, frequency filter). Some networking functionality, including HTTP, TCP, and UDP(unclear?) mechanisms. Keyboard, joystick, mouse, and touchscreen input classes. And of course lots of rendering and physics-related stuff, including various shapes, cameras, meshes, sprites, animation, tilemaps, texture atlasing, internationalized fonts, particle systems, and multiple viewports.

eropple 13y ago
It looks pretty neat. I'm leery about their custom scripting language, but it at least sounds pretty bulletproofed. I'm interested in how much (if any) of the lower layers of their system are separated out from the higher ones; I'm more interested in how those layers could be used with my own engine than theirs itself.
- SomeCallMeTim 13y ago
  I get frustrated with people who think they can and should rewrite the scripting language. >I'm more interested in how those layers could be used with my own engine than theirs itself. You and me both. Also looking at Proton [1] and Allegro [2] for similar reasons. And just came across a Blackberry-backed engine [3] which looks interesting (and also Lua-driven). I actually have my OWN game engine (based on LuaJIT, thank you ;) that already targets Windows, Android, and iOS, but I'd like to rip out the platform layer and replace it with something that someone else is maintaining. I mean, it works now, but leveraging open source and other developers' efforts would be much better. I've considered just using SDL 2.0 and calling it good, but I'm tempted to pick up some of the higher-level functionality some of these other engines offer. None offer all the features I want, unfortunately. One of the big features they mostly miss is really good script/C++ cross-functionality. Aside from that, there are typically one or two other things that make me want to avoid them. [1] http://www.rtsoft.com/wiki/doku.php?id=proton http://www.rtsoft.com/wiki/doku.php?id=proton [2] http://alleg.sourceforge.net/ http://alleg.sourceforge.net/ [3] http://www.gameplay3d.org/ http://www.gameplay3d.org/
  - sillysaurus2 13y ago
    I get frustrated with people who think they can and should rewrite the scripting language. I actually have my OWN game engine (based on LuaJIT, thank you ;) This comment would be better if it wasn't snubbing everyone who dared try to shake up the status quo of programming languages. People two hundred years from now won't be using LuaJIT. Therefore why wait two hundred years to invent the future? We could have it within our lifetime, if we remain supportive.
    - jnbiche 13y ago
      If this comment were made about any other scripting language than LuaJIT, I'd be in agreement. But LuaJIT is the future of scripting. It's truly a stunning achievement.
      - aktau 13y ago
        LuaJIT is superior to anything else I've been able to find, it blows me away. Though there can always be something better! That being said, the "better" things I'm thinking about could be added to LuaJIT just as well as they could be to other scripting languages. For example, the LuaJIT compiler could try its best to auto-vectorize (really really hard) or could leverage the developer with SIMD-like vector operations that would adapt to whatever SSE/NEON/...-like instructions the target platform has. GCC/Clang already dod this to some extent with their vector extensions. Although for many instructions you still need to use specific intrinsics which are not cross-architecture compatible of course. The ones that are: - add/subtract - mul/divide - shuffle Which are already pretty important. One could argue over implementing some "generic" intrinsics and possibly emulating them on platforms that don't have it. But then one could be left scratching one's head when suddenly everything gets slow.... So I can understand the gcc/clang devs.
        lobster_johnson 13y ago
        I and a colleague have been looking a little bit at using Nimrod [1] as a game language. Nimrod is pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking like Python), and it's just amazingly fast, but not at the expense of ease of use. What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer. In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right. [1] http://nimrod-lang.org http://nimrod-lang.org
kevingadd 13y ago
One specific reason why they rolled a custom scripting language is that they needed vector/matrix types (i.e. vector3f, etc) exposed to scripts, and adding those through an interface like cpython or lua's embedding api would have produced scripts that were incredibly slow at manipulating vectors. Presumably luajit might have fixed this, but I can understand that they didn't go that far.
- kmavm 13y ago
  Torch seems to be a concrete example of a numerically oriented luajit embedding that provides high performance linear algebra primitives. http://torch.ch/ http://torch.ch/
- tc104 13y ago
  Their rationale for developing their own scripting language refers to Lua "fallbacks", which were a Lua feature from about a decade ago. It seems like they made their mind up a long time ago.
- oscargrouch 13y ago
  Yeah.. luajit and its amazing ffi module to the rescue here..
- eropple 13y ago
  AngelScript can use them directly, though. Perhaps it was too immature when they made the decision.
azakai 13y ago
Another interesting feature is the wide range of target platforms: > One-Click deploy to several platforms, such as Windows, Linux, Mac, Android, iOS, BB10 and HTML5.

by chipsy 13y ago

eropple 13y ago

It looks pretty neat. I'm leery about their custom scripting language, but it at least sounds pretty bulletproofed. I'm interested in how much (if any) of the lower layers of their system are separated out from the higher ones; I'm more interested in how those layers could be used with my own engine than theirs itself.

SomeCallMeTim 13y ago
I get frustrated with people who think they can and should rewrite the scripting language. >I'm more interested in how those layers could be used with my own engine than theirs itself. You and me both. Also looking at Proton [1] and Allegro [2] for similar reasons. And just came across a Blackberry-backed engine [3] which looks interesting (and also Lua-driven). I actually have my OWN game engine (based on LuaJIT, thank you ;) that already targets Windows, Android, and iOS, but I'd like to rip out the platform layer and replace it with something that someone else is maintaining. I mean, it works now, but leveraging open source and other developers' efforts would be much better. I've considered just using SDL 2.0 and calling it good, but I'm tempted to pick up some of the higher-level functionality some of these other engines offer. None offer all the features I want, unfortunately. One of the big features they mostly miss is really good script/C++ cross-functionality. Aside from that, there are typically one or two other things that make me want to avoid them. [1] http://www.rtsoft.com/wiki/doku.php?id=proton http://www.rtsoft.com/wiki/doku.php?id=proton [2] http://alleg.sourceforge.net/ http://alleg.sourceforge.net/ [3] http://www.gameplay3d.org/ http://www.gameplay3d.org/
- sillysaurus2 13y ago
  I get frustrated with people who think they can and should rewrite the scripting language. I actually have my OWN game engine (based on LuaJIT, thank you ;) This comment would be better if it wasn't snubbing everyone who dared try to shake up the status quo of programming languages. People two hundred years from now won't be using LuaJIT. Therefore why wait two hundred years to invent the future? We could have it within our lifetime, if we remain supportive.
  - jnbiche 13y ago
    If this comment were made about any other scripting language than LuaJIT, I'd be in agreement. But LuaJIT is the future of scripting. It's truly a stunning achievement.
    - aktau 13y ago
      LuaJIT is superior to anything else I've been able to find, it blows me away. Though there can always be something better! That being said, the "better" things I'm thinking about could be added to LuaJIT just as well as they could be to other scripting languages. For example, the LuaJIT compiler could try its best to auto-vectorize (really really hard) or could leverage the developer with SIMD-like vector operations that would adapt to whatever SSE/NEON/...-like instructions the target platform has. GCC/Clang already dod this to some extent with their vector extensions. Although for many instructions you still need to use specific intrinsics which are not cross-architecture compatible of course. The ones that are: - add/subtract - mul/divide - shuffle Which are already pretty important. One could argue over implementing some "generic" intrinsics and possibly emulating them on platforms that don't have it. But then one could be left scratching one's head when suddenly everything gets slow.... So I can understand the gcc/clang devs.
      - lobster_johnson 13y ago
        I and a colleague have been looking a little bit at using Nimrod [1] as a game language. Nimrod is pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking like Python), and it's just amazingly fast, but not at the expense of ease of use. What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer. In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right. [1] http://nimrod-lang.org http://nimrod-lang.org

kevingadd 13y ago

One specific reason why they rolled a custom scripting language is that they needed vector/matrix types (i.e. vector3f, etc) exposed to scripts, and adding those through an interface like cpython or lua's embedding api would have produced scripts that were incredibly slow at manipulating vectors. Presumably luajit might have fixed this, but I can understand that they didn't go that far.

kmavm 13y ago
Torch seems to be a concrete example of a numerically oriented luajit embedding that provides high performance linear algebra primitives. http://torch.ch/ http://torch.ch/
tc104 13y ago
Their rationale for developing their own scripting language refers to Lua "fallbacks", which were a Lua feature from about a decade ago. It seems like they made their mind up a long time ago.
oscargrouch 13y ago
Yeah.. luajit and its amazing ffi module to the rescue here..
eropple 13y ago
AngelScript can use them directly, though. Perhaps it was too immature when they made the decision.

azakai 13y ago

Another interesting feature is the wide range of target platforms: > One-Click deploy to several platforms, such as Windows, Linux, Mac, Android, iOS, BB10 and HTML5.