Pull to refresh
23
0
Павел Зинов @mrguardian

Игровой разработчик, техлид

Send message

Частенько использую codingame, а также topcoder для практики. Очень хорошие ресурсы.

Очень хотелось бы почитать чуть более подробно и в деталях. Надеюсь на выход следующих статей.

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

Мы уже писали об этом в статье про выбор ECS вот тут habr.com/company/pixonic/blog/413729.

Дело в том, что тут нельзя выделить какую-то одну-единственную фишку. Смысл в том, что это совершенно другая парадигма, как, например, функциональное программирование, у которой есть свои плюсы и минусы.

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

Композиционный подход вместо наследования, к которому всё больше склоняется ООП сообщество, тут реализован из коробки.

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

Недавно наша компания проводила Pixonic DevGamm Talks, на котором был доклад, также посвященный этой теме. Рекомендую ознакомиться с выступлением моего коллеги на нём youtu.be/GFb84n9gz94?t=2h29m39s
По поводу готового решения от Google — нет не смотрели. Спасибо за ссылку, посмотрим.
200мс — это то, что мы видим на большом наборе данных. Это среднее значение и физически у вас вряд ли получится поставить по серверу в каждой стране. По крайней мере, в нашем кейсе это так.

Photon не очень хорошо предназначен для подобного. Инфраструктура на Java гораздо более приспособлена под такого рода задачи.

Всё верно. Мета серверы используют Java и соответствующий стек технологий. Об этом тоже планировали рассказать в будущих статьях.

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


Единственное, что могу сказать — проблемы потери нескольких пакетов подряд при игре в реальных условиях (через мобильные сети, публичные wi-fi точки) — сильно преувеличены. Мы это видим на основе определённых данных, которые собираем в процессе тестирования. Если же wi-fi эфир действительно нагружен до предела, то все сетевые игры будут лагать. Как пример — на той же перегруженной wi-fi сети смотрели на Clash Royale и игра вела себя крайне нестабильно. Попробуйте поиграть в Overwatch на такого рода соединении.

Играется очень неплохо. К сожалению, пощупать можно будет только после глобального релиза :)

Такие типы данных использованы для удобства. Наш упаковщик данных режет лишние байты и биты. Если посмотрите на пример его вызова packer.PackUInt32((uint)((s.AimMagnitudeCompressed — min)/step), CalcFloatRangeBits(min, max, step)) — второй аргумент — это как раз количество значимых бит. В каждом компоненте мы помечаем допустимые значения, а автоматический генератор создаёт на основе этого оптимальный код для передачи по сети с использованием упаковщика.
По остальным вопросам:


  1. Размер серии вводов в пакете не превышает 200 байт. Потому следить за тем, что сервер уже получил, а чего нет, с точки зрения трафика, избыточно. Проще отправлять всё подряд и надеяться, что данные, сдублированные несколько раз рано или поздно будут доставлены. Если же нет, то тут либо дисконнект, либо слишком поздно досылать ввод. Сервер его уже все равно не примет.
  2. Относительно чего? Не совсем понял. Временная метка у нас только одна — номер тика симуляции.
  3. Нет. В этом случае сервер просто отбрасывает ввод игрока, т.к. если сервер обработал более поздний тик, чем клиент, значит клиенту надо подстроить свою локальную симуляцию под тики сервера так, чтобы опережать его на необходимое для досылки данных время. Этот процесс хорошо описан в нашей предыдущей статье.

Ниразу не fullstack разработчик. Поясните пожалуйста, а зарплату вы таким как за двоих платите?

Да тема вообще не раскрыта. Собеседники отвечают на четко поставленный вопрос в духе "может да, может нет, зависит". Отсюда и начинается вкусовщина и толпы TDD евангелистов.

А что там кстати с vivaldi стало? Заглох?

Отличная идея! Вы молодцы, ребят, так держать. Надеюсь, когда заработаете много денег, то сделаете какую-то более лояльную программу для небольших разработчиков.

Сексизм — это параноидально во всём видеть сексизм.

У меня такое чувство, что VS выпускается каждый год, чтобы в очередной раз прорекламировать TFS, которым, безусловно, все пользуются.

Спасибо, очень интересная статья! Желаю вам финансовых успехов! Небольшой вопрос не по теме: а подписку на тулзу не продаёте? Ведь сами же говорили, что проверять проект надо регулярно.

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

Интересно почитать про расширяемость. Можно ли приделать оплату в стороннем магазине? Например в webgl версии.

А можно поинтересоваться ссылочками на код, который вы читаете? Я тоже очень хочу, но утонул в тонне нечитаемых малопонятных модулей на гитхабе. Хочется взять проект и читать его вместо недельного изучения подводных камней устройства системы сборки.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity