编辑“︁DesignOverview”︁（章节）

= Basic Design of Marauroa =
Marauroa is an arianne server application with an UDP transport.

Marauroa server is and it is built using threads. marauroad has the following set of threads:
* 1 thread to receive data from clients
* N threads to send data to clients
* 1 thread to handle the data into server actions
* 1 thread to handle RPG itself.

To denote the active behavior of the thread classes their names include the word Manager. So marauroad has:
* NetworkManager
* GameManager
* RPManager

NetworkManager is the active thread that handles messages that come from the clients and converts them from a stream of bytes to a real Message object. See the Message Types document to understand what each message is for.

The pseudo code behind NetworkManager is:
<pre>
forever
  {
  Read stream from network
  Convert to a Message
  store in our queue
  }
</pre>

One level (conceptually) over NetworkManager is the GameManager, this is the part of the server that handles everything so that we can make the server work. Its main task is to process messages from clients and modify the state on the server to reflect the reply to that action, mainly related to:
*Login
*Logout
*ChooseCharacter
*Actions
*Transfer Content

See GameManager for a deeper understanding about what it does exactly. The hardest part of the Manager is to consider all the special cases and all the exceptions that can happen. The main pseudo code of the GameManager, if we skip exceptions, is:

<pre>
forever
  {
  Wait for Message to be available

  if(Message is Login)
    {
    check player.
    ask for character
    }

  if(Message is Choose Character)
    {
    check character
    add to game
    }

  if(Message is Action)
    {
    add action to game
    }
  
  if(Message is Transfer Request ACK)
    {
    send client the content requested
    }

  if(Message is Logout)
    {
    remove from game
    }
  }
</pre>

And finally RPManager is the active thread that keeps executing actions. Marauroa is, as you know, turn based, so actions when received are queued for the next turn, and when that turn is reached all the actions pending on that turn are executed.

The idea in RPManager is to split up complexity as much as possible: we have 2 entities to help it: Scheduler and RuleManager.

<pre>
forever
  {
  for each action scheduled for this turn
    {
    run action in RuleManager
    }

  Send Perceptions

  wait until turn is completed
  next turn
  }
</pre>

Scheduler handles the actions as they are sent by the GameManager. RuleManager is a class that encapsulates all the implementation related to rules.