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

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

Логика игры которая есть

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

Логика игры которая должна быть

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

• отсутствие случайности в игровом процессе,
• расход синих кристаллов на перемещение игрока,
• отсутствие очевидного оптимального пути развития игрока.

Также, возвращаясь к изначальной идее, мне видится весьма интересный геймплей, мотивирующий игрока строить, путешествовать и развиваться. И этот геймплей очень далёк от аркадного: в нём нет места безлимитному простому накоплению кристаллов и невозможности их утери. В моём видении любые показатели игрока могут быть не только улучшены но и ухудшены. Только так можно будет избежать большого количества игроков прокачавшихся до определенного уровня и превратившихся в демиургов и безраздельно влавствующих игровым миром. Мне нужен игровой мир в котором богатые, но плохо защищенные, могут стать мишенью для бедных, но хорошо организованных и вооруженных. Сильные и богатые в одиночку не должны иметь возможность справиться с бесконечным количеством бедных и слабых. Объединяясь игроки обретают безопасность и защиту. Исходя из описанных выше идей, мы допускаем вполне себе RPG-шную модель — игрок это то, что у него есть в инвентаре, это то, что он построил и то, в каких социальных связях с другими игроками он состоит. Пришло время разработки инвентаря.

Инвентарь

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

• богатство
• вооруженность/бронированность, которые также должны балансировать между собой
• вместимость

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

Теперь, когда у игрока появится инвентарь мне нужно ответить на вопросы:
— Как игроку осуществлять строительство, если теперь при клике на экране будет появляться инвентарь?
— Мне кажется не лучшим решением оставлять меню строительства отдельно от инвентаря сразу по нескольким причинам: усложнится меню и строительство будет выглядеть не совсем логично и останется полностью аркадным. Поэтому возникла идея — из синего стека кристаллов изготавливать строительный инструмент, допустим, blue construction box, который бы позволил строить базовые здания и вызывал строительное меню при клике на него в инвентаре.

ну или почти…

— Что теперь отображать в нижнем правом углу экрана игрока?
— Просто сумму кристаллов имеющихся у игрока в инвентаре.

— Как теперь себя будут вести постройки?
— Это отдельная тема требующая серьезной проработки. Но, очевидно, что генераторы будут работать и аккумулировать в себе кристаллы, а сейфы позволять эти кристаллы хранить.

Зачем мне при разработке понадобился UML?

Помните, в прошлой статье я писал об упорядоченных классах? Так вот — их стало много и содержимого в них тоже стало много. Для того, чтобы не портить красоту я решил запечатлеть эту красивую и простую, на мой взгляд, структуру в диаграмме классов используя для этого выразительные средства языка UML (Unified Modeling Language). Впервые в жизни я почувствовал необходимость в UML не связанную с фиксацией договорённостей с заказчиком, не связанную с требованиями в ТЗ, а просто для того, чтобы лучше видеть картину собственного кода.

Дам небольшую нотацию к диаграмме классов. Существует экземпляр главного класса websocketserver_class, который непрерывно работает ожидая сообщений пользователей, кстати, класс остался практически без изменений с того момента когда я использовал его для чата в одной из статей про веб-сокет. При инициализации, экземпляр создаёт и хранит в себе всё время существования экземпляр класса game_class отвечающего за всю игровую логику. websocketserver_class при подключении нового игрока, при отправке сообщения от подключенного, при выходе игрока из игры сообщает game_class‘у все необходимые данные, на что game_class обработав их и обратившись ко всем необходимым включенным в него экземплярам player_class отвечает пакетом сообщений, которые websocketserver_class должен разослать адресатам по протоколу websocket. game_class создаёт и удаляет экземпляры player_class‘а по одному на каждое установленное соединение игроков с сервером. game_class передаёт команды player_class‘у от пользователей. player_class обращаясь к инвентарю inventory_class и к карте map_class выполняет действия и возвращает сообщения game_class‘у о результатах действий.

Маинд-карта

На последок приведу еще и скриншот игры сделанный за несколько минут перед публикацией.

Краткий итог: Принято решение уходить от аркадной игровой модели. В игру добавлен инвентарь.

Сводка

Начало: 25 апреля 2014 года.
Приостановка проекта: 21 мая 2014 — 13 июля 2014 года.
Команда: 1 (25 апреля), 1 (14 июля).
Израсходовано: 176 + 24 = 200 чч., 56 + 24 = 80 чч.
Рабочих дней: 25 + 3 = 28, 7 + 3 = 10
Средняя производительность: 200/28 = 7,14 чч/день, 80/10 = 8 чч/день

Описание игрового процесса

Расчет баланса

Игровая графика

Веб-клиент

Игровой сервер

Веб-сайт

ИТОГО

Продложение: Growing Crystals vol 14. Балансировка игрового процесса