Мифы и заблуждения программиста игр

Как не заблудиться в трех соснах

Валерия Пудова

💬 Telegram: @valery_h2w

✉️ Email: valery.hww@gmail.com

📅 09.05.2022

Аннотация: Человек постоянно ошибается — не ошибается тот, кто ничего не делает. И даже лучшие из нас — опытные профессионалы — могут совершать досадные ошибки и заблуждаться. Этот документ описывает те расхожие заблуждения и ошибочные мифы, с которыми мне довелось столкнуться в профессиональной деятельности при разработке игровых проектов.

Введение

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

Значимость программирования преувеличена

Лучшие мировые специалисты сформировали культовый образ разработчика ПО в массовой культуре. В результате внутри игровых студий программисты нередко начинают восприниматься как «элита» команды, а все остальные создатели контента отодвигаются на второй и третий план. Чтобы вернуть баланс, достаточно честно ответить на вопрос: «Что именно делает каждый участник команды?»

• Художник делает все, чтобы игра была красивой.
• Аниматор делает все, чтобы мир двигался и оживал.
• Геймдизайнер делает этот мир увлекательным.
• Программист делает этот мир работоспособным.

Отсюда следует ключевой вывод: основная задача игрового программиста — создать такие инструменты разработки для дизайнеров, которые раскроют их креативность. Инструменты должны позволять им максимально быстро и автономно проверять любые гипотезы, чтобы в итерациях добиться самого увлекательного геймплея

Проблема трех больших заблуждений

Существуют три фундаментальных заблуждения, наиболее распространенных в среде разработчиков ПО.

Заблуждение 1: Программная среда — это платформа

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

Пример: Игра пишется не «под Unity или Unreal», а под конкретную целевую платформу (будь то мобильное устройство, консоль или ПК). Архитектура рантайма обязана учитывать ограничения физического процессора, памяти и графического чипа конкретного устройства.

Заблуждение 2: Код пишется для симуляции мира

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

1. Проблема поддержки (Maintainability): Вносить изменения в динамическую симуляцию становится чрезвычайно трудно, код обрастает костылями.
2. Проблема понимаемости (Comprehensibility): Понимание структуры и потока данных критически важно для локализации и решения любой проблемы, а глубокие абстракции изолируют разработчика от них.

На самом деле симуляция интерактивного мира требует представить модель этого мира в виде чистых данных и эффективно трансформировать эти данные кодом во времени.

Заблуждение 3: Код важнее данных

Код пишется исключительно для того, чтобы обрабатывать, преобразовывать и подготавливать данные к выводу на экран или в динамики — и ни для чего более.

Задача программиста состоит не в написании объемов кода, а в грамотной организации структур данных. Код должен совершать только значимые, полезные трансформации. Поскольку идеальной абстракции в природе не существует, разработчик обязан закладывать в саму модель данных гибкость для будущих изменений

Идеализация модели

В реальном мире человеческий мозг привык к строгой классификации: «стол — это просто стол». Но в виртуальном мире между объектами одного типа часто нет вообще ничего общего.

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

Проведение прямых параллелей между объектами реальной жизни и виртуального пространства — это не более чем ментальная подсказка для упрощения мышления программиста. Для полноценного моделирования игрового мира требуется кратно больше специфических данных, не имеющих аналогов в реальности: состояния анимационных деревьев, конфигурации коллайдеров, параметры кастомизации, логика распределения урона. Чем ниже по уровням абстракции мы спускаемся, тем хаотичнее выглядит задача, пока мы не дойдем до уровня бит и регистров процессора. Модель виртуального мира не может быть такой же простой, какой мы воспринимаем реальность. Попытка построить «идеальную академическую модель» на верхнем уровне неизбежно ведет к критическому усложнению программного комплекса. В конечном счете эффективное моделирование игрового пространства всегда приводит к созданию монолитной структуры разнотипных, но связанных потоком исполнения данных. В виртуальном мире решения, которые кажутся игроку верхом реализма, на стороне движка выполняются банальной заменой одного объекта на другой (например, целая ваза в кадре мгновенно подменяется набором осколков-мешей при получении урона) или простым запуском нужной анимации. Дизайнеры невероятно изобретательны в методах визуального упрощения моделей, тогда как программисты склонны усложнять их избыточным кодом. В такие моменты необходимо вовремя вспоминать фундаментальный принцип KISS.

«Всё должно быть сделано настолько простым, насколько это возможно, но не проще». — Альберт Эйнштейн

Ловушка зоны комфорта

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

При этом молодые, но талантливые разработчики часто с необъяснимым упорством запирают себя в рамках одного языка, одной привычной среды разработки и одной ОС. Свое нежелание расширять инженерный кругозор они оправдывают мнимым «совершенством» выбранного инструментария.

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

Дилемма высокого или низкого уровня

Программисты часто разбиваются на два непримиримых лагеря:

1. Высокоуровневый подход: Нужно абстрагироваться от железа, фокусироваться на чистой бизнес-логике, доверив всю оптимизацию и черновую работу компилятору и системным библиотекам.
2. Низкоуровневый подход: Код обязан создаваться с жестким пониманием платформы, которая будет его выполнять, то есть на уровне управления памятью, кэш-линиями и регистрами.

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

Ошибка архитектора

Программисты по своей природе — прирожденные архитекторы. Там, где требуется спроектировать сложную логическую систему, они выполняют задачу блестяще. Опыт, бэкграунд и инженерная культура заставляют их кропотливо возводить монументальное и стройное здание новой архитектуры. Но ключевая проблема в том, что игра в целом — это не классическая статичная информационная система. Игра в целом — это сложнейшая интерактивная анимация, работающая в реальном времени. А анимации и интерактивный отклик — это совсем не та область, где применимы законы построения жестких монолитных систем. Ситуация осложняется тем, что геймдизайнер на ранних этапах прототипирования физически не может точно знать, какое именно геймплейное решение сработает. Дизайнер всегда работает в циклическом, итерационном режиме: «сделали — покрутили в рантайме — посмотрели — улучшили/выбросили». Вместо того чтобы выдать дизайнеру простое, «грязное», но быстрое решение (минимально жизнеспособный прототип) для моментальной проверки гипотезы, программист принимается неделями выстраивать капитальное здание «идеальной архитектуры», безвозвратно теряя драгоценное время производства

Пренебрежение частным случаем

Представим ситуацию: программист пишет производительный код и искренне заботится о целевой платформе. Ему поступает геймплейная задача, которая со слов геймдизайнера кажется уникальной, изолированной и «встречающейся в игре всего один раз». Для экономии времени разработчик меняет свой строгий подход и решает её быстрым, но архитектурно неэффективным способом (например, через прямые ссылки или избыточные аллокации в куче). Однако по ходу развития проекта внезапно выясняется, что на новой локации — а что гораздо хуже, прямо в текущем игровом кадре — этот «уникальный» скрипт начинают использовать сотни и тысячи объектов.

Правило геймдева: Встретил задачу один раз — встретишь её еще множество раз.

Решай любую локальную задачу так, как будто аналогичных объектов в сцене будет колоссальное количество. Всегда держи в уме и используй пулы объектов (Object Pools), гомогенные массивы данных (Homogeneous Data Arrays) и принципы ориентированного на данные проектирования (Data-Oriented Programming / DOD)

Преувеличение значимости ООП

Современные мультипарадигменные языки программирования позволяют гибко комбинировать подходы. Мы можем спроектировать производительный модуль в функциональном или Data-Oriented стиле. Однако Объектно-ориентированное программирование (ООП) настолько популяризировано, что разработчики по умолчанию выбирают исключительно его, даже там, где оно неуместно. При таком слепом выборе во главу угла ставится компактность, иерархичность и читаемость кода, то есть исключительно удобство для самого программиста. Безусловно, в этом есть смысл, ведь согласно золотому правилу чистоты кода: «Программы пишутся в первую очередь для людей, которые их читают, и лишь во вторую — для машин, которые их исполняют». Но геймдев — это индустрия экстремальной производительности. Хороший инженер всегда трезво оценивает, какая именно парадигма программирования наиболее эффективна для вычислений в конкретной задаче, а не пишет весь проект по шаблонам ООП просто в силу привычки.

Преувеличение значимости инкапсуляции

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

Преувеличение значимости компиляции

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

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

Подобный страх перед интерпретаторами выглядит очень странно, учитывая исторический факт: подавляющее большинство мировых ААА-хитов создано с глубоким внедрением встроенных скриптовых движков и интерпретаторов (таких как Lua, Lisp/Scheme или кастомные байт-код машины).

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

Предпочтение исключительно инструментов с GUI

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

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

Программисты никогда не создавали бы избыточные GUI-окна, если бы сами регулярно использовали те утилиты, которые они пишут для геймдизайнеров. Чтобы сделать по-настоящему удобный графический интерфейс, необходимо написать тонны сопутствующего системного кода: продвинутый поиск, контекстную замену, системы отмены действий (Undo/Redo), валидацию ввода и так далее. Это сжирает огромные R&D-ресурсы. Во многих внутренних пайплайнах гораздо разумнее и эффективнее использовать структурированные текстовые файлы конфигурации (схемы). Ведь для текстового формата в мире уже созданы идеальные, развивающиеся десятилетиями графические интерфейсы — профессиональные текстовые редакторы (Emacs, VS Code, Vim), где из коробки есть все мыслимые инструменты автоматизации

Любовь к визуальному программированию

Программисты и геймдизайнеры часто проявляют удивительную солидарность в том, что графическое программирование (визуальные графы логики, блюпринты) — это однозначный путь к успеху. Мотивы у сторон разные:

• Для программистов наличие графов — это легитимный способ полностью делегировать рутинные, неинтересные им геймплейные задачи дизайнерам.
• Для дизайнеров это долгожданная автономность и тотальный контроль над процессом. С такой системой они чувствуют себя уверенно, зная, что могут быстро собрать рабочую сцену без участия программиста.

Отчасти это работает именно так. Однако у слепого внедрения визуального программирования во главу угла есть тяжелые долгосрочные последствия:

• Проблема читаемости: По мере масштабирования и усложнения игровых механик аккуратный граф неизбежно превращается в нечитаемое «спагетти» из связей.
• Проблема производительности: Автоматически сгенерированный под капотом графа код часто работает критически медленно и неоптимально расходует оперативную память.
• Проблема ограниченности: Инструментарий визуального языка всегда концептуально беднее, жестче и медленнее развивается, чем синтаксис текстового кода.
• Проблема коллаборации: Графы чаще всего сериализуются в тяжелые бинарные или сложно структурированные файлы. Их невозможно нормально сливать (merge) в системах контроля версий, из-за чего совместная одновременная работа нескольких человек над одним графом превращается в кошмар.

Эффективной альтернативой является интеграция легковесного текстового интерпретатора (например, Lua), либо грамотный гибридный подход: визуальный граф используется исключительно как высокоуровневый конечный автомат состояний (FSM), а вся внутренняя тяжелая логика узлов пишется программистами текстом

Пренебрежение документацией

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

Если вы стремитесь к стремительному профессиональному развитию — приучайте себя документировать архитектуру так, чтобы ею было удобно, легко и приятно пользоваться всей команде.

Ловушка «Я не хочу делиться тем, что знаю сам»

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

1. Командный результат: Создание современной игры — это строго групповой процесс. Итоговое качество продукта и стабильность рантайма будут определяться квалификацией самого слабого и неопытного разработчика в команде. Обучая коллег, вы напрямую застрахуете себя от ночных дебагов.
2. Профессиональный долг: Наш личный багаж знаний и глубокий опыт сформировались не только благодаря упорству, но и потому, что когда-то старшее поколение инженеров открыто делилось знаниями с нами. Обучать молодых специалистов — это наша прямая обязанность по сохранению инженерной культуры.
3. Эффект обратной связи: Обучая других и раскладывая сложные концепции на простые составляющие, учитель сам начинает глубже и чище понимать свой собственный предмет разработки.

Необоснованный скептицизм

В R&D-практике регулярно возникают нетривиальные задачи, которые с наскока решить невозможно. Это абсолютно нормальный рабочий процесс, но реакция специалистов на такие вызовы кардинально различается. Очень часто программисты (включая статусных сеньоров) включают защитную реакцию и начинают безальтернативно отрицать саму физическую возможность решения задачи, даже не попытавшись провести первичный анализ (RND). Они готовы тратить дни на написание отчетов и доказательств того, почему задача «невыполнима». Но парадокс в том, что в итоге красивое инженерное решение все равно всегда находится. В коммерческой разработке кратно комфортнее и эффективнее работать с теми людьми, кто изначально нацелен на поиск путей решения, а не на сбор доказательств невозможности его реализации. Позитивно и гибко настроенные разработчики показывают на дистанции колоссальную продуктивность и развиваются как профессионалы в разы быстрее скептиков.

Культура недоверия и страх ошибок

В индустрии нет людей, которые никогда не ошибаются. Но встречаются люди, органически неспособные признавать свои промахи. Страх уронить свой дутый «авторитет» в глазах коллег бывает настолько велик, что заставляет человека упорствовать в своем заблуждении, совершая ошибку за ошибкой и блокируя развитие проекта. Инженер, который открыто признает: «Я этого не знаю / я этого сейчас не понимаю», обучается и растет с космической скоростью. Ему не страшно довериться экспертизе коллег, чтобы вместе докопаться до сути проблемы и прийти к элегантному решению. Каждому из нас нужно непрерывно учиться слушать, слышать и доверять своей команде.

Отсутствие целостного взгляда на проблему

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

1. Исходный баг в реальности не был устранен, либо исправился лишь частично, для узкого частного случая.
2. Локальная правка нарушила логику связанных модулей, что вызвало каскад новых критических багов в совершенно других частях проекта.

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

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

В какой день недели всё-таки начинается понедельник?

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

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

1. Ваш первоначальный прогнозируемый срок.
   1. Реальный фактически затраченный срок по факту закрытия таски.
   2. Детальную причину задержки (что конкретно вы не учли на этапе планирования — непредвиденные аллокации, чужой баг, плохой рефакторинг).
   3. Физический объем результата: количество созданных/измененных файлов, классов, чистых строк кода.

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

Данность или развитие?

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

Истинное развитие требует колоссальных осознанных усилий. В них нет никакого ментального смысла для того, кто считает, что уже «всего достиг» и является идеальным. Качественно и непрерывно развиваются только те специалисты, кто обладает здоровой инженерной самокритикой и считает свой текущий уровень знаний недостаточно хорошим для вызовов будущего.

Всегда ориентируйтесь на вектор перманентного развития, а не на статичную данность текущего статуса

Заключение

Подводя итог, можно сформулировать ключевой свод целей и векторов для непрерывного и эффективного профессионального роста игрового программиста:

1. Расширяйте инженерный кругозор: Системно изучайте новые парадигмы, языки программирования и инструменты, выходя из привычной зоны комфорта.
2. Помните о клиенте: Делайте абсолютно всё, что в ваших силах, чтобы оперативная работа геймдизайнеров была максимально продуктивной, автономной и креативной.
3. Соблюдайте баланс уровней: Умейте ювелирно балансировать между высокоуровневыми абстракциями логики и низкоуровневой оптимизацией под целевое железо.
4. Управляйте сложностью: Никогда не идеализируйте архитектурную модель и не усложняйте решение сверх необходимого. Свято чтите принцип KISS.
5. Фокусируйтесь на сути: Первостепенно отвечайте за проектирование чистых и производительных данных модели, а не за объемы обслуживающего их кода.
6. Выбирайте парадигму осознанно: Трезво приоритезируйте и комбинируйте возможности языков (ООП, DOD, функциональный стиль) под конкретную физическую задачу.
7. Экономьте R&D-ресурсы: Проектируйте инструменты разработки эффективными и быстрыми, сводя к минимуму временные затраты на создание тяжеловесных кастомных GUI там, где можно обойтись структурированным текстом.
8. Пишите документацию: Создавайте исчерпывающую, понятную техническую документацию — как для кристального планирования архитектуры, так и для быстрого онбординга коллег.
9. Делитесь экспертизой: Не замыкайте знания на себе, активно обучайте и менторите свою команду.
10. Будьте нацелены на решение: Всегда ищите инженерные пути реализации любой сложной проблемы, а не тратьте силы на доказательства её нерешаемости.
11. Доверяйте команде: Учитесь слушать коллег и доверяйте их экспертизе — это фундаментальный маркер инженера высочайшего уровня.
12. Вникайте холистически: Всегда глубоко анализируйте первопричины багов в масштабе всей системы и подвергайте фиксы тотальному тестированию.
13. Уважайте сроки: Учитесь прецизионно оценивать графики работ и железно выполнять свои обязательства перед продакшеном.

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

Что было улучшено при редактуре

1. Терминология: Словосочетания вроде «objects pools, homogenous data arrays» заменены на принятые в русскоязычной инженерной практике термины в единственном числе: «пулы объектов (Object Pools), гомогенные массивы данных (Homogeneous Data Arrays)».
2. Исправление слияния слов: Устранены технические артефакты PDF-сканирования, такие как «Программнаясреда», «в репозитарий» (исправлено на «в репозиторий»), «оobjects».
3. Стиль: Предложения со сложной структурой переформулированы для достижения строгого, но живого и авторитетного технического слога.

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