Всем привет!

Я гейм-дизайнер и в данный момент вместе с небольшой командой занимаюсь разработкой двумерной адвенчуры на Unity3D. Цель этой публикации – рассказать о процессе дизайна локаций для нашей игры и приемах, которые я использую.
Ну и параллельно показать вам все стадии развития локации – от схемы до финальной версии.


Забегая немного вперед – так выглядит кусочек уже готовой локации в действии.

«Горячая» и часто обсуждаемая сегодня тема оптимизации конверсии привела к безусловной популяризации А/Б-тестирования, как единственного объективного способа узнать правду о работоспособности тех или иных технологий/решений, связанных с увеличением экономической эффективности для онлайн-бизнеса.

За этой популярностью скрывается практически полное отсутствие культуры в организации, проведении и анализе результатов экспериментов. В Retail Rocket мы накопили большую экспертизу в оценке экономической эффективности от систем персонализации в электронной коммерции. За два года был отстроен идеальный процесс проведения A/Б-тестов, которым мы и хотим поделиться в рамках этой статьи.

В процессе работы над match-3 проектом рано или поздно обязательно встает вопрос — как оценивать сложность созданных уровней и общий баланс игры?

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

Ниже рассказ о том, как мы это сделали в нашей инди-матч3-игре, над которой сейчас заканчиваем работать. (Осторожно — портянка!)

Хабр, привет! Перевели статью Кевина Дабровски, креативного директора Ten Square Games. На примере их игры Fishing Clash он рассказал, какие у них случались факапы, и что делать, чтобы у вас такого не повторилось.



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

Продолжение под катом.

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

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

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

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

Конечно же, преимущества процедурных карт бессмысленны без большой вариативности механик и контента — однообразный hack-and-slash здесь не подойдёт. Поэтому все roguelike, выдержавшие испытание временем, имеют глубокий геймплей.

Этот пост является результатом моей работы над генерацией карт для Cogmind.

Diablo 1 — это классический roguelike 1996 года в жанре hack and slash. Это была одна из первых успешных попыток познакомить широкие массы с roguelike, которые до этого имели нишевую графику в виде ASCII-арта. Игра породила несколько сиквелов и множество имитаций. Она известна своей тёмной, мрачной атмосферой, сгущающейся по мере спуска игрока в подземелья, располагающиеся под городом Тристрам. Это была одна из первых для меня игр с процедурной генерацией карт, и возможность генерации столь правдоподобных уровней просто потрясла меня.

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

Благодарю Дэвида Бревика и команду Blizard North за создание такой потрясающей игры, а также galaxyhaxz и команду Devilution за их удивительную работу по восстановлению читаемого исходного кода проекта.

Разработка мобильных игр — отрасль с очень высокой конкуренцией. Миллионы игр в Google Play и Apple Store, позабытые пользователями сразу после запуска, и редкие истории успеха тому свидетельство. В очередном посте блога «Менеджмент игровых интернет-проектов» мы перевели статью разработчика игр Росса Пшибыльски (Ross Przybylski) о расчёте потенциального дохода мобильных игр F2P. За свою десятилетнюю карьеру Росс успел набраться опыта и в инди-студиях (D20Studios), и в крупных AAA-компаниях (EA).

Наш партнер, аналитическая компания Playliner, подготовила для блога программы "Менеджмент игровых интернет-проектов" исследование по топовым жанрам и сеттингам мобильных игр. Под катом вы найдете информацию о том, какие жанры и сеттинги лидируют в настоящее время в топ гроссинга Google Play. Были проанализированы 150 игр на 1 апреля 2017.

Вопрос расчёта lifetime value (он же LTV, customer lifetime value, CLV) рано или поздно встаёт перед разработчиками мобильных (впрочем, и не только) приложений. Методов расчёта придумано множество, и по поводу того, как считать LTV, существует сколько людей, столько же и мнений. В данном материале я решил описать наиболее распространённые методы, обозначить их плюсы и минусы. Данные методы подходят прежде всего для описания f2p-модели.

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

Это вторая часть серии. Первую часть можно посмотреть здесь.

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

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

Тем не менее, soft launch может быть трудоемким процессом – не всегда очевидно, что нужно делать, а чего лучше избегать. Только в 2017 году мы в Nexon провели soft launch около десятка игр. В процессе проб и ошибок мы поняли, что лучше всего подходит для наших игр. Предлагаем вам некоторые из наших лучших практик.

Всем привет! Мы два новоиспеченных разработчика мобильных игр, бывшие одноклассники, выпускники Казанского федерального университета, Айдар и Эд.

Айдар: «История нашей игры «Syncomania» началась с того, что мне приснился странный сон. Он представлял собой компьютерную игру, где на квадратном поле синхронно передвигались четыре белых шарика. Когда первый из них вырвался за пределы игрового поля, я проснулся. Наутро я позвонил Эду, а уже в обед мы встретились во дворе университета, где я работал».

Эд: «Какой программист не мечтал сделать свою игру? Летом 2014-го у меня было много свободного времени, и я с радостью ухватился за эту идею. Тогда мы и представить себе не могли, с какими трудностями мы столкнемся».

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

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

В этой статье я расскажу о внедрении «глубокого UX» в современную мобильную разработку, благодаря которому мне удалось добиться существенного и устойчивого роста Ret1. Под глубоким UX я понимаю комплекс мер, который направлен на работу не только с такими привычными вещами, как информативность, предсказуемость и удобство, но и с такими субъективными, как эмоциональное вовлечение и удержание.

Как создать свою игру? Сколько на этом можно заработать? Какая нужна команда? Каковы ключевые этапы разработки и что нужно делать команде на каждом этапе? Ответ на эти вопросы – в открытой лекции по разработке игр в рамках программы «Менеджмент игровых интернет-проектов», которую разместили наши партнеры — открытая система электронного образования Универсариум. Вот здесь можно посмотреть открытую лекцию:

• «Как создать свою игру», часть 1
• «Как создать свою игру», часть 2

А под катом вы найдете краткое текстовое описание.

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

1. Глобальные общефилософские рассуждения из разряда «10 причин, почему тебе не надо становиться инди-разработчиком игр»;
2. Узко специализированные туториалы, решающие конкретную задачу: «Поворачиваем изображение в %framework_name% на произвольный угол при помощи %tool_name%»

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

Многие думают — хочу делать игры! Вроде и идей у меня куча (правда скорее всего никак не оформленных), и в других играх я все недочёты вижу с первого взгляда и мысли свои излагать могу связно и последовательно, но… Чего-то не хватает! Что именно делать, если хочешь попробовать себя на ниве игростроя? Пути вроде всего два: делать игры в составе какого-нибудь профессионального коллектива или делать игры самому. Но даже беглый обзор в моём регионе (Санкт-Петербург) показал, что такой позиции, как «Junior Game Designer», в принципе не существует. И даже не джуниор позиции очень редки.
Видимо, это закрытая кухня, в которую со стороны попасть трудно. Отсюда возникает другое решение — идти в контору, производящую игры самостоятельно на любую открытую позицию, естественно при наличии соответствующей квалификации). Но и тут есть нюанс, личный опыт мне подсказывает, что будучи рядовым разработчиком, шансы поучаствовать в написании GDD (да в принципе и любого другого ТЗ) или хотя бы в формировании начальных требований к нему, очень незначительны. Времени на это просто не будет, а на общих собраниях, с участием всех отделов, если таковые вообще будут, можно почерпнуть только очень, как это ни странно, общие концепции.

16 сентября 2007 года японский ютубер под ником Computing Aesthetic загрузил 48-секундное видео с громким названием «ULTRA MEGA SUPER LUCKY SHOT» («УЛЬТРАМЕГАСУПЕРУДАЧНЫЙ ВЫСТРЕЛ»). В видео показан сверхрезультативный выстрел в популярной игре Peggle, частично основанной на принципе японских автоматов для пачинко. В этой игре шарик летает по экрану, зарабатывая очки при ударах об разноцветные штырьки, которые после удара почти сразу исчезают; чем больше ударов, тем больше очков. Хотя в Peggle и требуется мастерство — перед выстрелом игрок должен точно прицелиться — принципиально игра зависит от удачности отскоков шарика. В видео Computing Aesthetic игрок зарабатывает огромное количество очков благодаря удачным отскокам между штырьками. Чтобы подчеркнуть кажущуюся удачность выстрела, игра до последних кадров видео проигрывает эйфорическую «Оду к радости» Бетховена, после чего шарик падает в лунку внизу игрового поля и на экране появляется мерцающая надпись «FEVER SCORE». В описании к видео, просмотренному почти четверть миллиона раз, написано «I couldn’t balieve this when it happened!!!!!!!!!» («Не могу паверить, что это случилось!!!»)

Как и в реальном мире, в играх есть множество объектов, каждый со своим внешним видом. В Unreal Engine этот внешний вид зависит от материалов. Какой цвет имеет объект? Прозрачен ли он? Блестит ли? Все эти свойства задаются материалами.

Материалы используются почти для любого визуального элемента в Unreal Engine. Материалы можно наносить на любые объекты, включая меши, частицы и элементы UI.

В этой части туториала вы научитесь следующему:

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