MUD (игра) концепция дизайна вопрос о временных событиях

Question

Я пробую свои силы в создании MUD (многопользовательской интерактивной игровой игры)

Я нахожусь в фазе проектирования / концептуализации и столкнулся с проблемой, для которой не могу найти решение. Я надеюсь, что некоторые более опытные программисты будут иметь несколько советов.

Вот проблема, насколько я могу объяснить. Когда игрок решает выполнить действие, он отправляет команду на сервер. Затем сервер обрабатывает команду, определяет, может ли действие быть выполнено, и либо выполняет его, либо отвечает с указанием причины, по которой это не может быть выполнено. Одна из причин, по которой действие может потерпеть неудачу, заключается в том, что игрок занят чем-то другим. Например, если игрок находится в середине боя и только что ударил массивным широким мечом, может пройти 3 секунды, прежде чем он сможет повторить это действие. Если игрок попытается снова размахнуться в ближайшее время, игра ответит, указывая, что он должен подождать x секунд, прежде чем сделать это. Теперь это я, вероятно, могу разработать без особых проблем. У меня проблема в том, как я могу воспроизвести это поведение от искусственных существ. Все события, которые выполняются сервером ПО СВОЕМУ СОБСТВЕННОМУ, иначе говоря, не как немедленная реакция на то, что сделал игрок, должны быть чувствительными ко времени. Какой-то злой монстр наложил на вас заклинание, но должен подождать 30 секунд, прежде чем делать это снова ... Я думаю, что, вероятно, я добавлю все эти события в какую-то очередь событий, но как я могу сделать эту очередь событий чувствительной ко времени?

Answer 1

Действия MUD обычно выполняются на «тиках», а не сразу - это позволяет ограничить влияние задержки, а команды монстра вставляются в очередь и обрабатываются справедливо.

Лично мне не нравится этот подход, но почти 99% MUD используют его. Вам необходимо создать надежную очередь команд и очередь событий, которая может обрабатывать как AI, так и пользовательские команды. Затем вы можете добавить «виртуальную задержку» к командам AI, которая может быть предопределена или равна средней задержке для всех пользователей, или как вам угодно.

Answer 2

Вы можете использовать потоки для обработки определенных типов мобов и помещать все экземпляры в какой-то массив. Затем поток просто просматривает список, многократно применяя логику. DelayTimeStart и Delay могут быть атрибутами родительского класса Mob, и когда поток проходит через цикл, он может отложить обработку любых экземпляров Mob, в которых есть время, оставшееся в задержке.

Answer 3

ИИ являются клиентами.

Они являются «частью сервера» только в самом отдаленном виде. Они на самом деле вне основного игрового движка. Это специализированные клиенты без людей.

Клиент AI имеет тот же интерфейс с сервером, что и клиент человека.

Answer 4

Ну, у ваших подконтрольных ИИ сущностей есть что-то вроде "что я собираюсь делать дальше?" метод, верно? Просто заставьте этот метод вернуть результат «Я занят, продолжайте делать то, что я делал», пока выполняется другое действие.

* 1003 Е.Г. *

class ToughGuy(AI):
   Action_Idle, Action_BroadswordSwing, Action_CastingMagic = range(3)

   MagicRange = 10
   MagicTime = 8
   MeleeRange = 4
   MeleeTime = 2

   def __init__(self):
      self.action = ToughGuy.Action_Idle
      self.actiontimer = 0

   def Update(self, timestep):
      if self.actiontimer <= 0:
         self.action = ToughGuy.ActionIdle
      else
         self.actiontimer -= timestep

      if self.action == ToughGuy.Action_Idle:
         global player # don't do this
         if self.AmIFacing(player):
            distance = DistanceBetween(self, player)
            if distance < ToughGuy.MeleeRange:
               self.action = ToughGuy.Action_BroadswordSwing
               self.actiontimer = ToughGuy.MeleeTime
            elif distance < ToughGuy.MagicRange:
               self.action = ToughGuy.Action_CastingMagic
               self.actiontimer = ToughGuy.MagicTime

и т.д.. Извините за переменные стандарты кодирования ...;)

Answer 5

Может быть, вы найдете примеры реализации здесь:

• Evennia MUD Server Alpha - Evennia - это MUD с открытым исходным кодом на основе Python
• Простой Python MUD
• Пример игры Python MUD
• Краткий обзор кодовых баз
• 16K MUD соревнование
• MUDServ
• DjangoMUD - домашняя страница

Answer 6

Я предоставлю вам ответ с точки зрения LPMud / LDMud.

Каждый игрок в MUD является экземпляром player.c. Player.c наследуется от living.c. Вещи, которые живут, бьются. Функция сердцебиения обрабатывается один раз каждые 2 секунды для каждого живого объекта в грязи (или всего, что имеет функцию сердцебиения ()). Синхронизация событий обычно выполняется не на основе секунд, а на основе количества тактовых импульсов, прошедших через счетчики внутри объекта.

Замечательная новость, которая относится к вашему вопросу, заключается в том, что монстры также наследуют от living.c. Это означает, что если у вас были действия, которые можно выполнять только периодически, все это может быть выполнено в пределах тактового импульса в зависимости от числа произошедших тактов.

Answer 7

Основной подход состоит в том, чтобы иметь структуру данных, представляющую экземпляр его заклинания злым монстром, с таймером восстановления. Когда используется сила, время восстановления устанавливается (предположительно, на количество секунд, определяемое основным определением заклинания); Попытка использовать его снова не удастся, как со способностью игрока. Это можно интегрировать с очередью событий, используя время восстановления очереди и, если оно еще не истекло, ждать его истечения, или прервать действие, или перенести действие, в зависимости от ситуации.