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

Очень вольный перевод статьи 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 - это само по себе показательно. Некоторые игры висят там годами, потому что никому не хочется выпускать неиграбельное говно, а без фидбэка игроков именно оно и получится с высокой вероятностью.

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

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