Рубрика «ecs»
Почему я отказался от разработки игр на Rust, часть 1
2024-04-30 в 9:42, admin, рубрики: borrow checker, ecs, Rust, игровые движки
У Unity всё плохо
2021-12-05 в 10:44, admin, рубрики: C#, dots, ecs, unity, unity3d, графомания, Программирование, разработка игр
На просторах интернета, и в частности хабра, очень трудно встретить статьи с критикой игрового движка Unity. Я решил это исправить, и приготовил вам текст о переходе на DOTS, насилию над C#, знаменитых UI пакетах, MonoBehaviour, универсальности и о многом другом.
ECS back and forth
2020-02-29 в 15:27, admin, рубрики: algorithms, architecture design, c++, ecs, game development, game engine, Gamedev, gamedevelopment, pattern, patterns, Алгоритмы, Программирование, разработка игрПривет! Представляю вашему вниманию перевод статьи "ECS back and forth — Part 1 — Introduction" автора Michele skypjack Caini.
ECS back and forth
Часть 1 — Введение.
Когда я в первые узнал про архитектурный шаблон entity component system, я пошёл искать больше информации о нём в интернете. Но, к сожалению, тогда на эту тему не было пролито достаточно света, а ресурсов, где описывались бы разные подходы с их плюсами и минусами, не существовало. Почти каждые статья, пост, комментарии (существенная их доля) были об одной специфичной реализации и только слегка ссылались на другие примеры.
В этом посте я попытаюсь вас ввести в курс дела и открыть для вас несколько вводных моделей, давая некоторые советы для того, чтобы вы могли сделать свою собственную ECS.
Почему я должен использовать ECS?
Старайтесь не быть одураченным тем, что говорят вокруг. Если вы работаете над AAA проектами на серьёзном уровне, главной причиной почему вы должны использовать такой серьёзный инструмент — это организация кода, а не (только) производительность. Конечно, производительность имеет не последнее значение, но хорошо организованная кодовая база бесценна, и с большинством игр у вас не будет проблем с производительностью, будь они написаны с использованием ОПП парадигмы либо с другой опциональной реализацией компонентного шаблона.
В сущности, компонентно-ориентированное программирование — это крайне мощный инструмент, который позволяет сделать код легко расширяемым и ускорить цикл разработки. Бесспорно, всё это должно быть вашей первостепенной целью.
Конечно, не забываем о производительности. Хотя пока мы находимся в другой лиге, но в следующих статьях и в следующих вводных статьях я дам вам достаточно примеров моделей, по крайней мере некоторые модели будут точно ориентированы на производительность.
Физика для мобильного PvP шутера, или как мы из двумерной игру в трёхмерную переделывали
2020-01-24 в 9:09, admin, рубрики: C#, ecs, entity component system, Gamedev, multiplayer, online, unity, Блог компании Pixonic, геймдев, игровая физика, мобильные игры, мультиплеер, проектирование, Проектирование и рефакторинг, разработка игр, разработка мобильных приложений, физический движок, шутер
В предыдущей статье мой коллега рассказал о том, как мы использовали двумерный физический движок в нашем мобильном мультиплеерном шутере. А теперь я хочу поделиться тем, как мы выкинули всё, что делали до этого, и начали с нуля ― иными словами, как мы перевели нашу игру из 2D-мира в 3D.
Читать полностью »
Физика для мобильного PvP шутера и как мы подружили её с ECS
2019-12-25 в 13:55, admin, рубрики: C#, ecs, entity component system, Gamedev, multiplayer, online, unity, Блог компании Pixonic, геймдев, игровая физика, мобильные игры, мультиплеер, проектирование, Проектирование и рефакторинг, разработка игр, разработка мобильных приложений, физический движок, шутерВсем привет! В этой статье мы расскажем про личный опыт работы с физическими движками для мультиплеерного шутера и главным образом сфокусируемся на взаимодействии физики и ECS: на какие грабли мы наступили в процессе работы, чему научились, почему остановились на конкретных решениях.
Объектное хранилище в подсобке, или Как стать самому себе сервис-провайдером
2019-11-12 в 10:20, admin, рубрики: dell, ecs, Veeam, забекапь бекапщик мне бекап, резервное копирование, системное администрирование, СофтПервый прототип объектных хранилищ мир увидел в 1996 году. Через 10 лет Amazon Web Services запустит Amazon S3, и мир начнёт планомерно сходить с ума от плоского адресного пространства. Благодаря работе с метаданными и своей возможности масштабироваться, не проседая под нагрузкой, объектные хранилища быстро стали стандартом для большинства сервисов по хранению данных в облаках, и не только. Другая важная особенность — это хорошая приспособленность для хранения архивов и подобных им редко используемых файлов. Все, кто был связан с хранением данных, ликовали и носили новую технологию на руках.
Но людская молва полнилась слухами, что объектные хранилища — это только про большие облака, а если вам не нужны решения от проклятых капиталистов, то сделать своё будет очень сложно. Про развёртывание своего облака уже написано много, а вот про создание так называемых S3-compatible решений информации маловато.
Поэтому сегодня мы разберёмся, какие есть варианты "Чтобы как у взрослых, а не CEPH и напильник побольше", развернём один из них, а проверять, что всё работает, будем с помощью Veeam Backup & Replication. В нём заявлена поддержка работы с S3-совместимыми хранилищами, и вот это заявление мы будем проверять.
О топорах и капусте
2019-05-24 в 15:57, admin, рубрики: Amazon Web Services, AWS, cloudwatch, EC2, ecs, kinesis firehose, redshift, облачные сервисы, сертификацияРазмышления о том, откуда берется желание сдать сертификацию AWS Solutions Architect Associate.
Мотив первый: «Топоры»
Один из самых полезных для любого профессионала принципов «Знай свои инструменты» (или, в одно из вариаций «точи пилу»).
Мы в облаках уже давно, но до поры до времени это были просто монолитные приложения с базами, развернутые на инстансах EC2 — дёшево и сердито.
Но постепенно нам стало тесно в рамках монолита. Взяли курс на распил в хорошем смысле – на модуляризацию, а затем и модные нынче микросервисы. И очень быстро на этой почве «расцветают сто цветов».
Да что там далеко ходить – проект логирования активности, который я сейчас веду, включает в себя:
- Клиентов в виде разнообразных приложений нашего продукта – от глухих уголков дремучего легаси до ультрамодных микросервисов на .Net Core.
- Очереди Amazon SQS, в которые складываются логи о том, что происходит с клиентами.
- Микросервис на .Net Core, который достает сообщения из очереди и отправляет их в Amazon Kinesis Data Streams (KDS). Имеет также Web API интерфейс и swagger UI как дублирующий канал и для ручного тестирования. Оборачивается в докеровский linux-контейнер и хостится под управлением Amazon ECS. Предусмотрен autoscaling на случай большого потока логов.
- Из KDS данные пожарными шлангами направляются в Amazon Redshift с промежуточными складами в Amazon S3.
- Операционные логи для девелоперов (дебаг-информация, сообщения об ошибках и т.п.) форматируются в приятный глазу JSON и отправляются в Amazon CloudWatch Logs
Работая с таким зоопарком сервисов AWS хочется знать что есть в арсенале и как это что-то лучше использовать.
Читать полностью »
ООП мертво, да здравствует ООП
2019-02-22 в 4:32, admin, рубрики: ecs, entity component system, ood, антипаттерны, ооп, Программирование, Проектирование и рефакторинг, шаблоны проектирования
Источники вдохновения
Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым 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: добавляем в шутер аптечки
2018-12-03 в 9:02, admin, рубрики: ecs, Gamedev, games, pvp, shooter, unity3d, Блог компании Pixonic, Проектирование и рефакторинг, разработка, разработка игр, разработка мобильных приложений
От ковров перейдем к серьезным вещам. Мы уже рассказали про ECS, какие есть фреймворки для Unity и почему написали свой (со списком можно ознакомиться в конце статьи). А сейчас остановимся на конкретных примерах, как используем ECS в нашем новом мобильном PvP-шутере и как реализуем игровые фичи. Отмечу, что применяем эту архитектуру мы только для симуляции мира на сервере и системы предсказания на клиенте. Визуализация и рендер объектов реализованы с помощью MPV-паттерна — но сегодня не об этом.Читать полностью »
Общая игровая логика на клиенте и сервере
2018-11-12 в 10:40, admin, рубрики: ecs, entity component system, unity3d, Блог компании Pixonic, геймдев, игровая логика, игры, код, кодогенерация, конференции, проектирование, Проектирование и рефакторинг, разработка, разработка игр, рефакторингНа Pixonic DevGAMM Talks выступал еще наш DTO Антон Григорьев. Мы в компании уже говорили, что работаем над новым PvP-шутером и Антон поделился некоторыми нюансами архитектуры этого проекта. Он рассказал, как построить разработку, чтобы изменения в игровой логике клиента появлялись на сервере автоматически (и наоборот), и можно ли не писать код, но при этом минимизировать трафик. Ниже — запись и расшифровка доклада.