• Разработка ММО РПГ – практическое руководство. Сервер (часть 2)
    0
    Код сервера у нас базируется на коде, написанном для другого сетевого приложения ещё лет 10 назад. Я не знаю, была ли десять лет назад протобаф. А код у нас остался и отлично работает. Единственное, что пришлось допилить — так это скрипт на РНР, который генерирует сами пакеты (тогда, 10 лет назад и клиент и сервер были на С++, поэтому таких проблем не возникало). Но скрипт нам в любом случае нужен был, т.к. необходимо, например, генерировать enum и для клиента и для сервера и ещё с БД синхронизировать. В общем, по нашей оценки искать и пробовать опен-соурс решение было бы дольше написания скрипта.
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    0
    У нас нет такого понятия, как «ход» — игра в реальном времени.
    О работе с БД я напишу в следующей статье ).
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    0
    Все-таки вам стоит посмотреть на игру, тогда часть вопросов отпадет :).
    Есть два типа оружия на борту: один полностью управляет сервер, главное сказать кого мочить и подлететь на дистанцию выстрела. И второй тип: им полностью управляет пользователь. И сервер попробует произвести быстрел абилкой как только к нему прийдет пакет на выстрел.

    Теперь про шутеры: вы в CS пробовали играть на плохом инете? Или в Старик? Попробуйте, сразу поймете насколько сильно они привязаны ко времени пинга. На нормальных серверах игроков с плохим пингом просто кикают, чтобы играть не мешали. С плохим пингом вы нормально ни в одну игру реального времени по инету играть не сможете.

    Теперь про ориентацию. Сервер передает коэффициенты уравнения движения на клиент. И клиент уже строит ф-цию движения по ним. Но если произошла задержка в передаче (и, скажем, составила 500мс или больше), то будет небольшая рассинхронизация, т.к. за это время сервер уже новую команду на движение дал, а клиент ещё это не отобразил.
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    0
    Все проверки делаются на сервере, часть из них (для удобства пользователя) дублируется на клиенте.
    Конкретно к вашему вопросу порядок такой
    1. Игрок А скомандовал стрелять по игроку Б
    2. На сервер ушла информацию о намерениях игрока А
    3. Сервер проверил, можно ли атаковать эту цель, если да, то созда Action TFollowShipAction, который будет пытаться подлететь на близкое расстояние к цели, но при этом не «врезаться» в ней. А так же выставил в TSpaceShip::Enemy корабль Б
    4. На сервере, в каждом TSpaceShip::Update проверяется, если есть Enemy и есть турели, которые могут в него стрелять (позволяет расстояние, закончен кул-даун и т.д.), то производится выстрел.
    5. Данные о произведенном выстреле отправляются на клиенты, чтобы он мог создать particle выстрела из лазера и отобразить урон.
    Выстрел из лазера (турель) долетает до противника мгновенно.

    Отдельно ведется огонь из спец.оружия (абилки). Там порядок такой
    1. Игрок жмет на кнопку «выстрел абилкой», пакет уходит на сервер
    2. Сервер проверяет, можно ли произвести выстрел абилкой. При этом не все типы абилки требуют наличие TSpaceShip::Enemy
    3. Если стрелять можно, то сервер производит выстрел. Выстрел может быть двух типов — с созданием объекта (ракеты, плазма, мины, дроны), которые как-то перемещаются и наносят урон, только настигнув цель — или мгновенный урон (призмалуч).
    4. В случае мгновенного урона данные об уроне отправляются на клиенты, чтобы они могли отобразить particle выстрела и урон
    5. В случае создание объекта, этот объект выполняет свою полетную программу, на клиенты уходит пакет о добавлении объекта и данные о его полетных командах. Если объект наносит урон, то так же отправляется пакет на клиенты с типом урона, чтобы клиенты могли отобразить необходимый particle и цифры урона.

    По задержкам. С пингом до 100мс играть можно без проблем. При большем пинге возникает проблема не с самимы выстрелами, а с тем, что ориентация корабля в космосе не соответствует тому, что расчитано на сервере. А для некоторых абилок это критично, т.к. у них есть угол поражения.
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    0
    Нет, не open source. Английского пока нет — локализация в процессе.
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    +1
    Не секрет. Это будет описано в следующей части статьи
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    0
    Признаться, я интересуюсь ракетной техникой и, в частности, гибридными двигателя. Ну и там всякие хитрые смеси иногда проскакивают, типа бора с фтором или все того же лития. И, к своему стыду, атомный номер лития я не помню :(. Помню только, что одновалентный. Но, конечно вы правы — это наша ошибка. Слишком много внимания было уделено технической строне и графике, а вот некоторые огрехи в сюжете есть.
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    –2
    Спасибо за похвалу.
    Про литий. Сюжет пишут филологи. Потому что они действительно умеют писать. А вот со знанием таблицы Менделеева у них проблемы. А эту ошибку нашли уже когда все озвучили (и приняли озвучку у актеров), так что переделывать не стали.
  • Разработка ММО РПГ – практическое руководство. Сервер (часть 1)
    0
    Всегда пожалуйста :). Надеюсь, материал и будущих статей будет для Вас интересен.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Немного реальных цифр. Мы уменьшили объем загружаемых данных на регистрационном клиенте с 10МБ до 6.5Мб за счет разбивки загрузки в два этапа и получили +10% к игрокам, которые дождались загрузки игры вообще. А если бы там 100Мб грузилось — то наверное конверсии переходов в загрузки вообще были бы в ройоне нуля.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Спасибо за ценную информацию, это действительно может нам пригодиться.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Дело в том, что нам хотелось сделать красиво. А для этого необходимо использовать, как минимум, апаратное ускорение графики. Реализовано оно может быть только через Stage3D, который в качестве драйвера использует Direct3D под Windows. А начиная с DirectX8 двумерный компонент, DirectDraw был исключен из состава DirectX и вся отрисовка, в том числе и 2D графики делается на 3D pipeline видеокарты. Т.е. не важно, 2Д или 3Д игра — все равно отрисовка идет через 3Д.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Тут вы совершенно правы.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Да, извините, это я перепутал. Но проблема не в этом. Пользователи ничего переключать не будут — у них все будет крутиться на хромовском. А как его отлаживать? А он работает немного не так, как адобовский.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Хм. Так вроде ж в хроме свой плагин, туда не ставиться нативный. У нас с этим куча проблем была — нельзя дебаговый флеш плеер поставить. А если его ставишь с помощью грязного хака, так это он выполняется, а не плагин хрома, на котором все и будут играть. Как сейчас помню — регулярно падал у нас клиент на нем, пока не обнаружили, что текстуры 1х1px создавать нельзя, это под хромом не работает.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    +1
    Ну, с технологией я могу помочь — вернее вы сможете об этом прочитать в следующей статье :). Но у нас там шейдеры используются. В принципе, Stage3D ренедрится под основным рендером флеша, поэтому можете его запускать для космоса спокойно. Но, кроме технологии, нужен ещё толковый художник, который понимает, что да как. Вот, можете заценить spacehunters.ru/demo/game.php — это вообще одна из первых версий, офлайн, все на flex без stage3d. Но планеты, например, удалось сделать с картой высот и реальным освещением, потому что на для сферического объекта в ваккуме можно существено упростить математику и использовать pixel blender.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Просто Adobe сделал очень большой рывок с появлением AS3.0 и Stage3D. А в сознании многих флеш так и остался векторной рисовалкой для создания банеров.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Я тоже люблю флешь :). Но сейчас install base Unity3D стал большой, на нем уже можно делать. А Юнити, как ни крути, быстрее флеша работает. И программистов на C# легче найти, чем на AS3.0. Поэтому, если бы пришлось делать этот проект сейчас, то, скорее всего, выбор пал бы именно на Юнити.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    +2
    Дебаг черным — это так символично :)
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Для 2015 — я с вами согласен. Но разработка началась 3 года назад и тогда альтернативы не было. Только Unity3D, но у него install base был очень маленьким, по сравнению с флешем, так что тогда это тоже был не вариант.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Основная проблема клиента — он должен взаимодействовать с человеком, а сервер — с другой машиной :). А человек любит, чтобы были всякие там подсказки, подсветки, фильтры и т.д. А ещё человек хочет, чтобы когда он нажал на кнопку, все срабатывало быстро, лишние 0.1 секунды он ждать не будет. Программа же более лояльна :). Поэтому много времени тратиться на логику интерфейса и оптимизацию производительности. И то, как вы видите, народ жалуется на недостаточную скорость работы.
  • Разработка ММО РПГ – практическое руководство. Эпизод 1
    0
    Так Adobe их купило. Уже год или два как. Так же как и Away3D — это была сторонняя разработка, но Adobe их купила. Насколько я понимаю, с выходом Stage3D у самой Adobe просто не было средств разработки под него, а написать — руки не дошли, вот и прикупили два ведущих open source проекта.