Description

The server has two things that keep it busy. For one the network with new client connections beings established and incoming messages from connected clients. Second the world timer that makes the world advance to the next state at a certain interval. The handling of incoming messages and the updating of the world are the two main alternating activities in the main loop of the server. They are not interleaved or multithreaded, avoiding unnecessary complexities with that. Listening to incoming messages is handled in a separate thread, but they are put in a queue to be processed in the main loop.

Pseudocode skeleton

 - Initialize world from data files and persistent storage
 - Install world timer (to say, 20 ticks per second)
 - Start listening for incoming connections
 - Connect to other known servers*

 - For each world tick, do {
    - Handle all messages that are in the queue at this point
    - Update all active beings
       - Update Player processes and combat, checking collisions, etc.
       - Update Monster AI
       - Save state changes in temporary storage
    - Store some of the changes in persistent storage
    - Replicate some of the changes to other servers*
   }
   until quit server

 - Halt world timer
 - Close client connections
 - Make sure latest world state is stored in persistent storage
 - Replicate necessary information to other servers*

In the loop the steps marked with * are only applicable in a multi-server environment. I'm still undecided wether it would be most convenient to have a single server that can work together with other servers in a p2p way, or wether to have multiple more specialized servers. I think I'd prefer the equal-servers-p2p-network way, but this loop leaves that decision out for now.

With updating all objects I specifically noted them as "active objects", because I can very well imagine a lot of the objects, but also beings, will be inactively waiting on some events. Hence I'd suggest mainting both an all objects list as an active objects list, and only loop the active objects list on the world tick. Any object would be able to move himself in or out of the active objects list at either a tick or any other event (which could come from either an incoming message, or notifications from active objects).

Comments

Kyokai: I was thinking, some processes will begin with a user command and continue until the user gives a quit command, like walking. We need an "upkeep" routine to maintain these working processes. Also, we will need a routine to deal with monster AI and such.

---

Bjørn: Player walking would be either "walk to this location" or "walk in that direction" followed by for example "stop walking". All of these messages simply change the state of the being in question, there is no need for some kind of "upkeep" routine there. Note that a being that is walking will certainly be in the active beings list, so when a being is in a walking state, the world tick will make sure he'll actually walk.

Monster AI is the same, the AI implementation would be able to hook up to events (like "notice being", "take damage") with appropriate parameters, and during these events the state of the controlled being is changed so that in the world tick it can be decided what the being will do or continue doing.

---

This is a subpage of server development.