На просторах интернета, и в частности хабра, очень трудно встретить статьи с критикой игрового движка Unity. Я решил это исправить, и приготовил вам текст о переходе на DOTS, насилию над C#, знаменитых UI пакетах, MonoBehaviour, универсальности и о многом другом.
Привет! Представляю вашему вниманию перевод статьи "ECS back and forth — Part 1 — Introduction" автора Michele skypjack Caini.
Часть 1 — Введение.
Когда я в первые узнал про архитектурный шаблон entity component system, я пошёл искать больше информации о нём в интернете. Но, к сожалению, тогда на эту тему не было пролито достаточно света, а ресурсов, где описывались бы разные подходы с их плюсами и минусами, не существовало. Почти каждые статья, пост, комментарии (существенная их доля) были об одной специфичной реализации и только слегка ссылались на другие примеры.
В этом посте я попытаюсь вас ввести в курс дела и открыть для вас несколько вводных моделей, давая некоторые советы для того, чтобы вы могли сделать свою собственную ECS.
Старайтесь не быть одураченным тем, что говорят вокруг. Если вы работаете над AAA проектами на серьёзном уровне, главной причиной почему вы должны использовать такой серьёзный инструмент — это организация кода, а не (только) производительность. Конечно, производительность имеет не последнее значение, но хорошо организованная кодовая база бесценна, и с большинством игр у вас не будет проблем с производительностью, будь они написаны с использованием ОПП парадигмы либо с другой опциональной реализацией компонентного шаблона.
В сущности, компонентно-ориентированное программирование — это крайне мощный инструмент, который позволяет сделать код легко расширяемым и ускорить цикл разработки. Бесспорно, всё это должно быть вашей первостепенной целью.
Конечно, не забываем о производительности. Хотя пока мы находимся в другой лиге, но в следующих статьях и в следующих вводных статьях я дам вам достаточно примеров моделей, по крайней мере некоторые модели будут точно ориентированы на производительность.
В предыдущей статье мой коллега рассказал о том, как мы использовали двумерный физический движок в нашем мобильном мультиплеерном шутере. А теперь я хочу поделиться тем, как мы выкинули всё, что делали до этого, и начали с нуля ― иными словами, как мы перевели нашу игру из 2D-мира в 3D.
Читать полностью »
Всем привет! В этой статье мы расскажем про личный опыт работы с физическими движками для мультиплеерного шутера и главным образом сфокусируемся на взаимодействии физики и ECS: на какие грабли мы наступили в процессе работы, чему научились, почему остановились на конкретных решениях.
Первый прототип объектных хранилищ мир увидел в 1996 году. Через 10 лет Amazon Web Services запустит Amazon S3, и мир начнёт планомерно сходить с ума от плоского адресного пространства. Благодаря работе с метаданными и своей возможности масштабироваться, не проседая под нагрузкой, объектные хранилища быстро стали стандартом для большинства сервисов по хранению данных в облаках, и не только. Другая важная особенность — это хорошая приспособленность для хранения архивов и подобных им редко используемых файлов. Все, кто был связан с хранением данных, ликовали и носили новую технологию на руках.
Но людская молва полнилась слухами, что объектные хранилища — это только про большие облака, а если вам не нужны решения от проклятых капиталистов, то сделать своё будет очень сложно. Про развёртывание своего облака уже написано много, а вот про создание так называемых S3-compatible решений информации маловато.
Поэтому сегодня мы разберёмся, какие есть варианты "Чтобы как у взрослых, а не CEPH и напильник побольше", развернём один из них, а проверять, что всё работает, будем с помощью Veeam Backup & Replication. В нём заявлена поддержка работы с S3-совместимыми хранилищами, и вот это заявление мы будем проверять.
Мотив первый: «Топоры»
Один из самых полезных для любого профессионала принципов «Знай свои инструменты» (или, в одно из вариаций «точи пилу»).
Мы в облаках уже давно, но до поры до времени это были просто монолитные приложения с базами, развернутые на инстансах EC2 — дёшево и сердито.
Но постепенно нам стало тесно в рамках монолита. Взяли курс на распил в хорошем смысле – на модуляризацию, а затем и модные нынче микросервисы. И очень быстро на этой почве «расцветают сто цветов».
Да что там далеко ходить – проект логирования активности, который я сейчас веду, включает в себя:
Работая с таким зоопарком сервисов AWS хочется знать что есть в арсенале и как это что-то лучше использовать.
Читать полностью »
Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!
Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.
Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).
Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!
TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).
Читать полностью »
От ковров перейдем к серьезным вещам. Мы уже рассказали про ECS, какие есть фреймворки для Unity и почему написали свой (со списком можно ознакомиться в конце статьи). А сейчас остановимся на конкретных примерах, как используем ECS в нашем новом мобильном PvP-шутере и как реализуем игровые фичи. Отмечу, что применяем эту архитектуру мы только для симуляции мира на сервере и системы предсказания на клиенте. Визуализация и рендер объектов реализованы с помощью MPV-паттерна — но сегодня не об этом.Читать полностью »
На Pixonic DevGAMM Talks выступал еще наш DTO Антон Григорьев. Мы в компании уже говорили, что работаем над новым PvP-шутером и Антон поделился некоторыми нюансами архитектуры этого проекта. Он рассказал, как построить разработку, чтобы изменения в игровой логике клиента появлялись на сервере автоматически (и наоборот), и можно ли не писать код, но при этом минимизировать трафик. Ниже — запись и расшифровка доклада.
Хочу поделиться механизмами, которые мы используем на сервере для визуальной отладки игровой логики и способами изменения состояний матча в реальном времени.
В предыдущих статьях подробно рассказывали (список сразу под катом) о том, как устроена ECS в нашем новом проекте в разработке и как выбирали готовые решения. Одним из таких решений был Entitas. Он не устроил нас в первую очередь из-за отсутствия хранения истории состояний, но очень понравился тем, что в Unity визуально и наглядно можно посмотреть всю статистику по использованию сущностей, компонентов, систему пулов, производительность каждой системы и т.д.
Это вдохновило нас на создание своих инструментов на игровом сервере, чтобы смотреть, что происходит в матче с игроками, как они играют, как перформит система в целом. На клиенте у нас тоже есть подобные наработки для визуальной отладки игры, но инструменты в клиенте чуть более простые по сравнению с тем, что мы сделали на сервере.
Читать полностью »
