Экспериментальная top-down ММОRPG ищет талантов (видео в теме)

    Цель данного проекта - раскрыть социальную составляющую PvE ММОRPG жанра, где игроки могут влиять на состояние мира, которое в свою очередь может влиять на других игроков. Кроме того, мы поощряем вербальное и невербальное взаимодействие между игроками, поощряя кооперацию, возникновение новых знакомств и дружбы.

О геймплейных акцентах:

Список готовых игровых механик:

Используемые технологические особенности и решения:

Команда:

На данный момент в поисках:

Последние обновления можно посмотреть тут: www.ehizia.com
и тут: https://x.com/UntamedEhizia
Видео (ноябрь 2024):

выглядит очень достойно и много обещающе. подпишусь.

Хехе. Прям конкурента моей ARPG делаешь ))
Там тоже примерно такое запланировано.
Видать, популярная нынче тема.

Да уж, замах не на рубль, а аж на десять. Посмотрим, выстрелит ли и на какую сумму.

Yakobu
> Автогенерация дерева умений
> есть поддержка автоматической генерации дерева умений из заданных блоков.

Это просто поддержка на уровне "движка"? Как делается генерация (выбор) - рандомно из имеющихся (доступных) вариантов?

Yakobu
> Общесерверный прогресс (?) возможен в двух вариантах. В первом - это может быть
> глобальный квест, решаемый всем сервером, и достаточно сложный для того, чтобы
> его завершение требовало несколько месяцев.

Сразу подсказываю, что несколько месяцев для старта - это много (долго), нужно инкрементно. Типа неделя на старте, потом 2, потом месяц, потом несколько. Если, конечно, не будет залит трафик или не случится взрывной рост.

P.S. Советую заглянуть https://gamedev.ru/projects/forum/?id=252714 - возможно, найдёте что-то интересное.

pahaa
> Прям конкурента моей ARPG делаешь
Предпочитаю видеть в тебе скорее товарища, с которым можно было бы обменяться знаниями и опытом :)
Я так понимаю, ты про эту игру говоришь?
https://gamedev.ru/projects/forum/?id=263631

GDR
> Это просто поддержка на уровне "движка"? Как делается генерация (выбор) -
> рандомно из имеющихся (доступных) вариантов?

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

Вот пример, как эта система может выглядеть:
Игрок класса A по умолчанию имеет полный фиксированный набор блоков, относящихся к классу А.
Этот игрок при достижении N-го уровня может подойти к NPC, и выбрать вторичный класс Б. В этом случае он получает фиксированный базовый (не полный) набор блоков класса Б. И этот игрок больше не может получить другие базовые блоки для других классов, так как он уже выбрал свой основной и вторичный класс. Но этот игрок может пойти и выполнить ещё какой-нибудь сложный и большой квест (доступный, например, для игроков любого класса), и получить ещё какой-нибудь детерминированный блок.
Ну и наконец, игрок может убить моба, и с крайне низким шансом он может автоматически приобрести редкий/легендарный блок, выбранный уже случайным образом.

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

И да, стоит упомянуть, что на данный момент нет никаких прямых связей(node prerequirements) между блоками. Каждый блок работает по принципу созвездий из Grim Dawn. Связи между нодами есть лишь внутри блоков.

GDR
> Сразу подсказываю, что несколько месяцев для старта - это много (долго), нужно инкрементно.

Основной смысл общесервеного квеста - это дать "цель". Если утрировать, то она даже не обязательно должна быть достижимой. Главное, чтобы игроки верили, что она достижима и продолжали сообща (или по отдельности) искать решение. Но да, если хватит скорости создания контента, то можно такие квесты делать чаще и рассчитывать на более короткое время прохождения, особенно при релизе.

Но всё, что касается общесерверного прогресса - пока под вопросом. Если есть другие идеи вербальной и невербальной кооперации игроков, буду только рад.

Yakobu
"Если есть другие идеи вербальной и невербальной кооперации игроков, буду только рад."

Что думаешь о механике свадьбы?

Yakobu
> Главное, чтобы игроки верили, что она достижима и продолжали сообща (или по
> отдельности) искать решение.
Если не давать реварды за продвижение прогресса то никто это делать не будет. Такие игроки меркантильные:)

Чёрный ворон
> Что думаешь о механике свадьбы?
Честно говоря, я нигде не видел, чтобы механика свадьбы была в core-gameplay игры. Обычно - это просто фича, которую прилепляют сбоку, и которая мало на что влияет. И если она таковой и остаётся, то я не вижу в ней ничего плохого.

Mephistopheles
> Если не давать реварды за продвижение прогресса то никто это делать не будет.
Полностью согласен. У квеста должна быть награда, соответствующая сложности достижения цели.

Yakobu
> Я так понимаю, ты про эту игру говоришь?
Да, про неё.
Могу поделиться кое-чем ))
1. Постоение древа должно иметь некие строго осознанные ограничения со стороны разработчика, подогревающие геймплей. Полная свобода приводит к тому, что пользоваться этим скучно. Раньше у меня игрок мог выбрать любой компонент из доступных в любом сочетании. Теперь я переделываю, чтобы готовые блоки из нескольких компонентов и с разной степенью гибкости нужно было выбивать из монстров. Это обеспечивает эффект "казино" от гринда, и, в то же время, сохраняет свободу фантазии.
2. Кроме основного сюжета можно добавить "случайные" побочки. Но на самом деле вообще не случайные. Подготавливаем заранее несколько экземпляров одноразовых побочных квестов на мир. Квесты могут быть простенькие, и класс квестов может повторяться (типа квест1 - убей монстра А, квест2 - убей монстра Б). Это позволит поучаствовать существенному количеству игроков. Собираем статистику по игрокам и распределяем эти квесты между игроками или между гильдиями в соответствии с этой статистикой. Каждый выполненный или проваленный побочный квест влияет на мир - например, какой-то тип монстра получает новое заклинание. Прогресс по множеству побочек разными игроками постепенно двигает главный квест для всех. Но, честно говоря, не знаю, насколько такой концепт сработает - до ЗБТ ничего узнать не получится.

Мир бесшовный или из комнат состоит? Как ты на Unity переключение между серверами делаешь при переходе в другую локацию? Для глобального чата отдельный сервер поднят? Как к юнити прикрутил луа (а, главное, зачем)?

pahaa
> Мир бесшовный или из комнат состоит?
Мир со швами - каждый физический сервер отвечает за определённую часть локации. Когда игрок подходит к точке перехода, происходит экран загрузки, после чего игрок продолжает играть уже в новой территории, находясь на другом физическом сервере. Комнат (инстансов одной и той же зоны) сейчас нет, пока не уверен, что это нужно.

> Как ты на Unity переключение между серверами делаешь при переходе в другую локацию?
Алгоритм примерно следующий:
1. Сервер детектирует, что персонаж находится на точке перехода
2. Сервер сохраняет в SQL координату и название зоны на момент после перемещения между зонами.
3. Сервер отправляет клиенту информацию с IP и портом сервера, куда тот должен переподключиться.
4. Получив информацию, клиент разрывает соединение с сервером, и соединяется с новым сервером.
5. Новый сервер обращается к SQL базе, проверяет, что игрок действительно находится в той зоне, куда подключился, и ставит игрока по нужным координатам.

> Для глобального чата отдельный сервер поднят?
Сейчас полностью глобального чата нет, пока не уверен, что такой нужен.
Есть чат внутри зоны, в рамках радиуса вокруг игрока. Для него не требуется отдельных серверов.
Для реализации приватного чата (а в будущем для party/clan чатов) действительно есть отдельный "Broadcast" сервер. К этому серверу подключаются остальные сервера зон. Задача Broadcast сервера обеспечить через себя коммуникацию серверов зон "всех со всеми".

> Как к юнити прикрутил луа (а, главное, зачем)?
  Для Lua использовал библиотеку MoonSharp: https://www.moonsharp.org/
  Необходимость в Lua возникла на фоне следующих аспектов:
  Одна из минорных, но важных фич данного проекта - серверная авторитарность над информацией. Клиент в своём коде не знает о существовании каких-либо навыков. Механики работы навыков знает лишь сервер.
  Но в этом случае, когда игрок хочет использовать какой-либо навык, потребуется подождать полноценный пинг для получения от сервера информации о том, что же всё таки произошло (и произошло ли вообще что-нибудь). Это значительно уменьшает играбельность.
  Чтобы решить данную проблему проблему и потребовался Lua. Алгоритм тут следующий:
1. При подключении к серверу клиент получает и кэширует Lua скрипты для всех выученных навыков, которыми владеет персонаж
2. Когда клиент хочет использовать навык, клиент посылает запрос на сервер, и не дожидаясь ответа запускает Lua скрипт.
3. Главная задача Lua скрипта, зная о текущих статусах у персонажа, предсказать, произойдёт ли каст навыка или не произойдёт. Нужно ли останавливать передвижение персонажа или нет. Нужно ли начинать анимацию каста или нет.
4. Затем от сервера приходит подтверждение (в редких случаях, опровержение) того, что предсказал Lua скрипт. Клиент корректирует происходящее на основе ответа от сервера.

Yakobu
> Игрок класса A по умолчанию имеет полный фиксированный набор блоков,
> относящихся к классу А.
> Этот игрок при достижении N-го уровня может подойти к NPC, и выбрать вторичный
> класс Б. В этом случае он получает фиксированный базовый (не полный) набор
> блоков класса Б. И этот игрок больше не может получить другие базовые блоки для
> других классов, так как он уже выбрал свой основной и вторичный класс.

По этому краткому описанию похоже, что это своеобразная замена выбору класса персонажей на старте игры (или регистрации). Т.е. вместо "хочу паладина" предлагается выбить блок умений воина и блок умений хилера/борца с нежитью (условно). Кстати, предусмотрен ли апгрейд умений (или там просто формула?), и делается ли он автоматически (или всё же игрок сам решает на что тратить "очки") ?

> Если есть другие идеи вербальной и невербальной кооперации игроков, буду только рад.

От сессии (PvP/PvE) и геймплея много зависит. По сути, почти все виды кооперации - вариации квестов или отыгрыша профессии, тут на что фантазии хватит.

> У квеста должна быть награда, соответствующая сложности достижения цели.

Квест может (и должен, пожалуй) усложняться по кол-ву перепрохождений (ну или по времени жизни сервера/сезона, но это вариант похуже) и в т.ч. увеличивать награду. Ну и над распределением награды нужно думать, тут нет идеального варианта.

Yakobu
> 1. Сервер детектирует, что персонаж находится на точке перехода
> 2. Сервер сохраняет в SQL координату и название зоны на момент после
> перемещения между зонами.
а стейт игрока как перекидывается? тоже через базу?

GDR
> По этому краткому описанию похоже, что это своеобразная замена выбору класса персонажей на старте игры (или регистрации)

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

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

Mephistopheles
> а стейт игрока как перекидывается? тоже через базу?
Да, определённо. Стейт персонажа в любом случае должен быть залит на SQL перед тем как деспавнить персонажа, потому что нет никаких гарантий успешного переподключения клиента на другой сервер. Как только сервер перестаёт "вести" персонажа и отвечать за него, последнее актуальное состояние персонажа всегда должно находиться в базе данных.

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

Необязательно включать выбитые блоки, можно и нужно дать контроль игроку (хочу/не хочу). Я и зацикливаться (ограничиваться) на двух классах смысла не вижу, но Вам как автору виднее.

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