Comment by chipsy | Hacker News Reader

Comment by chipsy | Hacker News Reader

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.

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.

Torch seems to be a concrete example of a numerically oriented luajit embedding that provides high performance linear algebra primitives. http://torch.ch/

Yeah.. luajit and its amazing ffi module to the rescue here..

AngelScript can use them directly, though. Perhaps it was too immature when they made the decision.

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.

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

[2] http://alleg.sourceforge.net/

[3] http://www.gameplay3d.org/

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.

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.

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.

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

Very interesting. I'm currently still a bit enamored with Go as it allows me to be very productive and makes deployment, cross-compiling and concurrency such an absolute dream. The performance tradeoffs have been rather good to me I find, it's very speedy for the tasks I try to use it for (almost all of them web-based). But if Nimrod is better... well I can't be sad about that!

The foundation for SIMD vector operations has already been laid by Mike Pall, and his plan is to implement a pretty full API for supporting architectures. See:

http://lua-users.org/lists/lua-l/2012-02/msg00207.html

I think he's looking for a sponsorship to accelerate this feature[1], so if you know of someone who might be in a position to sponsor the feature, it's a very worthy project!

1. http://wiki.luajit.org/Open-Sponsorships#Vector/SIMD-Data-Ty...

I'm happy to see people do innovative things with programming languages.

But there are a lot of people doing that right now. I didn't get a vibe from this one that it could do anything interesting that you can't already do in either LuaJIT or Julia. Other innovative languages I've been tracking include Go, D, Nimrod and Dart.

The world is improved by innovations; it's not improved by script language proliferation, or "me too!" projects. Lua in particular is a very well documented language, and is the de facto standard in video game development. I think the bar has to be pretty high to justify creating a new language.

Yes it would be more fun than figuring out how to get 3d matrices to work and be fast in LuaJIT, if you don't already know how the FFI works. But there's a LOT of value in using LuaJIT, and unless you're bringing something else of value to the table, no, I don't think it's worthwhile backing Yet Another Language.

I know of at least a half dozen other engine-specific scripting languages, and I would wager NONE of them are as robust as Lua, as well known as Lua, as well defined as Lua, or even as well designed as Lua. The value of having a shared language does outweigh every new programmer's desire to write their own language.

Allegro is pretty janky, in my experience. I haven't tried Proton, thanks for the pointer.

I use AngelScript, because the C++ interop is about as good as it gets. Chaiscript isn't bad, but its lack of coherent community scared me off.

Thanks for the Allegro thoughts; I'll just drop that one off my list. It was close to the edge anyway, since it seems to have only recent (beta-quality, untested) Android support.

I'm using Dub for my C++/Lua bindings, which provides exceptional C++ interop. Dub also is easily modified, and with my modifications I can have C++ objects referenced by smart pointers that are wrapped in Lua objects, and those objects can have additional Lua "tags" added to them that persist for the lifespan of the C++ object (even if all Lua instances of the object are collected).

You just can't beat LuaJIT for speed; speed isn't that important for scripting on desktops, but can be relevant on mobile. And it's hard to beat Lua syntax to enable non-programmer scripting options.

>I use AngelScript

Have you seen the LuaJIT FFI by the way? Very similar to what AngelScript offers. But it's also JIT-compiled by the best dynamic JIT compiler in existence. :)

I've done a little toying around with GamePlay3D, and I must say it's a nice engine, with a clean API and it's relatively easy to get started with it and get some results early on.

I'm actually rather disappointed almost nobody is using it. I hope it doesn't get canned.

I imagine it is related to Blackberry's current situation.

Perhaps, but the engine seems robust and well made, and is available with very permissive licensing and works on all major platforms. Should it really matter who the primary sponsor of the framework is?

Sometimes it does, because many just want to use the framework, not support it.

I am no expert but, I'd retarget your platform specific stuff to SDL. AFAIK Emscripten has SDL1 support and SDL2 support is on the way. This would enable your engine to target HTML5 robustly with Emscripten via lua and sdl. Most of your graphics primitives should already be targeting OpenGL ES 2.

http://www.infoq.com/news/2013/05/lua-vm-javascript

https://github.com/kripken/emscripten/issues/457

https://github.com/kripken/emscripten/wiki/Roadmap

Is your engine open source? I anticipate a JS backend to LuaJIT in the not-too-far future.

>Most of your graphics primitives should already be targeting OpenGL ES 2.

My engine had a chance to rot for a while; I'll be upgrading to GLES2 as soon as I'm developing on it again. (Pesky clients paying me to do other work has been slowing down development on my game and engine.)

That is one of my hesitations about Proton; they're still on GLES1.

>This would enable your engine to target HTML5 robustly with Emscripten via lua and sdl.

Not a bad thought. Hmm. Not a bad thought at all. In fact, part of the game I've been trying to work on involves an HTML component, and I've been planning to do it in JavaScript, but if I could do it in my own engine...wow. Thanks for rebooting my brain there. :)

>Is your engine open source?

Not yet. There are a (very few) parts that I don't want to publish, for reasons from "they're broken and I want to fix them first" to "this class prevents pirates from copying games in a novel way, and publishing it would just make it easier for them to pirate my games."

I'd be very surprised if you had a seriously novel method of avoiding piracy. I get the desire to do so, but realistically, not so much. (If only because they just have to find its code and nop it out.)

You can be surprised if you like. But it was novel enough to prevent my game from ever being pirated. [1]

>If only because they just have to find its code and nop it out.

If they changed a single byte in the executable, then none of the encrypted data files (i.e., the actual game) would load. I used a cryptographic key generated from the signature of the binary.

More than one byte would need to be changed. :)

I know I just raised the bar, but due to that feature and the additional obfuscation and misdirection I added, no one ever cracked it. I'm sure that the bar has been raised higher on commercial PC apps (self modifying anti-debugger code comes to mind), but what I did was at least novel on Android.

My technique was dead in the water on iOS, unfortunately; Apple mucks with the binary (encrypts it?) in the production version. But no one pirates on iOS anyway, right? ;)

[1] Successfully, I should say. Pirates thought they'd hacked the game and uploaded it all over the various pirate web sites multiple times. Thing is that the game always detected that it had been pirated, and as a result it downgraded to the "free demo" behavior, so people downloaded the same app they could have gotten for free from the store.

Why don't you make that a product? Esp the downgrade to demo, it is a great feature.

I am sure you could take the signature of the executable in memory and create a key from that for iOS? You just can't _write_ to executable memory but you can read it.

Maybe you could port your GLES1 to a compat layer like

http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

https://code.google.com/p/gles2-bc/

https://github.com/p3/regal

http://www.gamasutra.com/view/news/177233/Indepth_Bringing_R...

Depending on how difficult it is. Might be an interesting way to bring codebases that target OpenGL ES 1 onto WebGL

Thanks for the links!

My current code is pretty trivial; dropping in a pair of standard shaders and tweaking the code would probably be sufficient.

WebGL is interesting, but it only just got support in IE11 [1]. My only current project with a web requirement would need to support older browsers, including older mobile browsers, and Safari and Android browsers also lack support.

But it doesn't hurt to prepare for the future. :)

[1] http://caniuse.com/#feat=webgl

Did you have a look at urho3d ( http://urho3d.github.io/ )? (just curious)

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.

Reply on news.ycombinator.com