erlang - Modelo de actor y detección de colisión
interaction actor-model (2)
Solo estoy pensando en la posibilidad de Erlang para el servidor del juego. (oh, yo no soy experto en Erlang, solo estoy considerando el escenario). Esto significa usar Actor Model para la simulación de juegos. Por supuesto, la mayor atracción es su concurrencia distribuida en múltiples nodos.
Mi gran pregunta actual es cómo debo realizar interacciones de múltiples actores, como la detección de colisiones. (esto es solo un ejemplo)
Aunque la detección de colisiones es esencial en cualquier juego, pero en la naturaleza de Actor Model, no parece eficiente e incluso no tiene sentido, ya que necesita una consulta de estado sincronizada globalmente y una actualización de todos los actores de orientación. Y si uso cualquiera de sincronización, anula todos los beneficios del modelo de actor de Erlang.
Por supuesto, seleccionar actores a la vez puede ser más pequeño si utilizo la partición del espacio correctamente, pero es solo una optimización, no una respuesta principal. ¿O es esta una respuesta correcta para esta pregunta? ¿Disminuye el rango de sincronización al disminuir el número de actores que interactúan?
Tengo un juego basado en el espacio que hace el servidor en Erlang. El truco es que cada ubicación / nodo / etc. también es un actor. Ejecuta la física de forma continua y envía la información a cada actor de entidad de juego de forma regular.
Todo se vuelve mucho más limpio cuando comienzas a pensar de manera más abstracta sobre lo que es un actor / entidad. Por ejemplo, las colisiones pueden ser actores de pleno derecho. Esto hace que el lado del cliente sea mucho más fácil: ate los efectos gráficos y de sonido a la colisión. En el lado del servidor, también lo es: evitar múltiples efectos de colisión entre dos entidades más de una vez en un momento dado.
Divide el mapa en partes más pequeñas y deja que cada parte sea su propio proceso (incluso puedes dividirlo tanto que cada tesela es su propio proceso). Un jugador que intenta moverse enviará un mensaje a la ficha / sub-mapa diciendo que va allí, y la ficha responderá si está bien o no. Esto evita colisiones ya que solo un mensaje es manejado por el mosaico / submapa a la vez. Múltiples submapas / mosaicos pueden manejar mensajes al mismo tiempo, por lo que sigue siendo un programa concurrente.