Task-based мышление в игровых движках
Игры всегда требовали высокой производительности системы, а игровые движки разрабатывались с учетом надлежащей поддержки многопоточных вычислений, чтобы задействовать все ресурсы компьютера. Но применение хороших абстракций сильно усложняет разработку и хотя многопоточность открывает очень широкие возможности в играх, проблем она также добавляет порядком. Вообще разработка любого софта с поддержкой многопоточности — это отдельный вопрос, и статей на эту тему написано немало. Здесь я решил показать основные шаблоны применения системы задач, которая с большой вероятностью будет реализована в любом игровом движке, ну а также их плюсы и минусы разных подходов.
Большинству игр «хватает» одного потока, это обычно подразумевает наличие главного треда, где выполняются все игровые задачи (обработка ввода, обновление мира, рендеринг и т. п.), для каждого кадра. И такая модель последовательных вычислений сохранялась очень долго, да и сейчас применяется в большом числе игр, особенно мобильных, задействую ресурсы одного ядра. Есть конечно хорошо выделяемые задачи, вроде загрузки текстур, звуков, но это скорее исключение, в силу обособленности данных для таких задач. Чтобы сделать исключение правилом разработчики игровых движков приучают пользователей этих самых движков разделять игровые «циклы» на независимые «задачи», которые могут выполняться отдельно в «менеджере задач», который уже в свою очередь может запускать их на разных ядрах. Профит тут конечно очевидный — параллельное выполнение — это основной фактор повышения производительности игр.
Что еще можно вынести в другой поток без особого ущерба для игры?
https://habr.com/ru/articles/861540/
#gamedev
👉 @game_devv
Игры всегда требовали высокой производительности системы, а игровые движки разрабатывались с учетом надлежащей поддержки многопоточных вычислений, чтобы задействовать все ресурсы компьютера. Но применение хороших абстракций сильно усложняет разработку и хотя многопоточность открывает очень широкие возможности в играх, проблем она также добавляет порядком. Вообще разработка любого софта с поддержкой многопоточности — это отдельный вопрос, и статей на эту тему написано немало. Здесь я решил показать основные шаблоны применения системы задач, которая с большой вероятностью будет реализована в любом игровом движке, ну а также их плюсы и минусы разных подходов.
Большинству игр «хватает» одного потока, это обычно подразумевает наличие главного треда, где выполняются все игровые задачи (обработка ввода, обновление мира, рендеринг и т. п.), для каждого кадра. И такая модель последовательных вычислений сохранялась очень долго, да и сейчас применяется в большом числе игр, особенно мобильных, задействую ресурсы одного ядра. Есть конечно хорошо выделяемые задачи, вроде загрузки текстур, звуков, но это скорее исключение, в силу обособленности данных для таких задач. Чтобы сделать исключение правилом разработчики игровых движков приучают пользователей этих самых движков разделять игровые «циклы» на независимые «задачи», которые могут выполняться отдельно в «менеджере задач», который уже в свою очередь может запускать их на разных ядрах. Профит тут конечно очевидный — параллельное выполнение — это основной фактор повышения производительности игр.
Что еще можно вынести в другой поток без особого ущерба для игры?
https://habr.com/ru/articles/861540/
#gamedev
👉 @game_devv
