¿Cómo funciona la comunicación de la entidad?

Tengo dos casos de usuario:

1. ¿Cómo entity_Aenviaría un take-damagemensaje a entity_B?
2. ¿Cómo sería la entity_Aconsulta entity_Bde HP?

Esto es lo que he encontrado hasta ahora:

• Cola de mensajes
  1. entity_Acrea un take-damagemensaje y lo publica en entity_Bla cola de mensajes.
  2. entity_Acrea un query-hpmensaje y lo publica entity_B. entity_Ba cambio crea un response-hpmensaje y lo publica entity_A.
• Publicar / Suscribir
  1. entity_Bse suscribe a los take-damagemensajes (posiblemente con algún filtrado preventivo para que solo se entreguen mensajes relevantes). entity_Aproduce take-damagemensaje que hace referencia entity_B.
  2. entity_Ase suscribe a update-hpmensajes (posiblemente filtrados). Cada cuadro entity_Btransmite update-hpmensajes.
• Señal / Ranuras
  1. ???
  2. entity_Aconecta una update-hpranura a entity_Bla update-hpseñal de.

¿Hay algo mejor? ¿Tengo una comprensión correcta de cómo estos esquemas de comunicación se vincularían con el sistema de entidad de un motor de juego?

¡Buena pregunta! Antes de llegar a las preguntas específicas que hizo, diré: no subestime el poder de la simplicidad. Tenpn tiene razón. Tenga en cuenta que todo lo que intenta hacer con estos enfoques es encontrar una manera elegante de diferir una llamada a la función o desacoplar a la persona que llama de la persona que llama. Puedo recomendar corutinas como una forma sorprendentemente intuitiva de aliviar algunos de esos problemas, pero eso está un poco fuera de tema. A veces, es mejor simplemente llamar a la función y vivir con el hecho de que la entidad A está acoplada directamente a la entidad B. Ver YAGNI.

Dicho esto, he usado y estoy contento con el modelo de señal / ranura combinado con el simple paso de mensajes. Lo usé en C ++ y Lua para un título de iPhone bastante exitoso que tenía un calendario muy apretado.

Para el caso de señal / ranura, si quiero que la entidad A haga algo en respuesta a algo que hizo la entidad B (por ejemplo, abrir una puerta cuando algo muere), podría hacer que la entidad A se suscriba directamente al evento de muerte de la entidad B. O posiblemente la entidad A se suscribirá a cada uno de un grupo de entidades, incrementará un contador en cada evento disparado y abrirá la puerta después de que N de ellos hayan muerto. Además, "grupo de entidades" y "N de ellas" normalmente se definirían por diseñador en los datos de nivel. (Por otro lado, esta es un área donde las corutinas realmente pueden brillar, por ejemplo, WaitForMultiple ("Dying", entA, entB, entC); door.Unlock ();)

Pero eso puede volverse engorroso cuando se trata de reacciones estrechamente acopladas al código C ++, o eventos inherentemente efímeros del juego: infligir daño, recargar armas, depurar, retroalimentación de IA basada en la ubicación impulsada por el jugador. Aquí es donde el mensaje que pasa puede llenar los vacíos. Básicamente se reduce a algo así como "diga a todas las entidades en esta área que sufran daños en 3 segundos" o "cada vez que complete la física para descubrir a quién disparé, dígales que ejecuten esta función de script". Es difícil descubrir cómo hacerlo de manera agradable usando publicación / suscripción o señal / ranura.

Esto puede ser fácilmente exagerado (en comparación con el ejemplo de tenpn). También puede ser una hinchazón ineficiente si tienes mucha acción. Pero a pesar de sus inconvenientes, este enfoque de "mensajes y eventos" encaja muy bien con el código de juego con guión (por ejemplo, en Lua). El código del script puede definir y reaccionar a sus propios mensajes y eventos sin que el código C ++ se preocupe en absoluto. Y el código de script puede enviar fácilmente mensajes que activan el código C ++, como cambiar niveles, reproducir sonidos o incluso dejar que un arma establezca cuánto daño produce el mensaje TakeDamage. Me ahorró un montón de tiempo porque no tenía que perder el tiempo constantemente con luabind. Y me permitió mantener todo mi código luabind en un solo lugar, porque no había mucho. Cuando está correctamente acoplado,

Además, mi experiencia con el caso de uso # 2 es que es mejor manejarlo como un evento en la otra dirección. En lugar de preguntar cuál es la salud de la entidad, dispare un evento / envíe un mensaje cada vez que la salud haga un cambio significativo.

En términos de interfaces, por cierto, terminé con tres clases para implementar todo esto: EventHost, EventClient y MessageClient. EventHosts crea ranuras, EventClients se suscribe / conecta a ellos y MessageClients asocia un delegado con un mensaje. Tenga en cuenta que el objetivo delegado de un MessageClient no necesariamente tiene que ser el mismo objeto que posee la asociación. En otras palabras, MessageClients puede existir únicamente para reenviar mensajes a otros objetos. FWIW, la metáfora de host / cliente es algo inapropiada. Fuente / sumidero podrían ser mejores conceptos.

Lo siento, divagué un poco allí. Es mi primera respuesta :) Espero que tenga sentido.

// in entity_a's code:
entity_b->takeDamage();

Preguntaste cómo lo hacen los juegos comerciales. ;)

Una respuesta más seria:

He visto que las pizarras se usan mucho. Las versiones simples no son más que puntales que se actualizan con cosas como el HP de una entidad, que las entidades pueden consultar.

Sus pizarras pueden ser la vista del mundo de esta entidad (pregunte en la pizarra de B cuál es su HP), o la vista de una entidad del mundo (A consulta su pizarra para ver cuál es el HP del objetivo de A).

Si solo actualiza las pizarras en un punto de sincronización en el marco, puede leerlas en un punto posterior desde cualquier subproceso, haciendo que el subprocesamiento múltiple sea bastante sencillo de implementar.

Las pizarras más avanzadas pueden ser más como tablas hash, asignando cadenas a valores. Esto es más fácil de mantener pero obviamente tiene un costo de tiempo de ejecución.

Tradicionalmente, una pizarra es solo una comunicación unidireccional: no manejaría la distribución de daños.

He estudiado un poco este tema y he visto una buena solución.

Básicamente se trata de subsistemas. Es similar a la idea de pizarra mencionada por tenpn.

Las entidades están hechas de componentes, pero son solo bolsas de propiedades. No se implementa ningún comportamiento en las propias entidades.

Digamos que las entidades tienen un componente de salud y un componente de daño.

Luego tiene algunos MessageManager y tres subsistemas: ActionSystem, DamageSystem, HealthSystem. En un momento, ActionSystem hace sus cálculos sobre el mundo del juego y genera un evento:

HIT, source=entity_A target=entity_B power=5

Este evento se publica en el Administrador de mensajes. Ahora, en un momento dado, el MessageManager revisa los mensajes pendientes y descubre que el DamageSystem se ha suscrito a los mensajes HIT. Ahora el MessageManager entrega el mensaje HIT al DamageSystem. El DamageSystem revisa su lista de entidades que tienen un componente de Daño, calcula los puntos de daño según el poder de golpe o algún otro estado de ambas entidades, etc. y publica el evento

DAMAGE, source=entity_A target=entity_B amount=7

HealthSystem se ha suscrito a los mensajes DAMAGE y ahora, cuando el MessageManager publica el mensaje DAMAGE en HealthSystem, HealthSystem tiene acceso a ambas entidades entity_A y entity_B con sus componentes Health, por lo que nuevamente HealthSystem puede hacer sus cálculos (y tal vez publicar el evento correspondiente). al administrador de mensajes).

En dicho motor de juegos, el formato de los mensajes es el único acoplamiento entre todos los componentes y subsistemas. Los subsistemas y entidades son completamente independientes y no se conocen entre sí.

No sé si algún motor de juego real ha implementado esta idea o no, pero parece bastante sólido y limpio y espero algún día implementarlo yo mismo para mi motor de juego de nivel aficionado.

¿Por qué no tener una cola de mensajes global, algo como:

messageQueue.push_back(shared_ptr<Event>(new DamageEvent(entityB, 10, entityA)));

Con:

DamageEvent(Entity* toDamage, uint amount, Entity* damageDealer);

Y al final del juego de bucle / manejo de eventos:

while(!messageQueue.empty())
{
    Event e = messageQueue.front();
    messageQueue.pop_front();
    e.Execute();
}

Creo que este es el patrón de comando. Y Execute()es un virtual puro en el Eventque los derivados definen y hacen cosas. Entonces aquí:

DamageEvent::Execute() 
{
    toDamage->takeDamage(amount); // Or of course, you could now have entityA get points, or a recognition of damage, or anything.
}

Si tu juego es para un jugador, solo usa el método de objetos objetivo (como se sugiere).

Si es (o quiere admitir) multijugador (multicliente para ser exactos), use una cola de comandos.

• Cuando A hace daño a B en el cliente 1, simplemente ponga en cola el evento de daño.
• Sincronice las colas de comandos a través de la red
• Manejar los comandos en cola en ambos lados.

Yo diría: no use ninguno, siempre que no necesite explícitamente retroalimentación instantánea del daño.

La entidad / componente que toma el daño / lo que sea debe empujar los eventos a una cola de eventos local o a un sistema en un nivel igual que contenga eventos de daños.

Entonces debería haber un sistema de superposición con acceso a ambas entidades que solicite los eventos de la entidad a y lo pase a la entidad b. Al no crear un sistema de eventos general que cualquier cosa pueda usar desde cualquier lugar para pasar un evento a cualquier cosa en cualquier momento, crea un flujo de datos explícito que siempre hace que el código sea más fácil de depurar, más fácil de medir el rendimiento, más fácil de entender y leer y, a menudo conduce a un sistema más bien diseñado en general.

Solo haz la llamada. No haga request-hp seguido de query-hp; si sigue ese modelo, se encontrará con un mundo de dolor.

Es posible que desee echar un vistazo a las Continuaciones Mono también. Creo que sería ideal para los NPC.

Entonces, ¿qué sucede si los jugadores A y B intentan golpearse entre sí en el mismo ciclo de actualización ()? Supongamos que la Actualización () para el jugador A ocurre antes de la Actualización () para el jugador B en el Ciclo 1 (o marca, o como se llame). Hay dos escenarios en los que puedo pensar:

1. Procesamiento inmediato a través de un mensaje:

   • el jugador A.Update () ve que el jugador quiere golpear a B, el jugador B recibe un mensaje que notifica el daño.
   • player B.HandleMessage () actualiza los puntos de vida del jugador B (muere)
   • el jugador B.Update () ve que el jugador B está muerto ... no puede atacar al jugador A

Esto es injusto, los jugadores A y B deberían golpearse entre sí, el jugador B murió antes de golpear A solo porque esa entidad / objeto de juego recibió una actualización () más tarde.

1. Poniendo en cola el mensaje

   • El jugador A.Update () ve que el jugador quiere golpear a B, el jugador B recibe un mensaje que notifica el daño y lo almacena en una cola
   • El jugador A.Update () verifica su cola, está vacía
   • el jugador B.Update () primero verifica los movimientos para que el jugador B envíe un mensaje al jugador A con daño también
   • el jugador B.Update () también maneja mensajes en la cola, procesa el daño del jugador A
   • Nuevo ciclo (2): el jugador A quiere beber una poción de vida, por lo que se llama al jugador A.Update () y se procesa el movimiento
   • El jugador A.Update () verifica la cola de mensajes y procesa el daño del jugador B

De nuevo, esto es injusto ... ¡se supone que el jugador A toma los puntos de golpe en el mismo turno / ciclo / tic!