¿Consejos para implementar la mecánica de misiones MMO?

¿Qué herramientas, patrones o mejores prácticas recomendaría para implementar la mecánica de misiones que se detallan a continuación?

Estoy hablando de la arquitectura de software (qué tan genérico debería ser) y las opciones de cableado de objetos, suscripción de eventos y representación de condiciones. La mención de herramientas / bibliotecas que ha utilizado con éxito es bienvenida. Editar: si está utilizando secuencias de comandos, ¿qué configuración recomienda?

Requisitos:

• mmo 2D simple (rpg)
• Todos los datos del juego, incluidas las misiones, se almacenan en una base de datos relacional
• cualquier evento en el juego podría desencadenar una nueva búsqueda para jugadores o el avance de misiones existentes
• una misión puede tener un número arbitrario de condiciones que deben cumplirse antes de que la misión esté disponible para los jugadores
• una búsqueda puede consistir en un número arbitrario de sub-misiones / pasos con condiciones arbitrarias

• las misiones van desde simples:

  hablar con A - matar a 5 B - hablar con A - aumentar permanentemente la salud

• bastante involucrado:

  usa el objeto en el área X - ve al área Y - un bot generará - mata al bot sin recibir más del 10% de daño - el bot suelta el objeto - recoge el objeto - el portal se desbloquea - entrega el objeto a J detrás del portal - recibe oro y experiencia - permitir pasar el portal una vez más - bloquear el portal para este jugador

• las instancias de nivel son una posibilidad (los jugadores pueden completar ciertas misiones en equipos o aislamiento que generará la ubicación de nivel solo para esos participantes)

• Las misiones deben ser manejables preferiblemente usando un editor mundial sin necesidad de programación o conocimiento de programación ( Edición: sin embargo, no se recomienda contra las secuencias de comandos en general)
• Asumo C ++ como el lenguaje de implementación

Estaba pensando que si pudiera combinar cualquier cadena de eventos y condiciones podríamos modelar misiones más complejas y, por lo tanto, posiblemente más atractivas. Experimenté con rodar mi propio motor ECA (Eventos-Condiciones-Acciones) pero eso podría ser excesivo. Ha sido particularmente difícil modelar condiciones genéricas sin usar ningún tipo de secuencia de comandos.

Primero una advertencia, luego algunos consejos.

La última vez que necesité implementar un sistema como este, no estaba usando un motor originalmente diseñado para aplicaciones tipo MMO. El sistema de búsqueda con el que se envió fue diseñado para emprendimientos de un solo jugador, y no se pudo usar.

Terminé teniendo que rellenar scripts en todos los objetos involucrados en las misiones más o menos a mano, como este (pseudocódigo):

Lever004_on_activate() {
    if isOnQuest(player, QUEST_0012) do_something();
    if isOnQuest(player, QUEST_0015) do_something_else();
}

Esta es una pesadilla completa. No hay forma de descubrir cómo funciona la búsqueda sin hurgar en todo el juego. No hagas esto.

Recomendaría crear un sistema donde toda la búsqueda (línea) se represente como una máquina de estados finitos, con eventos para verificar las transiciones y los scripts para reaccionar a dicha transición. Eso hace que sea fácil hacer un seguimiento de dónde se encuentra en una búsqueda (línea) determinada y mantiene todo el estado de la búsqueda perfectamente encapsulado.

Si lo desea, puede hacer una biblioteca de guiones / plantillas de guiones en su editor mundial para eventos comunes (el jugador habla con el NPC, el jugador mata a la mafia, etc.)

No me preocuparía demasiado por el rendimiento del script, siempre que no active los scripts de eventos con demasiada frecuencia. Como regla general, los guiones deben disparar al menos un orden de magnitud menor que la lógica del juego "central" (animación, física, etc.). Deben reaccionar a los eventos, en lugar de disparar periódicamente para verificar si se ha cumplido una condición.

Nuestro sistema consiste básicamente en ejecutar una expresión (lenguaje de scripting mini personalizado pero tcl / lua / python funcionaría igual de bien, o hacer algo usted mismo) en cada marco de servidor para cada paso de la misión. Esto es para "misiones personales" que están vinculadas a un jugador específico. Cada subpaso forma parte de una FSM (máquina de estados finitos) para la misión en sí (que podría ser un subpaso de otra misión). También hay "misiones de mapa" que tienen un solo FSM y están vinculados al mapa en lugar de un jugador (piense en las misiones públicas de WAR), pero los pasos secundarios funcionan básicamente igual.

Lo que estas expresiones realmente miran son eventos transmitidos por el sistema como "NPC murió" o "interacción completa". Esto significa que puedes desacoplar un poco las diferentes partes, los sistemas de juego solo envían eventos según sea necesario, y los guiones de la misión solo escuchan los eventos y no te preocupes por su origen. Si también se superpone a eso, puede hacer que los FSM de la misión interactúen con el estado mundial (solo muestre este contacto cuando está en el estado de misión X), puede obtener mucha potencia del sistema.