Комментарии 59
В одном из докладов на GDC по Uncharted, разработчики привели замеры, что 80% процентов времени игра проводит в таком коде, и только 20% в общем. Этот низкоуровневый код, быстрее обычного в десятки если не сотни раз, и если скорости мешает архитектура и какие-то правила написания совершенного кода, то и архитектура и правила идут лесом...
С другой стороны, следует намерное отметить что процент такого кода в проекте очень мал, в отличие от "общего кода".
Блюпринты надо бы уже в 3д пространство переводить. Реально проще будет разбираться.
Прекрасная статья.
Хочется добавить, что большинство проблем с производительностью вообще почти не связана с проблемами движкового или высокоуровнего кода (хотя и бывает)
Основные проблемы с последними поколениями инструментов случаются из-за отрыва разработчиков игры от понимания сложности.
По сути дизайнер уровень может зафигячить 100500 систем частиц и мешей и ему за это ничего не будет на мощной машине. Но на устройстве игрока это будет кряхтеть.
И не важно, насколько оптимален и великолепен код системы частиц. Если смасштабировать его на Х - он будет тормозить потому что производительность не резиновая.
что большинство проблем с производительностью вообще почти не связана с проблемами движкового или высокоуровнего кода (хотя и бывает)
Хм, ну на деле игра в документации указывает минимальные и рекомендуемые требования, так что это вообще не проблема игры.
Сомневаюсь, что дизайнер уровней реально так далек от понимания сложностей, и архитектор не выдавал свои рекомендации на сегодня.
Примерно.
Конечно же люди понимают, что их контент может ухудшить производительность, просто иногда им не с чем сравнить.
Видел это много раз, особенно в мобильной индустрии, когда изначально проблем нет и никто не видит их источников (потому что это обычная 2д игра), но после того, как все соберут свои разношерстные фичи - работает хорошо только в редакторе.
И оптимизация имеет убывающую полезность, потому что источники проблем слишком размазаны по самым разным фичам игры.
Иногда у тебя просто нет выбора - платформа уже выпущена и не может быть производительнее.
Но точно так же менеджмент может просто поставить плашку с другой производительностью / удалить старые устройства из поддерживаемых
Ой всякое бывает.
Мой любимый пример из моего геймдев-опыта. Игра - арканоид для какой-то из консолей. Начинает лагать, хотя графика довольно простая. Начинают разбираться в чем дело. Выясняют, что площадка уровня, по которой катается мячик, засеяна травой и цветочками. Цветочки эти занимают на экране по паре пикселей каждый, но вот 3д модель цветочка имела в себе полторы тысячи полигонов. Для сравнения столько полигонов в модели игрока в CS 1.6. А это середина-конец нулевых, для консолей это много, учитывая что этих цветочков в кадре сотни.
Оказывается художнику дали задачу - нарисовать цветочек. Ну он и нарисовал красивый цветочек как мог. Никто же не сказал, что этот цветочек игрок разве что с лупой на экране разглядит, и детализация там не нужна.
Из недавнего, что запомнилоь - вышел новый Cities Skylines 2, градостроительный симулятор. Т.е. игра, где игрок 90% времени смотрит на город с высоты птичьего полета, а люди и машины на улицах для него кажутся мелкими букашками. Но выяснилось, например, что в моделях прохожих на улице честно была смоделирована челюсть со всеми 32 зубами. Причем даже LOD были не сделаны или не настроены, то есть когда игрок с высоты в километр смотрел вниз на миллионный город, компьютер скрипя видеокартой и жужжа кулерами честно пытался отрендерить все эти миллионы зубов во ртах всех видимых внизу пешеходов.
В общем, какой уж тут C++. Супер-оптимизированный код на нижнем уровне тут скорее помогал до последнего прятать проблему, вытягивая рендеринг даже настолько не оптимальных сцен до уровня, на котором разработчики предпочитали на проблему забивать.
Помимо зубов там раскопали еще вазы в шкафах на 2-3к полигонов, в комнатах, куда 99.9999% никогда не заглянут. Я думаю либо намеренно так, либо недосмотрели
Оказывается художнику дали задачу - нарисовать цветочек. Ну он и нарисовал красивый цветочек как мог. Никто же не сказал, что этот цветочек игрок разве что с лупой на экране разглядит, и детализация там не нужна.
Так ведь художник не виноват, ему задачу не уточнили, или вообще описали некорректно. И дизайнер скорее всего не виноват, он мог не понимать что простенький маленький цветочек это полторы тысячи полигонов, может он думал что там спрайты.
Виноват архитектор или менеджер, который ставил задачи =)
Я думаю, если бы художник знал, что его цветок будет использован на фоне, в маленьком размере и во множественном количестве, он бы его вообще растром нарисовал.
Я подозреваю, что он просто не знал как будут использовать его наработку.
Могли бы отскейлить до нужного размера и конвертнуть в спрайт для простоты.
Ну не верю, что кто-то будет тратить время на полторы тысячи полигонов, зная о том как будет использован данный объект.
Опыт в геймдеве геобязателен. Если делать, например, мультфильм, то количество полигонов тоже имеет значение -- не у всех студий есть бюджет рендерить 100500 полигонов. Так что даже без опыта в геймдеве художнику стоило спросить про бюджет полигонов. Но причины почему не спросил могут быть разными - тут я не знаю.
Так и ответить. На персонажей первого плана A полигонов. На персонажей второго плана B полигонов. На кубики C полигонов. Разумеется, должен быть документ, описывающий какие персонажи первого плана, а какие - второго. Поэтому этап подготовки и планирования и может заниметь больше времени, чем производство. Нужно всё обдумать и прописать в ТЗ, что требует знаний и времени.
Ну и да и нет.
Все же если отправляешь человека в магазин, то ожидаешь, что он знает, как обращаться с деньгами и пакетами.
Соответственно и художник с каким никаким опытом должен это понять.
Другое дело, что иногда бывают разрывы, когда художнику не сказали контекста, или цветок был сделан для рекламного рендера а потом решили переиспользовать и т.д.
У кого-то из наших разработчиков игр (чуть ли не у Кранка из KD Labs) видел мнение, что у разработчиков должны быть самые мощные компы на данный момент. Потому что пока игра выйдет - они и до пользователей доберутся.
В принципе оно так и есть, у меня сейчас машина 13900к/64гб/4070, и она не то чтобы хорошо тянет редактор, но учтите что в редакторе на два порядка больше объектов чем в игре
Даже пожалуй это разумно. По крайней мере было на некоторых проектах в определенный период.
Сейчас разница не столь драматична.
Но бейзлайн не всегда компьютер, соответственно про это нужно помнить при консольной разработке и, естественно, при мобильной.
применить возможности С++20/3 в разработке игр и движков получится хорошо, если с опозданием лет эдак в пять
Встречный вопрос, а чего вам так хочется из 20-го стандарта применить в реальном проекте, чего нет в 11-ом?
модули, концепты и улучшеные компайл тайм вычисления? попробовал модули в текущем проекте, минус одна минута на компиляции из шести. Концепты позволят убрать процентов 10 шаблонного кода, и компайл тайм по мелочи, вроде фичефлагов вместо дефайн вилок
Очень удобны без стековые корутины, для асинхронного программирования. Не уверен что в геймдеве можно будет применить.
архитект сказал в морг, 1. в движке уже есть свои, 2. общая реализация слишком тормозная и алоцирует память
На то они и безстековые, что просто память дёргают, а не штуки страшные таскают.
Имхо, то как можно сделать "сопрограммы" бесчисленное множество. Кто-то в своих движках вообще файберы реализует и им норм живётся.
Вопрос с выделением памяти решается переопределением оператора new.
Что означает Java с Nintendo на второй картинке? Для Switch можно писать игры на Java? Она поддерживает Android приложения? Гугл выдает только что-то про Minecraft.
А что кстати случилось с OpenGL? А то я такой соня, меня даже вчерашний шторм не разбудил. Геймдевом занимался лет 15 назад, тогда он еще как-то был жив. И мне нравилось наличие открытой альтернативы DirectX, хотя его уже тогда не любили многие за слишком низкоуровневость, странность в API и местами проблемы с поддержкой.
последняя спецификация 4.6 выпущена в 2017, активная разработка прекращена, разработчики ушли в вулкан. Новых версий не будет, только патчи для критикал уязвимостей, под эту дудку эпл официально отпилила опенгл из своих ос, оставив только метал, а майки перестали апдейтить либы в винде. По скорости работы opengl проигрывает dx/vulkan на порядок. Ну вот както так, а была действительно очень хорошая технология, и понятная, и работала везде.
эпл официально отпилила опенгл из своих ос
Вообще-то нет. Они примерно с 2011 года не обновляли спецификацию (v4.1), а в 2018 объявили deprecated, но он до сих пор поддерживается, при этом OpenGL на M1-маках уже работает через трансляцию в Metal.
Вулкан намного проще, понятнее, стабильнее и не имеет "магии", которая есть в OpenGL. На одном устройстве работает, на другом - нет, здесь оптимизация работает, здесь не пашет. Столкнулся с этим в OpenGL и перешёл на вулкан. Многословность кода и низкоуровневость с лихвой перекрывается стабильностью и лучшей поддержкой различных архитектур и устройств.
Отдельная плюшка - поддержка шейдеров из OpenGL и словоохотливость в ошибках вплоть до ссылки на документацию (если включена отладка).
OpenGL хорошо работает на маленьких проектах, либо при тестах на десятке устройств.
Кроссплатформенный Vulkan является официальным преемником OpenGL, для новых игр применяют его (в Windows конкурирует с Direct3D, а в macOS - с Metal). Хотя и OpenGL никуда не делся, его используют, например, в вебе. А низкоуровневость теперь везде, шейдеры отвечают за все.
Компиляторы для плюсов оптимизировались десятилетиями, чтобы получить соответствующую производительность на другом языке, ему тоже придется пройти этот путь, пусть не десятилетия, потому что база уже есть, но годы точно.
Пишешь фронт-энд для своего нового ЯП на LLVM и бонусом получаешь десятилетия оптимизации в бэк-энде. Разве не так?
Однажды команда, в которой я работаю, транспилировала скрипты игры в С, чтобы выжать ещё производительности.
А вообще, я полностью согласен с автором. В геймдеве вообще плевали мы на все этим ваши чистый коды, абстракцию данных, инкапсуляцию... Все принесено в жертву производительности. Почешите левой ногой правое ухо, но выжмите ещё несколько кадров
Ну хз, у нас код в скрипте при загрузке конвертился в код. В точнее в набор последовательных и параллельных команд. Игры работали нормально на четвертых пеньках и тогдашних встройках от интел. Зачем в рилтайме транслировать?
Очень интересно увидеть кухню изнутри. Спасибо. А я то себе придумывал, стану крутым прогером на С++, изучу последние стандарты 20/23 и как и с двух ног начну крутой код писать, мего-оптимизированный с новыми фишками, в какой-нибудь гейм дев...
Спасибо за статью.
Не самый жесткий пример кода
Что характерно, читаемый и логичный, если знать математику и 3D помимо C/C++.
Разрешите поинтересоваться, а на Си (без плюсов) сейчас хоть часть кода пишут, или используют просто как подмножество в рамках C++? Заглядывал в выложенные исходники DagorEngine, но Сишных файлов не получилось найти, хотя указано, что треть на Си (может либы с заголовками).
Как java backend developer'у чертовски интересно почитать такие вещи, к которым скорее всего никогда не прикоснусь)
Автор, спасибо!)
Спасибо за статью, очень интересно про современные тенденции. Хотя насчет скорости С++, лет 10-15 назад делал проект на микроконтроллере dsPIC с ЦОС, сначала в лоб на С написал - медленно. Использовал библиотечные Си функции ЦОС - получилось раза в 3 быстрее. Переписал на асм с учетом архитектуры и цос команд (умножение с накоплением с инкрементом адреса и т.д.) получилось раз в 20 быстрее изначального кода. Но это только обработка, основная архитектура все равно на Си осталась ибо писать это на асм - нафиг надо.
Каков C++ в gamedev'e?