Pull to refresh

Эволюция геймплея на примере одной игры

Reading time7 min
Views4.3K
В конце ноября сего года на платформе Android и, неделей позже, на iOS вышла наша игра под названием Voltage (Android, iOS, Gameplay Video). Небольшой историей её создания я и хочу поделиться с сообществом. Следует сразу предупредить, что это не «success story», не инструкция по обращению с издателями и уж точно не теоретическое введение в разработку игровых приложений.

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



1. Остров доктора Пажитнова



Задача стояла следующая: разработать игру, которая являлась бы:

а. простой в изготовлении
б. простой в смысле игрового процесса.

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

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

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


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

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

image

Блоки в прототипе были пяти видов:

1. Универсальный блок, который можно было вращать и перемещать по горизонтали.


2. «Semirotary» — при перемещении на клетку влево или вправо, такой блок поворачивался на четверть оборота. Придумать ему адекватное русское название никто так и не удосужился — до сих пор он ходит под конспиративным псевдонимом «зелёный».


3. Фиксированный блок — не вращается при перемещении.


4. «Бомба» — будучи в закороченной цепи, уничтожает непосредственно соприкасающиеся блоки.


5. Изолятор — блок без проводников с характерной полосатой раскраской.



Тестирование прототипа выявило ряд недостатков. Самым очевидным оказался размер «стакана». Заполнить поле размером 11×16 хотя бы до середины представлялось делом почти неосуществимым. С этого и начали, урезав стороны до 7×8 клеток. Заодно, появилась возможность сделать сами блоки гораздо крупнее. Второй прототип выглядел примерно так:

image

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

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

2. Стилизация и стилизаторы



Практически с самого начала мы решили стилизовать игру под «дизельпанк». То есть, ретрофутуризм 30-х, со всеми соответствующими шрифтами, цветом и звуковым оформлением. И в этой короткой главе можно было бы просто показать картинку и идти дальше, если бы не одно «но»:

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

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

image

Следует сразу заметить, что на экране телефона картинка смотрелась куда более симпатично, но в целом стилизация была выполнена в полном соответствии с принципом, описанном в композиции «Just glue some gears on it and call it steampunk». В частности, газоразрядные индикаторы с эпохой дизеля пересекались с огромной натяжкой, не говоря уже о латунных трубках.

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

image

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

3. Между неприятным и неизбежным



С этой, уже почти готовой версией, мы покатили на Casual Connect Kyiv 2011, где, помимо обычных для подобных мероприятий развлечений, занялись полевым тестированием на живых людях. Выпусти мы игру сразу по возвращении, её можно было бы снабдить примерно такой аннотацией:

— I suck at this game.
         Some drunk guy from “Rovio”

— А зачем тут лампочки?
         Трезвый разработчик из-за соседнего столика

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

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

Вроде как очевидно. В действительности — нет. Во-первых, проблему создавал тот факт, что индикатор заполнялся пропорционально набранным очкам: чем длиннее цепи собирал игрок — тем быстрее он получал призовые ресурсы. Кажущаяся логичной схема не содержала достаточно подсказок, чтобы вывести её эмпирически. Во-вторых, в ней содержался любопытный подводный камень: что делать, если игрок имея 75% от полностью заряженного индикатора, прибавил ещё 50%?

Можно выдать ему причитающийся бонус и установить индикатор на 75+50-100 = 25%. Но тогда игрок, не обязанный в общем-то, наблюдать за индикатором неотрывно, в действительности увидит, что показания его уменьшились.

Можно индикатор обнулять. Это гораздо более очевидная и понятная механика, но она кроет ещё более неприятный подвох: игрок может потратить массу ресурсов на длинную цепь, но с заряженным на 90% индикатором большая их часть пропадёт даром. В итоге игра наказывает за то, что, по идее, должна поощрять.

Наконец, сама игра, несмотря на все усилия, упорно сваливалась в одно из двух стабильных состояний: «до обидного лёгкая» и «издевательски сложная». Геймплей настраивался из JSON-файла, в котором были описаны вероятности выпадения каждого блока и проводника — во время игры вероятности оставались неизменными.

Всё это мы начали перестраивать.

Сначала мы изменили принцип, по которому нарастает индикатор заряда — теперь значение имеет сам факт, что игрок замкнул цепь, а не длина этой цепи.

Затем, мы добавили понятие «уровня». Индикатор заряда стал аналогом счётчика «опыта». Для каждого нового левелапа количество замыканий постепенно растёт.

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

Система стала гораздо более прозрачной и понятной.

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

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

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

Как результат — упростилось погружение в игру на ранних уровнях. Кроме того, стал более контролируемым сам игровой процесс.

4. Корона, которая не жмёт



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

В конечном итоге, мы остановились на Corona SDK — который при определённых минусах, обладал двумя несомненными достоинствами: во-первых, для достижения совместимости с Android и iOS практически не требовалось никаких усилий и, во-вторых, в своём классе лицензии разработчиков стоили весьма и весьма дёшево.

Исходный код для Corona SDK пишется на Lua — в целом оказалось достаточно просто освоиться с этим языком.

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

Проблема производительности в Corona SDK решена просто: обрезанием сегмента бюджетных телефонов на уровне системных требований. То есть, на операционной системе более ранней, чем Android 2.2 и с процессорами ниже, чем ARM7, игра не запустится. Ни быстро, ни медленно — никак.

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

5. Вместо заключения



Выпущенная нами версия игры — бесплатная, со встроенной рекламой. К Рождеству мы переходим на модель Freemium — в платной версии будет отключена реклама, в неё же будут добавляться все новые вкусные фишки.

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

И ещё — новый режим игры.

Скачать Voltage можно здесь:

Voltage Android


Voltage iOS



Voltage Gameplay Video

P.S. Пока писалась эта статья, Voltage накопила небольшую статистику, которой я и поделюсь:

Android: за 2 недели количество скачиваний на Андроид Маркете: ~4700, общее количество закачек (андроид маркет+бесчисленные китайско-корейские маркеты) — 12к. Каждый день игру закачивают примерно на 100-200 юзеров больше, чем в предыдущий день.

iOS: около 2500 закачек, скорость роста которых такая же, как на Андроиде.

P.P.S. На недавно проходившем конкурсе ITJump Voltage заняла второе место в категории игр.
Tags:
Hubs:
+30
Comments16

Articles

Change theme settings