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

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

Ошеломляющего успеха не было, retention и платежные показатели оказались крайне скромными (правда, и деньги в раскрутку не вкладывались — оценки делали по первым 200к игроков, пришедших в игру в первые недели просто из каталога «Вконтакте», пока игра висела в разделе «новые»). В вопросах монетизации и геймдизайна я много опыта всё равно не набрал, однако несколько выводов для себя сделал и хотел бы ими поделиться — может, кому пригодится. Тем более, сейчас, работая в большой игровой компании, я особенно чётко вижу, как умные и опытные люди избегают моих «детских» ошибок.

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

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

Не переоценивать себя

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

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

Рассчитывать сроки максимально пессимистично — так не прогадаешь

Довольно общая рекомендация. Если кажется, что задачу можно решить за неделю — лучше запланировать на неё две недели. А то и три. Лучше взять больше времени и сделать раньше срока (показав себя предусмотрительным и быстрым), чем попытаться зарекомендовать себя умельцем-героем, взяв времени впритык, проработав в изматывающем кранче и всё равно не уложившись (уменьшив к себе доверие в будущем, и обеспечив, что к твоим словам уже не будут прислушиваться как раньше).

Геймдизайн и планирование крайне важны

Отсутствие диздока и плана затянули разработку раза в два-три. Мы имели лишь общее представление о том, какой будет игра, на уровне: «Это будет симулятор того-то, где можно будет делать то-то и то-то… ну и ещё хотелось бы того-то». Всё остальное выдумывалось на ходу: фичи, баланс, интерфейс, графический стиль. По мере того, как нам приходили в голову новые идеи, мы нередко отказывались от старых, вырезая куски уже готового функционала, а сам проект делая все менее похожим на изначальное видение и полным торчащих кусков от удалённых фич. Получалось порой примерно как в комиксе, только в пределах одного проекта.

Не увлекаться не связанными с игровым процессом вещами

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

А только затем уже, после всего этого, пришло осознание: на черта это всё нужно? Совершенно никакой ценности это не добавляет ни игровому процессу, ни монетизации — а время бесполезно потрачено.

Не пытаться сделать много и плохо, лучше мало и хорошо

Это уже было озвучено мной здесь в иной форме. Суть в том, что не стоит стараться гнаться за максимумом контента — лучше убедиться в том, что уже существующий работает хорошо. Тетрис и Bejeweled прекрасны — а ведь в них нет RPG-элементов, вида от первого лица, поддержки DirectX 11, аномалий и хабара. Иначе это создаёт лишь вопросы вроде: «А зачем в игре предметы XXX и ZZZ?» — «Ну, мы думали когда-то добавить фичу YYY, связанную с ними, но так и не дошли руки толком доделать».

Не давать принимать геймдизайные решения людям, с геймдизайном не связанным

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

Тестировать на незаинтересованных людях как можно раньше

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

А вот тревожным звоночком стало то, что когда на поздних стадиях сажали кого-нибудь за компьютер потыкать в игру, постоянно приходилось подсказывать: «Нет-нет, здесь нужно не так», «Ну вот смотри, чтобы на карту выйти — нужно на эту кнопку нажать, разве непонятно», «Нет, здесь так не получится, тут надо по-другому нажимать». И это был наш ровесник, периодически играющий в компьютерные игры. А мы планировали выходить в социальные сети, и целиться на людей вообще разных возрастов и с разным бекграундом!

И ещё одна — как я читал, довольно распространенная — вещь: критику тестировщиков следует воспринимать с благодарностью, без обид и попыток защититься («вот, мол, игра-то хорошая, просто они нубы и не понимают ничего»).

Не рефакторить раньше времени (важен продукт, а не красота кода)

Потенциальная почва для споров, однако моё личное мнение и выводы, сделанные из опыта: если код работает и в нём мало багов — значит, не следует трогать его по крайней мере до релиза. У проекта есть инвестор, каждый день разработки стоит денег, а конкуренты за это время выпускают по три аналогичных продукта. Рефакторинг становится малополезным онанизмом на красоту кода, а результаты оптимизации в духе «теперь этот конфиг парсится не за 0.3, а за 0.1 секунды — в три раза быстрее!» оказываются сомнительными с учётом того, что упомянутый конфиг загружается только один раз при запуске игры; при том, что на эту оптимизацию было потрачено три дня при незаконченном проекте. Хочется идеально красивого кода — пиши по вечерам опенсорс-движок на гитхабе.

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

Проводить стресс-тестирование и тестирование на слабом соединении

Здесь всё просто: каким бы надёжным и быстрым не казался сервер — он, скорее всего, не выдержит нагрузки в первые же дни. Аналогично, каким бы надежным и эффективным не казалось взаимодействие клиента с сервером — скорее всего, при медленном или рвущемся коннекте что-то в клиенте будет работать не так, как следует, или не работать вовсе.

Не бояться просить помощи

Я не скажу за других участников команды, однако лично я постоянно отказывался от предложений «сдай часть проекта аутсорсерам, мы выделим тебе на это денег сколько нужно, пусть они напишут часть кода параллельно с тобой». Просто потому что не был уверен в своём коде. Вот, думал, у меня здесь такая отвратительная структура кода, что другие люди, наверное, даже не захотят с ним работать, или будут критиковать; и вообще, у меня тут всё так тесно завязано, что нельзя править что-то одно, не переписывая куски по всему коду — потому работать с ним больше чем одному человеку будет вообще неудобно; да и мне тут немного осталось — вот ещё мелочь за пару недель допишу, а дальше всё легко будет, вот тогда можно будет подумать об аутсорсерах. Одним словом, только тем и занимался, что придумывал оправдания, почему мне не нужна ничья помощь. А на самом деле — я просто боялся попросить помощи.

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

Это — довольно общий совет, озвученный много раз в статьях и играх. Игроку следует в том или ином виде предоставлять информацию о том, на что он может повлиять и что зависит от него. Если игра напрямую реагирует на его действия — игрок должен иметь чёткое представление, как и почему. Достаточно представить, к примеру, Counter-Strike без индикатора здоровья или патронов, или World Of Warcarft, в котором не будет отображаться уровень мобов или количество опыта, оставшегося до следующего уровня героя. Механика не будет отличаться, однако игрок будет недоволен тем, что игра неудобна и не даёт ему всей важной информации.

Рано или поздно релизиться всё равно нужно

Это ещё Сид Мейер сказал, а мужик ведь дело знает!

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

Говорить всем игрокам одно и то же

Создав для игры группу Вконтакте, я оставил ссылку на свой профиль в разделе «Администраторы». После этого мне постоянно писали личные сообщения игроки (из них практически все — наша ЦА: девочки до 14 лет), среди которых часто звучали вопросы относительно планов на следующие обновления и планируемого контента. Стараясь отвечать как можно более кратко, иногда я всё же говорил о чём-то, что только витало у нас в далекоидущих планах на уровне: «Может если руки дойдут, добавим фичи ХХХХХ и YYYYY». Увы, уже на следующий день в группе Вконтакте уже были сообщения от этого же игрока: «Разработчики мне сказали, что в игре будет XXXXX», и отныне вопрос «а когда вы уже сделаете XXXXX? Вы же обещали!» от игроков становился регулярным.

К слову, Сергей Галёнкин в своей великолепной книге о маркетинге очень здорово рассказывает об общении с игроками, и среди прочего говорит: «Если вы заводите представительство в социальной сети, будьте готовы отвечать там на вопросы и оказывать техническую поддержку. Игроки не будут пользоваться теми инструментами, которые удобны вам — они всегда выберут то, что удобно им.». Я наивно полагал, что создав в паблике тему: «Технические вопросы по игре» — я буду только там их и видеть. Ничего подобного! Вопросы, комментарии, отзывы и жалобы были везде: в личных сообщениях, под новостями в группе (совершенно не связанными с темой вопроса), и даже в комментариях под личными фотографиями в моём профиле. Испытывая желание написать, юзеры пишут везде, где есть форма поста.

Автор:

Источник