Комикс: Технический долг в разработке игр
Откопала классное видео от образовательного канала Extra Credits, в формате «как объяснить, что такое технический долг даже ребёнку». Ну, или очень далёкому от этого взрослому. Мне так понравились иллюстрации, что я сделала из этого видео комикс. Покажите его своему менеджеру, когда он/она будет пытаться воткнуть новые фичи в спринт и забивать на внесения техдолга в бэклог.
Вы запускаете новый проект, всё идет отлично. Вы пишете код, создаете контент и арты. Но прямо перед самым завершением, когда думаете, что почти закончили, начинается ад.
Ошибки, которые вы планировали исправить за пару минут занимают часы. Каждая известная бага превращается в две неизвестных.
Контент не сочетается друг с другом. Вообще все ваши ассеты не сочетаются друг с другом. И самое ужасное, что нет ни времени, ни денег, чтобы что-то изменить.
Что произошло?
Наступил срок погашения технического долга.
Технический долг — это то, что происходит, когда проблемы, возникшие на раннем этапе разработки, не решают.
В результате чего их решение становится гооораздно сложнее или дороже.
Потому что технический долг работает почти как финансовый долг.
Если кредит не погашен, проценты будут расти, до тех пор, пока долг не окажется намного выше первоначального займа.
С точки зрения разработки игр, небольшая проблема может расти и расти, и никто этого не заметит, пока не станет слишком поздно или сложно ее исправлять.
Решение устранить проблему сразу или оставить на потом — вопрос, с которым сталкивается каждая команда разработчиков.
Это компромисс. На раннем этапе важно быстро наладить работу нового функционала, так дизайнеры и художники могут начать создавать контент. Однако это может привести к тому, что функции будут спроектированы без учёта потенциальных ошибок.
Это не говоря о том, что технический долго не ограничивается простым написанием кода.
Дизайнеры могут собирать уровень без какой-либо структуры, художники могут отправлять ассеты с чрезмерным количеством полигонов или дефектами текстуры. Когда проект только начинается, на эти ошибки обычно не обращают внимания, т.к. они никому особо не мешают.
Все предполагают, что ошибки обязательно исправят. Потом. Кто-нибудь другой. Этот кто-нибудь обязательно займется проблемами в будущем. Ну, или пока просто никто в команде не знает, как исправить эти ошибки. Команда просто двигается дальше.
Это проблема, т.к. стоимость повторного выполнения некоторых работ на поздних этапах проекта растет экспоненциально.
Многие критически важные системы могут опираться на забагованный код. Исправление, которое раньше заняло бы у разработчика 30 секунд, потенциально может поломать всю игру, а на поиски решения могут уйти недели. Может даже программист, который это написал, уже не в команде.
Или на уровнях перемешаны сотни или тысячи объектов с плохими названиями. Раньше, чтобы найти какой-то объект на уровне у художника или дизайнера уходило несколько секунд, сейчас на это уходят уже минуты. Суммируясь, эти минуты превращаются в часы потраченного впустую производственного времени.
А еще проблема не всегда выглядит как проблема.
Возможно, ваш дизайнер великолепно властвует над хаосом. Но как только в проекте появляются другие люди… им… приходится тяжко. Тоже самое с плохо комментируемым кодом или неорганизованными ассетами.
На организацию всего проекта на позднем этапе могут уйти часы, дни и даже недели.
Другие причины технического долга — планирование.
Когда у разработчика есть жесткий дедлайн для завершения большой фичи, ему придется срезать все углы, чтобы успеть вовремя реализовать функционал. И те решения, которые разработчик в принимает, будет трудно или даже невозможно отменить.
Например, программистам поручают создать вражеский ИИ. Им говорят, что игра только для одного игрока.
Программисты создают систему искусственного интеллекта, полностью ориентированную на реакцию одного игрока-человека.
Теперь предположим, что кто-то над ними принял решение, что игра будет кооперативной и многопользовательской.
Разработчикам придется переделать всю систему так, чтобы ИИ мог правильно реагировать на нескольких игроков.
Не говоря уже о том, что дизайнеры уровней разместили ИИ на уровнях в соответствии с его изначальным функционалом. Так что теперь им, возможно, придется перепроектировать куски уровней, чтобы компенсировать это.
Как для разработчиков, так и для дизайнеров, теперь все эти спагетти — помеха в работе с другими функциями или контентом. Приходится постоянно сдерживать этот поезд, катящийся в Ад.
Технический долг может стать настолько неуправляемым, что команда отложит релиз игры на неопределенный срок или полностью отменит. Иногда костылей столько, что проще выбросить всё и начать сначала.
Но с другой стороны, бывают случаи, когда есть обоснованные причины не сильно заботиться о техническом долге.
Прототипы игр часто лепят из чего попало, чтобы протестировать ранние концепции и идеи или оценить, стоит ли детально изучать эти идеи.
Нет смысла создавать и идеально подгонять систему для прототипа. Особенно, зная, что её спишут после одного игрового теста.
Некоторые студии даже отказываются от прототипов и начинают всё сначала, когда переходят к реальному производству. Иногда у них даже есть отдельные команды для прототипирования и для продакшена.
Иногда ошибки оставляют осознанно, если считают, что слишком дорого их исправлять или они не сильно влияют на игровой процесс.
Ошибку, которая полностью ломает игру каждый раз, когда возникает, важнее исправить, чем странный графический сбой, который случается только время от времени.
Игру можно допатчить после выпуска. Вы удивиться, узнав, как часто игры релизят под девизом: «грузим сейчас, фиксим потом» в связи с праздничными днями или крайними сроками продажи.
Так что не принимайте решения легкомысленно. Все мы знаем, как иногда существующая база игроков может… «реагировать» на эти изменения.
Минимизация технического долга — огромная проблема. Никто не может точно знать, что произойдет в будущем. Лучший способ справиться с тех долгом — просто осознавать, что это скорее всего произойдет. Но есть способы уменьшить потенциальный долг.
Выбирайте хорошие методологии работы в начале проекта. И придерживайтесь их.
Гайды и регулярные код-ревью могут показаться пустой тратой драгоценного времени на раннем этапе. Не говоря уже о том, что программисты будут ворчать по этому поводу. Но несколько минут на порядок или правильную организацию ассетов сэкономят огромное количество часов работы, когда вы будете завершать игру.
Выбирая, как потратить драгоценное время вашей команды разработки, помните: если у вас нет времени сделать это правильно, у вас не будет времени сделать это заново.
