lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I hate to be a nuisance, but this is a little more complicated than I was looking for (but I'm really grateful for the reply :)...

To expand this a bit, I started integrating lua into our project this morning. With the assumption that it was probably more likely to be a designer writing the lua code than a programmer I started explaining lua concepts to my house mate (a level designer who has worked on a few mods for various games) to get an idea of the general flavour of code that he picked up easily.

It appeared that he picked up the function calls (and the idea of using them as states) very easily. When I tried to explain that functions are just another type of variable he found that very confusing. Usage of objects was fine, but creating them wasn't as good, though he has done some C++ before (this reminds me of Visual Basic in the days that you couldn't create your own OOP objects). Coroutines were fine, from the perspective of only your own entity. How the entities run along-side eachother was confusing, however.

So based on these discoveries I started fiddling with how the basic structure would work. Which is why I decided to run with the interface I first described (the one I couldn't figure out how to get working ;)... This was doubled with the idea that if you write a small script for the lua command-line interpreter then it would tend to have the same structure that one of our game scripts would have. In this case it would be quite easy to show our designers examples of language usage from within someone elses script.

I think part of the problem is also that we don't want a big runloop for all our entities, but rather each called in turn by our engine. This is due to the usual issues in games with only wanting particular entities to be paused at specified points in our game, or staggering our updates when it starts coming to LODing our entities, etc.

- Mab

PS. I've had the fortune of working with coroutines at work before, thank goodness, otherwise I'd be freaking out at this point :P

PA wrote:

- I have a generic 'Task' object which 'wraps' any given object in a coroutine. - The 'tasks' register themselves with a 'runloop' which enumerator through all the coroutines to give them a chance to run. - When a 'task' is running, it's underlying object 'run' method is invoked with the 'task' passed as an argument.