• Какие баги есть в игре. Что такое баг и как с ним бороться? Туры по туристическим районам, Tours Through the Tourist District

    Описав методику систематического поиска багов по Джеймсу Уиттакеру (James A. Whittaker)

    Методика туров

    Приложение - незнакомый город.
    Тестировщик - турист.


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

    Как пользоваться методикой

    Выбрать тур из списка ниже.
    Изучить его цели.
    Поставить таймер на 2 часа (час, полчаса).
    Провести исследование системы строго по целям тура. Ни на что не отвлекаясь, только “миссия” тура.
    При необходимости повторить.

    В каждом туре есть описание автора (низкий поклон Джеймсу за разрешение перевода и публикации) в вольном переводе + собственные примеры. Для примеров взят сайт Дадаты - https://dadata.ru .

    Отправляемся в путь!

    Туры по деловому центру, Tours of the Business District

    Деловой центр - это место, где делается бизнес. Как правило, это непривлекательный для туристов район, где сосредоточены банки, офисные здания.

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

    Тур по деловому центру фокусирует внимание на главных частях вашего приложения и показывает сценарии их использования вашими клиентами.

    Туры по историческим районам, Tours Through the Historical District

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

    В ПО исторические районы могут быть также слабо соединены, как в Бостоне или сосредоточены в одном месте, как в Кёльне. Исторические районы в ПО представляют собой:

    • унаследованный код (legacy code);
    • функции, созданные в предыдущих версиях;
    • исправления багов.

    Последние особенно важны, потому что баги существа социальные и любят скапливаться в одном месте. Бажные секции в коде надо тестировать особенно тщательно.

    Туры по историческим районам проверяют старую функциональность и исправления ошибок.

    Туры по развлекательным районам, Tours Through the Entertainment District

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

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

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

    Туры по туристическим районам, Tours Through the Tourist District

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

    Туры по туристическим районам имеют несколько разновидностей. Это и короткие забеги для покупки сувениров, аналог кратких тест-кейсов для тестирования специфичных функций. Это и длинные поездки для посещения списка мест, которые хочется увидеть. Эти туры не о том, как заставить приложение работать, они о том, как посетить функциональность быстро… только чтобы сказать “мы тут были”!

    Туры по отельным районам, Tours Through the Hotel District

    Отель - убежище для туриста. Это место, куда можно сбежать из давки и суеты популярных мест для небольшого отдыха и расслабления.

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

    Туры по захудалым районам, Tours Through the Seedy District

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

    Порой, бороздя просторы интернета, можно встретить слово "баг". Что оно обозначает и какова этимология данного слова? Узнать ответы на данные вопросы вы сможете в этой статье.

    Баг — это что такое?

    Слово "баг" произошло из английского языка. На английском bug (произносится как "баг") — это букашка или жучок. Употребляется данное слово в основном среди программистов, тестеров и геймеров. Но что оно обозначает?

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

    Происхождение слова

    Пожалуй, теперь стоит поговорить об этимологии данного слова. Баг — это профессионализм, который чаще всего применяется в среде программистов. Есть несколько вариантов происхождения данного слова.

    Если верить легенде, то данный профессионализм появился еще в далеком 1945 году. Произошло это, когда ученые из проводили тестирование новой вычислительной машины под названием Mark II Aiken Relay Calculator. Устройство отказывалось работать, и причиной этому стал крохотный мотылек, который застрял между контактами. Насекомое извлекли из вычислительной машины и влепили в специальный технический дневник. Около мотылька находилась сопроводительная надпись «First actual case of bug being found», что переводится как "Первый случай в практике, когда был обнаружен жучок (баг)". После этой забавной истории слово "баг" и стало использоваться в значении "ошибка".

    Также существует версия, что этот профессионализм появился задолго до испытаний вычислительного устройства. Некоторые считают, что термин "баг" обязан своим происхождением известному изобретателю По легенде, Эдисон искал в своем фонографе таракана, но его там не оказалось. Баг был в самом аппарате.

    Очередная версия гласит, что слово "баг" появилось во времена Второй мировой войны. Тогда под данным термином подразумевали неполадки с радарной техникой.

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

    Игровые баги

    Баги есть не только в программах, они довольно часто встречаются и в играх. Баг игры — это недоработка разработчиков, из-за которой игровой процесс идет не так, как задумывалось изначально. За всю историю гейм-индустрии выходило тысячи забагованных проектов. О самых известных и занимательных мы и поговорим в этом разделе.

    Пожалуй, самым забагованным проектом за последние несколько лет можно назвать Assassin’s Creed: Unity. Проекты "Юбисофт" никогда не славились своей оптимизацией, но Unity — это настоящая энциклопедия багов. Порой персонажи находятся в очень странных и неестественных позах, проваливаются в текстурки, проходят через стены или же попросту зависают. Чего только стоит баг, который в считаные часы облетел весь интернет (у персонажей просто пропадали лица, из-за чего выглядели они довольно жутко). Даже сама "Юбисофт" признала свою ошибку, выпустила патч, который фиксит баги, и возместила покупателям ущерб.

    Порой игроки воспринимают баги в качестве фичи, особенности игры. Так произошло с мегауспешной серией игр под названием Mortal Kombat. В первой части игры был баг, который перекрашивал Скорпиона (одного из основных персонажей игры) в красный цвет. При этом имя героя заменялось на сообщение об ошибке Error Macro. Игроки посчитали, что эта недоработка является задумкой разработчиков, а красный ниндзя — это дополнительный секретный персонаж. Эду Буну (создатель МК) понравилась данная затея, и в последующей части он добавил в игру этого героя под именем Эрмак (сокращение от той самой Error Macro).

    Как уберечь себя от багов?

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

    Но не всегда тестеры находят баги, и порой пара-тройка недоработок все же просачивается в финальную версию проекта. В таком случае вся надежда на пользователей, которые могут отправить специальное письмо с описанием ошибки — баг-репорт. Это поможет улучшить конечный продукт. Кроме того, крупные компании хорошо вознаграждают за нахождение багов в их продукции. К примеру, в качестве поощрения за нахождение значимых багов в своем браузере Google готова дать 15 тысяч долларов.

    Как найти баг в коде

    Как часто вы тратите часы чтобы понять почему же эта эта вредная навигация сползла, а это изображение отображаясь искажает весь текст невероятным способом? Этот способ позволяет найти причину практически не думая за 5 минут. Наверное почти все пользовались этим методом поиска багов в вёрстке.

    Зачем

    Очень много времени в верстке уходит на решение багов, и поиски их причин. Если вы чувствуете, что можете потратить более 20 минут на поиски причины - лучше смело использовать этот метод, он редко отнимает более 5-10 минут. Впрочем, менее 5 минут, он тоже редко отнимает. И это его единственный недостаток.

    Когда

    Когда “сползла колонка”, или “это гадское меню опять отображается не так как должно”. Или еще тысячи глюков, которые вы наблюдаете и не можете понять, что заставляет сайт отображаться именно так. И какая строка в коде это делает.

    Идея

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

    Принцип очень простой, чтобы найти, например, точку на отрезке:

    1. Делим отрезок пополам, определяем в какой половине содержится наша точка
    2. Повторяем процедуру для полученной половины отрезка с точкой

    И так, пока не получим нужную точность.

    А так это выглядит в задаче про поимку льва в пустыне:

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

    Алгоритм в приложении к вёрстке мало отличается от классики. Львом будет кусочек кода делающий глюк. Пустыней - весь код.

    >Суперпупермегаалгоритм

    1. Удаляем половину или просто большой кусок HTML (CSS)
      • Если глюк остался виден, продолжаем процедуру для оставшегося кода
      • Если глюк исчез, возвращаем удалённый код и повторяем процедуру для него (удалив другую половину)

    В результате останется только “глючный” HTML, обычно это пара блоков связанных с глюком.
    Тоже самое повторяем для CSS кода. Если в HTML еще нужно было соблюдать иерархию, то в CSS можно смело удалять по половине кода.

    Таким образом, в конце у вас останется несколько строк CSS и только те блоки в HTML, которые составляют глюк. При таком количестве кода вам будет трудно не найти баг или опечатку.

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

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

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

    В конце

    Даже странно почему об этом способе так мало написано(может потому что это слишком просто?). Надеюсь кому-то он поможет, меня не раз и не два выручал. Вдобавок, такие действия помогают начинающим веб-мастеру лучше разобраться и прочувствовать как работает этот CSS. =) А при поиске глюка в чужом коде - это практически единственный путь.

    Привет баклан.

    Чё, руки чешутся? Сломать вебсервер охота, потому что там до хрена сайтов противоречащих твоей кул-хацкерской идеологии? Не суть. Но для начала надо войти в историю и узнать о багах, местах старых багов. Ведь зная суть этих багов, ты сможешь откапать новые баги...
    А это уже угроза, так сказать, сила. В этом одна из идей хакера - ПОИСК.
    Ну, с чего б начать то? Ну, во-первых, конечно же, CGI баги.

    О них и поговорим. Любимая атака (и самая лёгкая) это атака на подтверждения ввода. Суть атаки том, что кривые программисты написали своё детище так, что CGI сценарий неадекватно реагирует на вводимые в него данные. После чего этот сценарий делает не то, что от него хотел разработчик, а то, что хотел злобный взломщик:). Вот, например в IIS есть уязвимость называемая MDAC
    RDS. Компонент RDS (удалённый сервис данных) и есть уязвимый объект в
    MDAC. А если быть точнее, то этот компонент RDS Data Factory. Если админ - лошпекус, то он оставил настройки по умолчанию, где разрешено исполнение удалённой команды на сервере IIS. Команда выполняется обычно от пользователя
    SYSTEM. Теперь о том, как эту багу юзать. На сайте
    www.securityfocus.com есть сценарий на языке Перл, который позволяет послать и исполнить любую команду базе данных - btcustmr.mbr (экспериментальная база данных). Где-то я видел експлойт на Дельфи. Фишка заключается в добавлении к SQL запросу строки " | shell(\"$command\") | " . Обнаружив команду оболочки, MDAC выполнит команду в переменой
    $command. Да кстати, для любителей посканировать на CGI баги, если вы обнаружите библиотеку "msadc.dll", значит вполне вероятно, что система уязвима.

    Не отходя далеко от IIS, следующий баг, обнаруженный известной группой
    eEye: В Microsoft IIS 4.0 хреновая проверка в именах файлов.IDC .HTR и.STM. Как юзать Баг???
    Хе... пошлю я тебя на... на www.technotronic.com , там ищи прогу под эротичным
    названием -Iishack. Все что надо указать это - адрес жертвы, адрес, где лежит твоя прога + путь к проге...
    Большинство взломщиков, таким образом, закачивают на испытуемый сервак другую прогу:
    Getem.exe. Это Троян, который распаковывает pwdump.exe и запускает
    netcat. Pwdump - выводит дамп SAM, а неткат открывает 25 порт и даёт через него доступ к
    cmd.exe. То есть сначала ты коннектишься к 25 порту, а затем запускаешь pwdump и смотришь зашифрованные пароли, которые можно протестить L0pht crack"ом, который попробует перебрать пароли.

    Далее я расскажу про неправильное использование скрытых тегов. Читал я в одной
    книжке, что некоторые магазины используют скрытые теги для присваивания цены товару!
    Поясняю: input type=hidden, а value="123". А что тебе помешает поменять value??? Правильно
    - совесть! Введи в поисковик (Altavista) "type=hidden
    name=price"-а дальше только удача:). Ту я описал лишь два с половиной бага, известных бага. Как искать эти баги? Три пути.
    Либо пойти в поисковик и ввести там что-то типа: "url: "_vti_bin" " а далее тупо перебирать выведенные сайты на iis unicode. Второй путь: есть сайт, который надо наказать, бери сканер
    и скань на наличие багов, к слову есть хороший CGI сканер на
    www.xp-team.com с описаниями от
    www.gingroup.ru и небольшой базой експлойтов. Третий путь, путь истинных хакеров, это путь исследования, попытайся переполнить буфер запроса... короче попытайся применить все известные баги. Но будь разумен... не надо пытаться выполнить iis unicode под Apache, ну ты меня понял:).

    Всё, я пошёл, мне пора пнуть кота... тьфу ты... у меня ж нет кота... ну пну
    ещё кого-нить. Удачного пин...то есть хака, твой Дон Хуан.

    Когда что-то пошло не так.

    В закладки

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

    Это не тот случай, конечно

    «Экран-убийца» в старых аркадах

    Было бы неверно предполагать, что глитчи и баги появились лишь в современных играх. Они с нами почти с самого зарождения игровой индустрии. Самыми ранними примерами можно считать баги аркадных игровых автоматов, называемые kill screen («экран-убийца»). Суть ошибки в том, что последний уровень в игре чаще всего невозможно пройти.

    Взять к примеру Pac-Man. Если дойти до 255 уровня, то с игрой начинают происходить довольно жуткие вещи: половина экрана забивается цифрами и игровыми спрайтами, из-за чего играть становится проблематично (для обычных людей; профессионалов подобные трудности редко смущают). За то, где и в каком количестве появляются бонусы, отвечает особая процедура. Данные она берёт прямо из номера уровня, и когда значение выходит за пределы байта (то есть на 256 этапе), игра немного ломается.

    В Donkey Kong «экран-убийца» тоже присутствует, но немного в другом виде. Если дойти до 22 уровня, то Марио погибнет всего через несколько секунд после начала игры. Происходит это из-за того же байтового предела.

    Время, отводимое на уровень, рассчитывается по определённой формуле: 10x(*номер уровня*+4). Если игрок попадает на 22 уровень, то формула выводит число 260, однако игра воспринимает значения лишь до 256, а потому 260 превращается в 4. За четыре секунды герой успеет разве что пробежать пару шагов, после чего умрёт.

    В Duck Hunt на NES с «экраном-убийцей» можно было столкнуться, дойдя до 100 уровня. Тогда утки начинали вылетать из кустов с огромной скоростью и в больших количествах. Разумеется, подстрелить их было невозможно, и игра заканчивалась.

    Комбо в Street Fighter II

    Возможность наносить противнику множественные удары появилась ещё до Street Fighter, но именно вторая часть серии популяризировала систему комбо и заставила остальных разработчиков обратить на неё внимание.

    Как всё произошло: во время тестирования игры и отлова багов главный продюсер Street Fighter II Норитака Фунамицу заметил, что на бонусном уровне (где нужно было раскурочить автомобиль) персонаж может нанести несколько дополнительных ударов. Для того, чтобы сделать это, нужно было очень строго выдержать тайминг, что само по себе было сложно.

    Ошибку решено было не убирать из тех соображений, что вряд ли кто-то решится её использовать. Игроки, однако не отступили и выучили комбинации. Уже в Super Street Fighter II, который вышел в 1993 году, игра стала учитывать и вознаграждать каждый удар в комбинации, официально закрепив систему комбо в жанре файтингов.

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

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

    Норитака Фунамицу

    Продюсер Street Fighter II

    Ермак в Mortal Kombat

    Ермак из Mortal Kombat обязан своим появлением слуху. Дело в том, что после релиза первой части многие игроки стали утверждать, будто замечали в игре баг, при котором цвет одежды Скорпиона меняется с жёлтого на красный, а в полоске жизней появляется надпись Ermac.

    Ермак в фильме Mortal Kombat: Annihilation

    Сразу же было сделано предположение, будто это секретный персонаж, которого можно как-то разблокировать. В игровых журналах того времени даже появлялись изображения героя, которые, впрочем оказались поддельными. Никакого Ермака в первой части MK, разумеется, не существовало. Секретного персонажа с этим именем разработчики ввели лишь в Ultimate Mortal Kombat 3. Вот так, из-за слухов о баге на свет появился герой файтинга.

    Ultimate Mortal Kombat 3

    «Потерянный покемон» из Pokémon Red & Blue

    Во вселенной Pokémon множество культовых монстров. Но есть один особенный - MissingNO. В отличие от всех остальных, он - баг. Появляется покемон после выполнения трёх последовательных действий. Сначала игрок должен пройти внутриигровое обучение, затем использовать покемона со способностью к полёту, чтобы добраться до острова Синнабар. Там нужно взять водного покемона и плавать вниз-вверх рядом с восточным берегом острова. После этого в игре случится баг и MissingNO появится.

    Правда, нужно быть осторожным. Nintendo ещё в 1999 году предупредила пользователей, что любой контакт с секретным покемоном может повредить игровые сейвы. Также побочным эффектом встречи является то, что количество предметов, расположенных в шестом слоте рюкзака героя, увеличится до 128. Также в игре могут встречаться различные графические артефакты. MissingNO можно даже поймать и использовать в сражении. В покедексе тот получает номер 000. Само покемона имя расшифровывается как Missing Number (Потерянный Номер).

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

    Чтобы устранить проблемы с графикой, попробуйте отпустить покемона MissingNO. Если проблема останется, единственным выходом будет перезапуск игры. Это означает необходимость стереть текущие сохранения и начать заново.

    Информация на сайте Nintendo

    Баги Ultima Online

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

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

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

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

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

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

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

    Раф Костер

    Ведущий дизайнер Ultima Online

    Жонглирование противниками в Devil May Cry

    Изначально Devil May Cry задумывалась как очередная часть Resident Evil (четвёртая, если точнее). У руля проекта стоял Хидэки Камия, который планировал сделать из игры быстрый экшен в готических декорациях, с динамической камерой и главным героем - сверхчеловеком. В итоге, концепция эволюционировала настолько, что создатели поняли: в серию Resident Evil игра больше не вписывается. Сюжет переписали, название сменили, а герою дали имя Данте.

    Devil May Cry

    Интересная часть началась, когда Хидэки Камия сел тестировать игру Onimusha: Warlords (вышла в 2001 году на PS2). Оказалось, что в игре есть баг, из-за которого противниками можно буквально жонглировать, нанося удары. Из финальной версии его, конечно убрали, но геймдизайнеру настолько понравилась эта идея, что он перенёс её в DMC. Так из-за бага у игр про демона Данте появилась своя фишка.

    Изначально Devil May Cry должен был стать новой игрой в серии Resident Evil. Но он настолько не вписывался в серию, что превратился в DMC, а мы потеряли целый год разработки. Я думал, что, может быть, я облажался, а Capcom хотят меня уволить. Это бы объяснило то, что мне не разрешили работать над DMC2.

    Хидэки Камия

    Геймдизайнер Devil May Cry, в интервью сайту 1UP

    Onimusha: Warlords

    Чума в World of Warcraft

    В сентябре 2005 года мир World of Warcraft был усеян костями игроков. Виной всему была чума, сотнями выкашивавшая несчастных искателей приключений. Началось всё с рейда Зул’Гуруб, в котором игрокам предстояло сразиться с Хаккаром Свежевателем Душ. У босса в запасе был трюк: он высасывал из героев кровь, восстанавливая свои силы. Однако свою кровь можно было заразить: игрок получал урон, но Хаккар также заражался и, в конечном счёте, погибал.

    Хаккар Свежеватель Душ

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

    Люди старались не подходить к городам и писали остальным: «Не возвращайтесь в город, а то снова это подхватите. Держитесь дикой местности». Это был своего рода карантин, благодаря которому выживали игроки.

    Шейн Дабири

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

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

    Шейн Дабири

    Один из руководителей Blizzard

    Лицо Дрейка в Uncharted 2

    Изображение с размытым лицом Натана Дрейка из Uncharted 2: Among Thieves впервые появилось на имиджбордах. «Дрейкфейс», как его назвали пользователи, быстро обрёл популярность, стал мемом и своеобразным символом консольного гейминга. Якобы железо на PS3 устаревшее, графика мыльная, вот и получается такое.

    На самом же деле, «дрейкфейс» - результат бага, который, при желании, можно воспроизвести. Достаточно зайти в режим создания роликов в разделе «Коллективная игра», выбрать любую запись матча, сразу же навести камеру на стену и нажать паузу в момент первой смерти. Потом просто летим к месту гибели персонажа и видим «дрейкфейс». Из-за бага в момент смерти лицо персонажа прогружается неправильно, вот и получается такой эффект.

    Кричащий герой Heavy Rain

    Heavy Rain - не самая позитивная игра. Убийства, семейная драма, постоянный дождь, мало поводов для веселья. Однако один случайный баг меняет всё и превращает серьёзную и грустную историю в настоящий балаган. Осторожно, спойлеры.

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

    Читать еще: