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

Возвращаясь в прошлое, можно вспомнить игру Xena: Warrior Princess с первой PlayStation, в которой игрок всю дорогу попадал в ситуации, где шакрам (обруч с заостренными краями) использовался только в качестве метательного смертоносного оружия. Несчастные игроки, не имевшие доступа к YouTube ввиду того, что оного тогда еще просто не было, в итоге сходили с ума на головоломке, в которой нужно было нажать на находившийся в отдалении рычаг. Они отчаянно не понимали, как это сделать, ибо Зена до рычага не допрыгивала. Догадаться, что механизм открывания ворот нужно активировать с помощью шакрама, было сложно из-за функциональной закрепленности. Традиционное использование шакрама сводилось к умерщвлению людей, но никак не к тому, чтобы запускать им в находящиеся в отдалении рычаги. А ведь это и было единственно возможным способом решения проблемы – в самой середине игры обнаружить у себя новые возможности, о которых игроку никто не говорил.

Эгоистическая погрешность

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

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

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

Я уже писал, что нельзя сталкивать игроков с препятствиями, к преодолению которых они не готовы, однако здесь есть еще несколько хитростей. К примеру, использовать эгоистическую погрешность можно и в обратную сторону: успехи, которые обеспечила игроку сама игра, он припишет себе. Обратите пристальное внимание на управление в Dead Cells. Если игрок чуть-чуть не допрыгивает до уступа – игра включает «автодоводку»: персонажа слегка подбрасывает вверх, и на платформу он всё-таки приземляется. В случае, когда, прыгая с края пропасти, игрок нажал на кнопку чуть позже – когда падение вниз уже началось, – у него есть несколько десятых долей секунды, чтобы оттолкнуться от воздуха и совершить-таки прыжок. Этот трюк называется «время койота» (так его назвали в честь героя одного из мультиков серии Looney Tunes – Вайл И. Койота, известного комичным «замиранием» в воздухе над пропастью на несколько секунд, требующихся для осознания всей печальности ситуации; иногда вместо падения за этим следовало неистовое перебирание ногами, позволявшее Койоту как по волшебству вернуться на какой-нибудь уступ сбоку). «Время койота» используется повсеместно: такая механика есть даже в Sekiro, платформинг в которой не является основной составляющей. Есть и другие способы помочь игроку. Если в той же Dead Cells упасть с платформы спиной к монстру и нажать на кнопку удара, игра поймет, что игрок просто не успел развернуться, и развернет его сама таким образом, чтобы удар пришелся-таки по врагу. Если в Celeste прыгнуть вверх, находясь под краем потолка, и задеть его таким образом, что, например, левая часть персонажа упрется в потолок, а над правой частью не будет ничего, то персонажа слегка подвинет вправо – и прыжок будет выполнен на максимально возможную высоту.

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

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

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

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

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

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

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