Re: Bookworm Adventures Postmortem

[Niklas Frykholm <niklas@...>]

> 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