Всем привет! Хотели похвастаться очередным сложным, но очень важным шагом на пути к возрождению российского геймдева и заодно спросить мнения окружающих (да, мы всегда сначала делаем, потом думаем).

Традиционный подход подразумевает, что разработчик заключает договор с площадкой (Steam, VK Play, Itch и т.д.). Игрок покупает игру, и деньги идут на счёт платформы. После этого в определенные даты происходит выплаты на счета разработчиков за вычетом комиссий. Где-то больше, где-то меньше, где-то по-другому. Но смысл тот же. Этот подход позволяет, во-первых, брать комиссии, во-вторых, легче работать с возвратами и в-третьих, быстрее распознавать отмывание денег и мошенничество.

Мы решили использовать схему маркетплейсов, где каждый разработчик приходит со своим статусом (ООО, ИП, смз). Но приходит он в первую очередь не к нам, а к платёжным агрегаторам типа Юкасса, Робокасса, любая …касса. Одним словом, подключает себе интернет-эквайринг, такое делает любой банк. Банк ему даёт API для подключения, ID магазина, ключи для проведения оплат и всё, действуй.

Где здесь мы? Мы предоставляем бесплатный хостинг для игр. Сама площадка + страница игры + страница разработчика. Всё тоже самое что у itch[.]io. Заодно есть консоль разработчика, в которую добавляется всё больше и больше возможностей. Соответственно, в этой консоли разработчик указывает тот самый идентификатор магазина, суперсекретный ключ и дальше надеется на магию.

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

Опережу (почти) все вопросы и сразу отвечу:

Q: На что вы будете существовать если у вас комиссии 0%?

A: При покупке игры рядом есть еще кнопочка “поддержать платформу”, надеемся, что это сработает

Q: Вы делаете очередного убийцу стима?

A: Нет

Q: Это точно не развод?

A: Точно нет, чесслово

На остальные вопросы обязательно ответим. Так как это не реклама, то прямо указывать название площадки не буду, но подскажу, что наш канал https://t.me/dustore_official

public sealed class ChunkLight
    {
        private readonly Queue<Vector3Int> _lightsQueue = new();
        private readonly int[,,] _blockIds;
        private readonly byte[,,] _blockLights;

        public void SetLamp(Vector3Int position, byte lightForce)
        {
            AddLightForNeighbors(position, lightForce);
            while(_lightsQueue.Count > 0)
            {
                position = _lightsQueue.Dequeue();
                AddLightForNeighbors(position, _blockLights[position.x, position.y, position.z]);
            }
        }

        private void AddLightForNeighbors(Vector3Int position, byte lightForce)
        {
            lightForce -= 1;
            AddLight(position + Vector3Int.left, lightForce);
            AddLight(position + Vector3Int.right, lightForce);
            AddLight(position + Vector3Int.back, lightForce);
            AddLight(position + Vector3Int.forward, lightForce);
            AddLight(position + Vector3Int.down, lightForce);
            AddLight(position + Vector3Int.up, lightForce);
        }

        private void AddLight(Vector3Int position, byte lightForce)
        {
            if (_blockIds[position.x, position.y, position.z] != 0) return;

            if (lightForce <= _blockLights[position.x, position.y, position.z]) return;

            _lightsQueue.Enqueue(position);
            _blockLights[position.x, position.y, position.z] = lightForce;
        }
    }

Это упрощенный вариант кода, нет проверок на границы чанков, только чистая логика света. И представим _blockIds заполнен данными 0 и 1 (0 - нету блока, 1 - есть блок), а
_blockLights имеет значения от 0 до 15.

1. Блок света (Лампа) устанавливается в ячейку с координатами (x, y, z), а сила его света lightForce = 15.
2. Перебираю соседние ячейки: (x - 1, y, z), (x + 1, y, z), (x, y - 1, z), (x, y + 2, z), (x, y, z - 1), (x, y, z + 1).
2.1 Если в соседней ячейке есть блок, то он пропускается. И если lightForce внутри блока уже больше или равен присваиваемому lightForce, то блок пропускается.
2.2 Если блока нет, то ячейке присваивается lightForce= 14. Так же эта ячейка добавляется в очередь _lightsQueue.
3. Запускаю цикл While и также перебираю блоки внутри _lightsQueue.

Если вам интересно следить за разработкой игры и влиять на саму игру, у меня есть телеграмм канал.

itch.io - сайт для распространения инди-игр, сегодня утром подвергся ботнет атаке. Спустя несколько часов сайт восстановил свою работу везде... Кроме России.

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

Насколько долго это продлится и проделки ли это РКН - пока неизвестно

Видео:

https://rutube.ru/video/54aa5419eaac2a5477a01d05be0bc003/

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

Конечно, имитаторы/тренажеры являются только вспомогательным средством при проведении лекций или семинаров по техническим дисциплинам, там, где необходима наглядная демонстрация промышленных объектов, оборудования, принципа его работы, протекающие процессы и т. д. Такие имитаторы имеют достаточно много преимуществ перед традиционными технологиями, такими как презентация, видеофильм и т.д., главным образом в силу того, что тренажером можно управлять, т.е. лектор может производить демонстрацию «в реальном времени», т.е. управлять тем, что видят обучаемые. Если отдельно рассмотреть распределенные имитационные системы, то можно представить, например, следующую ситуацию...

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

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

Подробнее на https://habr.com/ru/articles/844810/

Уровень материала: 🐥 #middle

Ранее я писал, что прохожу обучение на курсе от Unity Architect. Недавно была тема, посвященная MVC. И упор был сделан не на очередной разбор очередной реализации, а на выяснение причин, почему существует такое разнообразие трактовок. Из этого вытекают и некоторые следствия, о которых не часто рассказывают, но которые находят место в практике.

Про разнообразие подходов 🛠️ :

Причина такого раздрая — «так исторически сложилось». Когда по принципу «глухого телефона» революционный много десятилетий назад подход дошёл до наших современных дней.

Подробнее с этим можно ознакомиться в длинном исследовательском материале из двух частей на Хабре: #1 и #2. Текст объёмный и сложный. Но увлекательный. Для вдумчивого чтения (а иначе смысла нет) стоит заложить на обе статьи где-то 1 час.

А один из примеров реализации в геймдеве я шарил в этом посте.

Следствие 1️⃣:

MVC — это изначально история про взаимодействие с пользователем. Т. е. про UI. Соответственно, попытки затащить это в геймплей сделают из MVC не MVC (и даже не обязательно какой-то MVx). Т. к. для удобства использования в геймплее эту штуку приходится адаптировать.

Следствие 2️⃣:

Как бы ни был «приготовлен» MVC, кто-то обязательно скажет, что это неправильно. Или это не MVC, а какой-нибудь другой MVx. Это бесконечные бессмысленные споры, стоящие на противоречивых источниках.

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

Ведь задача — спроектировать всё хорошо, а не сдать экзамен по «эталонному соответствию канонам». Тогда на нападки в виде «но в MVx же...» можно отвечать «а это не MVx».

Следствие 3️⃣:

Эталонно View и Controller находятся на одном слое взаимодействия с пользователем. И в современных системах, где нет низкоуровневого кода по непосредственно рендерингу и обработке ввода, контроллер как-таковой не шибко нужен. Поэтому достаточно использовать только Model и View.

В качестве Model можно подготовить специальную прослойку, типа Facade, Adapter или Mediator, которая будет агрегировать внутри всю коммуникацию с необходимыми игровыми моделями и сервисами.

Например, нажалась кнопочка, медиатор из WalletModel снял монетки, в StorageModel положил конфетки, а у AdService запросил показ InterstitialAd.

В свою очередь View будет отвечать за всю логику представления (кнопочки, формочки, генерация карточек, анимации прокрутки, заполнение прогресс-баров и пр.) и передачу событий в Mediator.

Связку из View и Mediator я и в своей команде использую уже очень давно — это отлично себя показывает в проектах разных масштабов.

На каком-то из стримов K-Syndicate оговаривались, что используют двухуровневый шаблон и связующий слой тоже называют Mediator. Не нашёл, на каком именно, но у них был большой классный стрим по MVx в целом.

————————————

#unity #gamedev #development #architecture #mvc #mvx #геймдев #разработка #архитектура #рекомендация #статья #видео

Уровень материала: 🐣 #junior

Unity выпустили серию роликов о своей системе AI Navigation. Вышло три видео (#1, #2, #3). В целом, очень полезный для знакомства с системой контент — Unity вообще радуют последние годы в этом плане. Но меня во время просмотра посетила любопытная мысль 💡

AI Navigation — это новое название пакета NavMesh. И у старых версий была неприятная особенность: строил навигацию он только на плоскости XZ. И неприятность в том, что для 2D-игр Unity использует плоскость XY 👾

Соответственно, 2D-игры ради навигации были вынуждены или искать/изобретать другие решения (пример), или использовать костыль: "разворачивать" свои спрайты так, чтобы они лежали на плоскости XZ. Были даже отдельные решения, основанные на этом ухищрении 🩼
[Форум с обсуждением]

Т.к. уже давно не работал с 2D-проектами, не придавал этому значения. И сейчас смотрю на видео и вижу, как настраивается навигация на вертикальной стене, на плоскости XY. Похоже, Unity теперь умеет полноценно в навигацию для 2D. Кто в 2D уже пробовал и может подтвердить или опровергнуть ❓

—————————————

#unity #gamedev #development #pathfinding #navigation #insight #разработка #геймдев #навигация #поискпути #рекомендация #видео

Уровень материала: 🐥 #middle

Хочу поделиться свежим полезным видео с реализацией системы реплеев. И дополнить своими комментариями. Однажды такая фича может потребоваться, и было бы здорово знать, в какую сторону начинать думать.

🔎 Суть реплея:

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

Чем меньше данных, тем более легковесным получится файл реплея. А это важно, ведь его надо хранить (ROM), читать (CPU), загружать (RAM) и возможно даже передавать по сети (Network).

Например, если поворот персонажа полностью восстанавливается из его направления движения, то достаточно записать только направление движения. И записывать его только тогда, когда оно изменится, а не просто каждые N сек. И т.д. Всё, как при синхронизации данных в мультиплеере.

Лучший вариант, когда игра детерминирована (т.е. при одинаковых вводных будет происходить всегда одно и то же). Тогда достаточно только записывать инпут от игрока с отметками времени и во время реплея его применять. Минимум данных, но детерминированность имеется (или хотя бы вообще возможна) не во всех проектах. Особенно в Unity с её недетерминированной физикой.

📐 Зачем нужен:

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

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

• Реплей может помочь с отладкой игры. Или с воспроизведением бага, который нашёл QA или какой-то игрок.

• Реплеи, собираемые с игроков, можно анализировать и в результате совершенствовать пользовательский опыт (или монетизационные подходы).

• По реплеям можно тестировать игровой баланс и прорабатывать его детальнее.

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

Т.е. отсутствие возможности реплея в самой игре как механики ещё не гарантирует её отсутствия как части проекта. И это стоит учитывать при проектировании очередного проекта.

————————————

#gamedev #development #feature #tool #replay #геймдев #разработка #механика #рекомендация #видео

Уровень материала: 🐣 #junior

Интересная коротенькая статья про то, как устроено deltaTime в игровых движках. Никакого откровения нет, если внимательно прочитать само определение параметра в документации к движку (например, Unity). Но всё равно найдутся те, для кого это может оказаться неожиданностью.

А не зная, как работает инструмент, можно получить неожиданное поведение при использовании.

Рекомендую также заглянуть в Appendix — там есть ссылки на более углубленные статьи: про нюансы отрисовки, общение между CPU и GPU, способы определения deltaTime, влияние параметра maxQueuedFrames и особенности работы при vSync.

Это контент посложнее, но, если заинтересует, уже будет понятно, в какую сторону рулить поисковые запросы и промпты для чат-ботов.

p.s. может потребоваться VPN.

—————————————
#gamedev #development #graphics #gpu #cpu #render #разработка #геймдев #статья #рекомендация

Уровень материала: 🎓 #education

На YouTube-канале CodeMonkey недавно вышло два больших видео, два бесплатных курса. Это 12-часовой курс по C# и 7-часовой курс по DOTS. Я их ещё не просмотрел и не могу объективно оценить. Но если вдруг какой-то подобный контент был как раз нужен — возможно это оно. Ранее там же выходил ещё курс по C# Intermediate.

# Про C#:

Видео по C# для меня интереса не представляет. Полистал, вроде всё адекватно, примеры нормальные. Видел пример реализации [Flags] для enum через побитовый сдвиг — очень полезная штука, почему-то её при обучении любят игнорировать.

✨ Про DOTS:

А вот видео по DOTS я, пожалуй, затестирую лично, но уже в новом году — пока катастрофически загружен. Напомню, что DOTS — это не только ECS-фреймворк, но и целый стек технологий, часть которых доступно и вне ECS (например, Burst Compiler и Job System).

Из ECS-решений ранее я пробовал DOTS, Entitas, LeoECS и Morpeh — и последний мне нравится больше всех, пусть он и не самый производительный. А DOTS нравился меньше всех. Интересно будет посмотреть, что в нём изменилось и что он из себя представляет сейчас.

📖 Про подобные курсы в целом:

Помнится, год назад Сакутин тоже выпускал подобные YouTube-курсы по C# и по Unity. Я их не смотрел, ничего сказать не могу. Видел только в чатах отзывы проходивших, что классическое «обо всём и ни о чём». Что, на самом деле, ожидаемо. 7–12 часов — это капля в море, особенно для Unity. Можно только успеть «тегов» набросать и по верхам пробежаться.

Так что это всё не более чем помощь в самообучении и практике. Только самостоятельное копошение в теме сможет чему-то научить. Не нужно ждать, что такие короткоформатные курсы смогут резко прокачать. Только подскажут и направят, не более.

🔖 Рекомендация от себя:

Пользуясь случаем, порекламлю мой любимый ресурс по C# (и не только) — Metanit. Удобный, качественный, бесплатный, масштабный. Он не заменит всё на свете, но это очень хороший дополнительный ресурс, который удобно использовать параллельно с другими ресурсами и к которому удобно возвращаться потом.

Сам по нему учился, параллельно с кучей других профильных книг. В «своё время» выел там весь контент по C#. Пригодилось ли мне это?

• С практической точки зрения: что повседневно не использую, то уже, конечно, не помню совершенно.

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

—————————————

#unity #gamedev #development #ecs #programming #csharp #code #разработка #геймдев #обучение #образование #курсы #программирование #рекомендация

Уровень материала: 🐣 #junior

Кто из лагеря Visual Studio уже успел попробовать теперь уже бесплатную версию Rider? Внутри много интересного: тесная интеграция с движками, шустрый и настраиваемый анализатор кода, полезные подсказки и автодополнения, генератор кода, мощный отладчик и всякое другое.

Даже простое знакомство с настройками может затянуться не на один час (при этом они удобно скомпонованы, и поиск по ним работает отлично). Но что важно — у Rider очень гибкая система шорткатов и хоткеев.

❓ Зачем это нужно? Для удобства. Конечно, для эффективности тоже. Но главное — для удобства. Нажатие на клавиши значительно быстрее, чем аналогичное действие совершённое мышкой. И требует меньше внимания. Мышку нужно перехватить, передвинуть, навести на меню, потом на вложенное меню, кликнуть и вернуть руку обратно (если нет навыка однорукой печати).

Rider позволяет полностью отказаться от мыши и сосредоточиться на работе. Захотел что-то сделать – стукнул пальцами и моментально увидел результат. При доведении до автоматизма, это превращается в настоящую магию, как-будто IDE управляется силой мысли. И это доставляет определённый кайф от работы.

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

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

• Горячие клавиши Rider: K-Syndicate

• Эффективная разработка в Rider IDE: DevGamm 2018

• Shortcuts, Editing, and Completion: Rider Essentials

• An Introduction to JetBrains Rider: Dan Clarke

⚙ Рекомендую также заглянуть в настройках во вкладку Keymap, где можно через поиск найти практически любое действие в IDE, которому можно назначить свой шорткат. Что-то часто приходится делать мышкой? Или на видео показывают полезный шорткат, который у тебя не срабатывает? Зайди в Keymap, найди нужное действие и назначь желаемую комбинацию.

Если запоминать комбинации не хочется, достаточно запомнить название операции и использовать поиск по Action'ам. Также в запоминании шорткатов может помочь плагин Key Promoter X (или может раздражать, если шорткаты игнорировать).

🤹 Шорткаты есть во всех программах. И везде они помогают сделать работу более комфортной (и эффективной). Не только в Rider и не только в IDE стоит уделять этому внимание. В т.ч. горячие клавиши есть и в Unity. И я рекомендую посмотреть их официальный тутор. Уверен, что ты сможешь узнать что-то новое, потому что в Unity далеко не все полезные возможности «лежат на поверхности». Также у них есть Shortcuts Manager, куда стоит периодически заглядывать.

—————————————————

#gamedev #development #rider #unity #code #programming #hotkey #shortcut #хоткеи #шорткаты #горячиеклавиши #разработка #геймдев #код #рекомендация #видео

Уровень материала: 🐣 #junior
<тестирую раздел Посты. этот материал уже можно было встретить в моём Telegram>

В рекомендации отправляю видео, которое показывает два любопытных подхода:

1. Хранение конфигурации уровня в ScriptableObject, а не в отдельной сцене.
2. Анимированное появление тайлов уровня.

И внутри есть ряд ещё более мелких интересных деталей.

📋 1. Хранение конфигурации уровня:

С этим я столкнулся в самом начале своей карьеры, т.к. начал с матч-3 направления, которое славится большим количеством уровней. По неопытности я хранил каждый настроенный уровень в отдельной сцене. Это привело к тому, что 10 таких уровней раздули билд без существенного контента до 100Мб.

Поизучав предметную область подробнее, я пришёл к тому, чтобы для уровня иметь одну сцену, а её наполнение формировать по данным из некоторого файла. Я использовал XML, т.к. тогда это было популярно (позднее для настройки уровня был подключен Tiled, который как раз умел экспортировать в XML). Билд тут же сдулся до 20Мб. А подход подарил невероятное количество всяческих бенефитов.

ScriptableObject — это тоже некоторый файл с данными (а точнее YAML или Binary, в зависимости от настроек Unity), который Unity умеет красиво отрисовывать в инспекторе.

А вот пример ассета (с ёмким описанием), который конвертирует уровень в JSON.

🎲 2. Анимированное появление тайлмапа:

Если уровень строится из тайлов, то это отличная возможность за "дёшево" сделать его эффектное появление. Например, как в видео, от точки позиции игрока плавно появить все тайлики в порядке удаления. Также можно и в целом оживить тайловое окружение, реагируя на разнообразные действия игрока.

✨ 3. Полезные мелочи:

В видео можно подглядеть:

• Как удалять элементы из списка, чтобы в for не делать лишних декрементов и в foreach не получить исключение InvalidOperationException “Collection was modified”. Подробнее про это можно также почитать в этом материале.

• Использование sqrMagnitude при сравнении дистанций для оптимизации вычислений. Про сравнение с обычным magnitude — тут (я тоже проводил подобные замеры: данные всё ещё актуальны).

• Как оформлять Coroutine для анимаций: нейминг, аргументы, содержание.

• Использование AnimationCurve для контроля плавности анимации.

• Использование Lerp для реализации анимации.

—————————————

#gamedev #development #animation #scene #loading #геймдев #разработка #анимации #загрузка #рекомендация #видео

• пишем стандартный CustomEditor(AssetImporter)

• создаем копию встроенного Editor'a, и вызываем из него OnInspectorGUI

• далее рисуем наши поля

• для сохранения используем plain class сохранённый с помощью JsonUtility в поле AssetImporter.userData (string)

• вызываем AssetImporter.SaveAndReimport чтобы применить изменения

Здесь базовый класс, который я использую, чтобы добавить поля в любой встроенный инспектор: GitHub | CustomOverrideEditor

Может быть непросто показать всё, что изначально рисовал встроенный инспектор (например, в примере с ModelImporter, у меня исчезли кнопки «Apply/Revert»), но имея доступ к декомпилированному коду, через рефлексию я успешно все отрисовал

В ваших пользовательских полях вам также придется обрабатывать mixed values вручную, потому что у вас нет общего SerializedObject. Вы можете создать ScriptableObject для каждого AssetImporter.userData, но это может крайне медленно, при выделении множества объектов одновременно

Код полной реализации с картинки-примера, ModelImporter с полем Enum, сохраняемым для каждой модели: GitHub Gist | Source code

В настоящее время я активно изучаю и использую Unity для разработки проекта с AR и столкнулся с классической проблемой "модификации UI элементов не в основном потоке" - так делать нельзя, поскольку средой будет вызвано исключение UnityException.

В рамках изучения этого вопроса я далеко не сразу нашёл решение. Передо мной стояла задача сделать обработку сообщения, получаемого по каналу связи через WebSocket, изменив при этом некоторые UI элементы. Обработка происходит не в основном потоке.

Через некоторое время я наткнулся на одно из возможных решений этой проблемы через очередь задач, которая решает данную проблему:

// Экземпляр WebSocket
private WebSocket _ws;

// Очередь команд для обработки
private readonly ConcurrentQueue<Action> _actions = new ConcurrentQueue<Action>();

void Start()
{
    // ...
    ConnectWebSocket();
}

void ConnectWebSocket()
{
    // ...
  
    // Добавление обработчика ответа от сервера
    _ws.OnMessage += OnMessage;
  
    // ...
}

void Update()
{
  // ...
  while (_actions.Count > 0)
  {
    if (_actions.TryDequeue(out var action))
    {
      // Выполнение задачи из очереди
      action?.Invoke();
    }
  }
}

void OnMessage(object sender, MessageEventArgs e)
{
  // Добавление команды в очередь
  _actions.Enqueue(() => MessageHandler(sender, e));
}

void MessageHandler(object sender, MessageEventArgs e)
{
  // Данный блок кода выполняется в основном (main) потоке
}

На рынке игровых движков полно вариантов на любой вкус и цвет, начиная от Open Source решений и заканчивая огромными коммерческими комбайнами. Большое количество игровых движков поддерживают сборку проекта для веб-платформ. Но от движка к движку различается итоговый размер собранного проекта. И это может влиять очень критично - не все платформы дистрибуции готовы хостить веб-проекты сами, а если и готовы, то они часто имеют ограничение на размер проекта.

В связи с этим решил посмотреть, а что по размеру сборок у основных игроков на рынке?

Тестовая сцена влючает в себя лого Godot 128x128 32 бита, размер 4,209 килобайт.
Результаты сборки при максимальных возможных оптимизациях на уровне движка:
1. Godot (4.2.2) - 18.7 мегабайта. Остались включенными только модули GDScript, OpenGL, Brotli. Для полноценной работы маловато, но терпимо. Снизить ниже уже в разы сложнее.
2. Unity (2022.3 LTS) - 8.42 мегабайта. Потенциально можно дойти до 3-5 мегабайт.
3. Defold (1.8.1) - 2.62 мегабайта. Размер сборок мониторится, графики правдоподобные.
4. Game Maker (2024.4.1) - 2.32 мегабайта. Ужать дальше можно только с сжатием контента. upd можно залезть в код

Сюда не вошли:
1. Unreal Engine. Последняя версия с поддержкой web-платформ была 4.24, дальше только в виде отдельного расширения.
2. Нативные для браузеров движки на JS/TS, коих множество.
3. Прочие решения, которые не подошли мне по разным параметрам: Phaser, PlayCanvas, Construct, GDevelop и другие.

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

Задача выбора целей для атакующих NPC

В играх RTS жанра обязательно возникает задача, как выбрать для NPC цель. Мы хорошо знаем, когда игроки на их жаргоне говорят "заагрился", что означает, что некий юнит, обратил внимание на юнитов игрока, и будет их преследовать и атаковать. В ряде игр от заагрившегося юнита можно убежать, в других наоборот, он будет вас выслеживать "по запаху, остаткам крови", как это реализовано в JA3. Но как усложнится задача, когда агрессивных NPC в игре сотни, и у игрока аналогично их сотни, или тысячи. Можно ли раз и навсегда заагрится на какого то конкретного юнита? По какому принципу перераспределять цели между разными NPC? Все это не тривиальные задачи, но они имеют одно достаточно простое решение на базе алгоритма искусственного интеллекта, который своими корнями восходит к алгоритму градиентного спуска.

? Стандартный рендеринг в CAD (BIM) программах часто не дотягивает до качества визуализации, но игровые движки, такие как Unreal Engine и Unity, произвели революцию в архитектурной и дизайнерской визуализации. Эти движки предлагают быстрый рендеринг и интуитивно понятные настройки света, материалов и геометрии, которые значительно улучшают процесс визуализации. Теперь клиенты могут изучать виртуальные модели зданий, взаимодействуя с такими элементами, как освещение и мебель, в режиме реального времени, что улучшает их понимание и вовлеченность. Unreal Engine позволяет проводить метаверсии, превращая 3D-виртуальные миры в крупные социальные центры.

? Unreal Engine позволяет создавать интерактивные приложения 3D, дополненной (AR) и виртуальной (VR) реальности из 3D CAD (BIM) моделей.
? Визуализацию или симуляцию движения автомобилей и людей можно настроить буквально в несколько кликов. Погода и время также легко настраиваются
? Бесплатные движки позволяют подключать алгоритмы искусственного интеллекта, которые наглядно позволяют воспроизводить симуляции в реальных сценах, а не на бумаге
? Используя Unity и инструментарий ML-Agents, ты можешь создавать ИИ-среды, которые будут физически, визуально и когнитивно насыщенными
? С помощью Unity Machine Learning Agents больше не нужно"кодировать" эмерджентное поведение, а можно научить интеллектуальных агентов "учиться",

Актуализировал свою статью про async/await в Unity.

• Обновил примеры

• Внёс ясности про асинхронность и UniTask

• Дополнил раздел про CancellationToken

Если упустили, советую ознакомиться.

P.S. Я там обещал статью о самых распространенных ошибках при использовании async/await. В ближайшее время и она увидит свет, так что следите за обновлениями.

Если у вас не работает автокомплит при работе с проектами Unity или вообще с c# проектами, зайдите в настройки VS Code, вбейте в поиск: omnisharp.useModernNet и в найденной опции, выберите false.

После этого перезапустите VS Code и все заработает.