Как обмануть себя и перестать бояться

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

Предыстория примерно такова. В геймдеве я с 2006 года. Прошёл полный путь от тестера, до продюсера, работая в известных и не очень компаниях над, в основном, никому не известными или давно забытыми играми. Так часто бывает. И была у меня распространенная среди геймдизайнеров, проблема: очень хотелось делать то, в чём руководство компании не видело смысла. Тут вообще много вопросов возникает к моим продюсерским умениям, но не о них речь. Особенно, учитывая то, что прямо продюсированием я занимаюсь не так давно (и тут мой внутренний голос такой: «На самом деле достаточно давно, ты никого не обманешь»).

Так вот под давлением желания сделать что-то своё я периодически брался за это неблагодарное дело. Но порой не хватало тех самых продюсерских навыков, чтобы ограничить как-то свои желания (да, я научился немножко кодить на AS3 и Python для сервера, но так и не придумал, что интересного я осилил бы сам сделать). Иногда приходили продюсерские навыки и «говорили», что пора заканчивать уже мучить тушку мегаоригинальной супер-пупер игры с механикой «Сапёра». Просто не придумал монетизацию.

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

Впрочем, один раз меня DTF все-таки засветили со статьей о «Поиске здорового метагейма», которую я написал по горячим следам, оставленным разработчиками из SuperCell в Твиттере. Ну и теперь у меня есть несколько глав книги про то, как вообще делаются компьютерные игры.

Моя проблема в плане самостоятельного творчества заключается в том, что мне совершенно не интересно то, что сейчас называется, инди-играми. Даже если они успешны. Последние лет восемь, наверное, я занимаюсь «социалочками», последние лет пять — «мобилками». Я любою F2P.

Мне нравятся игры, которые не пытаются меня сожрать или растрогать, а просто дают развлечься. Я не хочу нести никакого месседжа людям, по крайней мере, своими играми — у меня для этого книга есть. Я не хочу заниматься творчеством ради творчества. Да, у меня, как у любого нормального геймдизайнера, возникают в голове идеи каких-то злободневных игр, но мой внутренний продюсер говорит, что я это не сделаю, и не продам; не нужно тратить на это время.

Я хочу просто заработать денег сделав правильный продукт. Будь то в рабочее или в свободное время (если такое вообще бывает). Это довольно сильно ограничивает минимальные требования к игре, отметая всё, в чём я не разбираюсь хотя бы чуть-чуть.

Я довольно долго искал идею, которая удовлетворила бы моего внутреннего продюсера. Критерии же довольно простые: идея должна быть реализуема, идея должна иметь коммерчески успешные прототипы, я должен достаточно много времени с удовольствием наиграть в этот прототип, ну и у прототипа должны быть какие-то проблемы, которые я, вроде как, знаю как исправить. Да, тут всё на вере в себя держится. В общем, я решил делать ферму.

Если что, я делаю её с августа 2017 года.

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

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

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

У меня уже был некоторый опыт работы с Unity 3D (я на нем «Сапёра» делал, да), поэтому вопроса движка для меня не стояло. Да и окружающие программисты, в основном, были именно специалистами по C # в контексте Unity. Опять же, во времена работы над «Сапёром» я выработал довольно удачную на мой вкус структуру интерфейсов, основанную на простенькой стейтмашине. Так что старт получился достаточно шустрым. Ну да, повозился немного с перемещением объектов в 3D, с которым раньше никогда не работал. Не страшно.

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

У меня есть некоторое представление о том, как должен выглядеть проект, чтобы с ним было удобно работать, чтобы в него было удобно вносить изменения. Но это только представления. Я никогда не работал в качестве программиста в команде профессиональных программистов. Да я последние лет пять вообще только с документацией работаю. Всё, что я делал и делаю сейчас — это результат моего опыта, то есть потраченного времени.

Я бы хотел сказать что-нибудь типа «не делайте так». Но я не знаю, как надо делать. Правило «осуждаешь — предлагай» не выполняется.

Мой опыт очень ограничен задачами, которые я решал раньше. Например, та же стейтмашина интерфейсов. А вот с конфигами я никогда раньше не работал. Вернее, конечно, у «Сапёра» были конфиги, но они были настолько примитивными, что этот опыт на ферму вообще никак не переносился. Ну, просто где конфиг со списком уровней пазла (который даже не обязательно было делать в виде JSONа) и где конфиг построек, рецептов, магазинов.

В результате, разработка таких вещей — это как прыжок веры в Assasin's Creed, только внизу вместо стога сена контейнер с граблями. А когда вылезаешь из этого контейнера, то обнаруживаешь себя на собранном из граблей велосипеде. С которого не можешь слезть.

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

Примерно зимой, когда игра уже находилась в разработке четыре месяца, я прочитал Game Programming Patterns. Я узнал (и тут же забыл), как называются вещи, которыми я и так пользуюсь. Типа стейтмашины, синглтонов или ивентов (обзервер). Эта книга безусловно полезна, хотя бы тем, что приведённые в ней примеры связаны с решением не каких-то абстрактных задач, а с разработкой игр — они понятны тому, кто сам пытается делать игру. Но я не уверен, что эти пример будут понятны тому, кто вообще не знает, что такое (любой) язык программирования. Но у нас же у всех была информатика в школе, наверное.

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

Например механизм конфигов я переписывал почти с нуля три раза.

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

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

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

В-третьих, табличный конфиг не позволяет работать с вложенными объектами. Например, есть постройка и есть рецепт. Удобно же смотреть на рецепты одной постройки и редактировать их. Но в формате таблиц все постройки будут в одной табличке, а рецепты — в другой. И всё, каша из рецептов, нечитаемо и нередактируемо. Я знал про этот недостаток таблиц (я три года работал на проекте, в котором конфиги хранились в mySQL-базе данных), но понадеялся, что моей мотивации хватит на то, чтобы перетерпеть страдания.

Третий, и, надеюсь, финальный конфиг я стал делать из сочетания всего приобретенного мной опыта и некоторых ограничений выбранного мной сервера. И на этот раз я потратил три недели. Я сделал в Unity свой редактор, который удовлетворял бы моим требованиям, с выгрузкой в JSON и хранением в Scriptable Object. Причём самое обидное заключается в том, что я бы сразу так сделал, если бы тогда знал о существовании плагина Odin Inspector, который радикально облегчает разработку интерфейсов для редактора Unity (разобраться в родных средствах разработки я не смог). Кстати, на том проекте, в котором конфиги хранились в mySQL-базе, я, в итоге, тоже сделал свой редактор на OpenOffice Base (не думаю, что о существовании такой штуки вообще кто-то знает).

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

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

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

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

Хранить свой проект я решил просто в облаке. Для этих целей пригодился One Drive. Всё равно же есть, почему бы не использовать? Ну, и что может пойти не так с облаком? Особенно если между двумя рабочими компьютерами полтора часа езды — достаточное время, чтобы они успели синхронизироваться.

Но в один прекрасный момент, у меня умер файл сцены со всеми настройками интерфейсов и логики. Это был знак, что пора перестать ныть и научиться пользоваться репозиториями на Git. Да, когда я последний раз что-то руками делал, SVN всё ещё был в моде. И да, сразу начать пользоваться Git мне мешал именно страх. Страх того, что будет сложно разобраться, и что придется просить помощи.

За помощью я обращаться жутко не люблю. И причина не только в том, что я стесняюсь, а ещё вот в чём. Если кто не знает, у репозиториев на Git есть специальный файл в котором перечисляются файлы и папки которые следует игнорировать при сохранении изменений в проекте. По интернету ходит множество файлов, предназначенных для проектов на Unity 3D и не все они хорошие. Мне посоветовали плохой.

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

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

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

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

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

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

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

Когда же логика отделяется от отображения переездом на сервер... С одной стороны появляется необходимость — игрок может подделать сообщение с клиента, поэтому не стоит доверять клиенту отправку информации о выполнении условия. Но, вместе с тем, появляется и понимание того, когда именно эта необходимость действительно возникнет: когда появятся игроки. То есть, копирование на сервер функции проверки условий можно отложить в долгий ящик. Главное — вспомнить про этот ящик когда придёт время.

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

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