Как стать автором
Обновить
23
0
Николай Григорьев @HexGrimm

Ведущий разработчик мобильных игр и приложений.

Отправить сообщение

Жалко что вы не прошли чуть дальше по методу "Метод конического масштабирования". Кажется что математически такое пересечение и расположение камеры можно рассчитать, но только если объекты это сферы, а это как раз ваш случай. Может быть дело просто в сортировке, сортировать нужно по точкам-основаниям перпендикуляра от центральной линии камеры до центра сферы. А после того как порядок известен, опять же для сфер, можно рассчитать их масштаб так, чтобы сферы объектов не пересекались, но были максимально близко к Near Clipping Plane.

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

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

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

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

А почему кстати при маппинге при увеличении числа время растёт? Маппинг ведь подразумевает расчёт указателя, верно? Если есть расчёт, то и файл не нужно читать с начала, а с произвольного индекса.

Дело не только в количестве сущностей. Вопрос практический - современные IDE подсвечивают стек вызовов методов между классами при дебаге, и сканируют использования методов для навигации по коду. В случае с EB я не видел примеров удобной навигации, большую кодовую базу поддерживать будет тяжело. Единственный пример использования аналога EB я могу представить только когда количество методов у класса на столько большое, что только у него в API накладные расходы на EB меньше, чем на написание большого кол-ва сигнатур методов руками.

ни разу не "размыли логику" или не "спрятали зависимости"

А какие аргументы то приведены? Выглядит так что если цепочка вызов увеличится, как это происходит в многослойном ООП, то сложно отследить кто вообще что вызвал и в каком порядке, и как это прервать.

Да, еще забыл сказать, необходимо мочь сериализовать всё, иначе результаты вычислений будут расходиться. Или, например, если игрок только подключился и у него совсем нет информации о мире. Если работать с сущностями по одной, то получится неконсистентность данных, если делать в лоб. Такой подход есть в Unreal, или в NetworkForGameObjects, но в играх так совсем уже не делают. В современных тайтлах всегда где нибудь да есть предсказание, или компенсация лага.

По коду сложно сказать достаточно или нет, тк сам контракт подразумевает что данные можно трактовать по разному. Тут ведь при синхронизации для данных нужен еще факт создания или удаления сущности, и какого она была типа (набора компонентов данных + набора логических систем + связей между объектами). Если бы вся информация об этом была гарантирована в данных, то было бы надёжнее.
Ну или я просто не правильно представляю рабочие примеры, а не синтетические. Мне кажется что подход не полностью датаориентированный, тк тут замешаны ООП свойства, и я перечислил список частых проблем в недатаориентированных средах.

Функцией сериализации придется наделить либо все сущности, либо каким то образом шарить дополнительные детали из метода Compose() (о чём я писал выше). Это будет дороговато поддерживать, и в целом это доступ к рандомной памяти в куче, в большом количестве итераций. Например, файтинг или шутер, где нужно делать копию мира по 7-8 раз за кадр, так не сделать.

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

С точки зрения кода любой игровой объект состоит из данных и логики

Это не очень хорошо. Когда данные и логика связаны то сущность теряет гибкость и тестируемость. Есть набор задач, которые в таком подходе сделать будет невозможно или как минимум дорого:

  • Сериализация состояния мира в больших масштабах.

  • Тестирование и воспроизведение конкретного кейса.

  • Декларирование порядка вызовов между атомарными объектами или внешнего кода.

  • Копирование объектов (сложно оценить как скопируются функции и эвенты)

    Это и проблема многих ECS, где нет доступа к блокам памяти, или нельзя выделить размер в памяти нормально.

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

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

А разве модель есть в доступе для запуска локально? На сайтах не вижу такого, только веб интерфейс.

А разве не наоборот? Сначала интерфейс, затем тест использования, а только потом реализация. Получается надо и апи спрогнозировать, и варианты его использования, правильные и не правильные.

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

своё лучше чем чужое

Скачав бесплатные ассеты с ассет стора, подписав приложение Android SDK сборку из движка Unity? Ох забомбит сейчас в комментах от такого лицемерия...

традиций, которые весьма отличаются от западных

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

Стоит начать с того кому принадлежит RuStore, и по какой причине он вообще существует, прежде чем рассуждать о чем то духовно-полезном. И тем более делить с этой площадкой прибыль.

Мне кажется что 3 и 4 пункты как раз в Zenject есть. Это момент когда у рутового объекта будет вызван единственный Resolve. Этот объект и может иметь единственную точку входа и единственный Update() метод во всём проекте, и дальше работать уже со своим деревом просто как c C# классами.

А вот как раз 5 и 6 и не должны быть в функционале контейнера, и если в сахаре Zenject это есть, то использовать то не стоит.

Всё так, но почему в примерах статьи так много наследников от MonoBehaviour когда это обычные классы которые нуждаются в конструкторе?

Не нужно иметь под рукой сервис локатор или метод GetService, если в конструктор всё приходит, и выстроено в правильном порядке. А то что накликано в юнити мышкой, ну фиг знает, скорее всего DI нарушен многократно.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность