Геймдизайнеру о программистах

Страница 2 из 3

Знайте о пользе сосредоточенности


Важный График

На Важном Графике нарисована примерная зависимость работоспособности программиста от того, как давно он в последний раз отвлекался от своей работы. Зависимость построена на примере программиста RPG-механики г-на Петрова, но может быть обобщена и на других.

Отвлечь от работы г-на Петрова может многое, но наиболее типичные случаи таковы:

  • Г-н Иванов, главный дизайнер проекта, приходит, чтобы сообщить Петрову о том, что курицы-NPC опять перестали клевать зерно
  • Некто говорит Петрову, что необходимо СРОЧНО выполнить какую-то другую мелкую задачу, например, написать письмо турецкому султану или оценить, за какое время он сможет воплотить такое-то изменение
  • Пришел очередной e-mail, о чем компьютер радостно извещает звуком и картинкой в tray
  • В комнате постоянно раздаются громкие вопли "ура" или "fuck", в зависимости от ситуации на фронте
  • В комнате кто-то громко ругается по телефону
  • Надо посетить проектное совещание на тему улучшения клевания зерна курицами, или какое-нибудь другое собрание
  • Microsoft Visual Studio опять зависла
  • Идет "раскачка" в начале рабочего дня
  • Наступил обед

Как легко видеть, взяв интеграл функции на Важном Графике, каждое из этих событий крадет у Петрова от 20 рабочих минут до получаса. Зная стоимость человеко-дня (а она складывается не только из зарплаты Петрова, но и из аренды офиса, стоимости компьютеров, налогов, и прочего менеджерского мумбо-юмбо), можно вычислить, что это "выброшенные в пропасть" примерно $2 - $7, то есть 50-200 рублей. Если вам нравится представлять все визуально, представьте баночку красной икры, со свистом улетающую... куда-нибудь.

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

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

Итого

  • Надо лишний раз подумать, прежде чем отвлекать программиста от работы. Помните, что любое отвлекающее от работы событие - это инвестиция от 50 до 200 рублей в мировой хаос
  • Лучше рассказать о новой задаче с помощью e-mail или на каком-нибудь собрании, чем прийти с ней к человеку в случайный момент времени
  • Намного лучше принести один раз десять вопросов и предложений, чем десять раз по одному
  • Не надо шуметь так, что в соседней комнате падают стулья
  • Не надо посылать коллегам в середине дня понравившиеся изображения голых баб или несмешные анекдоты

Следите за рискованными системами

В любом проекте есть сколько-то систем, ошибки в проектировании которых могут потребовать масштабных переделок. Мне известны следующие:

  • Поиск путей и передвижение персонажей. Связаны с риском почти всегда. Подавляющее большинство переделок или доработок этих систем, вначале кажущихся мелкими, выливается в чудовищные проблемы, по крайней мере, у программистов, а иногда у всего проекта
  • Сollision detection. Переделка того, как происходит collision detection, может в худшем случае потребовать переделать значительную часть уже готовых игровых уровней и моделей игровых объектов, сильно замедлить загрузку игры или надолго занять лучших программистов проекта непонятной эзотеричной работой
  • Загрузка уровня. Связана с риском, если есть random map generation, просчет чего-либо при загрузке карты, или подгрузка "на лету"
  • AI. Переделка AI может быть очень рискованной, если его действия сильно влияют на геймплей, или есть сложный сценарий, с которым действия AI должны быть согласованы
  • Любая из "главных фичей" игры рискованна
  • Любая система, которую раньше не делали, даже если кажется, что проблем быть не может
  • Система, с которой у вас раньше уже были проблемы
  • Любая другая система, на которую многое опирается
  • Любая сложная автоматика

При дизайне чего-либо, относящегося к рискованным системам, думайте дольше. Думайте заранее. Думайте вместе с программистами.

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

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

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

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

Думайте об инструментарии заранее

При создании игр обычно используются по крайней мере такие инструменты:

  • Редактор карт
  • Редакторы внутриигровой информации (диалогов, квестов, характеристик, персонажей и т.п.)
  • Asset pipeline

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

Создание качественной миссии в редакторе Starcraft занимает три рабочих дня. Как насчет вашего?

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

Обратная сторона проблемы заключается в том, что создание инструмента, хорошо подходящего для ваших нужд, стоит немалого времени и денег. Поэтому важно использовать как можно больше стандартных форматов и инструментов. Замечательно, если ваши миры и их наполнение можно создавать в Maya, Max, Photoshop, Visio, да в Notepad, в конце концов. Они существуют и развиваются долгие годы, по ним есть множество учебников и множество людей уже умеет работать с ними.

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

Знайте, как планируется работа программиста

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

Вот чем программерские оценки отличаются от дизайнерских и от артовых:

Во-первых, у нас работа менее предсказуема, поэтому оценка куда менее достоверна.

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

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

Навскидку можно предсказать число А с довольно высокой точностью, число В - с ошибкой в 1.5 - 2 раза в ту или иную сторону, предсказать число С очень сложно, а для некоторых тасков (обычно связанных с переделками pathfinding или других рискованных систем) вообще невозможно.

Для дизайнерских, артовых и прочих непрограммистских тасков первые два или даже все три числа обычно совпадают с хорошей точностью. Поэтому когда просят оценить задачу, неявно предполагают, что и тут будет то же самое. Это не так. Поймите это и не удивляйтесь, когда задача, оцененная в неделю, через месяц все еще толком не работает (число С). Ведь рабочего времени на нее потрачено только дней 8 (число В), а первая версия и впрямь была готова через неделю (число А). Лучше всего в самом вопросе уточнять, какое из чисел вам требуется узнать.

В-третьих, дизайнеры редко понимают следующий факт: если сделать 1 заклинание стоит 3 дня, то сделать 5 похожих заклинаний стоит вовсе не 15 дней, а скорее 5-6 дней. Это происходит даже не из-за batching'а (хотя он тоже влияет), но просто из-за того, что большую часть работы надо выполнить ровно один раз. Другими словами, программерские оценки неаддитивны. Время на то, чтобы сделать N задач, полезно оценивать не как С*N, а скорее как: С1 + С2*N, где С1 (время на подготовительную работу) часто существенно больше, чем С2 (время на каждую задачу). Тогда у вас будет шанс узнать, что, условно говоря, сделать 50 заклинаний всего втрое дольше, чем 5, и задуматься над этим.

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

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

Вранье и ошибки в оценках

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

Оценка больше, чем человеко-месяц, правдивой, как правило, не бывает. Она может означать, что трудозатраты вообще не получается оценить, так как слишком мало информации. Или что это на самом деле слишком неконкретная задача (типа "сделать миссионный интерфейс", про который еще не известно, как он будет выглядеть), и ее надо уточнить. Или что задача очень страшная, никто не понимает, как ее делать, и есть риск ее вообще не сделать. Или даже может значить "делать не буду, все вы меня задолбали". Но только не то, что задача действительно стоит N месяцев. Уточняйте, что имелось в виду.

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

Если задача очень рискованная (например, "полностью переделать то, как летают самолеты"), в оценках могут врать в сторону увеличения. Вернее, вам вполне могут сказать верхнюю грань, т.е. число С из прошлого пункта.

Если задача очень аппетитная, например, Умная Автоматическая Система Генерации Чего-Нибудь, или Продвинутый AI на Нечеткой Логике, то в оценках будут врать в сторону уменьшения, и говорить что-то вроде числа А из прошлого пункта, деленного на 2.

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

Batching

Большая часть работы программистов - это создание разных, непохожих систем. Но и у нас встречается что-то, похожее на asset'ы, то есть многочисленные однотипные задачи. Например:

  • Механика для 50 заклинаний
  • 25 интерфейсных экранов
  • 40 перков
  • 100 скриптовых функций
  • 100 правил и формул RPG-механики

И так далее. Удивительный факт: если все N однотипных работ записать как одну-единственную задачу, скорость работы над ней будет примерно втрое выше, чем если записать это как N задач (где N, как ни странно, целое положительное число, большее 5) и время от времени подкидывать программистам очередную. Этот эффект называется batching. Почему так происходит?

Вот как идет работа над подобной задачей:

  1. Прочитать спецификацию (или что-то вроде спецификации)
  2. Найти время и автора-дизайнера, чтобы обсудить непонятности и неточности
  3. Обсудить непонятности и неточности
  4. "Врубиться" или вспомнить, как же делаются подобные задачи
  5. Вспомнить или найти несколько мест в коде, в которые потребуется вносить изменения
  6. Сделать copy files и get latest version
  7. Сделать check out, надеясь, что visual studio не "повиснет"
  8. Собственно программирование
  9. Запустить редактор
  10. Прописать в базе какие-нибудь константы
  11. Собрать debug версию у себя на компьютере
  12. Запустить debug версию на тестовой зоне (это может оказаться довольно долгим процессом, т.к. debug версия тормозит гораздо сильнее обычной)
  13. Протестировать, найти ошибки
  14. Если есть ошибки, исправить
  15. Собрать release версию и проверить на нормальной сценарной зоне на предмет невыявленных ошибок
  16. Сделать check in
  17. Найти заказчика и оповестить его, что работа сделана

Так вот, при batching все пункты, кроме 8, 10 и 14, выполняются ровно один раз, а не десять (или пятьдесят). Замечу, что на пунктах 6, 7 и 16 Visual Studio как минимум жестоко тормозит, а часто и виснет, что в частности приводит к большому искушению бросить работу и начать читать Интернет, да и вообще уменьшает мировую гармонию.

Кроме этого, видя все задание целиком, легко даже в жирных пунктах заранее увидеть какую-то повторяющуюся работу. И сделать ее опять же ровно один раз, а не десять (или пятьдесят).

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

Почему же lead programmer не всегда организует работу так, чтобы произошел batching? Дело в том, что дизайнеры расставляют задачи согласно своим приоритетам. У задач, входящих в один batch, могут быть (и обычно бывают) совершенно разные приоритеты, вообще раздвигающие их выполнение на месяцы. Эти приоритеты, в общем, тоже не из пальца высосаны, так что идея выполнять такие задачи пачкой может вызвать искреннее недоумение.

Часто в планах milestone'ов, которые сдаются издателю, написано что-то такое:

Этап 1. Готово одно заклинание, одна спецвозможность и один тип строений
Этап 2. Готово три заклинания, три спецвозможности и три типа строений
Этап 3. Готово 10 заклинаний, 10 спецвозможностей и 10 типов строений
...
Этап Последний. Все заклинания, спецвозможности и строения готовы

Этап 1 действительно запланирован правильно: необходимо как можно раньше попробовать все и тем самым снять риски. Но начиная с этапа 2 программисты непонятно зачем будут работать неоптимально, и не отвертятся от этого никак (издатель уже требует версию!).

Скорость работы, меняющаяся втрое - что-то, что лучше не игнорировать. Поэтому в каждом конкретном случае полезно посоветоваться с lead programmer или с непосредственным исполнителем, чтобы узнать, насколько будет полезен batching в данном случае, и организовать работу именно так, чтобы использовать этот эффект.

Надо культивировать batching и стремиться к нему, или, во всяком случае, не ставить задачи в таком порядке, который "убивает" его напрочь.

Copyright © 2016 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение