Re: Bookworm Adventures Postmortem
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Bookworm Adventures Postmortem
- From: Niklas Frykholm <niklas@...>
- Date: 2007年3月15日 09:30:25 +0100
Anyhow, the thing that I am interested the most is:
"And to aid in rapidly designing code we added a complete state synchronizer
that allowed you to modify any Lua code and reload it while the game was
running."
How can this work? And how stable can this work? Any idea?
It sounds highly useful, but I can't imagine that this can work stable - what if
certain variables are removed or parts are changed - what is happening then to
the previously assigned values?
In my Lua/C++ mixed projects I always have a "Reload" option which
allows you to reload all Lua files. I do this simply by clearing the
require-cache and running dofile on "main.lua" thus causing all
lua-files to be required again.
I do the "Reload" when I'm on the C++ side, so there is no Lua code
running when it is being reloaded. Since the "*.lua" files mostly define
functions and methods, reloading is pretty safe. I take care to write
the code so that global variables are not obliterated when it is reloaded.
Instead of this:
Account = class()
function Account:init()
...
I write:
Account = Account or class()
function Account:init()
...
Now a reload does not recreate the class, it just redefines the methods.
I have error handling set up for lua_pcall(...) so that if an error
occurs in the Lua code, the C++ part does not exit. Instead it prints
the error message, waits for me to fix the error and reload the lua
scripts and then continues running.
I can highly recommend this setup. It is a great speed boost to be able
to modify the Lua scripts without having to restart the C++ program.
// Niklas