Относительно недавно на CatGeek опубликовали заметку о причинах плохой оптимизации в играх

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


Относительно недавно на CatGeek опубликовали заметку о причинах плохой оптимизации в играх. И мне хотелось бы вставить свои пять копеек на этот счёт.

Ещё лет 20 назад, чтобы разработать игру, требовались серьёзные глубокие знания языков программирования, особенно низкоуровневых. Нужно было понимать, что такое процессор и что в нём происходит. Зачем нужна кэш-память и как можно ей грамотно пользоваться. Зачем несколько лет назад придумали видеокарту и как ускорить вычисления с её помощью. Понимать, что операционная система — это не магическая коробка (хотя и не без этого), а вполне себе инструмент, к которому можно и нужно обращаться напрямую через её API. Понимать, что такое память и как она работает, как она выделяется, что такое стек, что такое куча, не бояться использовать указатели и писать ассемблерные вставки, где это необходимо. Да, господи, тебе нужно было знать Си. А ещё иметь хорошие знания в области математики и, что самое важное, линейной алгебре.

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

Но шли года, и инструменты развивались. Появились безусловно крутые языки программирования, с помощью которых можно сделать кучу классных штук довольно просто. Особенно это заметно начинающему разработчику, когда он сравнивает программирование на чистом С/С++ с С# или Python. Но у них всех есть большой изъян — вы не можете контролировать то, что происходит у них «под капотом». Аналогичная история и с крупными игровыми движками (Unity, Unreal): да, там в теории можно переписать исходники, но разобраться, что там происходит, переделать что-то под себя и сделать так, чтобы эти нововведения не сломали ничего в самом движке — это постараться нужно, не говоря уже о количестве потраченного на это сил и времени.

Все инструменты, паттерны, структуры данных, алгоритмы — всё пытается быть универсализированным, всё запихивается и обмазывается поверх миллиардом абстракций, чтобы тебе было приятно и удобно писать. Вот только всё это ни капли не бесплатно. Всё это жрёт время твоего процессора. Всё это скрывает от тебя работу с памятью и ВАЖНЕЙШИЙ момент, связанный с обработкой данных на процессоре, — кэш попадания.

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

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

Приведу цитату из книги Джейсона Грегори «Игровой движок. Программирование и внутреннее устройство»:

«Можно с уверенностью сказать, что чем более универсален игровой движок или компонент промежуточного программного обеспечения, тем менее он оптимален для запуска конкретной игры на конкретной платформе. Так происходит потому, что разработка любого эффективного компонента программного обеспечения неизменно влечет за собой компромиссы, основанные на предположениях о том, как будет использоваться программное обеспечение, и о целевом оборудовании, на котором оно будет работать.»

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

https://www.youtube.com/watch?v=rX0ItVEVjHc#t=1h16m17s

В этом видео примечателен один момент, когда в конце какой-то дедок задаёт вопрос, который можно перефразировать так: «И что с того? Мы хотим писать код быстрее, это важнее для нас, как для разработчиков».

И ведь действительно, а в чём он не прав? Так писать дешевле и быстрее. Не нужно искать крутых спецов или долго и упорно подтягивать знания текущих работников. Потому что многие эти знания на данный момент уже не нужны для того, чтобы написать игру. Есть инструмент, и он работает, да, медленно и не без проблем, ну и что, ведь так у всех. Значит, игру купят. Разработчики и издатель деньги получат. А ситуация не изменится.

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

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

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


Источник: www.youtube.com

Комментарии: