Приветствую, читатель. Здесь начинается небольшой цикл статей, посвящённых разработке мультиплеерных игр. Мультиплеер — это весьма объёмная область, из-за чего в ней очень легко потеряться или пойти не туда. И я хочу попробовать расставить ориентиры, которые бы помогли начать, указывали направление и подсвечивали важные моменты.
Последние годы я занимался разработкой преимущественно мультиплеерных проектов под разные платформы. И я ещё помню, как было сложно в начале: часто было непонятно, что делать дальше, в информационном поле мелькало множество незнакомых тегов, уходило много времени на изучение не самых важных на тот момент вещей. Тогда мне не хватало какого-то краткого руководства, где было бы написано "сейчас нужно это, потом потребуется это, а вот тут можно сделать так или так". Это бы помогло значительно сэкономить время, эффективнее искать информацию и двигаться более осознанно и последовательно.
Повествование я буду вести со своей "колокольни Unity-разработчика", используя те термины, примеры и технологии, которые для меня ближе и с которыми я знаком непосредственно. Но это не какой-то уникальный опыт, который существует только внутри мира Unity — всё это будет актуально и для других инструментов.
В этой вводной части я хочу поделиться рядом наблюдений, которые я успел сформировать, чтобы объяснить свою мотивацию к написанию этого материала, и, возможно, объяснить твою мотивацию, дорогой читатель, для изучения сабжа, если встречи с ним ещё не случилось (если случилось – буду рад обменяться впечатлениями в комментариях).
Наблюдение №1: Сложность
Мультиплеер — это очень обширное и живое направление, которое активно развивается, постоянно накапливает новые практики и подходы и имеет свои ответвления. Но даже то, что касается каких-то общих базовых знаний, требует большого количества времени для поиска, изучения, освоения, а главное — понимания.
Поиск – пусть не главный этап, но очень важный. Нельзя изучить то, что не удалось найти, и о существовании чего ты даже не знаешь :)
В "моё время" всю информацию приходилось кусочно собирать и выдирать из глубин, заведомо не зная, что эти глубины вообще есть: множество туториалов ограничивались самыми банальными вещами и заканчивались на самых интересных моментах. А чтобы сформировать нужный запрос в поисковую строку, нужно было знать определённые термины и контекст. И область поиска не ограничивалась только Unity или геймдевом: приходилось искать всюду и учиться прикладывать добытые знания к своим задачам.
К счастью, сейчас контент стал более качественным и основательным. И появилась масса разнообразных AI-ассистентов, которые готовы подкинуть множество идей и дать полезных указаний в любой ситуации, даже в ситуации полной неизвестности. Строить маршруты для изучения стало как никогда просто. Этой уникальной возможностью нужно пользоваться.
Есть и специализированная литература, в т.ч. и современная, которая помогает основательно погрузиться в материал. Но если нет достаточного кол-ва времени для её изучения, можно попробовать использовать хотя бы содержание в качестве отправной точки.
**Вывод:** если однажды удосужиться попасть на мультиплеерный проект, не имея какого-то опыта, не стоит надеяться, что удастся разобраться со всем за недельку и начать успешно перформить — вряд ли из такой затеи получится что-то удачное (но вероятность всё же есть — ситуации бывают разные). И нужно быть готовым к тому, что здесь, как и в IT в целом, придётся постоянно учиться и совершенствовать свои навыки, чтобы иметь компетенции заниматься более качественными и масштабными проектами.
Наблюдение №2: Неизбежность
По мере развития игровой индустрии мультиплеер захватывает всё новые и новые "территории". Раньше мультиплеер был сродни отдельной касте развлечений: с конкретными жанрами, на конкретных платформах, с конкретными правилами.
Однако со временем эти ограничения всё больше размываются. Сейчас сложно найти жанр, для которого не было бы многопользовательских проектов. Актуальных платформ, которые не предоставляют подобный вид развлечения, тоже так просто не вспомнить. Мультиплеер пришёл даже в мобильный гейминг.
Раньше вокруг мультиплеера мог строиться весь геймплей как вокруг ключевой механики. Теперь это всё чаще выступает как дополнительная опция, т.к игроки хотят иметь возможность играть со своими друзьями практически во всех проектах: от соревновательных до сугубо сюжетных.
Из эпохи, когда игроки радовались наличию мультиплеера, мы постепенно переходим в эпоху, где игроки уже негодуют из-за его отсутствия.
А какое будущее рисуют нам компании? Будущее метавселенных! А что такое метавселенная — это большой мультиплеер. Вероятно однажды мультиплеер станет настолько обыденностью, что мы уже даже не будем знать альтернатив.
Вывод: чем дальше, тем больше в нашей жизни мультиплеера становится. С каждым днём шансы столкнуться с этой технологией возрастают. Рано или поздно, как бы мы ни избегали (если такие попытки есть), мы там окажемся. И лучше к этому быть готовым. Потому что <см Наблюдение №1>.
Наблюдение №3: Недооценённость
Мне неоднократно требовалось набирать разработчиков на очередной мультиплеерный проект. И каждый раз найти хоть кого-то хоть с каким-то опытом — задача крайне сложная, на грани удачи. Релевантных кандидатов очень мало и разбирают их очень быстро.
В ситуациях "безрыбья" приходилось прибегать к "грязному трюку", а именно предлагать кандидатам без нужного опыта выполнять ТЗ на разработку мультиплеерного прототипа.
Оффтоп: Почему я считаю этот трюк "грязным":
- Я не люблю давать ТЗ. Есть у тебя классный пет, который решает интересующие задачи — давай через него и познакомимся. На мой взгляд результат тот же, а затрат времени и энергии - меньше для всех.
- Если необходимость выдать ТЗ всё же есть, то я беру задание, которое выясняет для меня именно те моменты, которые не удалось выяснить другим путём. Чтобы задание было точечным, небольшим и не требовало много времени ни у кандидата, ни у меня как у проверяющего.
- Когда у кандидата отсутствует опыт работы с мультиплеером, не остаётся ничего, кроме как дать разработать какую-то мультиплеерную механику, а это априори получится целый прототип с лобби и подключением. Это не маленькое ТЗ займёт, как минимум, несколько вечеров, особенно у исполнителя, которому придётся ещё и изучать новую для себя технологию.
Оффтоп: Почему это – всё же "трюк":
1. Даже если у кандидата не было опыта работы с сетевыми кодом, он появится при подготовке ТЗ, что снимает с команды необходимость обучать нового коллегу с полного "нуля".
2. Это возможность оценить навыки самостоятельного обучения кандидата. Насколько быстро он справляется с освоением нового, насколько успешно прорабатывает документацию и как качественно полученные знания применяет.
3. Можно узнать, как кандидат выполняет работу в условиях дополнительного стресса, т.к. приходится работать с новой технологией в условиях дедлайна и запроса на качество.
4. Если кандидат ушёл не в ту сторону и его "душа" к этому ну совсем "не лежит", то это вскроется сразу и не станет отложенным сюрпризом.
На моей практике не было кандидатов, которые бы смогли успешно выполнить ТЗ, столкнувшись с сетевым кодом впервые при выполнении этого ТЗ. Тем не менее те, кто что-то когда-то слышали и сколько-нибудь пробовали, не редко давали весьма хорошие результаты. Пусть они не знали об определённых подводных камнях, которые приходят только с опытом, но поставленная задача была объективно выполнена.
Какое бы ни было решение по ТЗ, оставить конструктивный фидбэк, который поможет кандидату шагнуть на следующую ступеньку — на мой взгляд, для компании тоже полезный "трюк" (и, к сожалению, не общепринятый стандарт). А для самого кандидата это – отличная лазейка и точка роста.
Кандидат получает сводку по востребованным запросам и ожиданиям, которые можно проработать и пробовать применять на будущих собеседованиях. И если дать хороший фидбэк, который не захлопывает окончательно дверь, то кандидат может захотеть вернуться туда же и прийти повторно уже боеготовым, с нужным багажом опыта, что тоже снимает некоторую рутину по обучению.
Вывод: для разработки мультиплеера все хотят сотрудников "на опыте", но таких катастрофически мало. И сами разработчики почему-то не придают значения такой вехе в своём портфолио навыков. Поэтому даже небольшой скромный мультиплеерный пет поможет тебе выделиться среди других кандидатов и успешнее выполнить ТЗ, если оно вообще потребуется и ты уже не находишься в числе тех, кого "отрывают с руками". А команды всё чаще обращаются к мультиплееру. Потому что <см Наблюдение №2>.
Выводы
Мультиплеер – это сложно, объемно, актуально, перспективно и с каждым днём всё более востребовано. И, вероятно в недалёком будущем, почти обязательно. Но среди разработчиков это на данный момент не очень популярно. И как нанимающая сторона, я подмечаю некоторый "кадровый голод" в этой области.
Этим введением я хотел обратить внимание на наличие такого направления как мультиплеер и на его возрастающую значимость. И хотел "подстегнуть" не откладывать его изучение на потом. Лучше начать раньше и двигаться неспеша, чем пытаться однажды ворваться резко и дерзко.
Возможность (или даже необходимость) поработать над подобным проектом может возникнуть в любой момент. И чем больше ты успеешь к этому моменту освоить, тем выше шансы на твой успех. И в сложившейся сейчас ситуации даже скромный опыт на мультиплеерном поприще становится сильным конкурентным преимуществом.
В следующих статьях я планирую затронуть условные "типы" многопользовательских проектов, варианты реализации, сложности и проблемы, с которыми приходится бороться, инфраструктурные вопросы, актуальные на данный момент решения для Unity и не только, примеры реализации и практические "фишечки".
Эту и следующие статьи можно читать на площадках: Пикабу, VK, Dzen, Habr, Dtf.
Контент
В качестве доп. контента для этой статьи я решил указать книги, которые отложил в свою библиотеку. Полностью они не прочитаны, но регулярно испытывают на себе внимание на определённые темы.
1. Joshua Glazer, Sanjay Madhav. Multiplayer Game Programming: Architecting Networked Games (есть в переводе)
2. Alan R. Stagner. Unity Multiplayer Games
3. Marco Secchi. Multiplayer Game Development with Unreal Engine 5
