lua-users home
lua-l archive

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

Somebody else will likely point out the various Lua ways to do what you
want, but I'm wondering if you just added one more layer on your current
architecture  would yield better results.  In our game, we have 32
players and a bunch of other objects and we wanted to do something like
what you mentioned.  Our architecture (similar to yours initially) now
looks like this.

-"Objects" consist of C struct plus Lua table, tied together.
-Event objects that contain link list of members wanting to receive the
event (whatever it is)
-Each event member has a script associated with it.
-Events can be triggered automatically by the engine (e.g. ever 16 ms)
or by other scripts

Instead of calling one script to handle everything, you make "lego"
blocks that can be tied together under the generic idea of events.  With
this architecture you can use the concept of "self" in order to reuse
scripts with no "if-else".  For example, you could create an "update"
event that iterates your link list of sprites and calls a script that
simply moves a sprite (which could be same script for all members, but
the looping is handled by the list).  Another event could get "sprite
moved" events and check collisions and drive the animation forward, etc.
The advantage of doing something more generic like this is that you can
use or abuse it as you see fit.  Whether you want a long meandering
script to test a new idea or nicely organized and compartmentalized
scripts, it's up to you.  The key benefit for you though will be that as
you add more variables to your objects your CPU time won't necessarily
increase because you can break your code into blocks.

I'm no Lua veteran, but it seems that most people either do what you're
doing and use lua to explicitly run functions as needed or they go with
full-blown object oriented schemes and binding systems.  We've done
something more middle-of-the-road and so far we're quite happy with it
but we haven't tested it thoroughly yet.


----- Original Message ----- 
From: "Tim Conkling" <>
To: "lua-l" <>
Sent: Thursday, October 23, 2003 8:50 AM
Subject: transparent manipulation of C data

> In my game, each sprite is associated with a script that can modify
> member variables on a per-frame basis. Right now I'm simply exposing
> some accessor and mutator functions (like get/setSpeed and
> get/setAnimation) to the Lua environment that the scripts run in, and
> the scripts call those functions directly to manipulate the sprites.
> This isn't so bad, but it's kind of ugly:
> setSpeed(-getSpeed())
> setAnimation("walk right")
> It would be nice if users could instead do:
> self.speed = self.speed * 2;
> self.animation = "walk right"
> So I was thinking of doing something like this:
> mt = {}
> mt.__newIndex(t, k, v)
> if(k == "speed") then
> setSpeed(v);
> elseif(k == "animation") then
> setAnimation(v);
> else
> rawset(t, k, v)
> end
> end
> mt.__index(t, k)
> if(k == "speed") then
> return getSpeed();
> elseif(k == "animation") then
> return getAnimation();
> endif
> return rawget(t, k)
> end
> I'm worried, however, that I'll be slowing things down unnecessarily
> adopting this strategy. For sprites, there will probably be about 15
> 20 different variables that can modified, which is a lot of
> if-elseif-elseif... checks. Is there a better way to do what I'm
> to do? Also, are there any pitfalls to watch out for with this method?
> Thanks,
> Tim