Мы разрабатываем API-интерфейс, который будет состоять из пары конечных точек REST. Эти точки по сути являются вебсайтами, обслуживающими данные, а не страницы.
Перевод блога разработчиков
Итак, было принято решение разрабатывать Shallow Space больше в направлении мультиплеера. В одиночных играх большее внимание уделяется механикам, связанным с повествованием сюжета, а также созданию персонализированного игрового процесса. Это огромный объём работ, который часто недооценивают.
Так что же не так с одиночным режимом?
Проще говоря, разработка подобной RTS с теми средствами, которые нам доступны сейчас, просто невозможна. Поверьте, мы уже пробовали. Мы уже описали суть этого в предыдущем посте – сейчас у нас задача взять то, что у нас есть, и как можно скорее закончить игровой клиент.
Сюжет — это текст или аудио, которые необходимо записать и перевести на множество языков. Игровой процесс в одиночных играх сильно зависит от баланса между самой игрой и уже упомянутым сюжетом. От этого сильно зависит создание режима кампании. К тому же, нам всё равно пришлось бы каким-то образом добавлять мультиплеер во всё это, по сути работая над двумя совершенно разными наборами требований.
Невероятно трудно сделать всё это правильно, к тому же у нас нет опыта с разработкой одиночных игр, поэтому мы, скорее всего, потерпели бы неудачу – такое мы уже проходили. Мы, конечно же, не говорим, что многопользовательские игры делать легко (или что в них нет сюжета), но у нас гораздо больше опыта с разработкой серверной части программ, чем с многофункциональной клиентской частью, необходимой для одиночных игр.
Также, о многопользовательских играх чаще говорят, следовательно они живут дольше, а это означает большую вероятность того, что мы сможем дальше работать над продуктом после его релиза.
Когда речь идёт о многопользовательских играх, внезапно возникает интерес в сравнении параметров, создаются вики-сайты, интегрируются пользовательские базы данных и т. д. Всё это положительно влияет на жизнеспособность игры.
В одиночных же играх для этого необходим мощный маркетинг, т. к. игроки неохотно делятся своими впечатлениями и опытом. Мы не пытаемся создать компанию по разработке компьютерных игр. У нас задача – работа над одной, единственной игрой и точка.
Мы изучали как издатели рекламируют свои игры и наш бюджет попросту не рассчитан на необходимый маркетинговый инструментарий ради одной одиночной игры. Из-за «Брексита» с нами, скорее всего, не захочет работать ни один издатель. Так что это сугубо между нами и вами.
Но что если мне не по душе мультиплеер уровня «ямы с гадюками»?
Мы всё понимаем.
У игроков будет возможность закрывать свои сектора и со временем создавать собственные «инстансы» на наших серверах. Мы даже собираемся выпустить серверный стек когда он будет достаточно стабильным, чтобы игроки могли создавать собственные сервера.
В игре также будут ИИ-игроки.
Shallow Space не ММО, и в нём будет ограниченный функционал чата (для него мы будем использовать Discord) – т.е. по сути другие игроки просто будут выглядеть как дружеские или вражеские корабли ИИ. С помощью квестов мы сможем направлять множество игроков к тем или иным целям, так что всё это будет выглядеть скорее как одиночная игра с умным ИИ.
Но разве не дорого держать сервера для многопользователских игр?
Верно. Однако у нас есть такие инструменты как Docker и Kubernetes, позволяющие нам создать адаптивную платформу. Мы разделили приложение на несколько небольших частей (так называемых «микросервисов»), которые можно будет легко отделить и перестроить, если в этом будет необходимость. Подобная структура довольно гибкая. Если никто не будет играть, то вся инфраструктура просто свернётся и не будет ничего стоить. Но если полпланеты будет играть, то система начнёт набирать ресурсы и наращивать себя.
Рано или поздно в Shallow Space также будет добавлен функционал для самостоятельного хостинга, т.е. в (очень) маловероятном случае отключения основных серверов игроки смогут присоединяться к пользовательским серверам или создавать собственные.
Интересно. Но как вы это реализуете?
Мы разрабатываем набор интерфейсов API (Application Programming Interface «интерфейс прикладного программирования»), состоящий из пары конечных точек стиля REST. Эти точки по сути являются вебсайтами, обслуживающими данные, а не страницы.
Обычно было бы глупо делиться подробностями имплементации, как мы это сделали в скриншоте выше, но это игровой API, который не будет доступен широкой публике.
Отдельный общедоступный API-интерфейс будет отвечать за подключение через игровые клиенты и внешние вебсайты, которые бы предоставляли данные о рейтинге игроков или характеристиках кораблей.
Но как вы заставите это всё работать как следует?
В этом и суть ранее упомянутого скриншота.
Мы будем использовать инструменты вроде Grafana и Prometheus для мониторинга за API-вызовами и установки номинального уровня обслуживания. Используя предоставленные нам данные, мы сможем с легкостью работать над проблемными элементами, уделить им должное внимание и удостовериться, что весь процесс проходит гладко.
Это очень важно, так как мы хотим, чтобы система могла подстроится как под мелкие перепалки где-то на окраинах галактики, так и под эпичные баталии между флотилиями в её эпицентре.
Для нашей небольшой команды это наиболее достижимые цели.
Учитывая наши доступные средства и навыки, необходимые для создания и продвижения контента, нам попросту проще сначала поработать над мультиплеером.
Ну, хватит разговоров, пора обратно за работу!