Читаем Ошибки разработчиков видеоигр. От идеи до провала полностью

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

Наблюдение за игроками

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

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

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

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

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

Правильная демонстрация

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

Во-вторых, поведение игрока и время его нахождения в игре гораздо важнее его слов. Однажды игрок провел в Reflection of Mine полтора часа, изучив каждый уголок моей демоверсии, но в итоге сказал, что моя игра из рук вон плоха. Другой же поиграл пять минут и высказал восторженное мнение, что Reflection of Mine – это шедевр. Разумеется, оба этих игрока меня обманули.

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

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT