Fio:LuaBinder
From Fio
(→Lua Binder) |
(→Lua Binder) |
||
| Line 9: | Line 9: | ||
* npc behavior | * npc behavior | ||
| - | All the logics/policies are build on the | + | All the logics/policies are build on the mechanisms carried out by c++ classes which will do the real work of rendering, timing, event dispatching etc. This separation is to make the game fully data driven - thru scripting the logic itself is taken as data which can be easily modified without the re-compile-link of the mechanism part(or the engine). |
Lua has provided a bunch of [http://www.lua.org/manual/5.1/manual.html API]s for "the host program to communicate with Lua". To call function from lua into c++, we have to: | Lua has provided a bunch of [http://www.lua.org/manual/5.1/manual.html API]s for "the host program to communicate with Lua". To call function from lua into c++, we have to: | ||
| Line 16: | Line 16: | ||
* call c++ function; | * call c++ function; | ||
* push the return value onto lua stack; | * push the return value onto lua stack; | ||
| - | * take care the return value's | + | * take care the return value's lifetime. |
thru Lua APIs. | thru Lua APIs. | ||
| - | As the number of classes | + | As the number of classes needs to be embedded into lua increases, these routine work will be a burden to write and maintain for each function call. There're quite a few [http://lua-users.org/wiki/LuaAddons binders] out there to make the embedding easier. In Fio we implement a home brew binder - LuaUtil as a bridge between the c++ and lua world.(Not-Invented-Here Syndrome? no, it's just for better understanding of the scripting and faster compiling speed) |
===Quick Tour=== | ===Quick Tour=== | ||
Revision as of 13:32, 18 September 2006
"Like a bridge over troubled water..." - Simon and Garfunkel
still in ctoring
Contents |
Lua Binder
Fio use Lua as scripting language to implement the game logic which include(in a broad sense):
- UI design and switching
- event handler
- combat scheduler
- npc behavior
All the logics/policies are build on the mechanisms carried out by c++ classes which will do the real work of rendering, timing, event dispatching etc. This separation is to make the game fully data driven - thru scripting the logic itself is taken as data which can be easily modified without the re-compile-link of the mechanism part(or the engine).
Lua has provided a bunch of APIs for "the host program to communicate with Lua". To call function from lua into c++, we have to:
- extract the arguments from lua stack;
- check the argument/return value type;
- call c++ function;
- push the return value onto lua stack;
- take care the return value's lifetime.
thru Lua APIs.
As the number of classes needs to be embedded into lua increases, these routine work will be a burden to write and maintain for each function call. There're quite a few binders out there to make the embedding easier. In Fio we implement a home brew binder - LuaUtil as a bridge between the c++ and lua world.(Not-Invented-Here Syndrome? no, it's just for better understanding of the scripting and faster compiling speed)
Quick Tour
The Lua Application Program Interface
Construct An Object
- normal
- lightweight
Method Invoking
- method wrap
from lua into c++
- traits
- Overload
from c++ into lua
callback?
Type Checking
LSP
Destruct & Object Lifetime in the 2 Worlds
Misc
- const
- panic
- utility functions
