Как работать с программистами?
Очень здорово, когда вы сами имеете навыки программирования и можете либо самостоятельно выполнять программную часть своего проекта, либо на равных разговаривать с программистами в процессе разработки. Это одна из тех причин, почему на вопрос «хочу поступить в ВУЗ, а геймдизайну нигде не учат, на какого специалиста лучше пойти учиться?», я всегда отвечаю - на программиста. Это не просто позволит вам выполнять сразу две роли, если вы решите разрабатывать собственный проект. Программирование учит дисциплинированности, структурированности, аккуратности, и внимательности. Что немаловажно, в процессе обучения вы развиваете хорошие аналитические способности, и отменное логическое мышление. Все эти качества крайне важны не только для программиста, но и для геймдизайнера. Именно этими навыками вам придется пользоваться в любой момент времени: будь то написание дизайн-документации, анализ игр-конкурентов, или написание технических заданий. С остальными сферами разработки дела обстоят легче: художественную часть вполне можно понять, музыку - тоже. Легко понять интерфейсы, более того, их можно протестировать на других, не задействованных в проекте людях. Но вот понять программную часть игры - это задача крайне нетривиальная.
У меня был разный опыт работы с программистами и, в отличие от художников, которых я систематизировала в обоснованную классификацию, разделив их по стилю работы (если вы еще не читали о том как работать с художниками, рекомендую ознакомиться вот с этой статьей), то среди программистов я могу выделить только два типа: открытые программисты и закрытые программисты.
Это может прозвучать смешно, но это действительно так. На вашем профессиональном пути будут встречаться специалисты, настоящие профессионалы, но какие-то из них будут идти вам навстречу, показывать что и как устроено в игре, искать в коде для вас ответы, а какие-то - говорить загадками и сердиться за каждый ваш вопрос. Независимо от отношения к вам, нужно уметь найти общий язык с каждым специалистом, правда, в каком-то случае это будет чуточку сложнее.
Почему программист закрывается, делая работу над программной частью мучительной для вас? Точного ответа на этот вопрос у меня нет, но есть кое-какие предположения, которые я сформулировала за 6 лет работы.
1. Постоянные переделки реализованных игровых механик.
Возьмем, к примеру, художника: давая ему задачу, вы можете внести в его работу коррективы на самых ранних стадиях, чтобы в итоге получилось то, что бы наибольшим образом соответствовало идеалу. С программистами такой подход не сработает: чтобы оценить работоспособность игровой механики, нужно сначала дождаться, пока программист выполнит свою работу на сто процентов, пофиксит возможные баги, и только после этого вы сможете поиграть в то, что получилось и оценить результат с точки зрения геймдизайна. Теперь представьте: вы поиграли в то, что придумали и вам не нравится, как это смотрится в игре. Вы переписываете фичу и ставите новую задачу, а программист, который сделал со своей стороны работу на отлично, вынужден ее снова переделывать.
Какие здесь есть решения?
Как ни парадоксально, но это решается тщательным продумыванием фич, которые вы планируете добавить в игру, и прототипированием. Делайте бумажные прототипы, или прототипы в специально приспособленных для этого тулзах. Кирилл Шабордин из Social Quantum рассказывал, что в их компании есть целый отдел, который занимается прототипированием и делает это не в среде разработки проекта, а с помощью стандартных ассетов Unreal. Подробнее можно почитать вот тут.
Но если вы все-таки совершили ошибку, от которой никто не застрахован. Некоторые вещи вообще сложно реализовать правильно с первого раза, потому что иногда для определения этой правильности надо провести тестирование с пользователями. В такой ситуации нужно объяснить программисту геймдизайнерские причины того, что пошло те так, объяснить почему переделанная механика будет лучше того, что есть сейчас.
2. Вы не интересуетесь программной структурой проекта.
Это проявляется следующим образом: вы придумываете механику, стараетесь, описываете ее, приносите программисту. Он читает и говорит, что так нельзя сделать, потому что у вас эти элементы отрисовываются на разных слоях, или принадлежат к одному и тому же типу объектов, или по какой-то другой причине. А вы ему и отвечаете: что еще за слои? Неудивительно, что программиста бесят такие вопросы от человека, который не разбирается в собственном проекте, но при этом говорит, что ему делать.
Какие здесь есть решения?
Перед тем, как описать какую-то фичу, надо потратить 5-10 минут на ее обсуждение с программистом. Возможно ли ее вообще реализовать? Сколько это займет времени? Как она будет работать? Что лучше изменить в вашей идее, чтобы можно было сделать ее просто и красиво вписать в уже существующий код? Все общие знания, которые вы получите в процессе, запишите в отдельную тетрадочку: все такие пояснения от программиста в конце концов сложатся в единую картину, дающую вам хотя бы поверхностное понимание того, как устроен ваш проект.
3. Руководствование только геймдизайнерской логикой при постановке задач.
Дело в том, что геймдизайнерская логика очень часто не совпадает с логикой программной. Вот вам простой пример: вы хотите добавить в игру сундуки, которые будут спауниться на локации и выдавать игроку при открытии какие-то бонусы. При этом сундуки будут открываться за ресурсы. Также вы хотите чтобы кроме сундуков на локации появлялись сорняки, которые игроку тоже надо будет убирать. С точки зрения геймдизайна это две разные сущности: одна приносит игроку радость, а вторая - раздражает. А с точки зрения программинга это может быть одна и та же сущность, только с разными картинками и разной ценой уборки.
Какие здесь могут быть решения?
В принципе, пункт про однобокую логику - это еще один аспект пункта номер два, про знание программной структуры проекта, решение у него такое же. Чтобы не попасть в подобную ситуацию нужно все тщательно обсудить и убедиться, что вы с программистом друг друга понимаете правильно.
Подводя итог скажу: программисты - очень умные, вдумчивые ребята, которые выполняют крайне сложную и серьезную работу. В коллегах программисты ценят такой же профессионализм и большой объем знаний, благодаря которому и сами коллеги будут разбираться в том, чем занимаются. Единственный способ завоевать уважение программиста - это разговаривать с ним на равных, понимая специфику его работы и при этом имея хороший багаж по своей собственной специализации. Сердце самого закрытого программиста можно растопить, показав, что даже если вы пока не до конца понимаете, что он делает, вы все же очень стараетесь понять и делаете в этом успехи.
Так как же выглядит задача для программиста?
Задача для программиста должна быть описана максимально подробно. И когда я говорю «максимально подробно», я подразумеваю, что должна быть описана каждая деталь фичи, даже та, которая кажется вам само собой разумеющейся. Любой пробел в описании может потом обернуться против вас: программист просто реализует то, что вы не конкретизировали так, как ему удобно, и когда вы придете с новой механикой, или доработкой по текущей, программист разведет руками и скажет, что сейчас этого сделать уже нельзя, потому что тогда он сделал так, как ему было удобнее всего, так что теперь все работает по совершенно другой системе. По факту, ТЗ для программиста - это очень детальное описание механики, которым будут пользоваться и геймдизайнер, и программист, так что вам даже не придется делать одну и ту же работу дважды, достаточно хорошо описать все с первого раза.
Вот некоторые моменты, которые нужно помнить при описании механики:
- Если механика очень большая, разбейте ее на составляющие - маленькие кусочки общей картины.
- Если в описании нужно указать какие-то моменты, не критичные для программиста, то можно сделать соответствующую пометку или комментарием на полях, или прямо в тексте. Как в примере с сундуками: «Нам нужен механизм спауна объектов на локации. «…» С точки зрения геймдизайна, объекты будут следующих типов»
- Если для описания механики нужно сделать какие-то иллюстрации - сделайте их.
- Ну и как всегда, золотое правило - сохраняйте структуру, пишите короткими абзацами, выделяйте главное - нет ничего хуже, чем механика, описанная огромными абзацами слитного текста.
Пример постановки задачи для программиста
Предисловие: это мини игра для визуальной новеллы.
Мини-игра: поиск предмета в ограниченном пространстве
Мини-игра по поиску предмета в ограниченном пространстве касается тех ситуаций, когда игрок обшаривает чужие карманы, ящики столов, письменные столы и прочие подобные моменты, чтобы найти искомый предмет по квесту. Эта мини-игра ограничена по времени.
Мини-игра представляет собой темное очертание кучи предметов, которые находятся на отрисованной и не затемненной, цветной сцене.
Все предметы нарисованы отдельно и имеют свою область тапа и затемнены как масса.
Когда игрок тапает и попадает в область конкретного предмета, он по альфе расцвечивается а затем снова по альфе затемняется.
Во время того, как предмет раскрашивается и затемняется, тапы на другие предметы не проходят.
Игра завершается либо по окончанию таймера, либо по нахождению нужного предмета.
Если игрок вышел из игры в процессе мини-игры, то она считается проигранной и при перезапуске приложения игрок возвращается к последнему чекпоинту.
Атрибуты мини-игры:
- id мини-игры
- id картинки, которая является сценой-подложкой
- галочка о наличии ограничения по времени
- время, которое отведено на игру (в секундах)
- время в секундах, за которое раскрашивается и закрашивается предмет (может быть дробным числом)
- id предмета, по нахождению которого игра останавливается (предметов может быть несколько)
Атрибуты предметов игры
- id картинки предмета
- координаты расположения предмета на сцене
- id связанного предмета инвентаря, который получает игрок
Алгоритм игры:
1, Игрок протапывает сцену, предшествующую игре
2. Открывается экран с игрой. Появляется подложка с затемненной кучей объектов на ней.
3. Иконка таймера анимируется (скейлится) и таймер запускается, начиная отсчитывать время до окончания игры.
--3.1. Если таймера нет, то пункт 3 пропускается.
4. Игрок совершает тапы по массе предметов, пытаясь найти нужный.
Игрок нашел нужный предмет:
1. Таймер останавливается и все остальные предметы расцвечиваются по альфе одновременно
--1.1. Если игра без таймера, то пункт 1 пропускается
2. Найденный предмет зумится и перемещается в центр экрана.
3. Вся остальная сцена заблюривается (размывается)
4. Над предметом появляется надпись «найдено *название_предмета*»
5. Появляется кнопка «Далее»
6. Игрок нажимает кнопку и выходит из игры.
Игрок не нашел нужный предмет (игра с таймером):
1. Таймер анимируется и перемещается в центр экрана
2. Появляется надпись «Время вышло»
3. Тап в любую часть экрана вызывает появление следующего слайда по сценарию, который как правило означает конец игры
4. По тапу на сцену, появляется экран загрузки и игрок возвращается к последнему чекпоинту в сценарии.
Алгоритм работы над задачей для программиста
1, Вы хорошо обдумываете новую идею, которую хотите внедрить в проект.
2. Очень схематично формулируете ее: либо в голове, либо на листочке.
3. Обсуждаете задачу с программистом, выясняете, насколько она реализуема, какие могут быть подводные камни, задаете интересующие вас вопросы.
4. Описываете механику настолько детально, насколько это возможно, расшариваете документ программисту, выделяя время на его изучение.
5. Программист оставляет комментарии в вашем документе, отмечает пробелы, непонятные, или неправильно описанные нюансы механики.
6. Вы снова собираетесь и проводите повторное обсуждение документа и комментариев программиста.
7. Вы вносите правки в документ и отдаете механику на реализацию.
