инвентарь — основные принципы

инвентарь

Не секрет, что как не крути, но у игр одного жанра, есть основные особенности объединяющие их.

Многие вещи являются неотъемлемой частью, от игры, к игре и с годами не меняют своей сути и назначения. Одним из таких элементов является «инвентарь».

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

Начну издалека. Я уже писал, что в работе находится новый игровой проект. Жанр проекта RPG.

Учитывая, что игра является On-line, многие аспекты, не существующие в  single-проектах, требуют особого внимания и усердия.

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

Но причем тут инвентарь игрока и сеть? А дело вот в чем. На самом деле, «сумка» игрока это лишь малая часть, такого большого комплекса, как инвентарь. В инвентарь, в моем понимании, входит и сундучок с пряниками, и сумки только что поверженных врагов, и вообще все, куда можно положить предмет, или наоборот — изъять. Вот примерная схема, того, как я это вижу:

Примерная схема того, как я вижу инвентарь

Примерная схема того, как я вижу инвентарь

Поэтапная реализация инвентаря

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

Реализовал примерно так: Создал класс, в котором хранились основные значения, такие как, например, объем, вид интерфейса (окна, кнопки, иконки) и список ячеек. После, собрал класс, описывающий ячейку. Описывая ячейку, указал на элементы, характеризующие предмет. А что в нашем понимании предмет в сумке? Это Конечно скин, т.е. картинка, которая выводится, отображая предмет, его название и тип. Можно вложить собственно любое количество параметров, характеризующих предмет, но это уже на вкус и цвет.  Разработав простенький (для начала) интерфейс управления, где позволялось перетаскивать объекты внутри сумки, воздействовать на них и выполнять разного рода манипуляции, я приступил к разработке сундучка.

Примерная схема построения контейнера, с точки зрения программирования.

Примерная схема построения контейнера, с точки зрения программирования.

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

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

Универсальность класса сундука, позволила мне прикрутить его возможности к любому желаемому объекту. Будь то кабина разбившегося некогда самолета, трупик воина, или просто кем-то потерянный чемодан. Универсальность – вот главный плюс такого подхода. Единственное отличие сумки игрока, от контейнера игрового, это функционал в плане управления грузом внутри. На пример игрок может в своей сумке навести порядок, положить зелья в одну кучку, батарейки в другую, а пиво с сигаретами в третью. В контейнере такой возможности нет, перемещать предметы внутри сундуков нельзя. Зато у контейнера есть замечательная функция – «забрать все». Если игроку нужно все забрать, или ему некогда возиться, достаточно просто нажать кнопку, и все, что было внутри сундука переместиться в сумку. Если конечно хватит места.

Но если игрок найдет среди «хлама» лишь пару дельных вещей,  предусмотрена возможность индивидуального изъятия.

Все это было бы просто и хорошо, если бы не сеть. Основная проблема, с которой пришлось столкнуться, была впереди.

Сетевая синхронизация

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

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

Схема синхронизации данных инвентаря

Схема синхронизации данных инвентаря

На этом сборка инвентаря не закончилась, но был завершен основной объем работ. Впереди осталась реализация дополнительного функционала и прочих мелочей. Если будет интересно, обязательно напишу и об этом.

[wysija_form id=»1″]

Один комментарий

  1. […] понимания сказанного, даю ссылку на первый материал, опубликованный ранее, но вошедший, как первый в новой […]

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Проверка * Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.