[IOS] comparison of Lua scripting with corona SDK, wax and kobold2d

LinkToOriginal: Http://www.learn-cocos2d.com/2011/08/comparison-lua-scripting-corona-sdk-wax-kobold2d/comment-page-1/#comment-232193

This kobold2d FAQ article explains the difference between Corona SDK and iPhone wax library, and evaluates the existing and future options for Lua scripting in kobold2d.

About corona SDK

The corona SDK exposes a well-designed API in Lua for app and game development. this API is naturally different from the ios sdk since corona is also a cross-platform game engine, exposing the same API for all platforms.

For example, when you receive an accelerometer event in Corona you get an event object with these properties. the acceleration parameters are already split into "instant acceleration" and "Gravity acceleration", something that IOS developers have to do manually. at the same time, the event also reports whether it was a shake event. on iOS this is an entirely different api from the accelerometer events.

In one sentence, Corona exposes the functionality that the devices offer in a uniform, simplified way. corona also condenses information into fewer properties and methods. you deal with fewer functionswhich makes it great for rapid prototyping. but sometimes you'll have fewer functionality, and in particle you can't extend corona with your own objective-C, C or C ++ Code since the backend engine is proprietary. overall, this makes corona SDK very easy to learn but because it's not extensible and can impose restrictions, it's not for everyone.

About wax

The iPhone wax library is a dynamic, automatic binding of the Lua language to objective-C. Wax provides a translation layer that exposes regular objective-C code to Lua via objective-C runtime functions.

Since the binding happens at runtime, It'sDynamic binding-In other words there is no code that says that function x shoshould be exposed to Lua in a particle way. instead, there's code that creates the Lua methods and properties by analyzing the existing objective-C code at runtime, and applying generic conversion mechanisms to translate between the two ages. theBinding is automaticBecause that translation is transparent to the user.

Wax in essence allows you to write objective-C code in the scripting language Lua. this is nice, in Fig memory management shocould be mentioned as a positive feature of wax. but other than that it's really hard to justify the use of wax if you can write the same code in objective-C. here are the major drawbacks of writing (scripting) apps with wax:

1. You end up writing almost the exact same code as in objective-C. It may be a little less code but it's using a weird and uncommon syntax.
2. The dynamic nature of wax 'lua binding causes a significant overhead. so much in fact that actual gameplay scripting for realtime (60 FPS) games will result in disappointing performance-unless the game is rather simple and/or you target only newer devices (4th generation onward, and iPads ).
3. You can not properly debug Lua scripts. You can't set breakpoints, You can't single-step through script code, you can't inspect variables.
4. Lua is a dynamically typed language. That means the compiler won't check Lua scripts for errors. Any syntax errors in your script will only surface while your app is already running.
5. Lua support in xcode is non-existent. There's no syntax highlighting, no auto-completion, no refactoring, no quick help for Lua script files.
6. You lose named parameters in Lua code. Lua functions are non-descript like C functions:

   someFunction("myName", 1, true, "triggerMe", false, 100, 0.4)

In particle not being able to debug your wax scripts (#3) and not having compile-time syntax checks (#4) will completely offset any time-savings you might get from writing your app entirely in wax.

Wax doesn't play into Lua's strengths, which is that it's usually used to expose a simplified, domain-specific API. such an API wocould be less error-prone, is easier to understand and debug. instead, wax exposes the full complexity of objective-C and applies a weird syntax, removes debugging, disables syntax checking and reduces code editing comfort. not on purpose, mind you, but in effect that's what you get.

While corona shares the issues #4 to #6 with wax, it's performance and code design is well above that what Wax is able to provide. corona also comes with a Lua debugger, albeit a command-driven one (eg. like terminal ).

The middle-ground: A domain-specific script API in Lua

Lua is not without its advantages. it's an excellent language to script games in. but this is only true if the purpose of the language has been determined and an appropriate API has been designed and implemented, exposed to Lua via regular, non-dynamic Lua Bindings for optimal performance. that requires a lot of work.

You can bind the exposed API to Lua either by manually Writing C functions that manipulate the Lua stack, or via binding libraries such as tolua. Such an approach can have one of these goals:

1. A general purpose game engine API for writing apps in Lua. (corona SDK)
2. A domain-specific scripting API to manipulate existing game objects at runtime for a specific purpose. this is often tailored to work only with a particle (type of) game. (World of Warcraft UI scripting)
3. A "load-time" API to configure the app and its objects. reduces the amount of boilerplate code needed for setting up a scene. can be used by add-ons and tools as a user-editable data format for scenes, levels, etc. (kobold2d)
4. Use number 3 to configure a domain-specific, runtime state machine. the statemachine is implemented in a high-level language (objective-C, C, C ++) for best performance. the high-level API is exposed through Lua to provide a user-friendly API to designers. the Lua scripts are run once to initialize the statemachine. (battleforge, spellforce)

Number 3 is already implemented by kobold2d. number 2 and/or 4 cocould be implemented in the future, provided that there's a common module that the scripts are supposed to control. for example, this cocould be a Scriptable menu system so that menu screens can be designed and programmed entirely in Lua. this isNotA promise for a feature, just something thatCocouldBe done.

Number 4 is quite powerful, but new developers repeatedly find it confusing to write scripts that are executed exactly once (eg each time the level is restarted) because the scripting API implies a runtime nature that it doesn't have-it's only a setup/init script that's translated to a runtime state-machine.

Number 1 is not compelling-for one users can simply use the corona SDK if they want to write everything in Lua, and secondly some of the drawbacks for wax still apply: No debugging, no compile-time error checking, no xcode support.

In addition, implementing number 1 on top of cocos2d means that there will have to be some amount of hacks, compromises and extension code to keep the Lua API clean and simple while making it work with the already existing cocos2d API. it wocould make more sense to write an entirely new game engine with a Lua interface, and also make that cross-platform. but wait, that's what the corona SDK is! You also get such a Lua interface with Cocos2D-X.