Почему инди игры так сильно лагают?
Всем привет, коротенькая статейка для общего понимания темы начинающими разработчикам и геймерами. Не претендует на звание ключевой мысли и написана для базового пояснения сути оптимизации в играх, но основана на моём опыте работы с инди командами в кач-ве фрилансера.
(Можно было бы отфотошопить картинку и дописать, когда пое на секунду фризануло в 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. Не идите дети в разработчики игр, если не готовы въебывать как проклятые изучая гору инфы и разочаровыватся в собственных силах.
Лига Разработчиков Видеоигр
8.5K постов23.1K подписчиков
Правила сообщества
ОБЩИЕ ПРАВИЛА:
- Уважайте чужой труд и используйте конструктивную критику
- Не занимайтесь саморекламой, пишите качественные и интересные посты
- Никакой политики
СТОИТ ПУБЛИКОВАТЬ:
- Посты о Вашей игре с историей её разработки и описанием полученного опыта
- Обучающие материалы, туториалы
- Интервью с опытными разработчиками
- Анонсы бесплатных мероприятий для разработчиков и истории их посещения;
- Ваши работы, если Вы художник/композитор и хотите поделиться ими на безвозмездной основе
НЕ СТОИТ ПУБЛИКОВАТЬ:
- Посты, содержащие только вопрос или просьбу помочь
- Посты, содержащие только идею игры
- Посты, единственная цель которых - набор команды для разработки игры
- Посты, не относящиеся к тематике сообщества
Подобные посты по решению администрации могут быть перемещены из сообщества в общую ленту.
ЗАПРЕЩЕНО:
- Публиковать бессодержательные посты с рекламой Вашего проекта (см. следующий пункт), а также все прочие посты, содержащие рекламу/рекламные интеграции
- Выдавать чужой труд за свой
Подобные посты будут перемещены из сообщества в общую ленту, а их авторы по решению администрации могут быть внесены в игнор-лист сообщества.
О РАЗМЕЩЕНИИ ССЫЛОК:
Ссылка на сторонний ресурс, связанный с игрой, допускается только при следующих условиях:
- Пост должен быть содержательным и интересным для пользователей, нести пользу для сообщества
- Ссылка должна размещаться непосредственно в начале или конце поста и только один раз
- Cсылка размещается в формате: "Страница игры в Steam: URL"