Я хотел бы продолжить рассказ и осветить некоторые сокрытые моменты разработки, включая как техническую часть со своей стороны, так и важные моменты проекта от других участников команды. В результате записи мыслей, получилось достаточно много материала – гораздо больше, нежели в прошлый раз, поэтому публиковать его буду несколькими этапами. Благо, логически разбить его получилось очень просто.
И первая часть будет повествовать о заложении основ проекта – создании мира, продумывании механики игры, оттачивании баланса, поддержании порядка в системе. Вся первая часть полностью лежит в зоне ответственности нашего координатора проекта. Каждое событие проходило непосредственно через него, и каждое действие было совершено именно с его стороны – посему все описанное далее является трудом координатора в проекте.
Труд координатора
Координатор проекта в нашей команде играл и играет роль связующего звена – именно по его велению и пониманию устройства мира вводятся те или иные изменения, именно на его опыте игры и работе в подобных проектах строится вся суть баланса, управления поведением игроков, основные аксиомы проекта.
Например, с самого начала проекта было обозначено для всей команды, что в первую очередь игра не будет давать тотального преимущества игрокам, покупающим за реальные деньги игровую валюту – для каждого (или почти каждого) элемента игры обязательно будет предложен альтернативный источник добычи, и возможность использования этого элемента будет достижима. До сих пор на проекте есть только два уникальных для «платной» валюты момента, но даже при этом получить «печеньки» можно без непосредственной оплаты – через продажу игровых предметов на «рынке» игры.
Именно благодаря этому человеку вообще начался проект, и продолжается по сей день.
Создание мира
Любой проект начинается с идеи, однако некоторые проекты требуют не просто наличия основной мысли, но и ее детального описания, постоянного развития, подкрепления своей внутренней «физикой», и при этом полного учета каждого нюанса для поддержки целостности. Нашей целью было создать такой мир. Мир, который будет развиваться постепенно, но иметь под собой твердую основу с самого начала.
В прошлой статье я уже упоминал, что в начале пути в нашей команде было два концептщика, на которых возлагались надежды как генераторов идей, но я мало придал значения описанию их вложенного труда в развитие проекта. Они были приглашены в основном из-за того, что уже имели колоссальный опыт в качестве игроков в подобных проектах и могли словом и делом подсказать координатору «в правильном или неправильном направлении» движется его идея. Субъективно конечно, но на начальном этапе, чем больше мнений и обсуждений, тем для концепции – лучше.
Итого у нас получилось три человека, понимающих внутреннее устройство «браузерки».
На старте формирования концепции мы создали общий Skype-чат для коллективного мозгового штурма, куда выносились на обсуждение идеи, которые потенциально могли составить мир игры. Началось все с выяснения, кем заселить игру — нужен был набор из нескольких типов игровых персонажей, которые бы никак не пересекались с имеющимися аналогами в других играх. При этом благодаря найденным персонажам могло сложиться практически готовое название для проекта, и к моменту всеобщего соглашения об использовании разных видов птиц, проект получил кодовое название «birdz», а позднее через несколько месяцев был переименован в «Пернатск». Уникальное слово, свободный домен.
С тем же настроем придумывались валюты — вся валюта, за исключением разве что монет, на тот момент не должна была быть использована в других проектах в том сочетании, что будем использовать мы. Да и в принципе практически любой элемент игры должен быть отдален от действующих конкурентов на рынке.
Для нормального запуска проекта необходимо набрать критическую массу идей, пускай разрозненных, практически не связанных друг с другом и не сбалансированных в мире. Эти кусочки мозаики можно сложить в дальнейшем в общую карту проекта, попутно подпиливая углы у каждого кусочка из-за того, что они несколько неудобно стыкуются.
Для записи идей мною был написан Skype-бот, который, при появлении в сообщении слова «идея», копировал все сообщение в wiki, с надеждой на дальнейший разбор образовавшихся завалов. И это работало.
Обдуманный жаргон
По мере набора массы игроков и образования некого сообщества игры, по проекту обязательно начнет хождение некий набор слов-сокращений или англицизмов, характеризующих те или иные моменты проекта. При этом если заранее подумать над этим вопросом, можно предугадать и направить игроков на использование угодных нам слов или сочетаний, дабы определенные названия ассоциировались только с нашим проектом и ни с каким другим.
Для большинства элементов игры (когда целенаправленно в виде систематизированных списков, когда просто в виде мыслей) создавался некий набор ассоциаций и вариаций по написанию. Например, для редких предметов, которые должны добываться в игре посредством «случайного обнаружения», мы в итоге приняли за официальное название выдуманное слово «редлик», которое однозначно и коротко характеризует предмет и его тип при разговоре группы игроков, что сразу прижилось как уникальный термин.
«Пернатость», которая у нас характеризует «крутость» игрока в рейтинге, некоторые игроки называют «яйками» из-за внешнего сходства иконки, что, в общем-то, если абстрагироваться от изображения, может нести даже какой-то верный смысл.
Главного «бота» игры – противника, доступного для атаки в любое время с характеристиками рассчитываемыми сервером исходя из характеристик атакующего, – зовут «Железный птиц», а игроки называют его «железкой» или «железякой».
Повторюсь — эти моменты игры можно продумать заранее, предложить игрокам свои варианты, принять их как особенность игры, что придаст миру свои мелкие интересности, нужные штрихи и акценты.
Кладезь данных
Я уже упоминал, что для записи идей мы открыли wiki, но держать мысли в порядке и систематизации – не менее важная часть работы над проектом, чем непосредственно их генерация.
Благодаря тому, что наш координатор проекта имел за плечами некоторый опыт разработки сайтов своими силами, мы в wiki имели специальные разделы для разработчика, специальные разделы для художника и разделы для всех. Для быстрого написания админки у меня перед глазами был огромный список свойств персонажа, который мне предстояло упихивать в базу данных, попутно нормализуя в голове и составляя верную архитектуру – но основа для приятной работы у меня всегда была.
Любая статья в wiki проходила два-три этапа: набросок основной идеи концептщиком, придание читаемого вида (от разбивки на предложения, до ввода дополнительных условий работы функционала), технические требования для реализации. Координатор проекта работал у нас неким C3PO – связным между людьми и киборгами – помогая мне переводить поток эмоций от концептщиков в рабочий код.
Сейчас в нашей игре есть раздел Библио – идейный наследник wiki: описание каждой локации, каждого действия и элемента интерфейса. Организация в начале разработки wiki послужила началом и в принципе внесла идею создания базы знаний внутри игры.
Спустя полгода разработки мы обозначили для себя тот набор функционала, который должен был быть готов для запуска альфа- и бета-версии.
Открою небольшой секрет: из всего намеченного функционала на текущий момент (публичная бета-версия) реализовано примерно 70%. Почему так? Ответ прост, в итоге мы пришли к мнению, что просто не сможем сделать все, что задумали, не лишившись сил или рассудка. Часть требований были урезаны, а другая часть перенесена на «после старта». Однако к имеющемуся на тот момент списку в процессе работы добавлялись дополнительные важные модули, перекрывающие по объему упущенный функционал.
Сердце системы
Прежде чем будет возможно создание хоть каких-то действий в игре, необходимо определиться с главными параметрами, от которых будет рассчитываться в дальнейшем практически все. В первую очередь нужно составить список характеристик персонажа и определить, какую смысловую нагрузку будет иметь тот или иной параметр. В нашем случае было выделено пять характеристик, к которым позднее для ввода дополнительных усложняющих факторов добавились еще две.
На самом деле, если меня попросят продемонстрировать какой-то кусок исходников системы, я без проблем покажу любой, за исключением только одного – класса с формулами. Один единственный файл формирует всю логику работы и весь баланс в игре, именно этот файл постоянно модифицируется и дополняется в процессе отладки баланса. И чтобы создать такой файл или вообще одну любую формулу расчета, необходимо определиться с желаемым поведением игрока.
Ниже я приведу пример концепции и возможной реализации. Пример не является фактическим.
Предположим, что мы хотим держать «только что зарегистрированного» игрока на первом уровне ровно один «рабочий» день при его заинтересованности в этом. Для этого мы определяем методом «научного тыка», что игроку за день нужно провести 50 боев, получая за каждый бой ровно одну единицу опыта — таким образом, для достижения второго уровня игрок должен набрать 50 единиц опыта. Чтобы было невозможно провести за день больше боев, мы определяемся с задержкой времени между боями – условимся на 10 минутах реального времени. Итого за 8 часовой день при постоянном мониторинге таймеров игрок наберет 48 единиц опыта.
Далее нам требуется определить, какой именно бой мы хотим видеть, и какие события в нем должны присутствовать. Предположим, в бою можно попасть по противнику, нанести критический урон, промахнуться, заблокировать удар – этот набор «событий» должен сочетаться в бою с такой частотой, чтобы количество событий можно было регулировать при помощи изменения характеристик игрока, и с увеличением его уровня не возникало бесконтрольного числа таких событий. На каждое из «событий» следует ориентировочно прикинуть, какие параметры игрока должны прямым образом влиять на их наступление.
Теперь можно предположить, что для факта нанесения критического урона нам необходимо значение «меткости» атакующего и значения «интуиции» защищающегося – от сочетания этих двух параметров должен зависеть исход наступления события. Сила удара будет зависеть от значения одноименной характеристики атакующего и значения характеристики «защита» защищающегося. И, опять же, предполагаем, что мы хотим за один бой из 10 раундов видеть 1-2 подобных удара.
Аналогичный путь создания проходят все остальные желаемые события.
В итоге, из большого количества таких «предположений» складывается начальная картина поведения персонажа в бою, в дальнейшем корректируясь в зависимости оттого, что именно мы хотим получить.
Нынче существует большое количество формульных моделей расчета для поединка между игроками. Но, создавая что-то своё, вы практически будете тыкать пальцем в небо — подстраивая, анализируя и экспериментируя.
Для повышения самих характеристик персонажа используется валюта, которую тоже нужно каким-то образом добывать. И если мы желаем ограничить количество характеристик, которые игрок сможет улучшить на определенном уровне, мы можем прикинуть объем валюты, необходимый и достаточный для добычи за определенный отрезок времени.
Например, можно ограничить на первом уровне значения характеристик лимитами от 1 до 10, по всем параметрам (в сумме потраченных средств). На втором уровне — от 10 до 25, на третьем — от 25 до 40, и так далее, чтобы на высоких уровнях интерфейс и типовые ограничения полей базы данных вмещали в себя нужные показатели.
Далее необходимо смоделировать поведение персонажа на каждом уровне, включая все рабочие элементы, занимающие время у игрока. При этом очень важно заранее предугадывать возможные «перекосы» по уровням активности. Хотя добиться идеала – невозможно. Кроме того, в игровые формулы можно ввести случайные величины, чтобы расчет поединков, добычи ресурсов и прочие формульные зависимости не были линейны и подконтрольны ожиданию.
Продумывать и предполагать приходится очень много – при фактическом отсутствии конкретики получается огромная картина всяческих взаимосвязей, которую приходится держать в голове для корректировки какого-то участка системы.
После появления разрозненных кусков информации, обилия взаимосвязей между базовыми параметрами, многочасового обсуждения, составления моделей основных типов игроков, приходит время написать сами формулы и применить на практике.
В нашем случае, координатором проекта собственноручно был написан сводный анализ формул: огромных размеров страница, с несколькими десятками полей для ввода параметров, которая по нажатию единственной кнопки просчитывала несколько сотен боев с заданными значениями характеристик, моделей добычи ресурсов. Итоговый «выхлоп» расчетов анализировался, коэффициенты модифицировались, и расчет запускался заново. Подобный подбор коэффициентов и вида формул занял практически два месяца, в то время, пока разрабатывались основные модули админки, и создавался общий концепт иллюстраций.
Главной задачей, которая решалась и решается до сих пор, является создание баланса добычи ресурсов, получения опыта, пернатости, увеличения характеристик и структуры проведенных боев, когда развитие персонажа происходит равномерно с учетом побочных мини-игр и дополнительного функционала, открывающегося с ростом в уровне.
Во время публичного бета-тестирования, мы получили несколько негативных отзывов относительно того, что баланс отвратительный и выполнен неверно. Доводом игрока служило то, что его персонаж просто обязан при текущей «раскачке» в абсолютно всех случаях проведения поединка уворачиваться от удара противника. К слову сказать, игрок полностью все добытые средства вложил в одну единственную характеристику «ловкость», доказывая, что его подход единственно верный. Наше же понимание баланса складывается из других принципов, и формулы будут подстраиваться под общее понимание развития персонажа, а не под откровенные «перекосы» в попытке получения тотальной выигрышной ситуации, что, по сути, и является — дисбалансом.
Ненавистный многими «рандом» в подобных формулах был сведен к минимуму, но не исчез полностью. Характеристики являются ограничителями и множителями случайных величин, а не единственным фактором расчета, при этом колоссальный перекос по одной характеристике между двумя персонажами не является фактическим залогом выигрыша, так как всего лишь соответствующим образом влияет на шансы удачного попадания в диапазон случайной величины. Такой подход к постановке формул позволяет двум поединкам между одними и теми же персонажами каждый раз проходить по-разному, и оставлять шанс на победу над более сильным противником.
До сих пор главной ответственностью координатора проекта является постоянный мониторинг проведенных боев с целью выявления малейших колебаний в сторону от задуманных целей и желаемого поведения игроков. В течение всего бета-тестирования вносятся соответствующие корректировки в формулы, регулируется баланс. Стоит отметить, что одной из последних функций, введенных в систему перед запуском беты, был сбор большого пласта статистики – более трехсот показателей – который агрегируется с некоторой периодичностью. Кроме того, на каждое действие, связанное с расходом или получением средств и показателей в игре делается отдельная запись лога. Эти два больших инструмента отслеживания позволяют корректировать наше представление о действиях пользователей и, соответственно, изменять баланс в нужную сторону.
Если попытаться дать вольную характеристику браузерной игре, то это «эдакий большой инженерный калькулятор», слегка «приправленный» графикой, где игроки пытаются решить большую систему уравнений с огромным количеством неизвестных. Решают они методом «тыка», анализируя общее изменение поведения среды от изменения каких-либо параметров. При этом администрация, в свою очередь, пытается по готовым ориентировочным придуманным решениям уравнений составить математическую модель в виде системы уравнений. Вообще, знаете, это – мысль, надо будет попробовать как-нибудь привлечь к работе математика.
Звезда команды
Не стоит забывать, что координатор проекта помимо основных обязанностей по сотворению мира имеет на своих плечах весь груз по созданию правильных связей в команде. При этом абсолютно не обязательно, чтобы все участники команды каким-то образом контактировали друг с другом, более того, лично я намеренно отстранился от общих разговоров внутри нашей группы – такова особенность моего характера, и координатор полностью принял такое поведение с моей стороны как нормальное и приемлемое. Это позволило мне работать спокойно над своей частью проекта и не лезть в текущую социальную бездну, которая могла повлиять на меня совершенно непредсказуемо.
Благодаря координатору и его магическим возможностям создавать благоприятное к себе расположение людей, мы смогли организоваться как команда, и работать в дальнейшем, не развалившись на части. Да, некоторые ушли от нас, но эти потери были устранены силами координатора, и проект не остановился на месте.
Поскольку с самого начала наш проект намечался как долгосрочный, то делать его с полным отсутствием ориентиров не представлялось возможным. Любой план, даже невыполнимый, придает некую уверенность и цель, к которой можно стремиться. Именно поэтому после обдумывания и упорядочивания идей сотворения мира, мы утвердили примерные сроки запуска каждого из этапов проекта (пре-альфа, альфа-, закрытое бета-, открытое бета-тестирование, запуск), составив подробный список модулей, которые должны быть готовы.
Ад и мясорубка
Поскольку мы не знали, как себя поведет сервер и система в целом от увеличения нагрузки, какой порог пользователей следует считать критичным, на время бета-тестирования мы защитились от возможных лавинных набегов пользователей путем ввода наличия обязательного приглашения для регистрации в игре.
На самом деле реально ощутимого «хабраэффекта» не случилось в прямом понимании этого слова, хотя ситуация была куда лучше, нежели я предполагал. Я смиренно ждал реплики: «Очередная браузерка» — вместе с фактически отсутствующим интересом к проекту, однако всего за несколько дней количество зарегистрированных человек увеличилось практически в десять раз по сравнению с ситуацией до публикации – со 180 до 1600 человек. Наш сервер ныне живет под «нагрузкой» в 4-12 запросов в секунду и практически не замечает этого, имея средний показатель загрузки CPU в районе 4%.
Но не то был «хабраэффект», от которого мы предполагали, что защитились. Главным взрывом в проекте оказался поток обсуждений, рекомендаций, отчетов об опечатках и ошибках, которые мы в течение первой недели пытались разгрести ударными темпами. Мы имеем в наличии шесть каналов связи пользователей друг с другом и администрацией на проекте – внутренняя служба поддержки, внешняя служба поддержки (включая входящие письма в почтовый ящик), «пвиттер», форум, комментарии к новостям, личные сообщения. Каждый из этих каналов связи был полностью загружен поступающими для нас данными, которые необходимо было быстро обрабатывать, дабы не бросать пользователей в неизвестности.
Первые дни координатор проекта практически жил без сна – даже если он говорил, что уже «вот-вот» пойдет спать, он все равно продолжал в итоге отвечать на вопросы пользователей. Мой характер не позволяет мне легко и просто общаться с людьми в «быстром режиме». И я не могу написать сообщение без свойственного мне стиля, который не все могут воспринять адекватно, без того, чтобы увидеть в нем некое пренебрежение или надменность (хотя это не соответствует действительности и моим реальным мыслям на тот момент). Поэтому все, что я мог делать в данной ситуации – исправлять «баги», дописывать улучшения интерфейса и исполнять пожелания пользователей, не вступая с ними в реальный контакт.
Но координатор был не один – ему в помощь в разборе «завалов» пришли два человека, влившиеся в нашу команду еще с момента старта альфа-тестирования. А с момента старта бета-тестирования, команда расширилась вновь и теперь насчитывает 8 человек, обзаведясь администраторами и модераторами игры.
Несомненно, бета-тестирование принесло огромную пользу проекту. Как в отлове «багов», так и в общении с игроками.
Белка в центрифуге
С каждым новым куском вводимого обновления в проекте увеличивается объем информации и знаний, который должен помещаться в голове координатора. Помимо того, что необходимо просто знать, что же мы сами делаем в проекте, необходимо видеть и замечать все, что делает пользователь и администраторы, отвечать на повторяющиеся вопросы, следить за каждым возможным непредусмотренным действием, составляя перечень «багов» или доработок – это ежедневный минимум мониторинга, который осуществляет координатор проекта.
И столько уже было написано материалов на тему того, что руководитель всегда работает круглые сутки, в нашем случае – это не просто полностью отражает действительность, а практически списано с нашей ситуации. По идее, все, что необходимо для решения данной проблемы – найти источник финансирования проекта, и привлечь больше людей, которые смогут на основе полноценного работника выполнять задачи. Однако поиск финансирования сопровождается, во-первых, огромными вложениями временных ресурсов (гуляния по «стартап-тусовкам», презентации, мольбы к инвесторам и так далее), и, во-вторых, большим отсевом среди потенциальных желающих получения инвестиций, что несколько снижает наши шансы.
Невозможно полностью надеяться на чудо или других людей в команде, передавая свои обязанности кому-то. Ровно как я не могу отдать написание модуля проекта координатору (несмотря на наличие у него опыта разработки), так и координатор не сможет делегировать мне обязанности создания концепта системы, хотя при этом периодически мы подкидываем друг другу некоторые хорошие идеи. Кроме того, появляется банальная ревность за свою работу и ее качество – лично я много раз задумывался, стоит ли продолжать поиски программиста в подмогу нам, но главный вопрос, останавливающий меня, остается: «А что если другой разработчик что-то испортит, украдет код, сделает пакость, неправильно напишет модуль или что-нибудь еще?».
При всем объеме работ приходится каким-то образом находить время на семью, личный отдых, основную работу. Появляются мешки под глазами, количество будильников на утро приближается к двузначному числу, во сне ищутся решения проблем, которые возникли в период бодрствования.
Что самое интересное, то буквально за пару дней до прошлой статьи на Хабре такой ситуации не наблюдалось – но с каждым новым зарегистрированным пользователем неожиданно увеличивается объем работ и ответственность на проекте. И все это делается с надеждой когда-нибудь услышать от совершенно незнакомого человека «упоминание нашего проекта в беседе с кем-либо», ну и, конечно же, с надеждой, что вся эта затея принесет еще немного прибыли, помимо огромного багажа уже заработанного опыта.
А я еще и вышивать могу… и на машинке тоже
Чего уж лично я никак не ожидал в первый месяц бета-тестирования – так это появления тех людей, которые готовы «вдруг неожиданно делать удивительные вещи для проекта», не требуя ничего взамен, и не претендуя на место в команде разработчиков.
Однажды на форуме проекта ни с того ни с сего один из игроков стал своего рода «заводилой» для игр и конкурсов – он писал стилизованные тексты, раздавал собственно нажитое «богатство», организовывал игроков к «культурным мероприятиям». При этом никто из администрации проекта никогда не видел и не слышал о таком игроке, никто не понимал, зачем и почему он это делает, и делает настолько качественно, что нам стыдно было не помочь в его начинаниях.
Вот в качестве примера список пользователей, которые просматривают тему конкурса от «Безумного Филина» в час проведения конкурса:
В дальнейшем, этот же игрок написал отличные концепты для общественных мероприятий — к такому подходу мы с координатором проекта были просто не приучены. Вспоминая покинувших нас концептщиков, их труд не шел ни в какое сравнение с качественно проделанной работой «Безумного Филина».
Помимо этого, в преддверии новогоднего обновления, в службу поддержки поступило неожиданное предложение от другого игрока – помочь в отрисовке зимнего оформления игры, с уже готовым наброском и видением, которое попало точно в цель по стилистике игры.
Иногда такие поступки совершенно незнакомых людей дают новую порцию мотивации к работе, так как возникает «немножко» больше надежды и уверенности в то, что сообществу игроков интересен и нужен наш проект, и мы потратили эти два года не просто так.
Мнение общественности
Поскольку проект делается не для разработчиков, а для игроков, то мнение пользователей играет порой главную роль в решении вопросов. Конечно же, не к каждому пользователю нужно прислушиваться, но и не каждого можно игнорировать – аргументированность, корректность постановки проблемы, массовость явления и адекватность подачи являются основными показателями для пристального рассмотрения одного конкретного отзыва.
Всего за месяц работы проекта в открытом для игроков виде было сделано множество изменений (исправлений, доработок интерфейса, усовершенствований логической и формульной составляющей). Были изменены объемы опыта, необходимые для получения уровней, доработан интерфейс чуть ли не на каждой странице, изменены условия нападения на других игроков (ограничили «избиение» более слабых игроков), сдвинули на уровень ниже возможность вступления в «стаи» и так далее.
Сам факт возможности влияния на процесс разработки со стороны игроков воспринимается как двусторонняя лояльность от игроков к проекту и от проекта к игрокам. В процессе бета-тестирования игроками было предложено множество вариантов дальнейшего развития мира – от мини-игр до полноценных игровых локаций с массовыми действиями. Часть из предложенных идей и без того была запланирована, другая часть будет принята в качестве дополнительных, которые можно развивать.
Администраторы конкурирующих проектов тоже не оставили нас без внимания – были регистрации со знакомыми нам почтовыми адресами. Никаких конфликтных ситуаций не возникало, но факт заинтересованности со стороны конкурентов радует.
Кроме реальных отзывов был еще косвенный – под самый «новый год» нам предложили продать проект. Предложенная сумма была несоизмеримо мала по сравнению с нашими вложенными трудозатратами, и мы отказались от сделки, но, опять же, мы почувствовали некую гордость за свой проект.
Тестовый период
Вообще, бета-тестирование направлено было в первую очередь не на отлов ошибок кода (хотя с этим тоже было немало исправлений), а, все-таки, на создание грамотной базы игры. Данный этап разработки должен был выявить те моменты игры, которые бы прямым образом влияли на легкое достижение преимущества над остальными игроками, — неточности формул боя, расчеты наград, стоимость характеристик, условия получения «пернатости».
Каждая теория, каждое предположение, которое было сделано в процессе закрытой разработки, должно быть проверенным и исправленным в соответствии с желаемым поведением игроков. Поскольку весь проект держится на таких предположениях и недоказанных теоремах, то реальный запуск был бы практически невозможен.
Например, на новогодних праздниках был большой этап пересчета «пернатости» всем игрокам, который подразумевал предварительные корректировки формул расчета. Были увеличены требования к легкодостижимым статистическим единицам и уменьшены для труднодостижимых, а степень сложности была как раз выявлена в результате месяца полноценной игры пользователей. При этом реальную сложность можно было оценить на основе статистического отчета по всему проекту, который, например, может дать представление о среднем значении того или иного показателя по всем пользователям (что как раз может подтвердить или опровергнуть предполагаемую сложность показателя).
Помимо корректировок формул на проекте выявляются ошибки, связанные с логикой работы проекта, прямым образом влияющие на достижение целей игроков. Например, существует мини игра (называется «весы-шка») с «местной» валютой, где на кон ставится единица валюты и игрок пытается угадать среди пяти представленных закрытых вариантов «более тяжелый» предмет – в случае выигрыша ставка удваивается, в случае проигрыша теряется. Данная мини-игра подразумевает дополнительную глобальную награду за определенное количество выигрышей, а каждая глобальная награда в свою очередь несет в себе дополнительный объем баллов игрока, которые можно потратить на «покупку» умений. Таким образом, если игрок многократно выигрывал в мини-игру, то он гарантированно получал дополнительную возможность совершенствования умения, а в случае наличия большого количества времени (или возможности написания игрового бота), получение вознаграждения не составляет особого труда. В данном случае правильным решением было ограничение количества мини-игр, доступных в одни сутки, чтобы не дать пользователям быстро и без особых затруднений получить желанный плюс к очкам.
По очевидным причинам продолжить игру после бета-тестирования с тем набором полученных «ачивок» мы никак не можем – какие-то игроки успели ухватить свой кусок пирога, заметив несовершенство системы, другие же это сделать не успели. Как это не грустно звучало бы, но к марту месяцу весь текущий прогресс игры будет полностью аннулирован за исключением нескольких показателей, оставленных в качестве поощрения за три месяца, проведенные с нами (и, конечно же, накопленного фактического опыта самих людей, понимающих основные принципы «прокачки» персонажа). О такой участи текущей стадии проекта каждый был предупрежден посредством письма при регистрации, и мы все же надеемся, что это не послужит причиной со стороны игроков оставить проект.
Куда ушли два года жизни
За все время работы над проектом координатор был не только непосредственным главным руководителем, но и выполнял огромный пласт работ, который был не под силу остальным членам команды – моделирование поведения игроков, составление концепта мира, разработка и правка расчетных формул, поддержка связи с игроками. Найти такого человека в команду – фактический залог успеха проекта с точки зрения завершенности и запуска. При этом незаменимых людей не бывает, конечно, но в нашем случае пришлось бы искать сразу несколько человек.
Концептуальный уровень проекта – понимание устройства мира и составление его правил – является фундаментом всей нашей разработки, ровно как работа координатора в команде является основой для поддержания работников в команде, а обеспечение связи с игроками – залогом интереса и лояльности пользователей.
Весь бета-тест проекта нацелен не столько на выявление ошибок кода и текстов, сколько на корректировку основного процесса игры. Бета-тест должен показать состоятельность системы для того, чтобы мы смогли, наконец, понять – в том ли направлении мы двигаемся, и верно ли работает наша логика там, где нам не хватает реальных знаний разработки подобных проектов. В конце концов, бета-тест должен дать нам базу для дальнейшей разработки – тот фундамент, который подтвержден практически, в процессе реальной игры, и может использоваться для аналогичных логических выводов в построении следующих ступеней проекта.
ссылка на оригинал статьи http://habrahabr.ru/post/208734/
Добавить комментарий