Почему инди игры так сильно лагают?

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

(Можно было бы отфотошопить картинку и дописать, когда пое  на секунду фризануло в 30 раз за минуту, но мне лень)


Все хардкорные геймеры знают с какими словами ассоциируются инди игры у комьюнити. А именно: лаги, фризы, краши.

Конечно, мы сейчас не говорим об инди студиях, которые состоят из опытных ветеранов с большим опытом и талантом. Мы говорим об инди студиях (или можно сказать "инди-людях", т.к. в таких студиях 1-2 человека).


Коротко говоря, изначальная проблема, конечно, в том, что порог входа в создание игр стал намного ниже и абсолютно любой геймер (ведь именно любители игр являются инди разработчиками) можно запустить анрил\юнити\годот и накидать на сцену моделек и по урокам с ютуба заставить игрового персонажа двигаться или выполнять анимацию, и сразу гордо именовать себя разработчиком игр.

В чем же основные проблемы инди разработчиков с лагучими проектами? Они не понимают сути программ и вычислений. О чем речь? Давайте несколько углубимся в тему и посмотрим на простые и всех знакомый термин: FPS - кадры в секунду.

ФПС - это, простыми словами, сколько раз в секунду картинка на экране обновится.

Но, любые игровые движки мыслят более глубокой сущностью: миллисекундами исполнения (мс).

В 1 секунде = 1000 миллисекунд. Для того, чтобы выполнить какие-то действия, приложению затратить 20 миллисекунд. Сколько это фпс? 1000\20=50 фпс.

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

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

Что даёт нам это понимание? Давайте проведём немного вычислений для наглядности.
Допустим, для игры требуется 1 млрд. действий в секунду.
Наш процессор имеет 3.2 млрд. действий
Итого вычислим ожидаемый ФПС на такой машине:
(100\320)*100=31 мс или 1000\31=32 фпс.

Сейчас мы имеет 31 фпс, но ведь 3.2 ггц - не самый слабый процессор. Что же будет на 2.2?
(100\220)*100=45 мс или 1000\45 = 22 фпс.


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

Основные проблемы начинающих в том, что они пытаются интерполировать свои знания из универа\уроков в школе на процесс разработки совешенно забывая про то, что в программирование не бывает бесплатных действий. Самое банальное: длина вектора (например, растояние между нашим персонажем и противников)? По какой формуле считать? Хм, давайте посмотрим в интернете...

Круто, такая хорошая формула, как по учебнику. Жаль, что она не подходит для геймдева от слова совсем. Начнём мыслительный процесс: что такое длина от одной до другой точки? Это относительное растояние между точками. Посмотрим пример расчётов с того же сайта:

Итак, тут длина - 6. Но в формуле у нас есть корень - сложная математическая операция, которую не используют в типичных формулах в геймдеве. Давайте просто его уберём и получим, что длина = 36, а не 6. Разве для нас или игроков есть разница на какую цифру мы ориентируемся на 36 или 6? Никакой разницы нет, а процессорное время сэкономили. Т.е. вы просто будете сравнивать этот результат с другими числами - вот и всё.

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

И это самое базовое - математика\физика. Существуют так же другие пути оптимизации графики и прочего, но все они сводятся к простой истине: Чем меньше расчетов - тем лучше.


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

Допустим, в сцене стоит 2 моба. Человек тестирует его, вроде бы всё ок по производительности. Он всё сделал, отдал дизайнерам, которые начали в сцене использовать 40 мобов. Т.е. в будущем допустив небольшую ошибку производительность на сцене упадёт разительно, ибо потребление ресурсов будет умножено на 40. (Привет POE)


------------------------------------------------
Давайте немного примеров:

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

Что по производительности?
Майнкрафт - запуск на любом ведре и игра без лагов.
Ведьмак 3 - запуск только на средне-хороших компах и игра без лагов.
Eco - запуск на топ компах, фризы и лаги на каждом шагу.


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

В чем же причина лагов и такой жести в этом проекте? Вероятно в том, что у тех. специалистов нет даже базовых знаний о подходе к оптимизации. Т.е. сходу тестируя игру я увидел отсутствие использования базовых механизмов оптимизации проекта. Это я даже в код не смотрел. Сходу видны были горы ошибок и неправильных использований базовых технологий. Например, когда открываешь дверь, то каждая позиция двери приходит от сервака. Т.е. пока она открывается я получаю 20+ пакетов сверху, а это всё тоже не бесплатное.

Что ещё? Хм, миры в Eco загружаются\создаются очень долго, миры в Minecraft - 2 секунды. Почему? Всё просто. Ребята из Eco в тупую хранят все клетки как физ. объекты, а не как Гейб в Minecraft-е - в паре тысяч цифр.

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


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

P.S.S. Не идите дети в разработчики игр, если не готовы въебывать как проклятые изучая гору инфы и разочаровыватся в собственных силах.

Правила сообщества

ОБЩИЕ ПРАВИЛА:

- Уважайте чужой труд и используйте конструктивную критику

- Не занимайтесь саморекламой, пишите качественные и интересные посты

- Никакой политики


СТОИТ ПУБЛИКОВАТЬ:

- Посты о Вашей игре с историей её разработки и описанием полученного опыта

- Обучающие материалы, туториалы

- Интервью с опытными разработчиками

- Анонсы бесплатных мероприятий для разработчиков и истории их посещения;
- Ваши работы, если Вы художник/композитор и хотите поделиться ими на безвозмездной основе

НЕ СТОИТ ПУБЛИКОВАТЬ:

- Посты, содержащие только вопрос или просьбу помочь
- Посты, содержащие только идею игры

- Посты, единственная цель которых - набор команды для разработки игры

- Посты, не относящиеся к тематике сообщества

Подобные посты по решению администрации могут быть перемещены из сообщества в общую ленту.

ЗАПРЕЩЕНО:

- Публиковать бессодержательные посты с рекламой Вашего проекта (см. следующий пункт), а также все прочие посты, содержащие рекламу/рекламные интеграции

- Выдавать чужой труд за свой

Подобные посты будут перемещены из сообщества в общую ленту, а их авторы по решению администрации могут быть внесены в игнор-лист сообщества.


О РАЗМЕЩЕНИИ ССЫЛОК:

Ссылка на сторонний ресурс, связанный с игрой, допускается только при следующих условиях:

- Пост должен быть содержательным и интересным для пользователей, нести пользу для сообщества

- Ссылка должна размещаться непосредственно в начале или конце поста и только один раз

- Cсылка размещается в формате: "Страница игры в Steam: URL"

Вы смотрите срез комментариев. Показать все
1
DELETED
Автор поста оценил этот комментарий
Статья была бы актуально лет 15 назад. Сейчас оптимизация игр совсем другое. Есть туча встроенных утилит в любом движке, которые говорят где проблема по скриптам. Основная засада для низкопроизводительных машин это с батчами бороться и подбирать адекватный рендер пайплайн с постпроцессингом.
Короче в статье нет ни слово из реальной практики.
ещё комментарии
ещё комментарий
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку