Unity Hot Update Scenario (Ulua vs Slua)

First of all, the address of the two projects, these two projects are a more complete LUA solution, from the efficiency and use of the same way, I finally chose Ulua, but not to say that it has an overwhelming advantage.

Ulua:http://ulua.org/index.html

Slua:https://github.com/pangweiwei/slua

The introduction of LUA is basically for hot updates, but Apple seems to have a tight limit on the hot updates to LUA scripts, and it's sneaky to do hot updates with scripts. Therefore, my consistent view is that the game frame design reasonable (such as skills, interface can be configured, try not to hard code), stable, more testing, do not always want to go online and then to fix what deadly bug. Under normal circumstances, we need to update frequently, should be game resources or planning values. It is reasonable to make an all-inclusive version update when we add a feature or a batch of interfaces. Players want to play new features to update, do not want to play new features will not be updated, so that the existing players do not have any big impact. Conversely, if the forward compatibility is never considered, such as a message casually modify the meaning of the field, or disrupt the message structure without reasonable use of protobuf, then the game code design is unreasonable.

In terms of development efficiency, I think C # is easier to write and more maintainable, since no IDE on Earth knows C # more than vs. In terms of operational efficiency, C # is about 50 times times faster than the fastest LUA solution.

Based on this, my use of LUA is to limit it to a limited number of modules, allowing Lua to serve the game rather than let the game compromise for Lua. This is not the same as Cocos2dx+lua, after all, qualified C + + developers are difficult to recruit, and development efficiency and scripting language is not comparable, as a 2D game, in most cases, the efficiency of LUA to meet the requirements. For example, the interface part can be used with LUA, basically an interface is a UI prefab plus a LUA script. The Novice boot section can also use Lua, as this is too likely to change frequently. The task section can consider using LUA, which is much more variable and less likely to be called frequently.

The choice of solution, the candidate scheme has three Ulua Slua and l#. Other such as Unilua, personal feeling is not very perfect. The above mentioned three, whether from the level of perfection, or operational efficiency are in line with the demand.

l#, feel a little bit off, no special attention, if you use C # as a script, I would rather give up the code hot Update, and in the game frame above the more effort, the same can meet most of the update requirements.

Slua and Ulua are used in a similar way and are equally efficient. Note here that Ulua is going to use the latest version, because the early Ulua is using the reflection mechanism, and the script runs poorly. The new Ulua integrates the Cstolua, which is implemented in a similar way to Slua, pre-generating a batch of code to export Unity's classes and functions to Lua, and then LUA to invoke it, so that both efficiency and GC are more perfect.

Slua has a benmark http://www.sineysoft.com/post/164 that shows the performance of Slua. But my actual test found that the latest version of the Ulua in fact, in many cases faster than the Slua, may be about a few times faster. For example, loop 200W calls V = Vector3 (i,i,i). Ulua consumes an average time of 0.7 seconds, while Slua time is 1.4 seconds, and C # native call is 0.06 seconds. The exact time may be related to the platform and the machine, but Ulua has no performance disadvantage in terms of theory (Implementation ideas) and actual results.

In use, you can refer to this article: http://blog.csdn.net/neil3d/article/details/44200821 related Tutorials A lot, there is not too much to be wordy.

Unity Hot Update Scenario (Ulua vs Slua)