Мысли в сторону. Честно говоря мне казалось что такое невозможно еще ближайшие годы.

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

Однако, это уже работает. ChatGPT под капотом связывает сущности, и может этим оперировать.

И мне всегда казалось что эта проблема связывания - единственная на пути создания честного ИИ. Который будет мыслить, делать выводы, из выводов делать новые выводы и так далее. Та самая технологическая сингулярность, когда от человека больше не понадобится мыслить

Интересно что будет дальше. Уверен, через год-полтора у каждого в телефоне будет свой "джарвис", поисковые сервисы сделают огромный скачок, голосовые и чат-боты перейдут на новый уровень, персонажи в играх начнут отвечать на твою речь, а не на заготовленные фразы

По сути это будущее уже здесь и сейчас, разработчики уже ищут пути как правильно это применить. Пойду попробую поисковик bing, в который microsoft уже встроил chatGPT. А еще они проинвестировали в OpenAI. Молодцы, вовремя подсуетились

Google тоже радует: https://youtu.be/6DaJVZBXETE

god bless chat gpt

немножно необычного. Квест для внимательных 😉

Поговорим о слоях и сортировке. Казалось бы, 2D графике все просто, но все же в любой игре, над которой я работал, была проблема организации сортировки:
- нужно рисовать персов, чтобы они не пересекались своими частями друг через друга
- нужно сверху рисовать UI, со своей массой слоев. А иногда и нужно рисовать персов в UI
- ребята с Unity еще скажут - "и партиклы надо запихать куда-то!!!11"

В общем, дело тонкое. Как же решать эту проблему? Как правильно, а самое главное удобно и понятно, раскладывать графику по слоям и приоритетам?

Начнем с самого простого способа - рисовать в том же порядке, в каком находятся объекты в дереве сцены. Объекты рисуются друг за другом, в порядке обхода. Для большинства случаев этого, на самом деле, достаточно. Но иногда нужно что-то нарисовать выше или ниже. Классический пример из UI - это попапы. Их удобно располагать в иерархии прямо на объекте, куда они указывают. Но рисоваться он должен как бы поверх всего, чтобы на него не налазили соседние элементы и он излишне не отсекался. Всегда возникают ситуации, когда нужно что-то сделать "повыше" или "пониже". Поэтому просто сортировать в порядке обхода иерархии не получится

Окей, тогда явно будем задавать числовой приоритет, все будем контролировать вручную. Тут, с одной стороны, гибко - все и правда можно задать руками. Но в этом и минус, ведь ВСЕ придется задавать руками. И тут конечно же будут ошибки и так называемая "гонка приоритетов". Это когда две разные сущности конкурируют за превосходство быть верхней, и разные разработчики все больше и больше повышают им приоритет

Да и два одинаковых объекта с одинаковым набором приоритетов будут "проходить друг через друга". Представьте тех же персов, собранных из приоритетов, проходящих друг через друга. Ноги, руки, тело - все будет пересекаться между двумя персами, хотя они должны выглядеть как одно целое. В общем, для большинства кейсов такое не подходит

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

На мой взгляд самая правильная система - это комбинирование всех. В ней есть слои, и первоначально задан их порядок. Один слой ни при каких обстоятельствах не может "залезть" на другой слой. Затем по-дефолту все сортируется в порядке иерархии, тк в большинстве случаев это и нужно. И для отдельных кейсов задается числовой приоритет, который как бы "вытаскивает" объект из иерархии, и сортирует в рамках слоя в зависимости от его приоритета. У дефолтных объектов приоритет 0, таким образом можно что-то сделать ниже, а что-то выше

Однако у такой системы получается серьезный минус - сложность. Все нужно держать в голове, кто от кого наследуется, какой приоритет, слой и тд.

У меня уже давно была идея сделать два режима отображения иерархии в сцене: реальная иерархия и очередь отрисовки. Собственно, почему бы не вывести дерево очередности отрисовки камер, слоев и объектов там? К тому же, через drag'n'drop это очередность можно будет редактировать. Захотел поменять слой - перетащил объект в нужный слой. Захотел чтобы он был в подиерархии другого объекта - просто перетащил. И мгновенно увидел результат, дерево с порядком отрисовки сразу поменялось и ты видишь актуальный результат

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

Окошко еще не финальное, но уже вполне получается проверить концепцию.

Цветом выделены разные батчи, цифра справа - числовой приоритет, если задан. В руте показаны камеры (на скрине не видно), под каждой камерой - список слоев, которые она рендерит. В слое объекты и их дети. Выглядит все просто и понятно. А главное drag'n'drop интуитивен: ты хочешь чтобы объект рисовался в определенном месте - просто перетаскиваешь его туда

Расскажу о демке и о том, над чем сейчас работаю уже в течение последних 3х месяцев

Сейчас я интегрирую о2 в чужой движок.

Для чего это вообще нужно? Допустим, у вас есть проект, работающий на кастомном С++ движке. Проект живой, зарабатывает денег, и выкинуть на помойку истории его нельзя. При этом свое решение уже обросло костылями, оно становится совсем не удобным, и что-то исправть все сложнее и сложнее. При этом перелезть на Unity или другой движок не реально. Нужно переписывать проект с нуля некогда, нужно переучивать команду, да и вообще не факт что с перфомансом все будет в порядке.

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

В этом как раз моя идея, интегрировать о2 в эти движки, добавляя нужный функционал в старые проекты. По-сути это то, чем я занимался в Playrix в команде VSO (это внутренний движок) - мы прокачали старые проекты новыми тулзами, похожими на Unity. В итоге это дало буст разработки на всех проектах в разы, сохраняя старый код и перфоманс в игре

Собственно сейчас я работаю над интеграцией о2 в чужой движок. На самом деле он уже интегрирован и сейчас идет работа над оптимизацией. Оптимизация довольно интересная, как и тот продукт, над которым я работаю. Это - гемблинг, игровые автоматы проще говоря, на стареньком железе с 10-ти летним 32битным ARM, линуксом под капотом и ультра-дерьмовой видеокартой.

Сейчас все на этапе эксперимента, попробовать интегрировать о2 в их движок и добиться приемлемого перфоманса на их железе. Это позволит им делать игры быстрее, верстать графику в редакторе. А скрипты на JS помогут в портировании игр под WEB. В общем, почти мгновенная прокачка тулсета студии за счет внедрения о2

Этап интеграции прошел относительно быстро. Пришлось научить все компилироваться вместе, разрулить зависимости в CMAKE, да и собственно перевести о2 на CMAKE. Поддержать платформенные API под линукс и OpenGLES. Поправить ошибки gcc (скажите мне про кросс-компиляемость С++ ага). Основная работа связана со специфичным железом, компиляцией под него и значительной переделкой рендера.

Видюха там и правда слабая и привередливая. Например, очистка стенсил-буффера, который ты даже не юзаешь, может дать +20 FPS. До сих пор идет поиск всех крупиц, неочевидно съедающих перфоманс. Правильная запись в буффер вершин, сжатие DXT, все что угодно может влиять. Отличный способ прокачать свои знания в графике

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

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

В этом время можно продвигать движок на открытых площадках. Он будет открытый, бесплатный, и проверенный реальными задачами. И если все пойдет крайне удачно, можно монетизировать набранную аудиторию через условно-платные сервисы в виде модулей для движка: система покупок, аналитика и тп. Думаю сейчас серьезный движок для мобильных 2D игр вполне может откусить 10% от рынка: https://www.linkedin.com/pulse/game-engines-market-2023-size-professional-survey/

Так что если интересно пописать двигло - велкам, заняться можно чем хочешь ;)

когда рефакторишь какое-нибудь serious shit

Пару слов о "грандиозном рефакторинге". Его целью была переработка системы слоев в движке. Эта итак большая задача зацепила еще одну большую задачу - переработка ивентов акторов и компонент, по типу OnStart, Awake из юнити.