Проблема с ChatGPT в том, что она не появилась по мановению волшебной палочки. Просто это была узкая ниша, и пока не появились действительно впечатляющие вещи, никто о ней не слышал. Чатботы были и активно развивались и в 90-х и в 00-х, конкурсы проводились. Результаты были не очень. Компьютерное зрение тоже развивалось, сверточные сети повявились в конце 80-х, Open CV появился в 2006, там целый сет инструментария постоянно развивался. Настоящей тихой революцией стало появление архитектуры трансформеров в 17-м, но этого никто не заметил, хотя это сильно бустануло развитие распознавания голоса и т.д.
Просто мы видим взрыв и кажется, что ничего сопоставимой энергии не было, хотя тысячи людей копали там в разных направлениях.
Простите, опечатка Речь о ECS. То есть вот этот сценарий факторио с кучей перекладываемых ресурсов, конвейеров и прочие клеточные автоматы - это как раз подходящая для распараллеливания и строгой организации задача.
Спасибо за статью, не то чтобы узнал нечто новое, но обзорно она очень неплоха.
По поводу геймплейного кода и многопоточности могу добавить, что помимо усложнения кода многопоточность не очень оправдана с точки зрения производительности.
Все же производительность важна коду, выполняющемуся часто, а геймплейный код хоть и комплексный, но либо не очень высоко нагруженный, либо собран в некоторых местах (большая часть кода выполняется когда переключаются экраны и жмутся кнопки)
К примеру в шутере с логической точки зрения происходит не так много - несколько десятков персонажей-точек, тысячи пулек.
При этом рендер кустов, анимации и частицы отбирают то же процессорное время, столкновения пулек считает физика - это уже оптимизированные компоненты движка, распаралелленные и т.д.
В итоге для оптимизации полезнее не делать игровой код многопоточным, а посмотреть сколько жрут кусты.
Конечно есть и исключения, скажем игры типа факторио. Тут может помочь ecd. Последний кстати написан без ecs на плюсах и просто имеет хорошую структуру и оптимизацию для объектов
Спасибо, отличная статья. Я не только имел похожие мысли, но даже держу прототип похожей статьи в черновиках. Может когда допишу.
Единственное, с чем Я бы не согласился, это с тем, что среда определяет архитектуру приложения. Хотя размышляя сейчас, Я прихожу к выводу, что и так сказать можно, это в любом случае строительные блоки архитектуры. Так же и "архитектурные паттерны" ООП действительно являются архитектурными, просто это определенный разрез архитектуры.
Я бы привел такой пример: Архитектура приложения подобна архитектуре здания - Среда подобна материалам и базовым деталям. Для разных задач подходят разные среды. - ООП и архитектурные паттерны походят на типичные архитектурные решения - двери и окна, размер комнат, организацию коридоров и залов. Здесь же есть типичные паттерны - многоквартирные дома строятся от лифтовых шахт и подъездов, а больницы, к примеру, содержат коридоры и много кабинетов. - Высокоуровневая архитектура же скорее относится к организации здания в целом в зависимости от цели - больница это или завод.
Отсюда растут большие проблемы с дискуссиями про ООП и паттерны. Бесполезно говорить в терминах "давайте построим здание в паттерне один коридор и много мелких кабинетов" или "давайте построим кирпичный дом", но именно так выглядят беседы про паттерны.
Архитектура проекта - это высокоуровневая организация, идущая прежде всего от доменной области. Скажем больница - это палаты под Х пациентов, Y операционных, рентгенологическое отделение, административные помещения, и приемное отделение с Z кабинетами врачей. Обязательно наличие грузового лифта.
В случае вашего онлайн магазина архитектура это не MVP, а клиенты, товары, каталоги, модуль обработки платежей и прочее, а так же связи между ними. MVP может использоваться, но это лишь примечание, что "в нашей больнице используется централизованная система кондиционирования".
В этом смысле иногда критически важным становится технические ограничения. Скажем металлургический завод не построить нормально из жилого дома, он строится вокруг главной функции - нужно большое специальное помещение под доменные печи. Так же и сетевое приложение фундаментально содержит технические ограничения из-за работы по сети и клиент-серверную архитектуру.
Нет смысла обсуждать, должен ли быть завод кирпичным или бетонным вне контекста от этих деталей. Паттерны в этом смысле не бесполезны, просто нужно помнить про их контекст и ограничения.
К сожалению, остальные пункты из этого списка все еще актуальны - государство занято совсем другими проблемами и их тщательной поддержкой. Как слова, так и действия не направлены на рациональные решения, никто не ставит целью, к примеру, обеспечить электронную промышленность немного устаревшими, но массовыми и дешевыми компонентами или заниматься специализированными чипами фаблесс. Отдельный вопрос, что внешние отношения неплохо так подкошены и с фаблессом большие проблемы.
Безусловно что-то жить будет и может даже позже, в более благоприятных условиях прорастет. Но я всеж скептичен.
Что речь идет про поступательно развивающееся и востребованное производство гражданской электроники и широкого номинала продукции.
Что в текущих условиях нет ни действий, направленных на это, ни условий. Более того, все факторы, вся политика, вся логика текущих действий властей показывают, что это не изменится.
Конечно же в России выпускают какие то чипы, есть военка (но не вся), есть Зеленоград, есть байкал, есть даже те, кто по серьезному пытается в электронику, просто условия для этого токсичные. Получается вопреки. Как можно догнать и перегнать, если в самой концепции государственного управления транслируются мертвые парадигмы - импортозамещение (которое не очень совместимо с ростом), авторкия (которая вообще не про современные государства), госкорпорации (с неэффективным государственным управлением), неуважение к частной собственности (прощай малый бизнес и инвесторы, риски слишком высоки) и к труду (коллапс рынка труда, кончаются низкооплачиваемые высококвалифицированные специалисты)?
В тех странах, где что-то есть, это целая инфраструктура решений и бизнесов, это специальные условия государства, коллосальные вложения в НТР и университеты. Никакие государства не делают это в одиночку, это широкие кооперации от Европы до Азии. Чтобы догнать Тайвань, США и Корею, Китай вкладывает колоссальные деньги, и то получается слабо, хотя он и не закрыт, и более развит промышленно и выпускает много электроники.
Чтобы начать догонять, действия вообще не должны озвучиваться так, как об этом говорят, это не должно быть "все свое", наоборот, это должен быть поиск ниш, встраивание в цепочки, локализация производств, поиск каких то незанятых областей, специализированных решений, которые слабее покрыты и т.д. Долго в них инвестировать и создавать условия, не сажая всех участников за первый блин. Тогда через пяток лет может быть в этом питательном бульоне появится что-то приличное.
В комплексности разработки. ECS предоставляет преимущества, типа высокой производительности и явного состояния, но они достаются не бесплатно. ECS производительнее по умолчанию только при правильной ECS like организации: - Мелкие компоненты для батчей - Использование пулов сообщений вместо колбеков (это буквально одна из важнейших частей супер-производительности) - Фрагментация логики - вместо условного файла игровой сущности у вас десяток систем, гораздо сложнее понять логику, как ваш объект будет себя вести. - Для сложных вещей очень натуральна организация деревьев (отряд - солдат - оружие - пулька), в ООП можно организовать вложенность по ссылкам, но в плоской структуре нужна схема индексации, объекты должны собираться по индексам сущностей, это усложняет код. - Использование индексов сущностей для пункта выше и подобных подобно использованием сырых указателей - нет проверки типов, можно запихнуть неправильную сущность в неправильный слот, постоянно нужно проверять, есть ли у сущности некоторый компонент, это приводит к сложным ошибкам в рантайме, усложняет код и дебаг. - Так же требователен к архитектуре, но не имеет средств для ее решения. Людям кажется, что если структура плоская, то можно лепить все поверх и меньше рефакторинга. Я даже слышал шутку "Я использую ECS, теперь в моем приложении есть архитектура". Это не так, ты точно так же утопаешь в сложности решения и нужно иногда реорганизовывать свой код (а это сложнее, см пункты выше)
Это если кратко. Иными словами, фраза "производительность по умолчанию за бесплатно" - это если не вранье, то со звездочкой. Ты по чуть платишь буквально за каждый шаг и легко можешь лишиться преимуществ.
Важно понимать, что производительность в играх - это не совсем проблема того кода, который пишут прикладные программисты игр. Они пишут в основном организационную, интерфейсную логику, это очень важный, но не особо критичный к производительности код.
Производительность важна для массовых объектов, рендеринга, комплексных систем типа физики, которые в движках обычно написаны и неплохо оптимизированы. То есть с точки зрения производительности нужно не думать о коде юнитов, а следить за тем, сколько кустов на сцене расставляют художники, насколько жирные материалы и системы частиц используют и т.д.
Зато код довольно критичный к организации, простоте работы дизайнеров, правильным форматам данных конфигураций и т.д. ООП имеет в этом неплохой задел. И стандартные компоненты юнити хороши именно этим - простотой концепции и организации (по факту это agent based OOP в чистом виде)
Соответственно большинству игр действительно важно следить за полигонажем кустов, а игровой код оптимизировать по требованию и организовывать согласно реальным проблемам (удобству дизайнеров и программистов), а не выдуманным.
Где ECS реально может дать эффект, так это там, где оба его свойства (скорость и стейт) востребованы. К примеру сложные сетевые игры, типа стратегий, некоторые узкоспециализированные типы игр, симуляции. Люди, которым реально нужно такое, либо новички, которые учатся и набьют миллион ошибок, вероятно не доделав проект, либо профессионалы, которые не хуже меня знают, что им нужно использовать.
Это редактор, просто что же вы хотите от сделанного на коленке за 6 дней тула - UX не к черту. Можно создавать фигуры кнопкой A (сверху) Список фигур снизу Галочки не логичные Все фигуры - это подмножества сглаженных кубов (можно интерполировать от шара к кубу через капсулы)
Но за неделю действительно хороший результат, плюс тут важно то, что принцип действительно интересный
В результате обсуждений мы пришли к выводу, что корректнее Гиперкеж - это скорее бизнес-модель, а не тип игр. Простые игры существовали и раньше, миниигры и одностраничные игры тоже существуют отдельно от этого феномена и гиперказуалками не называются.
Суть тут скорее в абьюзе поисковых систем и рекламной монетизации, то есть дело не столько в играх, сколько в модели распространения.
Так как ресурс внимания конечен и уже плотно забит существующими казуалками, этот ресурс потихоньку истощается и гиперказуалки становится выпускать все менее и менее выгодно, либо возможности консолидируются у очень крупных издателей, которые могут обеспечить траффик и передачу пользователей с одних проектов на другие.
Видимо в будущем все прийдет к сложным гибридам казуальных игр, которые используют как бизнес приемы, так и механики безбарьерного входа в игру от гиперказуалок. Но наверное в этом смысле миниигры, играбельные рекламные креативы и маркетинговые игры не стоит относить к этой категории.
То что вы предложили, выглядит довольно интересно, своего рода идеологический esc без ecs - плоская структура данных, разделение данных и функций по их обработке, вторая структура индексации (ключи) поверх основной (ссылки в ОП).
Я часто критикую ecs, и во многом ее минусы переносятся и на вашу архитектуру, но, должен признать, у ECS есть несколько плюсов - явный Стейт (который легко сохранять и синхронизировать по сети, к примеру) и нацеленность на производительность за счёт эффективного использования Кеша процессора через организацию данных. Последнее и создаёт большую часть особенностей работы с ecs и боли.
Ваш подход призван решить эти проблемы удобства, но убивает основное преимущество - производительность. Статичные функции в burst не решат проблему, если каждое обращение к стейту это запрос в словарь за сложным объектом, его анбоксинг и приведение (а компилятор добавляет там проверки). Это буквально противоположная сути ecs действие: ecs пытается исправить то, что ООП объекты расположены в памяти случайно, увеличивая время доступа к свойствам. ECS организует структуры в ленты массивов, которые гарантированно попадут в кеш. Ваш подход добавляет ещё слой RAM запросов.
В то же время меня это слабо беспокоит, потому что за редкими исключениями производительность не является основной проблемой среднего уровня игр на этом уровне.
По моему мнению гораздо большая проблема - это организация.
На словах плоская структура объектов и супер позднее связывание переменных может звучать хорошо, это то, что нравится людям в ECS - можно обратиться к любому свойству из любой части. Попытка организации кода в ООП стиле приведет к проблемам зависимостей, дырявым абстракциям, сложностям достать вот эту внутреннюю деталь юнита вот в этот эффект. Для взаимодействия нужно собирать объекты в разные списки, вводить промежуточные сущности и т.д. плюс есть всякие Solid, паттерны и рекомендации, которым нужно следовать.
Тут есть ощущение что все сложно там и все просто тут.
На самом деле Разработчиков не интересуют ни объекты, ни функции в чистом виде, его интересуют абстрактные сущности, например, как ваш юнит наносит урон вражескому. Задача - добавить новый тип урона. Какая организация кода быстрее обеспечит это (не во вред другим функциям) - такая и лучше.
Проблема в том, что если ООП может описывать это плохо, оно имеет очень много инструментов для этого, но в вашем подходе понять как работает эта фича из конца в конец крайне тяжело.
Так как последовательность операций конфигурируеиая, может даже не хватить просто кода.
Чтобы восстановить работу этой сущности нужно:
Найти Стейт
Найти все связанные поведения
Найти все связанные стейты, которые могут меняться помимо основного
Посмотреть варианты конфигураций порядка повелений
Создать у себя в голове ментальную модель того, как это работает, разбросанную по десятку файлов кода и конфигураций
Надеяться, что нет мало заметного сайд эффекта и никто не изменит порядок операций
На самом деле ООП даже с нарушенными паттернами может быть проще по организации, чем ваш подход. Можно использовать анемичные объекты (без поведения) и выносить поведение в некие системы или процессоры. Есть паттерн такой - DCI, для представления процесса как объекта (помогает в ответах на такие вопросы)
Второй момент - абстрактные переиспользуемые типы данных и плоская структура.
Опять же, выглядит неплохо, но есть и минусы. Дело в том, что DRY нужно применять с осторожностью, иногда объекты выглядят одинаково и имеют одинаковые поля, но они - разные. Это быстро выясняется, когда появляются новые неиспользуемые поля, специальные флаги, делающие функции не универсальными и т.д. Момент можно пропустить и потом получить печальные god-обьекты, которые являются сложными конфигурируемыми мутантами со всем поведением разом.
Аналогично с плоской структурой - это достоинство, когда ты хочешь через голову владельца армии посчитать патроны в карабине первого солдата. Но в остальном просто необходимо организовать армию так, что солдаты знают командира, карабин лежит в рюкзаке солдата и заряжен патронами. С плоской структурой нужно вручную следить за этими связями, нельзя использовать проверку на null для снаряжённого карабина. Вообще можно снарядить кабана в слот карабина и заметить фейл только на проде. Нет инструментов и паттернов для организации, как будто работаешь с void* ссылками в си и руками разыменуешь данные.
Третий момент - реактивные поля.
Идея звучит неплохо, но может порождать ад колбеков: так как порядок колбеков обычно не определен и объекты подписываются в случайном порядке, может получиться ситуация, когда флоу работает по разному а зависимости от порядка подписок. Это создаёт сложные баги и сложный для понимания код, потому что нельзя отделить те компоненты, которые управляют потоком, от тех, которые просто обновляют интерфейс.
Так как глобальные подписки очень удобны, моя рекомендация - не смешивать и делать либо множественных подписчиков для визуальных эффектов, но без flow, либо один контроллер через 1 интерфейс или колбек - только для контроля flow.
Итак, резюмируя:
ECS с удобствами, но без преимуществ ecs
Плохая производительность
Бойлер Плейт код (частично решается кодогенерацией, но все равно, get entity.getComponent на каждый чих)
Боль с пониманием кода из за конфигурируемого порядка операций и супер декомпозиции
Ад зависимостей
Сложности с организацией кода
Есть и плюсы:
Явный плоский Стейт, удобно хранить и передавать (Этого можно добиться и другими инструментами)
Не так больно, как ECS
С тестированием проще, это правда
В общем готов обсудить детали, тема на самом деле интересная. Простите за форматирование, пишу с телефона, не мог молчать)
Согласен в целом со статьей. В моей области (геймдев) есть много попыток использовать визуальное программирование, самое известное наверное Unreal Blueprints - визуальный язык для Unreal engine. Но все это считается несерьезным по целому ряду причин. Я думаю самая важная - быстро растущая комплексность делает эти диаграммы совершенно нечитаемыми паутинами, а средств организации кода, подобных модулям не придумали. Точнее что-то придумали, но использовать сложно, что противоречит идее "легкого входа". В итоге классический код становится хорошим компромиссным решением между сложностью написания, чтения и распознавания взаимосвязей.
Но есть много специализированных областей, в которых это может быть оправданно: - Редакторы шейдеров. Их можно писать кодом, но в визуальном программировании можно получить визуализацию промежуточных результатов, что обеспечивает глубокое понимание и легкую отладку того, что ты делаешь - Редакторы анимаций (по сути машины состояний) - аналогично, даже большие деревья все еще доступны для понимания, все узлы более менее однообразны. - Часто делают редакторы квестов/диалогов в виде деревьев. Тут нужно упомянуть, что хотя это и распространенное решение, так же часто используются и DSL, где это описывается обычным текстом. Например многие чатботы содержат деревья с визуальным программированием для начинающих, но более продвинутые версии все равно описываются через DSL - Я делал даже небольшой ЯП для геймдизайнеров на объектах, хотя по структуре он был ближе к scratch - скорее там были последовательности команд списками, нежели деревья или визуальное программирование. На самом деле основной плюс такого языка был в том, что не нужно было знать синтаксис, только основные принципы. Команды и переменные выбирались из списка.
В общем потенциал велик, но на пути использования визуального программирования есть серьезные проблемы, которое даже классическое программирование не научилось решать. И рано или поздно это упирается в самую главную проблему обычного программирования - войну со сложностью. И если для больших систем это научились худо-бедно решать, то с визуальным программированием беда.
По поводу мобилок - немного надеюсь на эпиков и демонополизацию рынка сторов. Если (когда) они выпустят свой стор на эппл и дублер на андроид (собственно стор у них там уже есть, просто там пока в основном фортнайт), это может изменить ситуацию. Появится точка входа с другими характеристиками и возможно другим уровнем качества по умолчанию. Apple Arcade имела потенциал, но как то сдулась.
По поводу отечественной разработки. Мне кажется перспективы все еще плохие. Да, восстановительный рост наблюдается, но это рост обычной индустрии. В ней ты по прежнему конкурируешь за деньги всего мира с последней CoD. И игру выпускать нужно прежде всего на европейский регион и США (а русский язык - это приятный бонус), это все еще правильно, потому что там - деньги, то, что и является ресурсом для бизнеса. Выпускать игру только на русском конечно возможно, просто это радикально меньший объем потенциального рынка без каких то специальных преимуществ. Ваша дешевая игра про бабу Ягу все еще конкурирует с CoD (только теперь пиратским). Конечно есть и бенефициары этой истории - новые платформы и игры с поддержкой от государства. Для первых появилось место, которое видимо займут яндекс-игры и ВК-плей. Вторые являются рисковой и нестабильной бизнес стратегией, потому что государство может и по голове настучать по результатам, и требования выкатить специфические. В принципе если по профилю подходит, можно пользоваться, хотя есть подозрение, что места будут заняты специальными людьми, специализирующимися не на играх, но на гос заказах.
В общем важно тут то, что видимо лучшая стратегия - это уход в серую зону. Ведь те же студии мейла или инди никуда не делись, так же работают в том числе на Россию. Соответсвенно не афишировать в России, что ты работаешь на мир, не афишировать в мире, что ты из России. Ну а какой рассвет получится с играми типа Смуты - нужно посмотреть. Скепсис конечно как и по поводу других гос инициатив.
О том и речь, что во первых, в природе они ещё и как болеют (но не сильно, потому что просто умрут), а во вторых в зоопарках живут дольше, поэтому мы и можем увидеть старого и больного медведя.
В дикой природе он бы не был молодым и красивым один фиг
Вот поэтому эта статья и ваши праведные возмущения в комментариях и выглядят как из страны розовых поней.
Оснований нет? Серьезно? Вы последние 20 лет на Луне жили? Все уже блокируют, методично, лицокнига у нас теперь террористическая, половина независимых журналистов, научные журналы, впн, покорежило кучу инфраструктуры амазона в попытках залочить телеграм. А уж по поводу импортазамещения - колоссальное бабло выделено, свободная энциклопедия у нас своя, поисковик - свой (что особо иронично при живом и работающем яндексе), самолет - свой, движки - свои, процессоры - свои, станция на луне уже в 2018 была достроена!
Нет конца списку проектов, на которые было выделено бешеное количество бабла и итог оказался пшиком, и ни с кого не спросили, и ничем не закончилось. Зато пафоса при их объявлении было как 1.5 презентации эппл.
Если прямо сейчас все эти господсосы обернуться фениксом и начнут клепать годноту одну за другим (не обернутся), еще лет 10 потребуется чтобы хоть какую то репутацию приобрести.
Ну, было бы это целью
Проблема с ChatGPT в том, что она не появилась по мановению волшебной палочки.
Просто это была узкая ниша, и пока не появились действительно впечатляющие вещи, никто о ней не слышал.
Чатботы были и активно развивались и в 90-х и в 00-х, конкурсы проводились. Результаты были не очень.
Компьютерное зрение тоже развивалось, сверточные сети повявились в конце 80-х, Open CV появился в 2006, там целый сет инструментария постоянно развивался.
Настоящей тихой революцией стало появление архитектуры трансформеров в 17-м, но этого никто не заметил, хотя это сильно бустануло развитие распознавания голоса и т.д.
Просто мы видим взрыв и кажется, что ничего сопоставимой энергии не было, хотя тысячи людей копали там в разных направлениях.
Простите, опечатка
Речь о ECS.
То есть вот этот сценарий факторио с кучей перекладываемых ресурсов, конвейеров и прочие клеточные автоматы - это как раз подходящая для распараллеливания и строгой организации задача.
.
Спасибо за статью, не то чтобы узнал нечто новое, но обзорно она очень неплоха.
По поводу геймплейного кода и многопоточности могу добавить, что помимо усложнения кода многопоточность не очень оправдана с точки зрения производительности.
Все же производительность важна коду, выполняющемуся часто, а геймплейный код хоть и комплексный, но либо не очень высоко нагруженный, либо собран в некоторых местах (большая часть кода выполняется когда переключаются экраны и жмутся кнопки)
К примеру в шутере с логической точки зрения происходит не так много - несколько десятков персонажей-точек, тысячи пулек.
При этом рендер кустов, анимации и частицы отбирают то же процессорное время, столкновения пулек считает физика - это уже оптимизированные компоненты движка, распаралелленные и т.д.
В итоге для оптимизации полезнее не делать игровой код многопоточным, а посмотреть сколько жрут кусты.
Конечно есть и исключения, скажем игры типа факторио. Тут может помочь ecd. Последний кстати написан без ecs на плюсах и просто имеет хорошую структуру и оптимизацию для объектов
А главное, какой же он тогда хороший менеджер?
Неплохой пример.
В каком то смысле и корабль, и буровая платформа и космическая станция - специализированные строения. Там люди так то живут.
И разница в функциях и требованиях делает их очень разными
Спасибо, отличная статья.
Я не только имел похожие мысли, но даже держу прототип похожей статьи в черновиках. Может когда допишу.
Единственное, с чем Я бы не согласился, это с тем, что среда определяет архитектуру приложения. Хотя размышляя сейчас, Я прихожу к выводу, что и так сказать можно, это в любом случае строительные блоки архитектуры.
Так же и "архитектурные паттерны" ООП действительно являются архитектурными, просто это определенный разрез архитектуры.
Я бы привел такой пример:
Архитектура приложения подобна архитектуре здания
- Среда подобна материалам и базовым деталям. Для разных задач подходят разные среды.
- ООП и архитектурные паттерны походят на типичные архитектурные решения - двери и окна, размер комнат, организацию коридоров и залов. Здесь же есть типичные паттерны - многоквартирные дома строятся от лифтовых шахт и подъездов, а больницы, к примеру, содержат коридоры и много кабинетов.
- Высокоуровневая архитектура же скорее относится к организации здания в целом в зависимости от цели - больница это или завод.
Отсюда растут большие проблемы с дискуссиями про ООП и паттерны.
Бесполезно говорить в терминах "давайте построим здание в паттерне один коридор и много мелких кабинетов" или "давайте построим кирпичный дом", но именно так выглядят беседы про паттерны.
Архитектура проекта - это высокоуровневая организация, идущая прежде всего от доменной области.
Скажем больница - это палаты под Х пациентов, Y операционных, рентгенологическое отделение, административные помещения, и приемное отделение с Z кабинетами врачей. Обязательно наличие грузового лифта.
В случае вашего онлайн магазина архитектура это не MVP, а клиенты, товары, каталоги, модуль обработки платежей и прочее, а так же связи между ними. MVP может использоваться, но это лишь примечание, что "в нашей больнице используется централизованная система кондиционирования".
В этом смысле иногда критически важным становится технические ограничения.
Скажем металлургический завод не построить нормально из жилого дома, он строится вокруг главной функции - нужно большое специальное помещение под доменные печи.
Так же и сетевое приложение фундаментально содержит технические ограничения из-за работы по сети и клиент-серверную архитектуру.
Нет смысла обсуждать, должен ли быть завод кирпичным или бетонным вне контекста от этих деталей.
Паттерны в этом смысле не бесполезны, просто нужно помнить про их контекст и ограничения.
Вы - молодец.
К сожалению, остальные пункты из этого списка все еще актуальны - государство занято совсем другими проблемами и их тщательной поддержкой. Как слова, так и действия не направлены на рациональные решения, никто не ставит целью, к примеру, обеспечить электронную промышленность немного устаревшими, но массовыми и дешевыми компонентами или заниматься специализированными чипами фаблесс. Отдельный вопрос, что внешние отношения неплохо так подкошены и с фаблессом большие проблемы.
Безусловно что-то жить будет и может даже позже, в более благоприятных условиях прорастет. Но я всеж скептичен.
Я думаю что имелось в виду все же другое.
Что речь идет про поступательно развивающееся и востребованное производство гражданской электроники и широкого номинала продукции.
Что в текущих условиях нет ни действий, направленных на это, ни условий.
Более того, все факторы, вся политика, вся логика текущих действий властей показывают, что это не изменится.
Конечно же в России выпускают какие то чипы, есть военка (но не вся), есть Зеленоград, есть байкал, есть даже те, кто по серьезному пытается в электронику, просто условия для этого токсичные.
Получается вопреки.
Как можно догнать и перегнать, если в самой концепции государственного управления транслируются мертвые парадигмы - импортозамещение (которое не очень совместимо с ростом), авторкия (которая вообще не про современные государства), госкорпорации (с неэффективным государственным управлением), неуважение к частной собственности (прощай малый бизнес и инвесторы, риски слишком высоки) и к труду (коллапс рынка труда, кончаются низкооплачиваемые высококвалифицированные специалисты)?
В тех странах, где что-то есть, это целая инфраструктура решений и бизнесов, это специальные условия государства, коллосальные вложения в НТР и университеты.
Никакие государства не делают это в одиночку, это широкие кооперации от Европы до Азии.
Чтобы догнать Тайвань, США и Корею, Китай вкладывает колоссальные деньги, и то получается слабо, хотя он и не закрыт, и более развит промышленно и выпускает много электроники.
Чтобы начать догонять, действия вообще не должны озвучиваться так, как об этом говорят, это не должно быть "все свое", наоборот, это должен быть поиск ниш, встраивание в цепочки, локализация производств, поиск каких то незанятых областей, специализированных решений, которые слабее покрыты и т.д. Долго в них инвестировать и создавать условия, не сажая всех участников за первый блин. Тогда через пяток лет может быть в этом питательном бульоне появится что-то приличное.
В комплексности разработки.
ECS предоставляет преимущества, типа высокой производительности и явного состояния, но они достаются не бесплатно.
ECS производительнее по умолчанию только при правильной ECS like организации:
- Мелкие компоненты для батчей
- Использование пулов сообщений вместо колбеков (это буквально одна из важнейших частей супер-производительности)
- Фрагментация логики - вместо условного файла игровой сущности у вас десяток систем, гораздо сложнее понять логику, как ваш объект будет себя вести.
- Для сложных вещей очень натуральна организация деревьев (отряд - солдат - оружие - пулька), в ООП можно организовать вложенность по ссылкам, но в плоской структуре нужна схема индексации, объекты должны собираться по индексам сущностей, это усложняет код.
- Использование индексов сущностей для пункта выше и подобных подобно использованием сырых указателей - нет проверки типов, можно запихнуть неправильную сущность в неправильный слот, постоянно нужно проверять, есть ли у сущности некоторый компонент, это приводит к сложным ошибкам в рантайме, усложняет код и дебаг.
- Так же требователен к архитектуре, но не имеет средств для ее решения. Людям кажется, что если структура плоская, то можно лепить все поверх и меньше рефакторинга. Я даже слышал шутку "Я использую ECS, теперь в моем приложении есть архитектура". Это не так, ты точно так же утопаешь в сложности решения и нужно иногда реорганизовывать свой код (а это сложнее, см пункты выше)
Это если кратко.
Иными словами, фраза "производительность по умолчанию за бесплатно" - это если не вранье, то со звездочкой.
Ты по чуть платишь буквально за каждый шаг и легко можешь лишиться преимуществ.
Важно понимать, что производительность в играх - это не совсем проблема того кода, который пишут прикладные программисты игр.
Они пишут в основном организационную, интерфейсную логику, это очень важный, но не особо критичный к производительности код.
Производительность важна для массовых объектов, рендеринга, комплексных систем типа физики, которые в движках обычно написаны и неплохо оптимизированы.
То есть с точки зрения производительности нужно не думать о коде юнитов, а следить за тем, сколько кустов на сцене расставляют художники, насколько жирные материалы и системы частиц используют и т.д.
Зато код довольно критичный к организации, простоте работы дизайнеров, правильным форматам данных конфигураций и т.д. ООП имеет в этом неплохой задел. И стандартные компоненты юнити хороши именно этим - простотой концепции и организации (по факту это agent based OOP в чистом виде)
Соответственно большинству игр действительно важно следить за полигонажем кустов, а игровой код оптимизировать по требованию и организовывать согласно реальным проблемам (удобству дизайнеров и программистов), а не выдуманным.
Где ECS реально может дать эффект, так это там, где оба его свойства (скорость и стейт) востребованы. К примеру сложные сетевые игры, типа стратегий, некоторые узкоспециализированные типы игр, симуляции.
Люди, которым реально нужно такое, либо новички, которые учатся и набьют миллион ошибок, вероятно не доделав проект, либо профессионалы, которые не хуже меня знают, что им нужно использовать.
Это редактор, просто что же вы хотите от сделанного на коленке за 6 дней тула - UX не к черту.
Можно создавать фигуры кнопкой A (сверху)
Список фигур снизу
Галочки не логичные
Все фигуры - это подмножества сглаженных кубов (можно интерполировать от шара к кубу через капсулы)
Но за неделю действительно хороший результат, плюс тут важно то, что принцип действительно интересный
Ну вы же вот не профессиональный пользователь, откуда вам знать?
В результате обсуждений мы пришли к выводу, что корректнее Гиперкеж - это скорее бизнес-модель, а не тип игр.
Простые игры существовали и раньше, миниигры и одностраничные игры тоже существуют отдельно от этого феномена и гиперказуалками не называются.
Суть тут скорее в абьюзе поисковых систем и рекламной монетизации, то есть дело не столько в играх, сколько в модели распространения.
Так как ресурс внимания конечен и уже плотно забит существующими казуалками, этот ресурс потихоньку истощается и гиперказуалки становится выпускать все менее и менее выгодно, либо возможности консолидируются у очень крупных издателей, которые могут обеспечить траффик и передачу пользователей с одних проектов на другие.
Видимо в будущем все прийдет к сложным гибридам казуальных игр, которые используют как бизнес приемы, так и механики безбарьерного входа в игру от гиперказуалок.
Но наверное в этом смысле миниигры, играбельные рекламные креативы и маркетинговые игры не стоит относить к этой категории.
Ох, пошла моя любимая тема. Жара, так сказать.
Заранее прошу прощения.
Итак приступим:
То что вы предложили, выглядит довольно интересно, своего рода идеологический esc без ecs - плоская структура данных, разделение данных и функций по их обработке, вторая структура индексации (ключи) поверх основной (ссылки в ОП).
Я часто критикую ecs, и во многом ее минусы переносятся и на вашу архитектуру, но, должен признать, у ECS есть несколько плюсов - явный Стейт (который легко сохранять и синхронизировать по сети, к примеру) и нацеленность на производительность за счёт эффективного использования Кеша процессора через организацию данных. Последнее и создаёт большую часть особенностей работы с ecs и боли.
Ваш подход призван решить эти проблемы удобства, но убивает основное преимущество - производительность. Статичные функции в burst не решат проблему, если каждое обращение к стейту это запрос в словарь за сложным объектом, его анбоксинг и приведение (а компилятор добавляет там проверки). Это буквально противоположная сути ecs действие: ecs пытается исправить то, что ООП объекты расположены в памяти случайно, увеличивая время доступа к свойствам. ECS организует структуры в ленты массивов, которые гарантированно попадут в кеш. Ваш подход добавляет ещё слой RAM запросов.
В то же время меня это слабо беспокоит, потому что за редкими исключениями производительность не является основной проблемой среднего уровня игр на этом уровне.
По моему мнению гораздо большая проблема - это организация.
На словах плоская структура объектов и супер позднее связывание переменных может звучать хорошо, это то, что нравится людям в ECS - можно обратиться к любому свойству из любой части. Попытка организации кода в ООП стиле приведет к проблемам зависимостей, дырявым абстракциям, сложностям достать вот эту внутреннюю деталь юнита вот в этот эффект. Для взаимодействия нужно собирать объекты в разные списки, вводить промежуточные сущности и т.д. плюс есть всякие Solid, паттерны и рекомендации, которым нужно следовать.
Тут есть ощущение что все сложно там и все просто тут.
На самом деле Разработчиков не интересуют ни объекты, ни функции в чистом виде, его интересуют абстрактные сущности, например, как ваш юнит наносит урон вражескому. Задача - добавить новый тип урона. Какая организация кода быстрее обеспечит это (не во вред другим функциям) - такая и лучше.
Проблема в том, что если ООП может описывать это плохо, оно имеет очень много инструментов для этого, но в вашем подходе понять как работает эта фича из конца в конец крайне тяжело.
Так как последовательность операций конфигурируеиая, может даже не хватить просто кода.
Чтобы восстановить работу этой сущности нужно:
Найти Стейт
Найти все связанные поведения
Найти все связанные стейты, которые могут меняться помимо основного
Посмотреть варианты конфигураций порядка повелений
Создать у себя в голове ментальную модель того, как это работает, разбросанную по десятку файлов кода и конфигураций
Надеяться, что нет мало заметного сайд эффекта и никто не изменит порядок операций
На самом деле ООП даже с нарушенными паттернами может быть проще по организации, чем ваш подход. Можно использовать анемичные объекты (без поведения) и выносить поведение в некие системы или процессоры. Есть паттерн такой - DCI, для представления процесса как объекта (помогает в ответах на такие вопросы)
Второй момент - абстрактные переиспользуемые типы данных и плоская структура.
Опять же, выглядит неплохо, но есть и минусы. Дело в том, что DRY нужно применять с осторожностью, иногда объекты выглядят одинаково и имеют одинаковые поля, но они - разные. Это быстро выясняется, когда появляются новые неиспользуемые поля, специальные флаги, делающие функции не универсальными и т.д. Момент можно пропустить и потом получить печальные god-обьекты, которые являются сложными конфигурируемыми мутантами со всем поведением разом.
Аналогично с плоской структурой - это достоинство, когда ты хочешь через голову владельца армии посчитать патроны в карабине первого солдата. Но в остальном просто необходимо организовать армию так, что солдаты знают командира, карабин лежит в рюкзаке солдата и заряжен патронами. С плоской структурой нужно вручную следить за этими связями, нельзя использовать проверку на null для снаряжённого карабина. Вообще можно снарядить кабана в слот карабина и заметить фейл только на проде. Нет инструментов и паттернов для организации, как будто работаешь с void* ссылками в си и руками разыменуешь данные.
Третий момент - реактивные поля.
Идея звучит неплохо, но может порождать ад колбеков: так как порядок колбеков обычно не определен и объекты подписываются в случайном порядке, может получиться ситуация, когда флоу работает по разному а зависимости от порядка подписок. Это создаёт сложные баги и сложный для понимания код, потому что нельзя отделить те компоненты, которые управляют потоком, от тех, которые просто обновляют интерфейс.
Так как глобальные подписки очень удобны, моя рекомендация - не смешивать и делать либо множественных подписчиков для визуальных эффектов, но без flow, либо один контроллер через 1 интерфейс или колбек - только для контроля flow.
Итак, резюмируя:
ECS с удобствами, но без преимуществ ecs
Плохая производительность
Бойлер Плейт код (частично решается кодогенерацией, но все равно, get entity.getComponent на каждый чих)
Боль с пониманием кода из за конфигурируемого порядка операций и супер декомпозиции
Ад зависимостей
Сложности с организацией кода
Есть и плюсы:
Явный плоский Стейт, удобно хранить и передавать (Этого можно добиться и другими инструментами)
Не так больно, как ECS
С тестированием проще, это правда
В общем готов обсудить детали, тема на самом деле интересная. Простите за форматирование, пишу с телефона, не мог молчать)
Согласен в целом со статьей.
В моей области (геймдев) есть много попыток использовать визуальное программирование, самое известное наверное Unreal Blueprints - визуальный язык для Unreal engine.
Но все это считается несерьезным по целому ряду причин.
Я думаю самая важная - быстро растущая комплексность делает эти диаграммы совершенно нечитаемыми паутинами, а средств организации кода, подобных модулям не придумали. Точнее что-то придумали, но использовать сложно, что противоречит идее "легкого входа". В итоге классический код становится хорошим компромиссным решением между сложностью написания, чтения и распознавания взаимосвязей.
Но есть много специализированных областей, в которых это может быть оправданно:
- Редакторы шейдеров. Их можно писать кодом, но в визуальном программировании можно получить визуализацию промежуточных результатов, что обеспечивает глубокое понимание и легкую отладку того, что ты делаешь
- Редакторы анимаций (по сути машины состояний) - аналогично, даже большие деревья все еще доступны для понимания, все узлы более менее однообразны.
- Часто делают редакторы квестов/диалогов в виде деревьев. Тут нужно упомянуть, что хотя это и распространенное решение, так же часто используются и DSL, где это описывается обычным текстом. Например многие чатботы содержат деревья с визуальным программированием для начинающих, но более продвинутые версии все равно описываются через DSL
- Я делал даже небольшой ЯП для геймдизайнеров на объектах, хотя по структуре он был ближе к scratch - скорее там были последовательности команд списками, нежели деревья или визуальное программирование. На самом деле основной плюс такого языка был в том, что не нужно было знать синтаксис, только основные принципы. Команды и переменные выбирались из списка.
В общем потенциал велик, но на пути использования визуального программирования есть серьезные проблемы, которое даже классическое программирование не научилось решать.
И рано или поздно это упирается в самую главную проблему обычного программирования - войну со сложностью.
И если для больших систем это научились худо-бедно решать, то с визуальным программированием беда.
Меня тоже смутило это место.
Наблюдаемая скорость расширения вроде растет
Статья неплохая и в целом рациональная.
По поводу мобилок - немного надеюсь на эпиков и демонополизацию рынка сторов.
Если (когда) они выпустят свой стор на эппл и дублер на андроид (собственно стор у них там уже есть, просто там пока в основном фортнайт), это может изменить ситуацию. Появится точка входа с другими характеристиками и возможно другим уровнем качества по умолчанию.
Apple Arcade имела потенциал, но как то сдулась.
По поводу отечественной разработки. Мне кажется перспективы все еще плохие.
Да, восстановительный рост наблюдается, но это рост обычной индустрии.
В ней ты по прежнему конкурируешь за деньги всего мира с последней CoD. И игру выпускать нужно прежде всего на европейский регион и США (а русский язык - это приятный бонус), это все еще правильно, потому что там - деньги, то, что и является ресурсом для бизнеса.
Выпускать игру только на русском конечно возможно, просто это радикально меньший объем потенциального рынка без каких то специальных преимуществ. Ваша дешевая игра про бабу Ягу все еще конкурирует с CoD (только теперь пиратским).
Конечно есть и бенефициары этой истории - новые платформы и игры с поддержкой от государства. Для первых появилось место, которое видимо займут яндекс-игры и ВК-плей.
Вторые являются рисковой и нестабильной бизнес стратегией, потому что государство может и по голове настучать по результатам, и требования выкатить специфические. В принципе если по профилю подходит, можно пользоваться, хотя есть подозрение, что места будут заняты специальными людьми, специализирующимися не на играх, но на гос заказах.
В общем важно тут то, что видимо лучшая стратегия - это уход в серую зону. Ведь те же студии мейла или инди никуда не делись, так же работают в том числе на Россию.
Соответсвенно не афишировать в России, что ты работаешь на мир, не афишировать в мире, что ты из России.
Ну а какой рассвет получится с играми типа Смуты - нужно посмотреть. Скепсис конечно как и по поводу других гос инициатив.
О том и речь, что во первых, в природе они ещё и как болеют (но не сильно, потому что просто умрут), а во вторых в зоопарках живут дольше, поэтому мы и можем увидеть старого и больного медведя.
В дикой природе он бы не был молодым и красивым один фиг
Вот поэтому эта статья и ваши праведные возмущения в комментариях и выглядят как из страны розовых поней.
Оснований нет?
Серьезно?
Вы последние 20 лет на Луне жили?
Все уже блокируют, методично, лицокнига у нас теперь террористическая, половина независимых журналистов, научные журналы, впн, покорежило кучу инфраструктуры амазона в попытках залочить телеграм.
А уж по поводу импортазамещения - колоссальное бабло выделено, свободная энциклопедия у нас своя, поисковик - свой (что особо иронично при живом и работающем яндексе), самолет - свой, движки - свои, процессоры - свои, станция на луне уже в 2018 была достроена!
Нет конца списку проектов, на которые было выделено бешеное количество бабла и итог оказался пшиком, и ни с кого не спросили, и ничем не закончилось.
Зато пафоса при их объявлении было как 1.5 презентации эппл.
Если прямо сейчас все эти господсосы обернуться фениксом и начнут клепать годноту одну за другим (не обернутся), еще лет 10 потребуется чтобы хоть какую то репутацию приобрести.