Dmitry_togliatti
ИТОГ: попрорукие - делают лажу. Но это закономерно и нормально. А unity норм для своих задач. просто не надо aaa делать, даже DOTS не спасёт.
Молодец. Адекватный человек пишет.
Не то что отбитый и контуженый на всю голову Increaser у которого нет проблем сделать Сталкера на Юнити.
И у Increaser нет фундаментальных проблем в Юнити, потому что клепает тетрисы :)
А вот что пишут те кто реально делает большие проекты в Юнити, а не тетрисы.
Неэффективное управление памятью. Утечки памяти могут приводить к постепенному снижению FPS и даже к крашам, особенно на мобильных устройствах. Решение: пулинг объектов, асинхронная загрузка, оптимизация коллекций.
Неоптимизированные физические симуляции. Например, использование сложных меш-коллайдеров вместо простых примитивов (сфера, куб, капсула).
Ресурсозатратные инструменты для интерфейса. Например, layout-группы, которые пересчитывают размеры и расположение всех элементов, что может снижать производительность, особенно при резких изменениях.
Зависимости между объектами и скриптами. Когда объекты напрямую взаимодействуют с другими скриптами или компонентами, возникает проблема сложных зависимостей, что делает код менее модульным и гибким. Решение: использовать принцип инверсии зависимостей и внедрение зависимостей, чтобы снизить зависимость объектов от конкретных классов и интерфейсов.
Еще одним недостатком является плохая оптимизация, как по использованию процессора, так и оперативной памяти. При изучении статей в Интернете о том, как улучшить производительность в Unity-проектах, большая часть советов касается сокращения аллокации памяти и минимизации сборки мусора (Garbage Collection, GC).
Garbage Collection - это удобный способ контролировать освобождение памяти. Однако стоит помнить, что этот процесс не может выполняться параллельно с выполнением игрового кода. Действительно, для освобождения памяти необходимо временно приостановить выделение новой, что в свою очередь требует приостановки игрового процесса, даже если это происходит лишь на краткое время. Такие периодические приостановки могут негативно сказаться на графике фреймтайма и плавности игры. Представьте, что пик активности сборки мусора совпадает с другими высоконагруженными событием в приложении.
Фрагментация памяти
Для того чтобы объект был размещен в памяти, необходимо найти непрерывный участок, в который он полностью поместится. Однако при постоянном выделении и освобождении памяти начинают образовываться небольшие пустые фрагменты, в которые новые объекты могут не поместиться. Эта ситуация называется фрагментацией памяти и при продолжительной работе игры она может привести к сбоям. В таком случае объем памяти может быть достаточным, но отсутствует непрерывное свободное пространство, в которое можно было бы разместить новые объекты. Для решения этой проблемы используется дефрагментация, но без разумного управления выделением и освобождением памяти она может оказаться неэффективной.
Паттерн Object pool
Для решения проблем с фрагментацией памяти и постоянным выделением и очисткой было разработано множество методов, и одним из них является паттерн "Object Pool" (пул объектов). Его суть заключается в том, чтобы не создавать объекты заново, а заранее создать их при старте сцены, затем включать и выключать их по мере необходимости. Это действительно позволяет существенно снизить количество операций выделения и освобождения памяти, однако при этом добавляет дополнительную сложность в архитектуру приложения.
Кэширование
Некоторые методы при каждом своем вызове могут создавать огромное количество новых объектов в каждом кадре, не кэшируя их, например, Physics.OverlapSphere(), который возвращает массив Collider[]. При каждом вызове этого метода мы выделяем память для массива коллайдеров, используем его и тут же отбрасываем результат, а в следующем кадре все повторяется. Для предотвращения этой проблемы нужно использовать специальные методы. Например, методы в классе Physics с суффиксом NonAlloc, которые используют изначально выделенный массив при каждом вызове. Второй вариант - это разрабатывать собственные механизмы кэширования информации. Важно помнить, что при этом всегда необходимо учесть, сколько памяти потребуется в будущем. Если мы выделим слишком много, это будет пустой расход ресурсов, а если слишком мало, то возможно потребуется разработать логику для выделения нового участка памяти в таких случаях.
Подводя итог главе, посвященной управлению памятью, отметим, что GameObjects, используемые в разработке игр, могут стать серьезной проблемой. Под них постоянно выделяется память в куче, и это происходит незаметно для разработчика, поскольку ответственность за ее очистку лежит на Garbage Collector. На самом деле, управление памятью требует внимания, так как недостаточный контроль в этом вопросе может привести к серьезным последствиям. Ложная простота языка C# с автоматической сборкой мусора несет опасность для небрежных разработчиков.
Кроме проблем с памятью, у GameObjects также есть некоторые проблемы, связанные с использованием процессора.
Проблемы с производительностью CPU
GameObjects сами по себе оказывают влияние на производительность игры. При небольшом их количестве изменения в производительности могут показаться незаметными, но если добавить на сцену, скажем, несколько десятков тысяч простейших NPC с даже самой простой графикой, то частота кадров в секунду (FPS) резко упадет практически до нулевого значения. GameObjects, по сути, представляют собой контейнеры для компонентов, но количество самих объектов имеет непосредственное влияние на производительность.
Более того, на компонентах GameObjects часто присутствует специальный Unity Callback под названием Update(). Даже пустой вызов этого метода вносит свой вклад в снижение производительности
Интерфейс
Неправильное расположение элементов интерфейса. Например, элементы могут смещаться после билда проекта из-за неверных настроек (точки привязки, разрешение, соотношение сторон). Решение: проверить точки привязки, режим масштабирования интерфейса и иерархию «родитель-потомок».
Лицензия
Ошибки при активации лицензии. Например, лицензия не активируется из-за проблем с сетью, блокировки соединения с серверами Unity (антивирус, брандмауэр) или старого файла лицензии, который блокирует создание нового. Решение: перезагрузить Unity Hub, проверить настройки брандмауэра или антивируса, удалить старый файл лицензии.
https://dtf.ru/gamedev/2232494-chem-plohi-gameobjects-v-unity
Increaser
берут FMOD
Ты тут меня упрекал, что в моём движке кривой код смотан изолентой.
А это я так понял вообще из говна и палок делали :)
https://xssracademy.com/blog/audiodvizhki/basic-scripts-fmod-unity.html
https://habr.com/ru/articles/650261/?ysclid=mi8j3o8ya5869793098
Increaser чем больше ты пишешь, тем больше я вижу что ты дно тупое.
Которое может только тетрисы делать в Юнити и как секритутка кнопочки нажимать.
Короче примитивный клацальщик кнопочек в Юнити.
Который в 5 кликов из чужих ассетов собирает тетрис.
Это максимум который доступный твоему интеллекту.
И твоя аватарка как раз уровень твоего интеллекта и отображает :)
Могу только кнопочки нажимать лапками.
ronniko
> пулинг объектов, асинхронная загрузка, оптимизация коллекций
Но это же норм практика. Лажа в том, что для САМ instantiate only main thread
ronniko
> использование сложных меш-коллайдеров вместо простых примитивов (сфера, куб, капсула)
И это норм. Не нра? Можно ы 2 движения поменять коллайдер
ronniko
> инструменты для интерфейса
Вот тут да. Они полная лажа.ronniko
> Зависимости между объектами и скриптами
Ну, это, наверное, везде. Правда хотелось бы, чтобы хто-то умный порешал из коробки, а не 100500 вариантов
ronniko
> плохая оптимизация, как по использованию процессора, так и оперативной памяти
Это да. Но для а достаточно, лишь бы не ааа. Однопоточная идеологическая база + garbage collecting
ronniko
> Неправильное расположение элементов интерфейса
Да, они пытались взять пример из android studio (constraint layout, xml разметка и всё такое), но получилось криво очень. и сложно.
тем не менее, я отчасти согласен с Increaser в том, что это норм движок. Логика "За неимением горничных будем драть дворецкого, господа", но это действительно так. Не согласен с идеализацией. Т.к. задумка unity кроется в названии. Всё для всего.
Dmitry_togliatti прикинь я в 2014 году на своем асм движке Directx 11 выводил, тупо без трюков и оптимизаций 40 000 анимированных собак на видеокарте geforce 1070 с 3 гигами видеопамяти !
Проц Intel i5-2320 4 ядра и озу 8 гиг. Рендер и всё остальное ,делал на одном ядре проца.
Каждая собака 8000 треугольников.
Я молчу про деревья, забор, частицы снега, GUI и текст. Хотя всё это тоже рендерится и есть на видео.
Самое ржачное было, когда один упоротый на подобии Инкриасера, написал Юнити без проблем в 2014 такое потянет.
Я ему говорю "выведи 25 000 анимированных персонажей на простой сцене"
Он мне пишет его Юнити проект крашнулся на 16 000 персонажах. И его железо было моего уровня.
ronniko
> выведи 25 000 анимированных персонажей на простой сцене
Может быть. Но unity юзерам не нужны 25 000 анимированных персонажей. Им нужны решения остальных 999 999 задач. А это возможно при большом комьюнити. Не вижу смысла в вашей войне.
Тема упирается в то, что один кричит, что unity забагованный непроизводительный кусок г. Другой - что юнити - лучшее.
Прикол в том, что оба правы)
Ну и большой плюс в том, что я то без Юнити могу делать игры.
Вулкан API асм 64 бит.
ronniko
насколько я понимаю,текущий предел игромеханической сложности для твоего движка это вот:
https://gamedev.ru/code/forum/?id=292868&page=5&m=6117465#m62
https://my.mail.ru/mail/ronniko/video/_myvideo/1.html
если знать что оно на асме... то впечатляет конечно. способность писать такие большие вещи на асме - бесспорно показатель личной отваги... тут я снимаю шляпу.
но если не знать (а игроку на это пофиг)... это же примитивно. на юнити подобное делают за дни или даже часы. что будет с твоим асмом, когда ты добавишь туда диалоги, разные паттерны поведения противников, системы инвентаря...
ну т.е. да, свою хардкорную крутость ты определенно показать можешь, но твое
> без Юнити могу делать игры
на самом деле это
> без Юнити могу делать [примитивные демки] игры[, которые с Юнити делают за пару вечеров или часов].
этого явно недостаточно для морального права свысока относиться к т.н. юнити-боям.
PS: на этом форуме есть люди, способные писать более-менее нормальные игры без юнити, но они почему-то не бегают за юнити боями и не пытаются их унизить. возможно они что-то знают.
kkolyan
> что будет с твоим асмом, когда ты добавишь туда диалоги, разные паттерны поведения противников, системы инвентаря...
Ничего не будет, потому что этого никогда в его движке не будет.
ronniko
ну а кроме того, насколько если я правильно понимаю, твой код привязан к архитектуре, и если надо к примеру игру на мак с М1 или телефон или васм собрать, то... тебе придется писать отдельный код в том числе игровой механики... но этож жесть)
Increaser
> ичего не будет, потому что этого никогда в его движке не будет.
не, ну в движке этого и в юнити нет) но пусть хотяб в игре. но вообще да, понимаю твой скепсис)
kkolyan
твой код привязан к архитектуре, и если надо к примеру игру на мак с М1 или телефон или васм собрать, то... тебе придется писать отдельный код в том числе игровой механики... но этож жесть)
Да.
kkolyan
Что то ты старые видосы смотрел.
За 3 года такое сделал на своем движке.
ronniko
> За 3 года такое сделал на своем движке.
вижу что какой-то функционал добавился, но это все еще не игра.
kkolyan
Да еще надо делать и делать.
Последнее это добавил физику в свой асм движок.
Но такие игры как Сталкер толпой годами пилят. Даже на Анриале.
Даже Сталкер тень Чернобыля почти 6 лет пилили.
Сам смысл , в том ,что я не просто делаю игру типа Сталкер, я пишу движок и прокачиваю его так, что бы быстро делать игры на подобии Сталкер.
Вот она в чем суть всей моей затеи.
На данный момент я уже не пишу руками на асме код. Я через скрипт даю задания движку.
Например init sound. Open3Dlevel "level1.zone.a.txt"
Либо создаю скриптом буфер на 3000 персонажей и задаю свойства генератором.
Так же скрипт грузит GUI и вешает на два треда. это тред рендер GUI и тред обработки GUI.
//script 19@@pool ;render GUIDX11 slot19 #s 1,29,1 ;set to list slotStart,[userTabProcs+v],index element. #s 2,30,0 #s 2,30,1 #s 2,30,2 #s 2,30,3 #d 'hl\guibtns.bin' .. 18@@pool ;thread GUIchecker slot18 #f 'hl\guiifbtns.bin' #g 19,0 ;get data from poolslot nomer its 'hl\guibtns.bin' ..
Таким образом много делается через скрипт, что сильно ускоряет и облегчает работу с движком.
И мне становится проще и легче делать игры на своём движке.
Кстати компиляция асм движка занимает меньше секунды !
А это классно когда ловишь баги или добавляешь новые функции.
Перекомпилил проверил. Перекомпилил проверил.
А вот с++ Сталкера ждешь сборку минутами.
В Юнити наверное тоже не быстро.
kkolyan я не бегаю за Юнити-боями , они сами лезут в мою тему.
https://gamedev.ru/flame/forum/?id=272753&page=58
И в тему движкописателей.
https://gamedev.ru/code/forum/?id=292868
Dmitry_togliatti
Прочитал сообщение 82.
Теперь понял. Ты хочешь изменить тонкости работы какого-то компонента посередине, оперируя интерфейсами через ScriptableObject'ы? Подход интересный, если я правильно понял.
В таком случае мои доводы о сериализации вообще не в ту степь ушли. Да и размещение в проекте вопросов не вызывает, условно папка GameDesign.
Подход интересный, я до такого не додумывался. Но это я. Мне гораздо проще оперировать непосредственно в коде.
С геймдизайнерами без знания кода практически не работаю, либо они документы со всеми формулами высылают заранее.
Хотя был на одном проекте. Геймдизайнеру нужно было формулы просчёта урона подбирать, и желательно в движке. Так у нас один проггер заморочился и сделал AST парсер из строки формата "10 * x + (15 * y - 5 * z)". А всякие переменные "XYZ" он выделял парами <string,enum> и рисовал в инспекторе как выпадающий список со статами. Типа такого:
[ X ] = [ Сила ▽ ]
[ Y ] = [ Выносливость ▽ ]
[ Z ] = [ Уровень персонажа ▽ ]
Ну и метод просчёта учитывал эту формулу, брал нужные переменные из объектов, которые поставляются как аргументы функции. Жёсткая тема ИМХО. Но не воспринимай как какое-то требование. Просто вариант развития мысли.
Dmitry_togliatti
> А меня немного напрягает. Рефлексия + сериализация путей... Достаточно хрупкая тема. SO тоже могут слететь, да. Но этот механизм по кр мере не предполагает дополнительного кода. Всунул вынул и пошёл.
Сама работа в разработке софта - штука весьма хрупкая. В любом скрипте поставь 1 запятую - не скомпилируется весь проект вне зависимости от масштаба, от Тетриса до GTA 5. А конструкция while(true) { } положит любой процессор на лопатки.
Поэтому не считаю довод ультимативным. Инструментами надо пользоваться, чтобы реализовывать задачи, но и учитывать сильные и слабые стороны выбранных решений.
После общения в теме взялся глядеть, как слетают ссылки у SerializeReference. И за вечер с ChatGPT сделал компонент, который обезопашивает переименование классов и смены пространства имён.
1. Вешаем на целевой класс аттрибут "[Utility.SerializationLinks.SerializationKey("Field1")]".
2. Перекомпилируем
3. Всё компонент заработал.
При рефакторинге:
1. До компиляции - проходится по сборке, собирая все классы с аттрибутом "SerializationKey". Запоминает старый путь сериализации.
2. Компилирует.
3. После компиляции - проходится по сборке. Нашёл изменения - проходится по всем YAML файлам (сцены, префабы, Scriptable Objects) проекта и заменяет строки-ссылки на новые данные.
Но и у этого решения есть минусы:
- У сериализуемых классов необходимо прописывать аттрибут (громоздко) и вручную учитывать уникальность ключа сериализации.
- Нельзя изменить ссылки на объекты в памяти. Пример - компонент на несохранённой сцене. Чтобы на сцене всё работало, нужно сначала всё сохранить, затем делать рефакторинг, и затем вручную обновить сцену через Control+R. Тогда ссылки подхватятся.
ronniko
> Самое ржачное было, когда один упоротый на подобии Инкриасера, написал Юнити без проблем в 2014 такое потянет.
> Я ему говорю "выведи 25 000 анимированных персонажей на простой сцене"
> Он мне пишет его Юнити проект крашнулся на 16 000 персонажах. И его железо было моего уровня.
Я глянул видео. Допустим, 40 000 анимированных объектов есть. Да, не крашится. Но какой ценой? На записи 1 FPS, хотя, полагаю, меньше, просто счётчик простой.
Тем временем есть проект Ultimate Epic Battle Simulator, который сделан на Unity и позволяет запускать битвы c буквально миллионом участников с разумным FPS. И раз уж говорим про Unity, уже существуют репозитории, которые помогут повторить этот подход. С ним на RTX 3070 Laptop запускал под 60 000 юнитов на 60 fps, но с тенями.
Но и Unity тоже не серебряная пуля. Опять же - инструмент, который делает процесс разработки проще (позволяя большему количеству разработчиков пользоваться технологиями оптимизации), но работающий менее оптимально.
Сори конечно что влезаю в ваш холли-вар, но как по мне, результат это игры в которые можно играть. И на юнити великая масса игр в которые можно поиграть. Да, скорее всего разработчики столкнулись с определёнными проблемами, но результат - игры в стиме которые люди купили (да же прости господи EFT).
Какая кому разница, как движок работает с памятью, с cpu и gpu, если можно просто открыть игру и поиграть?