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

14

¿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.

jmp97
fuente
¿Hay alguna razón específica por la que elegiste omitir cualquier script? (como lua / gamemonkey, etc.)
Simon
Principalmente debido a la falta de experiencia y debido a suposiciones (posiblemente erróneas) de cómo esto podría afectar negativamente el rendimiento. También quería mantener la edición mundial lo más simple posible. Sin embargo, estoy abierto para usar secuencias de comandos.
jmp97
1
Estoy de acuerdo, sin soporte de secuencias de comandos será difícil agregar variedad a las misiones sin involucrar a los programadores del motor.
drxzcl
1
Los lenguajes de script tienden a ser lo suficientemente rápidos como para que no sea un problema. Recomiendo encarecidamente usarlos. Dicho esto, gran parte de las secuencias de comandos de WoW se basan en la activación de hechizos y eventos. "Hablar con A", detrás de escena, haría que A "lanzara un hechizo" sobre el jugador, y la búsqueda en realidad se codificaría "esto tiene éxito cuando el hechizo # 55728 se lanza sobre el jugador". Entonces solo necesitas un poco de codificación de IA para que las criaturas echen hechizos sobre el jugador y estás listo.
ZorbaTHut
1
Los lenguajes de script modernos (como el Lua Vm) probablemente sean lo suficientemente rápidos para usted. Son fáciles de usar, fáciles de implementar, puede volver a cargar los scripts en tiempo de ejecución, puede depurar y escalonar los scripts en tiempo de ejecución y puede iterar MUCHO más rápido mientras crea contenido. Recomiendo encarecidamente buscar un motor de secuencias de comandos (ejemplos: lua y gamemonkey) para realizar búsquedas de secuencias de comandos.
Simon

Respuestas:

6

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.

drxzcl
fuente
3
Sin embargo, ten en cuenta que las máquinas de estado tienden a enredarse muy rápido si quieres que las rutas de búsqueda se vean influenciadas por factores externos o si tus misiones son relativamente complejas. También las máquinas de estado de misiones múltiples (si pueden estar activas varias misiones) pueden ser una pesadilla. Sin embargo, dado que en esencia cada programa es una máquina de estado, se puede hacer. Pero los problemas complejos siguen siendo complejos, sin importar cómo los encapsule. Un buen ejemplo (imo) es Oblivion, donde algunas modificaciones impiden que otras modificaciones funcionen: sus condiciones previas y posteriores para los estados deben ser bastante sólidas o extremadamente tolerantes / tolerantes a errores.
Kaj
Sí, Kaj tiene razón. Solo dirígete a los foros de WoW en este momento y lee sobre las personas que se quejan de misiones inconclusas. Sucede todo el tiempo, incluso en las grandes ligas. Es realmente difícil hacer todo bien.
drxzcl
3

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.

coderanger
fuente