[MUD-Dev] Modular Design Issues RFC

[Ryan Rhodes]

>Russ Lewis wrote

>> How many Threads???  Having the logical modularity and distribution
>> issues already covered, there seems to be left only 4 reasons for
>> threads in a system.

>>1. To block for Data Base I/O
>>2. To block for Socket Input
>>3. To block for incoming connections
>>4. To simulate time and action in the world

> I'm not sure what you're speaking about here.  Is this just timer
> messages?  You could easily build the kernel to send a component
> "tick" messages at various times....

(4) is not necesarily a different thread from the game thread.  In our
system it is not.  I'm speaking here of time simulation in general, in
all its forms.  No matter how the game is organized there is at least
one infinite loop simulating time.  Whether we are talking about
players and creatues recovering hp's and movement, plants growing, the
length of a combat round, spell durations, casting times, or mobiles
moving and acting on ticks, all of these events I would call here the
simulation of time.  Even your event system comes under this because
no matter what chain of function calls lead to the occurence of your
event the root function call of that chain will be found within an
infinite loop.

In the case of parsing user input, our system uses a single infinite
loop.  Every time a certain number of loops has passed, the game goes
down the list of users parsing available input.  In parsing this input
Events are created.  (I'm trying to use the vocab of this forum here
not ours) I assume alot of games work this same way.  However, for
some reason my instincts tell me that commercial games maintain a
separate thread for each player.  This 'player' thread has it's own
infinite loop and from it parses the players input, creates events,
and executes them, thus simulating time for the player.  The problems
this would seem to create, in terms of data synchronization, would
seem enormous.  If anyone has seen a system like this or has any input
please post.

An example of the benefits of such a system are thus.  After writing a
new component online, our developers use the compile command to
compile it.  To do a compilation we are going to have to block.  I
could use a thread or thread pool to handle this type of action and
have it send a notification to the players object when it is finished
much like the manner you used threads for something in your post.  The
problem with this is that to the player it appears as though he
executed his command and is free to move about and execute other
commands - like to clone this newly compiled file, only the file isn't
really compiled yet and is going to let you know when it is.  Now had
I just used the main game loop to block, the wizard would have felt a
delay until the compile was finished, solving the problem.  The
problem here, obviously, is that I've given everyone else a delay as
well because I shut down the main game loop and everything that goes
with it.  Now if every player had his own game loop I could just block
his thread when he executes the compile command and everything is
great.  I suspect this solution causes that wealth of synchronization
problems I'm talking about.  Please comment.

Your point about Multi-processor machines being able to take advantage
of multiple threads is correct.  I had forgotten this in my argument
for threads.  I would point out though that java has already forced us
to a separate thread for every connection, so in the context of that
system I don't feel multiple threads handling events could do anything
but degrade performance further.  With 99 connections and 1 thread for
the game loop, a machine with 4 processors would already have 96
threads in a wait state.  Our system aside, I really liked your idea
of being able to configure the number of threads on a per system
basis.

Our system also sounds very similar to yours in that nearly every
aspect of the system is driven by interfaces, although you're scope
sounds quite abit greater than ours as we are not doing a distributed
architecture.

Ryan

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev