Re: One or many instances?

[Vaughan McAlley <ockegheim@...>]

Back when I was writing addons for World of Warcraft, addons would
often need to register for the COMBAT_LOG_EVENT_UNFILTERED event (
http://www.wowwiki.com/API_COMBAT_LOG_EVENT ). You needed to register
a frame for it, and every time a combat event came through you needed
to see if it was relevant from the many parameters (am I interested in
the source or destination of the damage, is it the right kind of
damage etc), and process it. With multiple addons all doing this (and
not all as efficiently as mine :-) ), in a battle situation with many
events per second, you would think might be performance issues, but
Lua was fast enough to cope with heated battle situations without
skipping a beat.

Vaughan

2010/1/13 Jerome Vuarand <jerome.vuarand@gmail.com>:
> 2010/1/8 Christopher Eykamp <chris@eykamp.com>:
>> I'm the lead developer for Bitfighter (http://bitfighter.org), written in
>> C++ and Lunar, and have been working on creating Lua scripted robot players
>> for a while.  There is one script per robot, and several robots could be
>> running the same script, or each could be running a different one.
>>  Typically, I would expect no more than 10 robots would exist at any time.
>>
>> Currently, management is quite easy: we create a single Lua instance for
>> each robot, each with a function that gets called one per game-cycle.
>> Because they are running in their own instance, there is no possibility of
>> one robot mucking up the environment of another, and it seems a very clean
>> solution.  When a robot is removed from the game, we simply delete the
>> instance, and everything associated with that robot is gone.
>>
>> Lately, however, I've been thinking about adding event listeners to the
>> robots, in the form of a series of functions with a name like
>> "onPlayerAdded(player)", "onShipKilled(ship, killer)", etc. that would be
>> called from C++ as needed.  This complicates things a bit because instead of
>> calling each script once per game cycle, we might be calling different
>> functions within the same script a dozen times each cycle. Multiplied over
>> the number of robots, this becomes a lot of calls, and I'm afraid of the
>> increasing overhead this might incur.
>>
>> So I've been rethinking my original design, and am wondering if it might
>> make sense to have the robots all running in a single process, which would
>> get called once per event, with some sort of Lua management script calling
>> the event handlers in each robot.  Furthermore, management of timers and
>> keeping track of which robots implement which listeners might be easier, as
>> there could be one timer management script for all robots, rather than the
>> current practice of one-per-robot.  And it seems that keeping track of which
>> robots implement which listener would be easier in Lua than in C++, which
>> would also argue against the one-instance-per-bot design.
>>
>> So the question is what is the best architecture for this sort of problem?
>>  My two key goals are maintaining adequate performance, and making the bot
>> scripting as simple as possible, which would seem to imply that each robot
>> should feel like it has it's own global namespace.  How have others
>> addressed this issue?
>
> Whether you dispatch the event to the multiple listeners (the robots)
> in C or in some Lua script, the same amount of functions will be
> called. I can't tell which language would be the fastest to do it, but
> I suspect the difference is pretty small. So in the end it might not
> be worth giving up your clean robot separation for that little (if
> any) speed improvement.
>