Как найти баги в играх

Что такое баги в игре и как их находить при тестировании

Любая созданная игра — это , по сути , свод определенных правил, по которым работает эта самая игра. А за этими правилами стоят сложные математические вычисления. Плюс внешний дизайн и обратная связь между игроками. Это все образует большой и сложный игровой процесс, в котором могут быть баги. Что такое баги в игре и как их искать — об этом и не только поговорим в сегодняшней статье.

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

Что такое баги в игре и как они классифицируются

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

Как классифицируют игровые баги:

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

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

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

Баг производительности. Игровые проблемы с FPS , не связанные с пользователем, — игра работает медленно и лагает на производительных устройствах.

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

Технический баг. Н ес табильный интернет , отчего игра плохо работает. Или , например , не хочет запускаться в 3G — сети.

Баг совместимости. К примеру, игра не запускается на совместимых устройствах.

Н о эт о еще не все. Это была классификация по происхождению бага. Еще они классифицируются по приоритетности и скорости их устранения. В этом случае выделяют три категории:

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

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

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

Но и это еще не вся классификация багов . Д ля лучшей градации их разделяют еще по категориям в зависимости от того, кого или что они затрагивают. Тут получается следующее разделение:

Баги, мешающие пользователям игры. В целом влияют на количество игроков, на различные рейтинги и т. д.

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

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

Что такое баги в игре — разобрались , и как их классифицируют — тоже. Остается вопрос : а как вообще появляются эти «недостатки» и от чего зависит их количество в проектах?

От чего зависит количество багов в играх

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

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

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

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

Игровой процесс. Чем сложнее процесс и больше функциональности в игре, тем больше шансов, что при их реализации возникнут ошибки в игре.

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

Раннее тестирование. Один баг часто порождает целую цепочку багов, поэтому необходимо качественное тестирование на ранних этапах разработк и .

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

Сетевой режим RPG-игр. Огромный игровой мир с просто невероятным количеством возможных сценариев при взаимодействии игроков между собой.

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

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

Как искать и находить баги в играх

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

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

Как искать и находить баги в играх, советы:

Фокусировка. Важно фокусироваться именно на процессе поиска, а не на процессе игры. Можно даже держать постоянно в голове мысль: «Здесь должен быть баг!»

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

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

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

Тестировать разные жанры. Нужно тестировать разные жанры игр или даже разные проекты, чтобы глаз не «замылился» и вы всегда были способны вовремя заметить ошибку.

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

Думайте. Как н и странно, но мысли по типу: «Почему игры пишутся с багами?», «Почему баги в играх — это то , что считается нормой?», «Что вообще такое баги в играх?» и т. д . помогают развивать собственную философию в этом вопросе. А со в ре менем вы сами будете находить подтверждение своим мыслям и догадкам. И у вас появ ятся собственный алгоритм и методики поиска.

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

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

Заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Какие баги находят тестировщики?

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

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

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

Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет эксперт и руководитель отдела тестирования компании Inlingo Андрей Васильев.

Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.

Итак, баги в играх можно условно классифицировать по следующим категориям:

Баги, связанные с самой игрой:

  • Баги функциональности. Не работают или неправильно работают какие-то функции в игре. Например, при переходе в настройки приложения происходит аварийное завершение работы;
  • Баги интерфейса. Искажается графика, элементы не находятся на своих местах, текст не вписывается в отведенные ему рамки;
  • Баги локализации. Ошибки в текстах, присутствие непереведенных строк. Скажем, вместо перевода выводятся заглушки, вроде “russian_text_001”;
  • Баги производительности. Приложение на устройстве работает медленно. Например, во время анимации атаки персонажа FPS заметно «проседает» на устройствах high-end сегмента;
  • Баги логики и баланса. Выставленные настройки баланса и игровой логики не позволяют пройти игру или достигнуть нужных целей. К примеру, персонаж наносит урон в 100 единиц, вместо 150 обещанных в игре;
  • Технические баги. Игра неправильно работает в условиях нестабильного интернет-соединения, как вариант, приложение не может подключиться к серверу в 3G сетях;
  • Баги совместимости. Игра попросту не работает на совместимом устройстве или запускается с критическими ошибками.
Читайте также  Какие есть климатические пояса

» data-medium-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/1.gif?fit=500%2C281&ssl=1″ data-large-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/1.gif?fit=500%2C281&ssl=1″ svg+xml,%3Csvg%20%20viewBox=’0%200%20500%20281’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»500″ height=»281″ data-recalc-dims=»1″ data-lazy-src=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/1.gif?resize=500%2C281&ssl=1″ />

Потренируемся: какой это баг по классификациям? Если вы ответили: «Функциональный, низкоприоритетный, графический, затрагивающий команду разработки», то ура — вы тестировщик (нет)

Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:

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

» data-medium-file=»https://i2.wp.com/apptractor.ru/wp-content/uploads/2018/12/2.gif?fit=512%2C288&ssl=1″ data-large-file=»https://i2.wp.com/apptractor.ru/wp-content/uploads/2018/12/2.gif?fit=512%2C288&ssl=1″ svg+xml,%3Csvg%20%20viewBox=’0%200%20512%20288’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»512″ height=»288″ data-recalc-dims=»1″ data-lazy-src=»https://i2.wp.com/apptractor.ru/wp-content/uploads/2018/12/2.gif?resize=512%2C288&ssl=1″ />

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

Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:

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

От чего зависит число багов в игре?

Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.

  1. В первую очередь это зависит от опытности команды разработки.
  2. На втором месте стоит техническая сложность проекта. Шансы появления багов прямо пропорциональны количеству кода и числу используемых библиотек.
  3. На третьем месте — количество возможностей в игре и разнообразие игрового процесса в целом.
  4. Серьёзная статья — это сетевой режим и пути взаимодействия игроков друг с другом. Для сетевого режима разработчики зачастую даже в играх, уже прошедших тестирование на этапе производства, запускают закрытые тестирования для настройки баланса и поиска неочевидных багов.
  5. Ну и конечно, прямая зависимость от эффективности тестирования именно на раннем этапе разработки. Дело в том, что чем больше багов будет найдено как можно раньше, тем меньше шансов, что эти баги позже приведут к появлению новых.

» data-medium-file=»https://i1.wp.com/apptractor.ru/wp-content/uploads/2018/12/3.gif?fit=377%2C247&ssl=1″ data-large-file=»https://i1.wp.com/apptractor.ru/wp-content/uploads/2018/12/3.gif?fit=377%2C247&ssl=1″ svg+xml,%3Csvg%20%20viewBox=’0%200%20377%20247’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»377″ height=»247″ data-recalc-dims=»1″ data-lazy-src=»https://i1.wp.com/apptractor.ru/wp-content/uploads/2018/12/3.gif?resize=377%2C247&ssl=1″ />

Привязка выявляемого количества багов к жанрам

  • RPG с сетевым режимом. Большой мир, масса сценариев взаимодействия игроков друг с другом;
  • Игры с открытым миром. Очень много возможностей поведения игрока, которые надо тщательно тестировать;
  • Любые игры с мощной графической составляющей. Практически невозможно одинаково оптимизировать игру под все устройства, если речь не о консольных тайтлах.

Хороший пример того, как игроки испытывают игру на прочность. Skyrim в этом смысле рекордсмен.

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

  • Игры в жанре match-3. Здесь игрок ограничен только игровым полем и комбинациями фишек, бонусов и количеством игровых механик;
  • Игры в жанре hidden objects (поиск предметов), в которых, как правило, свобода игрока ограничена
  • Файтинги;
  • Казуальные игры, действие которых происходит на одном экране — тайм-менеджеры, кликеры, shoot’em up и т.д.

» data-medium-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/4.gif?fit=444%2C250&ssl=1″ data-large-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/4.gif?fit=444%2C250&ssl=1″ svg+xml,%3Csvg%20%20viewBox=’0%200%20444%20250’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»444″ height=»250″ data-recalc-dims=»1″ data-lazy-src=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/4.gif?resize=444%2C250&ssl=1″ />

COD WWII за принципиально новый эко-транспорт

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

Ошибки дизайна уровней

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

Ошибки обратной связи

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

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

Ошибки игрового баланса

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

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

А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.

Не фича, а баг: тестировщик о классификации игровых глюков

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

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

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

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

Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.

Итак, баги в играх можно условно классифицировать по следующим категориям.

  • Баги функциональности. Не работают или неправильно работают какие-то функции в игре. Например, при переходе в настройки приложения происходит аварийное завершение работы.
  • Баги интерфейса. Искажается графика, элементы не находятся на своих местах, текст не вписывается в отведенные ему рамки.
  • Баги локализации. Ошибки в текстах, присутствие непереведённых строк. Скажем, вместо перевода выводятся заглушки, вроде «russian_text_001».
  • Баги производительности. Приложение на устройстве работает медленно. Например, во время анимации атаки персонажа FPS заметно «проседает» на устройствах high-end сегмента.
  • Баги логики и баланса. Выставленные настройки баланса и игровой логики не позволяют пройти игру или достигнуть нужных целей. К примеру, персонаж наносит урон в 100 единиц, вместо 150 обещанных в игре.
  • Технические баги. Игра неправильно работает в условиях нестабильного интернет-соединения, как вариант, приложение не может подключиться к серверу в 3G сетях.
  • Баги совместимости. Игра попросту не работает на совместимом устройстве или запускается с критическими ошибками.

Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:

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

Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:

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

Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.

  1. В первую очередь это зависит от опытности команды разработки.
  2. На втором месте стоит техническая сложность проекта. Шансы появления багов прямо пропорциональны количеству кода и числу используемых библиотек.
  3. На третьем месте — количество возможностей в игре и разнообразие игрового процесса в целом.
  4. Серьёзная статья — это сетевой режим и пути взаимодействия игроков друг с другом. Для сетевого режима разработчики зачастую даже в играх, уже прошедших тестирование на этапе производства, запускают закрытые тестирования для настройки баланса и поиска неочевидных багов.
  5. Ну и конечно, прямая зависимость от эффективности тестирования именно на раннем этапе разработки. Дело в том, что чем больше багов будет найдено как можно раньше, тем меньше шансов, что эти баги позже приведут к появлению новых.
  • RPG с сетевым режимом. Большой мир, масса сценариев взаимодействия игроков друг с другом;
  • Игры с открытым миром. Очень много возможностей поведения игрока, которые надо тщательно тестировать;
  • Любые игры с мощной графической составляющей. Практически невозможно одинаково оптимизировать игру под все устройства, если речь не о консольных тайтлах.

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

  • игры в жанре match-3. Здесь игрок ограничен только игровым полем и комбинациями фишек, бонусов и количеством игровых механик;
  • игры в жанре hidden objects (поиск предметов), в которых, как правило, свобода игрока ограничена;
  • файтинги;
  • казуальные игры, действие которых происходит на одном экране — тайм-менеджеры, кликеры, shoot’em up и т.д.

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

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

Читайте также  Как уменьшить расход топлива на газ 3110

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

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

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

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

А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.

Если вдруг вы разработчик и хотите, чтобы подобных ошибок в вашем проекте было поменьше, пишите нам на order@inlingogames.com — мы придумаем что-нибудь вместе.

И вообще, доверяйте свои игры профессиональным тестировщикам, да поменьше багов вам в готовых продуктах: далеко не все из них станут легендарными, вроде знаменитого «geddan».

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

Требования — это старый миф. Наиболее олдовые айтишники на древних форумах пишут, что существуют такие мифические существа как аналитики. По легенде, они подпускают к себе только девственниц и ПМов. Говорят, что когда Луна находится в нужной фазе, а звезды сходятся под верным углом, аналитик может окуклиться у себя на рабочем месте. Если правильно ухаживать за этой куколкой, то спустя 3-5 рабочих дней погружения в астрал и взаимодействия с эфиром, куколка аналитика раскрывается и тогда у проекта появляются записанные на священных скрижалях заветы — требования.
К сожалению, из-за вырубки лесов и вмешательства человека в экологию, сейчас этих дивных существ почти не встретишь, а потому труд обычного тестировщика тяжел и неблагодарен, поскольку приходится работать без требований.

Как искать баги в играх

15 Jul 2018 в 00:27

15 Jul 2018 в 00:27 #1

Решил изменить свою жизнь и стать из рандомного дотера — ГЕЙМТЕСТЕРОМ!
Но вот незадача — меня пригласили и сказали что нужно будет пройти тест. Тебе дают час, а ты находишь столько багов сколько сможешь. НО БЛИН, а если я ни одного не найду, баги это же рандомная фингня, мб проканает а мб нет.

ЧТО ТОГДА?

МЕНЯ НЕ ВОЗЬМУТ?

КАК ИСКАТЬ БАГИ ЦЕЛЕНАПРАВЛЕННО, ФОРУМЧАНЕ, ПАМАГИТИ!

15 Jul 2018 в 00:28 #2

делай всякую нестандартную хрень

15 Jul 2018 в 00:29 #3

делай всякую нестандартную хрень

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

15 Jul 2018 в 00:30 #4

с сейвлоадом в каждой второй игре какой-то баг есть (даже которая уже вышла)
а вообще посмотри кучу спидранов, там почти все баги +- похожи

15 Jul 2018 в 00:31 #5

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

15 Jul 2018 в 00:31 #6

с сейвлоадом в каждой второй игре какой-то баг есть (даже которая уже вышла)
а вообще посмотри кучу спидранов, там почти все баги +- похожи

Я просто даже не знаю во что буду играть..

15 Jul 2018 в 00:33 #7

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

15 Jul 2018 в 00:34 #8

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

Спасибо хоть за пару примеров..

15 Jul 2018 в 00:38 #9

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

15 Jul 2018 в 00:42 #10

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

Спасибо за ответ. Вот я уже думаю как буду убивать нас и тут я приду а мне дадут кэндикраш или денс десн революшн:/

15 Jul 2018 в 00:45 #11

Спасибо за ответ. Вот я уже думаю как буду убивать нас и тут я приду а мне дадут кэндикраш или денс десн революшн:/

В том же денс денс революшн можно на коляске танцевать

15 Jul 2018 в 00:52 #12

Хаю Хай!

Решил изменить свою жизнь и стать из рандомного дотера — ГЕЙМТЕСТЕРОМ!
Но вот незадача — меня пригласили и сказали что нужно будет пройти тест. Тебе дают час, а ты находишь столько багов сколько сможешь. НО БЛИН, а если я ни одного не найду, баги это же рандомная фингня, мб проканает а мб нет.

ЧТО ТОГДА?

МЕНЯ НЕ ВОЗЬМУТ?

КАК ИСКАТЬ БАГИ ЦЕЛЕНАПРАВЛЕННО, ФОРУМЧАНЕ, ПАМАГИТИ!

Но хех, баги еще и репотрить уметь нужно, а не только находить.

Игровые баги, которые внезапно стали фичами

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

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

Повышение сложности в игре

Начнем, пожалуй, с одного из самых серьезных багов в игровой индустрии, который породил такое понятие, как «сложность в играх». В 1978 году появилась Space Invaders, и если сейчас ее можно запустить чуть ли не на микроволновой печи, то тогда ее с трудом тянули даже самые мощные ПК. Именно поэтому игра работала не совсем так, как этого хотели разработчики. Когда противников на экране становилось меньше, они начинали двигаться быстрее. Суть в том, что компьютер начинал быстрее отрисовывать модели врагов, потому что машине банально приходилось задействовать не всю мощность.

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

Бесконечные монеты

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

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

Комбо удары в файтингах

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

На этапе тестирования Street Fighter 2 разработчики много времени уделяли изучению анимации бойцов. Однажды они решили протестировать удары на бонусном уровне, где персонаж просто стоял и разбивал врукопашную старенький седан. В этот момент создатели заметили, что анимацию одной атаки можно прерывать, если быстро нанести другую. По сути, баг давал возможность забивать соперника до смерти, постоянно меняя атаки, и тот даже не мог поставить блок. Разработчики думали, что этот баг никто не заметит, и решили его не фиксить, а оказалось, что именно он стал переломным моментом в истории файтингов.

Скрытый персонаж

Аркадная версия Mortal Kombat привлекала внимание не только своей жестокостью и садистским обращением с противниками, но еще и забавными фишками, которые игроки «выковыривали» из автоматов годами. Одним из багов, который обнаружили не сразу, стал скрытый экран диагностики, где последним пунктом была надпись «ERMACS». Это сокращение от «error macros», то есть ошибки в макросах игры.

Поскольку в начале 90-х программистами были только избранные, и мало кто вообще понимал, что было написано на том экране диагностики, игроки решили, что Ermacs – это скрытый персонаж. Причем данная теория стала распространяться с невероятной скоростью, и про нее начали писать даже в игровой прессе. В итоге разработчики подсуетились, баг с доступом к экрану диагностики в продолжении убрали, а в Ultimate Mortal Kombat 3 добавили персонажа по имени Ермак. Самое интересное, что первая его версия — это тупо перекрашенная в красный цвет моделька Скорпиона, которому поменяли несколько приемов.

Рокет-джамп и распрыжка

Именно в этой игре появилось сразу 2 бага, которые впоследствии стали фичами практически во всех современных шутерах. Первой особенностью Quake стал «рокет-джамп». Игрок мог выстрелить себе под ноги ракетой и его тут же уносило далеко-далеко вверх к звездам. Эта механика чистой воды баг со стороны движка, который неправильно воспроизводил физику персонажа и вместо того, чтобы убить его, просто увеличивал высоту прыжка.

Вторая особенность Quake – это «распрыжка», которая встречается сегодня буквально в каждом FPS. Суть в том, что нужно поочередно прыгать влево-вправо и вправо-вперед, чтобы персонаж смог развить огромную скорость и буквально пулей летал по карте. Фича появилась вследствие того, что разработчики допустили ошибку при расчете движения по диагонали, в чем они сами позднее признались. Вот так исключительно математические баги создали серьезные фичи для любителей многопользовательских шутеров.

Читайте также  Нужно ли мыть куриные яйца

Сумасшедшие копы на дорогах

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

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

Чужой среди своих

Начнем с того, что история создания Team Fortress сама по себе интересная. Изначально это был вообще мод для Quake, который в дальнейшем перерос в полноценный проект. Некоторые классов TF разработчики создавали буквально на ходу. Самый интересный пример – это то, как в игре появился Шпион.

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

Держащая в воздухе стрельба

Кто играл хотя бы в одну часть этой серии прекрасно помнит особенности здешней боевой системы. Угарный слэшер позволяет плясать с противниками в сумасшедшем танце, после которого только ведущий танцор остается в живых. Один из элементов боевой системы Devil May Cry изначально был багом, который разработчики обнаружили на этапе создания Resident Evil 4. Речь идет о том, что главный герой DMC может запускать врагов в воздух, а затем держать их там хоть до бесконечности с помощью непрерывных выстрелов из огнестрела.

Недолго думая, разработчики решили убрать из медленной и более тактической Resident Evil этот баг, после чего выстроили вокруг него новый проект, который в итоге и получил название Devil May Cry. Именно там эта механика идеально вписалась и, скорее всего, вы даже не знали, что изначально эта фишка боевой системы была просто ошибкой разработчиков.

Можно бить своих

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

В Warcraft 3 вы можете бить кого угодно и когда вам этого захочется. Разработчики самой популярной MOBA в мире проморгали эту особенность, и каждый герой в Dota мог бить своих крипов, даже если у них полное здоровье. В итоге баг доработали и превратили в фичу, которая оказалась отличительной чертой Dota от всех остальных игр в подобном жанре.

Создание Крипера

Пожалуй, один из самых «свежих» багов в игровой индустрии за последнее время. Именно в Minecraft нелепая ошибка создателя привела к тому, что в игре появился Крипер. Дело в том, что Маркус Перссон создавал игру исключительно используя свои навыки программирования, он не был дизайнером и у него даже не было софта для 3D-моделинга. В итоге каждый персонаж, который есть в игре, создавался путем написания кода и обретал какую-то форму только после десятка проб и ошибок.

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

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

Ликвидировать нужно не баги, а причину их появления: кейс от разработчика игр

От переводчика: сегодня публикуем для вас статью опытного геймдев-тестировщика Ричарда Тейлора. Статья будет полезна как начинающим, так и опытным разработчикам, — обсудить тут точно есть что.

Я создал множество игр. Обычно завершающий этап разработки весьма болезненный. Ведь именно в конце мы сталкиваемся с багами, и лишь после этого можно уже окончательно наводить лоск на продукт. Ситуация ухудшается, когда у разработчика есть минимум времени на завершение проекта. Работать приходится быстро, и баги в этом случае — частые гости. Как можно справиться с ними? Очень просто: допускать меньше ошибок, только и всего (это ирония автора — примечание переводчика).

Skillbox рекомендует: Двухлетний практический курс «Я – Веб-разработчик PRO».

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Снижаем количество багов

Поскольку все баги — в коде, то, наверное, просто достаточно попросить команду разработки допускать меньше ошибок?

Если вам смешно в этом месте, я не удивлюсь. И действительно, ведь никто (ну или практически никто) не совершает их по собственной воле. Так что же можно предложить команде, чтобы она делала меньше ошибок в коде, с тем, чтобы в нем не было багов?

Начинаем новый проект. Шаг первый — не повторяем предыдущих ошибок

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

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

Речь идет о том, чтобы освободить время на выполнение интересных задач, тех, что позволяют радостно просыпаться утром и тут же браться за реализацию таска. Это то, что сделало нас всех разработчиками — возможность использоваться свое время на по-настоящему крутые штуки!

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

Отвечая на вопрос, как это сделать, необходимо следовать основам научного метода: наблюдение, гипотеза, тест, повторение.

Наблюдение

Категоризация

Откройте базу данных багов вашего последнего проекта и просмотрите ее. Разновидностей багов много, так что просто сказать: меньше ошибок — попросту бесполезно.

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

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

Причина проблемы

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

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

Мы же вам говорили!

Затем мы провели встречу вместе с программистами для того, чтобы обсудить наши находки. Как оказалось, ребята знали о большинстве проблемных мест в коде. Но если это так, какой смысл был в том, чтобы проводить встречу?

Ответ: у нас получилось провести параллель между конкретными местами кода и временными потерями, связанными с этими проблемами. А это, в свою очередь, дало возможность объективно оценивать любое предложение по обслуживанию кода.

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

В самом деле, многие проблемы были системными. Многие «невидимые» аспекты приводили к цепочке событий, которые обусловливали появление ошибки. К слову, причины проблем были настолько системными, что проект пришлось начинать практически с нуля.

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

Гипотезы

Гипотеза 1. Специфические паттерны кодинга, вероятно, приведут к появлению багов в крупном программном проекте.

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

Давайте определимся с тем, что такое большой проект. Это около 25 программистов, 12 месяцев разработки. Для него справедливы следующие утверждения:
А. Любой код будет жить достаточно долго, так что стоимость обслуживания в итоге превысит стоимость самой разработки.
Б. Сложность соединения отдельных систем проекта выше, чем сложность конкретно взятой системы.

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

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

После нашего обсуждения мы получили вот такую формулировку результатов: «Данные показывают, что эти конкретные шаблоны программирования были общим фактором, связанным с различными багами/проблемами. Мы считаем, что избегая этих паттернов, сможем сократить время, которое тратится на исправление ошибок, и одновременно улучшить качество».

Теперь приступаем к практической реализации.

Тестирование

Что дальше?

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

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

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

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: