Re: Bookworm Adventures Postmortem

[Eike Decker <eike@...>]

I am using a quite similiar approach:

if Agent then Agent.cleanup() end -- Agent must be nil

Agent = {} 
...

I need to do some cleanups at the end, since the visual objects in Luxinia are
not directly Garbage collected.

Anyhow, this is not always wanted. For instance, my Agent might have a function
called think, that handles the way it behaves. Now the agent approaches a
certain complex situation that resulted randomly. If I reload, the agent code
is reloaded - and thus the agent is deleted. 
Of course, I could always place the thinking method in an extra file and let the
agent reload then thinking function from that file in case it changed...
however, wouldn't it be more functional, if I could just edit the same file and
the changed stuff replaces the running code?
The current approach requires the author to have this pattern in mind. Even
worse, it requires global variables in case of a reload. This bugs me most,
since I often don't want the variables to be global... but this seems to be the
only way to recognize, if a file was reloaded - and accessing the previously
used value.

-eike


> 
> > 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
>