[MUD-Dev] Modular Design Issues RFC

[Ryan Rhodes]

Modular Design Issues - RFC

Hello there, this is my first post here so I'll give some background
on my project.  A friend and I have been working on a pure java mud
framework for about three years.  We've created various simulation
versions of most of our architectural concepts so I've got a decent
idea of what the pieces of the system will be, and I have some very
specific design questions about it.  I would point out that I'm
fascinated how some of the more complex issues I've read about on
these lists seem almost a non-issue in java while our most significant
issues are often other things.  In short, I'd really appreciate any
expert java opinions.

What is modularity?

I've read a lot of the posts on modular design and the issue seems to
get fuzzier the farther you get down the thread.  I've seen everything
from separate threads for areas to separate processes for multi-world
systems.  As best I can divide the issues they seem to center around
three ideas of modularity.

  1. Logical
  2. Distributed
  3. Threaded

We modularize in the logical sense to divide the problem into more
understandable parts, to encapsulate data, for code reuse, for
composition.  Our system has a complete object model encapsulating
every aspect of them game into objects.  The system is divided along
clear interfaces.

  Question: Is it not true, that while we may divide our system into
  threads and processes to deal with other issues, we do not divide
  our system into threads and processes to increase the logical
  modularity?

Modularity, in terms of distributing our system among multiple
processes seems to have been done for two primary reasons in the
posts.

  1. To allow components to be processed on multiple machines
  2. To allow components to be hot bootable

When I say hot bootable I mean to allow a reboot of the Data Backend
without a reboot of the game, or the game without the server and vice
versa.

  Question: Are these the only two reasons to divide a system into
  separate processes?

I've seen three primary candidates in the posts for a separate process.

  1. Game Servers
  2. Connection Servers
  3. Data Servers

The game would be distributed only if you wanted to allow for worlds,
or a world, distributed over multiple systems.  Distributed servers to
allow for multiple login sights and connection handling over multiple
systems.  It would seem as if the database should, at least logically,
appear as if it's on a single machine but could easily be distributed.
All three components might even run on a single system and receive the
hot booting benefits of a distributed architecture.

  Question: Are these the only three logical subsystems that benefit
  from distribution?

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

The posts have confirmed my own experience with java in that you can't
interrupt a thread from blocking for I/O (please post anything to the
contrary).  In order to capture link death, our system uses a separate
thread for every connection.  A separate thread would then be needed
for the server, unless the server was distributed and on its own
process.  A pool of worker threads could be allocated for handling
database I/O, weather the Database was actually on another machine or
not.  These first three items already considered, the only reason left
for threads is the reason to simulate time and action.

Now here is where my problem comes between my design issues and a lot
of posts I've seen on these ideas.  I've seen areas on their own
threads, weather, combat modules, event handlers and all sorts of
things that seem, in the context of this java system, to be illogical.
I realize some have separated into areas threads to reduce I/O
blocking for elements inside the areas.  A pool of I/O worker threads
is replacing this issue so I'm more concerned with time.

  Question: When you divide these various things into threads are you
  generating the ticks for players in the area from this thread also?
  Are you parsing input and generating game action for players in the
  area from this thread?  Are you handling the timing of weather
  events from the weather thread or combat events from the combat
  thread, for those of you that do this?

Assuming that our architecture modularizes the system logically.
We've used distribution for the reasons stated above and threads to
eliminate I/O blocking from halting the CPU.  Beyond that, using
additional threads to simulate time and process game events just slows
down the system.

  Question: Is it not true then that to divide any non-blocking
  sequential piece of code into multiple threads only degrades
  performance.  Threading is used purely to prevent the CPU from
  waiting on I/O?

  Question: Am I correct in assuming that most game systems out there
  use a single threads "Game Loop" to simulate time and, indirectly,
  trigger the parsing and processing of all game events?

Other than a java architecture based in general on the issues I've
outlined above I can only see one other logical alternative that
raises different issues.  As I've said we collect player input with a
separate thread for each player.  These buffers are then synchronized
with the game as it attempts to processes them.  So we are
multithreaded in the sense that we have eliminated the chance of I/O
blocking the CPU with light weight threads; however, once stored that
input is parsed and processed by the single "game" thread (per game
server).  I would especially like to hear from anyone who knows
anything of the workings of the commercial graphical systems on this.

  Question: What are the design and synchronization issues involved in
  a system where every player is parsing input, moving, acting,
  delaying, and generating events from his own thread?  What are the
  benefits?

The difficulties of synchronizing the data would seem enormous.  Do
the commercial games use a single looping thread to simulate time and
action or one looping thread for each player connected?


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