[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: [Q] several questions from a LUA newbie
- From: Benoit Germain <bgermain@...>
- Date: Wed, 29 May 2002 09:44:56 +0200
Hello everybody,
I am currently evaluating the functionalities of LUA 4.0 in the event of
integrating it in a game.
To to so I need some answers to the following questions:
1°) Since there is no keyboard input, every chunk will be present only in
precompiled format. Therefore, the script compiler will not be necessary in
the final build. From what I have seen so far it should not be too difficult
to remove (alongside with the C functions and API calls that might use it of
course). Is this the case ? Not that it takes much memory, but as a rule I
don't want to put in the code what is not necessary.
2°) I don't quite see yet if I will need one LUA state for all script
executions, or if I will need one LUA state per agent. Let's say that I want
to implement a soccer game. Can I use the same LUA state for all players ? I
fear I might encounter problems like globals collision, requiring strong
enforcement of coding practices (the projet will most probably involve
several script coders), which is very difficult to implement/verify. It
looks like some of these problems could be solved with the introduction of
namespaces, but this is only for LUA 4.1, and I don't know if I should count
on this version. OTOH, If I run quite a large number of LUA states, this
would end up using a lot of memory, thus losing the benefit of having AI
stored as game data (and loaded only as required) instead of having
everything embedded inside the main code.
3°) In the previous example, obviously several agents will need the same
functionnalities (say, run with the ball, and tackle an opponent). In the
event I use one LUA state per agent, I can sort of "preload" each LUA state
with the functionnalities I need through calls to lua_dobuffer() using
chunks declaring 1 function per ability. Will each LUA state have its own
copy of the function's bytecode, or will this only create a global of type
"function" that will reference the same memory instance of the bytecode ?
4°) Since agent scripts will be called each game frame, what happens in the
event a LUA state runs a script declaring functions ? I suppose the global
of type "function" will exist from one call to the next, meaning that the
function declaration bytecode will only slow down the scripts but won't
thrash the gc. I believe that I won't get a new instance of the function
bytecode in the LUA state each time the script is run ? What about local
function declartions ? Would this thrash the gc ?
5°) This one is more for Titmouse users/integrators. In the event there are
several LUA states, I suppose I can run one debugger instance per state ? I
also plan to add some features to titmouse so that debugging is easier. What
I think would do for a start is (in that order of importance):
- automatic local variables (so that I don't have to add them when I am
stepping inside a function, and once they are added and I leave the
function, they are displayed as nil because there are no globals of t he
same name)
- call stack (self-explanatory)
- context-dependant watch expressions (remember which function was being
traced when a watch expression was added, so that this expression is only
displayed when we trace the same function again).
- conditional breakpoints
Are some of these features in the process of being implemented in a future
realease ?
Thanks in advance for your answers.