Unity

И вот, спустя несколько месяцев я завершил демо-версию игры. Суть проста: вам нужно решать загадки и головоломки взаимодействуя с окружением. В игре полностью рабочий UI, звуки, анимации. На баги демка отполирована. Модели я брал из магазина ассетов Unity, звуки из сайтов с бесплатными звуками. Среднее время прохождения - 30 минут. Ну и добавлена офигенная пасхалка, которая точно многим понравится:)

Буду рад услышать мнение об игре :)

Демо бесплатное. Ссылки для скачивания:

VKplay: https://vkplay.ru/play/game/hugger-mugger_mystery_of_the_man...

Itch.io: https://racemoon.itch.io/hugger-mugger-mystery-of-the-mansio...

Новости о проектах в ТГ: https://t.me/RaceMoonGames_rus

P.S. Планирую публиковать посты раз в неделю-две. Расскажу об интересных проблемах и багах, с которыми столкнулся во время разработки, о том как и куда выложить свой проект, выложу статистику о загрузке демо-версии. Сейчас совместно с дизайнером начинаем разработку еще одной игры, так же о ней скоро расскажу)

На связи Virgin defence с новой игрой INCEL SIMULATOR!

Мы — несколько студентов одного богом забытого ВУЗа, и в свободное от «гранита учебы» время, решили сделать небольшой проект. Мы подумали, что для первого раза подошло бы что-то не сложное, простое. Поскольку в новостях в последнее время часто мелькает Поднебесный, мы решили, что это то, что там нужно. Итак, мы придумали идею, распределили наши обязанности и… начали делать.

INCEL SIMULATOR — это визуальная новелла, оформленная под карточную игру, в которой вы играете за Алексея Подне... Подземельного. Несмотря на все попытки, у Алексея никогда не было девушки, кажется, сам мир противится этому. Впрочем, может ещё не поздно всё изменить? Вопрос лишь в том, что каким путем пойти: вновь и вновь пытаться прокачать тело и дух или же стать королем инцелов?

Все что вам надо, свайпить карты, прямо как в тиндере, от чего зависит исход сюжета в виде трёх рутов. Станет ли Алексей героем очередной пасты с двача? Королем всех инцелов? А может быть... наконец найдет девушку? Зависит только от воли игрока.

Мы вдохновлялись не только идеями Поднебесного, но и пастами с двача и другим подобного рода треш контентом. Для фанатов таких историй мы подготовили специальный рут)

А ещё мы решили, что у нас будет свой этакий Джонни Сильверхенд. Его роль в сюжете будет занимать секретный персонаж)

Вас ждет пусть небольшая, но проработанная история, с интересными выборами и последствиями, своего рода стоическая драма про героя нашего времени!

А пока просим милостливо добавить нашу игру в вишлист :)

1. Введение

2. -> Синглплеер и Мультиплеер

3. ...

Что считать мультиплеером

Для начала нужно определить, что далее будет пониматься под словом "мультиплеер". Зафиксируем:

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

Т.е. какой-нибудь абстрактный лидерборд не будем считать мультиплеером, т.к. игроки друг с другом не взаимодействуют и не оказывают друг на друга прямого влияния. Они всего лишь меряются своими результатами, полученными обособленно друг от друга.

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

Клиент-серверное взаимодействие, всяческий LiveOps и облачные механики тоже не делают игру мультиплеерной — это используют и многие сервисные игры, которые могут быть полностью синглплеерными.

Где отличия от синглплеера

Разница между мультиплеерным и синглплеерным проектами, если говорить про кодовую базу, не носит глобального характера. Чтобы понять, на что обращать внимание для определения типа проекта, следует обозначить какие-то составные части.
Среднестатистический игровой проект, в т.ч. и мультиплеерный, с технической точки зрения можно представить в виде комбинации следующих крупных блоков:

• CoreGame: основной игровой процесс, главные игровые механики, которые формируют целевой игровой опыт и определяют жанр.
  Примеры: механика управления автомобилем, логика гоночного процесса, работа ИИ противников, система разрушаемости и пр.

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

• Infrastructure: технические "обвесы" и подключаемые модули.
  Примеры: звуковой движок, физика, работа с удалёнными узлами для социального взаимодействия и хранения данных, системы мониторинга и аналитики и пр.

• Runtime: общая архитектура проекта, "клей" для всех блоков.

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

Ключевое отличие мультиплеерного проекта от синглплеерного, как правило, кроется в области CoreGame.
Здесь чаще всего игроки и получают возможность для непосредственного воздействия друг на друга. Многие мультиплеерные игры, когда не могут найти достаточное кол-во игроков для новой игровой сессии, превращаются в этом месте в синглплеерные: игрок в одиночестве или в сопровождении ботов болтается в основном игровом цикле.
Здесь проявляются знаковые отличия в реализация для обеспечения многопользовательского режима. Если потребуется синглплеерный проект превратить в мультиплеерный (и наоборот), то править придётся преимущественно CoreGame.

Другие блоки тоже могут быть задеты. Например, в MetaGame могут потребоваться лобби, поиск игроков или выбор сервера. А в Infrastructure может появиться больше сервисов, систем и удалённых вычислительных узлов, которые будут требовать координации. Но об этом позже.

Классификации мультиплеера

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

По взаимодействию:

1. Соревновательные / PvP / Players versus Players: игроки соревнуются друг с другом, командами или поодиночке.

2. Кооперативные / PvE / Players versus Environment: игроки объединяют усилия для борьбы с врагами, управляемыми компьютером.

По балансу:

1. Симметричные: все участники имеют примерно равные возможности и цели.

2. Асимметричные: предлагаются разные возможности и цели для разных сторон.

По времени жизни мира:

1. Массовые многопользовательские онлайн-игры / MMO / Massively Multiplayer Online Games: тысячи игроков взаимодействуют одновременно в одном постоянно существующем виртуальном мире.

2. Сессионные: небольшое число игроков взаимодействуют в одном матче или сессии, которые каждый раз начинаются заново.

По процессу:

1. Синхронные / Realtime: все игроки единовременно вовлечены в единый игровой процесс и взаимодействуют друг с другом в одном и том же виртуальном мире.

2. Асинхронные: игроки взаимодействуют друг с другом не в реальном времени, а по очереди.

По технической реализации:

1. Локальные.

2. Сетевые.

Локальный и сетевой мультиплеер

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

При таком режиме отличий от синглплеера в техническом плане практически нет. Есть несколько источников ввода: они или обрабатываются одновременно, или поочерёдно. Аналогично есть несколько режимов вывода. Грубо говоря, локальный мультиплеер вносит лишь незначительные корректировки в слой представления приложения.

Наибольший интерес и сложность представляет сетевой мультиплеер. Здесь каждый игрок использует своё отдельное устройство, и игроки объединяются в одну игру за счёт использования сетевого соединения. Чаще всего это Интернет. Для того, чтобы все игроки играли в одну и ту же игру, необходимо обеспечивать одинаковое игровое состояние на всех устройствах в каждый момент времени.

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

Такие условия априори вносят больше хрупкости и значительно бóльшие временные задержки в процесс обновления данных. Ситуация усложняется ещё и тем, что все игроки находятся в разных условиях: у кого-то соединение быстрее, у кого-то слабее. С такими вводными сложно обеспечивать одинаковое игровое состояние на всех устройствах и координировать действия игроков между собой.

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

Именно сетевой мультиплеер и будем рассматривать дальше и детальнее разбираться с тем, что приходится учитывать и делать для его реализации.

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

Статьи также доступны на площадках: VK, Dzen, Habr, Dtf.

Контент

• Полгода разработки мобильного PvP: Habr

• Multiplayer resource roundup: Unity

• Unity Multiplayer in 3 minutes: YouTube

• Как устроен мультиплеер: YouTube.Cyberstars

Чтобы компенсировать затраты, я сделал этот набор платным.
СТАНЬ ПОДПИСЧИКОМ, ЧТОБЫ ПОЛУЧИТЬ ДОСТУП

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

https://t.me/gamedev_sound_bot

Захотел сделать небольшую игру чтоб вот тебя закидывало в случайный фентези мир, а ты там "приключался", боссов бил, королевство свое строил. Что-то похожее на Terraria.

Но что делать если ты рукожоп не хочешь особо заморачиваться с качественной процедуркой игрового мира?

Сделать мир из огромных гексагонов? Звучит как хуета отличная идея! 💡

1. Генерируем двумерную карту

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

Предварительно я разделил для себя мир на несколько "слоёв":

1. Карта поверхности, на ней будет определена структура мира, в каких ячейках гексы вообще будут существовать собственно. База одним словом

2. Карта высот. На этой карте будут заданы группы высот для гексов, чтоб мир был не "плоский"

3. Карта биомов. На этой карте мы сформируем будущие группы биомов.

4. Карта рек и озер. Несмотря на "крупногексагональный" форм-фактор будущего мира, я хочу чтоб по нему текли реки и были озера. Эта карта пометит условный гекс (или же ячейку массива) как имеющую реку, а там разберёмся

Вот они, слева направо, их боялся весь проект

"Чё ты там нахуевертил" - Скажите вы щурясь как азиат из мема

Я художник! Я так вижу! На самом деле это техническая визуализация уже сформированного мира в 2D матрице, мне же надо было как-то смотреть на то что там выходит вообще.

"И шо ты, пёс, даже не расскажешь как ты это генерировал?" - спросит моя воображаемая аудитория.

А я вам отвечу! Нет. Сейчас все обьясню! И так, А-а-а-а-втомобиль лгоритм в студию!

Смотрите, существуют адекватные разработчики, которые, когда речь заходит за процедурную генерацию, в первую очередь думают в сторону шумов, тот же Шум перлина (Perlin Noise) это идеальный способ выстроить и попиксельную 2д карту ландшафта, с перепадами высот (чем темнее пиксель тем выше). Выглядит он вот так:

Но причём тут адекватные разработчики, и я)

Я сделал это по принципу который придумал себе ещё на первом курсе, саморастущие ядра (шо?)

Если вкратце, в двумерном массиве ограниченном размере мира (например сетка 64×64 ячейки) в случайных местах создается расчетное количество "ядер" генерации, каждое ядро помечает свой адрес как будущую поверхность сразу, и помимо этого несёт в себе случайное количество "зарядов".

Каждую итерацию ядро тратит на то, чтобы "расширится" в случайное направление сетки, захватив, и пометив как будущую поверхность и захваченную ячейку, и так пока у всех ядер не закончатся заряды.

Выглядит это вот так, и в принципе формируется нормальный +- ландшафт:

Жёлтые - ядро
Синие - захваченные ядром ячейки

Точно такой же принцип используется и для карты высот и карты биомов, только теперь ядра формируется в ячейках адреса которых уже являются "поверхностью".

Создаются группы высот которым назначаются высоты, которые при генерации самих гексов собсна говоря и передадутся.

В этот раз ядра, это ромбики, а разным цветом обозначеныгруппы высот:

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

Круто! Теперь у нас есть карты двумерных массивов содержащие все необходимые данные для генерации крупногексагонального мира

Используя гайды из Habr свои навыки и умения, я написал скрипт в котором циклом производится проходка по, сохраненным ранее в двумерные массивы, картам данных, и на основе этих данных формируется... Пока только гексагональная 3д структура с разными высотами:

Красиво, но пусто, а давайте запустим туда нашего персонажика которого я создал "за кадром"

Теперь вообще и пусто и некрасиво... Миша все хуня давай по новой! Тебе так никто денег не даст!

Добавим генерацию биомов, чтобы гексам относительно их адреса в карте биомов присваивался соответствующий биом:

Во, уже лучше! Это правда "биомы" пока условные, просто гексы те же, с разными структурками, на итоговый вид это особо не повлияет. Так что нужно на гекс навесить деталей. Tiling time!

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

А ещё добавлю "детали" какие нибудь, пусть будут ёлочки в биоме "лес", пока с временной графикой, пара текстурок.

Сделаю банальной "россыпью" этих елочек на каждый гекс

Уже что-то похожее на мир! На этом пока все, впереди ещё туева хуча работы, оптимизация отрисовки деталей (LOD), механизм генерации структур в мире (всякие замки, руины, домики набигающие) и.т.д

+ Мне ещё предстоит решить проблему как игроку перемещаться между гексами с сильными перепадами высот... Лестницы? Винтовые пещеры? Прыгучие платформы? Лианы? Надо думать...

p.s. У самих гексов реализован LOD, и их детализация уменьшается на отдаленном расстоянии от игрока, а дальше и вовсе отключается. Так же я сделаю с деталями на гексах я думаю.

Спасибо всем тем двум людям которые дочитают эту тягомотину до конца!