Код сервера у нас базируется на коде, написанном для другого сетевого приложения ещё лет 10 назад. Я не знаю, была ли десять лет назад протобаф. А код у нас остался и отлично работает. Единственное, что пришлось допилить — так это скрипт на РНР, который генерирует сами пакеты (тогда, 10 лет назад и клиент и сервер были на С++, поэтому таких проблем не возникало). Но скрипт нам в любом случае нужен был, т.к. необходимо, например, генерировать enum и для клиента и для сервера и ещё с БД синхронизировать. В общем, по нашей оценки искать и пробовать опен-соурс решение было бы дольше написания скрипта.

У нас нет такого понятия, как «ход» — игра в реальном времени.
О работе с БД я напишу в следующей статье ).

Все-таки вам стоит посмотреть на игру, тогда часть вопросов отпадет :).
Есть два типа оружия на борту: один полностью управляет сервер, главное сказать кого мочить и подлететь на дистанцию выстрела. И второй тип: им полностью управляет пользователь. И сервер попробует произвести быстрел абилкой как только к нему прийдет пакет на выстрел.

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

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

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

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

По задержкам. С пингом до 100мс играть можно без проблем. При большем пинге возникает проблема не с самимы выстрелами, а с тем, что ориентация корабля в космосе не соответствует тому, что расчитано на сервере. А для некоторых абилок это критично, т.к. у них есть угол поражения.

Нет, не open source. Английского пока нет — локализация в процессе.

Не секрет. Это будет описано в следующей части статьи

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

Всегда пожалуйста :). Надеюсь, материал и будущих статей будет для Вас интересен.

Немного реальных цифр. Мы уменьшили объем загружаемых данных на регистрационном клиенте с 10МБ до 6.5Мб за счет разбивки загрузки в два этапа и получили +10% к игрокам, которые дождались загрузки игры вообще. А если бы там 100Мб грузилось — то наверное конверсии переходов в загрузки вообще были бы в ройоне нуля.

Спасибо за ценную информацию, это действительно может нам пригодиться.

Дело в том, что нам хотелось сделать красиво. А для этого необходимо использовать, как минимум, апаратное ускорение графики. Реализовано оно может быть только через Stage3D, который в качестве драйвера использует Direct3D под Windows. А начиная с DirectX8 двумерный компонент, DirectDraw был исключен из состава DirectX и вся отрисовка, в том числе и 2D графики делается на 3D pipeline видеокарты. Т.е. не важно, 2Д или 3Д игра — все равно отрисовка идет через 3Д.

Тут вы совершенно правы.

Да, извините, это я перепутал. Но проблема не в этом. Пользователи ничего переключать не будут — у них все будет крутиться на хромовском. А как его отлаживать? А он работает немного не так, как адобовский.

Хм. Так вроде ж в хроме свой плагин, туда не ставиться нативный. У нас с этим куча проблем была — нельзя дебаговый флеш плеер поставить. А если его ставишь с помощью грязного хака, так это он выполняется, а не плагин хрома, на котором все и будут играть. Как сейчас помню — регулярно падал у нас клиент на нем, пока не обнаружили, что текстуры 1х1px создавать нельзя, это под хромом не работает.

Ну, с технологией я могу помочь — вернее вы сможете об этом прочитать в следующей статье :). Но у нас там шейдеры используются. В принципе, Stage3D ренедрится под основным рендером флеша, поэтому можете его запускать для космоса спокойно. Но, кроме технологии, нужен ещё толковый художник, который понимает, что да как. Вот, можете заценить spacehunters.ru/demo/game.php — это вообще одна из первых версий, офлайн, все на flex без stage3d. Но планеты, например, удалось сделать с картой высот и реальным освещением, потому что на для сферического объекта в ваккуме можно существено упростить математику и использовать pixel blender.

Просто Adobe сделал очень большой рывок с появлением AS3.0 и Stage3D. А в сознании многих флеш так и остался векторной рисовалкой для создания банеров.

Я тоже люблю флешь :). Но сейчас install base Unity3D стал большой, на нем уже можно делать. А Юнити, как ни крути, быстрее флеша работает. И программистов на C# легче найти, чем на AS3.0. Поэтому, если бы пришлось делать этот проект сейчас, то, скорее всего, выбор пал бы именно на Юнити.

Дебаг черным — это так символично :)

Для 2015 — я с вами согласен. Но разработка началась 3 года назад и тогда альтернативы не было. Только Unity3D, но у него install base был очень маленьким, по сравнению с флешем, так что тогда это тоже был не вариант.