Избранное сообщение

Очень вольный перевод статьи Designing to Succeed

Не так давно некий Tony Downey, геймдизайнер, опубликовал внушительную статью о разработке и игровом дизайне инди-игр. В ней он рассмотр...

среда, 27 июля 2016 г.

DTF ещё больше всё

Многие, наверное, и не помнят, но во времена расцвета российского геймдева существовал такой сайт - dtf.ru. DTF - это Daily TeleFrag. И был этот сайт первым русскоязычным профессиональным сообществом игровых разработчиков. Такие мастодонты как Юрий Мирошников и Сергей Орловский были одними из первых его пользователей. Регистрация на сайте большую часть времени была очень непростой - нужно было получать отзывы от "проверенных", чтоб получить статус полноценного пользователя. И всё было хорошо, пока был жив ритейл и старые концепции...

А потом мировая индустрия начала меняться, а отечественная - нет. Модной стала цифровая дистрибуция, планка качества игр постоянно росла. А у нас всё так же печатали диски и выпускали на них "Корсаров" версии 0.9 (здоровенный скандал был, кстати). И постепенно ресурс умер. Молодые разработчики общались всё больше в соцсетях, а не на форуме ДТФ, где можно было получить ушат помоев от заслуженного старожила и бан от модератора за попытку с этим старожилом поспорить, старые - кто закрылся (привет, "Акелла"!), кто просто исчез из информационного поля. В итоге в последние годы на ДТФ движуха сходила на нет.

А сегодня я с удивлением обнаружил вот это: тыц. Хипсторки с vc.ru купили домен и будут "возрождать легенду". Хотя уже по этому интервью видно, что у них получится чуть менее, чем ничего - ресурс будет про "трафло и бабло" и взаимное надрач подлиз... ну, в общем, про взимную любовь хипсторков с гопняцкими замашками, назначивших друг друга гуру геймдева.

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

вторник, 12 июля 2016 г.

Радость и боль блупринтов

Я тут недавно стал экспериментировать с Unreal Engine 4. Унрил - мощь, с кучей крутых штук из коробки, Юнити при этом тихо курит в стороне. При этом самой любопытной штукой в нём является система блупринтов - эдакое визуальное программирование. Тягаешь себе ноды, рисуешь связи между ними. Получается что-то типа того:
"Настоящие программисты" любят ругать эту систему, ибо "только C++, только хардкор". Я же ничего особо плохого в блупринтах не вижу - тем более, что зная плюсы всегда можно написать свою кастомную блупринт-ноду. Я бы выделил следующие плюсы и минусы этого всего:

Плюсы:

  • Можно быстро прототипировать простые функциональности, просто накидывая готовые ноды
  • Много функций реализовано заранее - не надо по сотому разу делать свои тригонометрические велосипеды, например, когда есть findLookAtRotation
  • Всегда виден чёткий execution flow - для поиска определённого места в чужом "коде" не нужно пробираться через дебри паттернов и других вещей, которыми решил выпендриться человек
  • Нет стандартов кодирования, холиваров из-за скобочек и прочей фигни. Хотя, возможно, есть холивары на тему красивого расставления нодов
  • Всегда можно написать свои кастомные ноды на C++ и дальше играться с блупринтами
Минусы:
  • Блупринты - это бинарные файлы, сурс-контроль только встроенными в редактор средствами через Perforce или svn
  • Порой излишняя громоздкость. Сделать на блупринтах 'boolVar = !boolVar' - это значит поставить ноду 'GET boolVar', протянуть от неё ребро, сделать ноду 'NOT', протянуть дальше, сделать 'SET boolVar'. А сложные логические ветвления - это вообще ад.
  • Вероятно, для больших и сложных проектов писать свои кастомные ноды на C++ - это не "можно", а "необходимо"
Возможно, в ближайшее время я погружусь в это дело поглубже и дополню пост.

вторник, 21 июня 2016 г.

Фидбэк и аналитика как метод QA

Анализ фидбэка от пользователей и их поведения - это очень важная часть разработки софта. Вспомните, сколько боли пользователям в последние годы приносили необдуманные редизайны крупных сайтов - все эти #Дуроввернистену, откровенно убогий и нефункциональный Кинопоиск, тысячи их... Нормальные люди предварительно выкатывают крупные обновления, затрагивающие UX, на фокус-группы - именно это сейчас происходит с новым интерфейсом VK, например.

В разработке игр фокус-группы, UX-тестирование и встроенная на каждое движение игрока аналитика - важны ещё больше. Если для обычных приложений и сайтов существуют какие-то устоявшиеся каноны (например, в 99% прикладных программ мы ожидаем увидеть сверху какое-нибудь меню, где будет "Файл - Сохранить"), то игры - непредсказуемы. И это касается не только и не столько интерфейса, сколько игрового процесса. Вписать удовольствие от игрового процесса в какие-то рамки и каноны - невозможно, игра строится исключительно на чуйке и личном опыте гейм-дизайнера. И тут кроется самая опасная ловушка для игровых разработчиков, особенно начинающих - можно начать делать игру для себя, а не для аудитории. Проблема в том, что игровой разработчик - обычно человек весьма искушённый в играх и имеющий очень специфические вкусы. И закончиться такая разработка может тем, что в игру потом будет играть только сам автор + 1,5 задрота со схожим взглядом на мир.

Именно поэтому важно всегда ВСЕГДА собирать фидбэк целевой аудитории. Сделал демо - дай погонять тем, кто будет пользоваться этим софтом или играть в эту игру. Погоняли - подробно опроси их. Полезно для таких случаев иметь подготовленный вопросник, заостряющий внимание на потенциально проблемных моментах. Возможно, стоит дать выполнить пользователю несколько подготовленных сценариев (например, "купи 5 заклинаний" или там "добавь в документ таблицу", если говорить о софте) и посмотреть, насколько легко пользователь с этим справится. И, конечно, всегда кроме заданий и опросников надо дать высказаться человеку в свободной форме - возможно, вы пропускаете что-то очень простое и очевидное.

При этом нельзя полностью доверять всему, что наотвечает ЦА. В идеале надо записывать всё, что происходит на экране пользователя, чтобы у человека не было искушения наврать о простоте выполнения какого-то задания. Люди не любят показывать себя глупыми и могут не сказать, что искали чёртову кнопку полчаса. Самый продвинутый вариант - писать не только экран, но и лицо пользователя. В частности, так в своих фокус-группах делают Big Fish Games. Это позволяет следить за эмоциями игрока и находить не только ошибки по части интерфейса, игровой логики, но и по части повествования или визуального стиля (например, если пользователь справился со всем, но на видео у него кровоточат глаза, а лицо перекосило в гримасе ужаса - значит с дизайном что-то явно не так).

Тем не менее, фокус-группы не могут выявить всех проблем, их тяжело набирать, а у маленьких команд может просто не быть возможности организовать нормальное фокус-тестирование. В этом случае остаётся полагаться только на встроенную аналитику (которая нужна, даже если у вас есть офигеннейшие фокус-группы). Если это не влияет негативно на производительность - то надо собирать статистику буквально по каждому значимому действию пользователя. Если влияет - то только по ключевым в финальной версии, и всё равно по каждому - в ранней. Существует множество готовых решений для лёгкого встраивания аналитики почти на все случаи жизни. Во времена расцвета Flash было невозможно представить уважающего себя разработчика, который не имел бы десятка самых разных графиков: вот среднее время прохождения уровня, вот динамика набора очков игроками, вот количество игроков, прошедших каждый из уровней... На основе этих графиков разработчики могли оперативно находить проблемы в своих играх - если график количества игроков, прошедших уровни, резко проваливался, а не снижался плавно - значит, с уровнем что-то не так, надо уменьшать сложность. Если график был слишком плоский - значит, уровни надо усложнять, нет соревновательности. Если график вдруг растёт (а уровни проходятся линейно) - значит в игровой логике где-то есть здоровенная дырень! Сейчас подобная ситуация наблюдается на рынке мобильных игр - там тоже полно средств аналитики, которые помогают улучшать пользовательский опыт. У меня нет статистики по использованию аналитики в играх для Steam, но такой раздел как Early Access - это само по себе показательно. Некоторые игры висят там годами, потому что никому не хочется выпускать неиграбельное говно, а без фидбэка игроков именно оно и получится с высокой вероятностью.

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

Но при всём богатстве средств и способов сбора информации, никогда не стоит забывать делать кнопочку "Сообщить о проблеме". Это, конечно, увеличит поток информации, которую будет необходимо обработать, но также увеличит и шансы не пропустить что-то критическое.

пятница, 4 декабря 2015 г.

SCIV


Просто логотип нашего самописного тестового фреймворка на текущем проекте...

понедельник, 10 августа 2015 г.

"Тестирование дот ком"

Сегодняшний пациент - это абсолютный лидер ответов на вопрос "А читали ли вы что-нибудь про тестирование?" на собеседованиях. Роман Савин "Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах". 

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

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

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

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

среда, 15 июля 2015 г.

Собесы: Playkot

Playkot - это вот эти ребята. Делают социальные игры, довольно успешные. Я был у них на собеседовании весной 2014 года.

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

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

четверг, 4 июня 2015 г.

Собесы: Artogon

Artogon - это небольшая питерская студия, которая делает казуальные игры. Их конёк - высококачественные HOPA в жанре spooky. HOPA - это Hidden Object Puzzle Adventure, по факту - практически квесты от первого лица с кучей паззлов и редкими мини-играми на поиск предметов. Spooky - это что-то типа "страшилок", то есть в играх есть мистика, приведения, оборотни и прочая атрибутика, но в итоге получается скорее страшная сказка, чем ужасы. Urban dictionary на этот счёт говорит интересное: There is a big difference between the words "spooky" and "creepy." Spooky can't hurt you. Creepy can and probably will. Goth is not "Creepy." It's "Spooky"Игры Артогона довольно часто висят в топах Big Fish Games и прочих казуальных порталов. 

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

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

Если говорить о собеседовании - то мы просто пообщались с руководителями, благо мой опыт работы на Flash толсто намекал, что программировать я умею. Собственно, понимание основных принципов программирования, чуть-чуть ООП, адекватность и базовые знания о геймдеве как таковом - это всё, что нужно для программиста игровой логики, или, как любит называть это Денис (основатель Артогона) "творца скриптов". Для артистов и низкоуровневых программистов, вероятно, требования иные, но адекватность, полагаю, всё равно будет иметь приоритет.

В общем, Артогон - отличное место, чтобы набраться опыта.

четверг, 28 мая 2015 г.

Просто любопытный факт

Тут Charter собирается покупать Time Warner за 55 миллиардов долларов. 55. Миллиардов. Долларов. 55...

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

четверг, 6 ноября 2014 г.

Watch your back!

Всегда тестируйте бэкэнд. ВСЕГДА. Даже если ваша задача - только фронт, удостоверьтесь, что кто-то активно занят бэком. Если не занят - заставьте кого-то заняться или займитесь сами.

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

-А-А-А-А! Почему наше приложение в категории Children показывает какие-то порно-фильмы?!
-Потому что вот все ответы от сервера на запросы списков фильмов - где-то за океаном контент-менеджеры облажались, мопед не наш.

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

В общем, мне тут пара написанных на коленке питон-скриптов, вытаскивающих с сервера заказчика данные по всем возможным запросам и проводящих базовый анализ ответов на корректность, помогла снизить количество ложных багов на 85% минимум. Теперь все довольны: мне меньше работы, разработчикам меньше головной боли, менеджерам меньше инфарктов, а заказчикам халявные баг-репорты. А сначала-то было "out of scope, не наше дело...", вот это всё.
PS:
Кстати, Гугол мне сейчас говорит, что "Бэкэнд - 1) последние 7,5 метров дорожки перед пиндэком 2) задняя часть пинсеттера в сборе." И то, и другое - это что-то из боулинга.