Модель актера и обнаружение столкновения

Я просто думаю о возможности Erlang для игрового сервера. (о, я не эксперт Erlang, просто рассматриваю сцену) Это означает использование модели Actor для игрового моделирования. Конечно, самым большим притяжением является его concurrency, распределенный по нескольким узлам.

Мой нынешний огромный вопрос заключается в том, как я должен выполнять многоактивные взаимодействия, такие как обнаружение конфликтов. (это только пример)

Несмотря на то, что обнаружение столкновения по существу требуется в любой игре, но по характеру модели Actor, оно выглядит неэффективно и даже не имеет смысла, поскольку ему требуется глобально синхронизированный запрос состояния и обновление по всем участникам таргетинга. И если я использую какую-либо синхронизацию, она отменяет все преимущества модели актера Erlang.

Конечно, ориентация на игроков в то время может быть меньше, если я правильно использую разметку пространства, но это просто оптимизация, а не основной ответ. Или это правильный ответ на этот вопрос? Уменьшение диапазона синхронизации за счет уменьшения количества взаимодействующих субъектов?

Ответ 1

Разделите карту в меньших частях и пусть каждая часть будет ее собственным процессом (вы можете даже разбить ее настолько, что каждая плитка - это собственный процесс). Игрок, пытающийся переместить, отправит сообщение на фрагмент/подкарту, в котором говорится, что он идет туда, и плитка отвечает, если это хорошо или нет. Это позволяет избежать коллизий, поскольку только одно сообщение обрабатывается плиткой/под-картой за раз. Несколько подвариантов/плиток могут обрабатывать сообщения одновременно, поэтому он все еще является параллельной программой.

Ответ 2

У меня есть космическая игра, делающая сервер в Эрланге. Фокус в том, что каждое место / node/etc является актером. Он постоянно работает с физикой и регулярно отправляет информацию каждому игроку игровой сущности.

Все становится намного чище, когда вы начинаете думать более абстрактно о том, что такое актер/сущность. Например, столкновения могут быть полноправными участниками. Это делает клиентскую сторону намного проще - привязывает графические и звуковые эффекты к столкновению. На стороне сервера он также работает - предотвращает множественные эффекты столкновения между двумя объектами более одного раза в заданное время.