[MUD-Dev] DGN - Method of controling NPC's.
elanthis at awesomeplay.com
Thu Dec 4 20:08:17 New Zealand Daylight Time 2003
On Thu, 2003-12-04 at 17:21, J C Lawrence wrote:
> On Tue, 2 Dec 2003 08:15:09 -0800 (PST)
> Tony Hoyt <gmtonyhoyt at yahoo.com> wrote:
>> The jobs where cron-ed due to allow for a random selected time to
>> occure before the NPC to spawn.
> Cron won't/can't do this. If you do use first class processes for
> NPC scheduling you can have them reschedule as `at` jobs, which is
> realted to but not quite the same as cron.
> More simply you need to examine what the benefits are, if any, of
> moving into a discrete process. It becomes a smaller piece of
> work to be sure, but you also lose all the ready access to state
> information and non-user-level interfaces.
Not to mention the resource implications - tons of information needs
to be duplicated in the server and the client, the overhead of the
processing of messages sent between the two, latency in sending
If you really need a separate process style design, using threads
might work better - much less duplicated information, faster
communication methods are available, etc.
Plus, instead of spawning and killing a process (or a thread), you
should pool them, so you don't need to incur the overhead of
creating a new one every time an NPC spawns - just look in the pool
and reinitialize and reuse an existing process. Many
multi-threaded/multi-process server architectures do this for the
obvious efficiency gains.
In the end, tho, what does the separate thread even really give you?
You can use a lite-weight scripting language (should be all you'd
need for even moderately complex AI) with lite-weight threading
features, and simplify things even further. Plus, the AI might even
become easier to code, since you can write/modify the script
language to have the exact features/syntax/etc you need for easy and
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev