MMORPG

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

Сервер

В сильно общем смысле:

Сервер – это вычислительная единица, которая выполняет определенные сервисные функции.

Какие могут быть функции:
- хранение данных;
- обработка запросов;
- управление сетевыми ресурсами;
- и пр.

В зависимости от своих функций серверы могут быть разных типов:
- файловые серверы;
- веб-серверы;
- DNS-серверы;
- почтовые серверы;
- и пр.

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

"Агрегатные состояния" сервера:
- отдельный компьютер, настроенный на выполнение своих функций;
- виртуальная машина, эмулирующая отдельный компьютер;
- контейнер, выполняющий серверные функции;
- серверное приложение, запущенное на настроенном для этого компьютере.

В моей практике в геймдеве чаще всего в качестве "серверов" используют серверные приложения в виде исполняемых файлов или docker-контейнеров, в зависимости от конфигурации окружения, в котором планируется их запускать. Это, в частности, позволяет запускать такие сервера на локальном компьютере для проведения локальных тестов.

В геймдеве есть и набор наиболее часто используемых типов серверов.

Мета-сервер

Самый распространённый вид сервера. Многие игры вовсе ограничиваются только им. А какие-то и не используют совсем.

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

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

Возможные функции мета-сервера:
- авторизация игроков;
- распределение игроков по прочим серверам и сервисам;
- взаимодействие с мастер-сервером;
- взаимодействие с профиль-сервером;
- поиск игроков для совместной игры;
- обработка игровых событий;
- валидация действий игроков;
- обработка платежей;
- и пр.

Профиль-сервер

Профиль-сервер предназначен для хранения и управления данными игроков.

Грубо говоря, это прослойка для работы с внешней базой данных или же сама база данных. В качестве базы данных может выступать какая-нибудь СУБД, сервис хранения данных или кастомное решение, построенное хоть на беспорядочной записи всего подряд в один файл.

Функции профиль-сервера:
- безопасное хранение пользовательских и игровых данных;
- синхронизация пользовательских данных между сессиями и между различными устройствами игроков, позволяя им продолжать играть с того места, где они остановились, независимо от используемого устройства.

Варианты реализации:
- отдельный сервер или сервис, с которым общаются через мета-сервер;
- отдельный сервер или сервис, с которым общаются клиенты напрямую (если нет мета-сервера);
- ответственность мета-сервера непосредственно.

Игровой сервер

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

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

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

Функции игрового сервера:
- обработка данных, полученных от клиентов;
- передача полученных данных другим игрокам;
- обеспечение синхронизации игрового процесса;
- управление логикой игрового процесса;
- обеспечение защиты от мошенничества;
- управления правами доступа игроков;
- хранение состояния игры;
- ведение статистики;
- и пр.

Игровой сервер обычно обеспечивает работу одной конкретной игровой сессии в рамках CoreGame. Когда сервер будет выключен, игровая сессия для всех игроков на этом сервере завершится. Поэтому в играх с длительной игровой сессией может требоваться механизм бэкапов, когда игровой сервер записывает перед выключением или по мере своей работы игровые данные в какое-нибудь подключенное хранилище, чтобы иметь возможность восстановить игровую сессию после запланированной (или нет) перезагрузки игрового сервера или его замены на другой.

Когда MMO-игры предлагают выбрать сервер, они предлагают выбрать именно игровой сервер, на котором поддерживается долгая игровая сессия, рассчитанная на большое кол-во игроков.

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

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

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

Мастер-сервер

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

Функции мастер-сервера:
- получение от активных игровых серверов специальных сигналов с информацией — heartbeat;
- формирование и хранение списков активных серверов по различным параметрам: режимы, карты, модификации и пр;
- мониторинг игровых серверов, отслеживание их заполненности и доступности;
- выдача списка доступных серверов по запросу клиентам или мета-серверу;
- создание и запуск новых игровых серверов.

Варианты реализации:
- отдельный сервер или сервис, с которым общаются через мета-сервер;
- отдельный сервер или сервис, с которым общаются клиенты напрямую (если нет мета-сервера);
- ответственность мета-сервера непосредственно.

Клиент

Клиент – это сама игра на устройстве пользователя.

Основные функции клиента (в контексте мультиплеера):
- получение ввода от пользователя;
- обработка полученных данных;
- передача данных серверу и/или другим клиентам;
- получение и обработка ответов от сервера и/или других клиентов;
- рендеринг игрового процесса на основе актуальных игровых данных.

В некотором общем смысле, если использовать термины MVP:

• Сервер: это Model (владеет данными игры и реализует бизнес-логику).

• Клиент: это View (получает инпут и рендерит игру) и Presenter (обрабатывает инпут, взаимодействует с моделью и обновляет представление).

В синглплеерных режимах/играх вся тройка MVP находится на одном узле – на клиенте.

Почему именно модель уходит на сервер:

• На сервере нет необходимости что-то рендерить.

• Инпут можно получить только от конкретного пользователя, который владеет только своим клиентом.

• Игра — это, в первую очередь, данные и манипуляции с этими данными. Чтобы игровой процесс распространить между несколькими клиентами, нужно чтобы данные, поверх которых строится игровой процесс, были общими.

• Для многопользовательской работы с данными нужно обеспечить очерёдность и порядок доступа к этим данным.

• Данные должны быть достоверными. Для поддержания достоверности необходимо валидировать действия с данными и не допускать превышения полномочий и возможностей со стороны клиентов.
  Лучший способ это сделать: достоверную копию данных вынести со всех клиентов туда, где к данными не будет прямого доступа со стороны этих клиентов.

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

Синхронизация данных на клиенте

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

При недостаточном качестве соединения синхронизация локальных данных будет происходить слишком долго. Из-за этого игра будет терять в отзывчивости (input lag), и игрок всегда будет наблюдать действия, которые уже не актуальны.

Для компенсации задержек используется масса всяких приёмов (подробнее – в следующих статьях). Из-за этого в реальности описанные выше MVP-границы разделения ответственностей часто размываются:

• Где-то клиенты имеют копию серверной бизнес-логики для локальной симуляции и быстрой реакции на инпут игрока.

• Где-то сервер пытается действовать наперёд, заранее предсказывая и имитируя инпут игрока.

• Где-то только наиболее важная определённая для геймплея часть данных считается достоверной и управляется сервером, а оставшиеся данные обрабатывают в своих локальных моделях сами клиенты.
  (это про авторитет над данными, об этом – позже)

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

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

Если какой-то элемент игры не влияет на геймплей, то не страшно, если у каких-то игроков его состояние не синхронизируется вовремя и корректно.

Пример: какое-нибудь падающее от взрыва дерево, которое не создаёт коллизий с игроками, может упасть позже или раньше, правее или левее – на геймплей это не повлияет, только на визуальный опыт.

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

Реализация Клиента и Сервера

Образно, что из себя представляет сервер, а что клиент, обсудили. Теперь обсудим, что они из себя представляют в плане реализации. Я знаком с двумя вариантами.

Клиент и Сервер – отдельные проекты

Достоинства:
✅ Можно выбрать любую любимую технологию с набором любимых библиотек, не зависимо от того, в каком движке разрабатывается игра. Подойдут любые языки программирования, предоставляющие возможность писать серверные приложения: Python, Java, .NET, Node.js, PHP и др.
✅ Это легковесное решение, т.к. серверное приложение будет содержать только необходимые зависимости, заложенные разработчиком и самой технологией.
✅ Можно использовать готовый шаблон, готовый фреймворк или реализовать сервер полностью своими силами, что позволит контролировать максимум аспектов работы приложения.
✅ Есть возможность реализовать специфичные сценарии работы. Например, реализацию поддержки нескольких игровых сессий параллельно.

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

Проблему общих зависимостей и их дублирования в контексте Unity решают следующим образом:
- Клиентская кодовая база в Unity написана на C#.
- Для реализации сервера используют .NET Core на C#.
- Общие зависимости выделяют в отдельную сборку или отдельный C#-проект.
- Клиентский и серверный проект подключают к себе модуль с общими зависимостями или используют собранные dll с ними.

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

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

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

Клиент и Сервер – один проект

Подобный способ реализации предоставляют практически все Netcode-библиотеки для Unity. Работая в Unity-проекте идёт работа как над клиентской логикой, так и над серверной. В зависимости от стиля работы это может быть как сгруппировано в отдельные модули внутри проекта, так и не иметь строго разделения. Тогда используют конструкции ветвления внутри логики для определения текущей стороны исполнения и запуска соответствующих сценариев работы.

Достоинства:
✅ Вместо двух-трёх проектов — один, что в каком-то смысле упрощает разработку.
✅ Проблема дублирования логики и общих зависимостей решается сама собой, т.к. всё необходимое всем сторонам исполнения уже находится в одном проекте.
✅ От сервера достаточно просто отказаться. Серверная логика уже написана на нужном языке и находится в целевом проекте – достаточно адаптировать её и включить в клиентские сценарии.

Недостатки:
❌ Сервер – полноценная игра на клиентском движке. Т.е. помимо серверного кода от CoreGame туда уйдёт, как минимум, сам движок с его зависимостями и, как максимум, вся остальная игра с MetaGame и прочим.
❌ Чтобы лишние зависимости не уходили на сервер, нужно постоянно заниматься их контролем и организовывать проект так, чтобы на этапе сборки всё лишнее имело возможность не попадать в билд.
❌ Клиент и сервер обычно имеют разные конфигурации для итоговой сборки, особенно в контексте CI/CD, поэтому нужно реализовывать и поддерживать разные сценарии сборки.
❌ Если используется готовая Netcode-библиотека, то один сервер будет обслуживать только одну игровую сессию. Чем больше параллельных сессий, тем больше серверов нужно включать.

Чем чревато утекание лишних зависимостей на сервер:

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

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

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

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

Аналогично серверные зависимости также могут "протекать" на клиент и вызывать схожие проблемы.

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

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

Заключение

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

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

Впереди ещё множество нераскрытых тем. Следить за выходом новых статей по мультиплееру и не только можно в моём блоге на VK / Telegram / Dtf / Dzen, где я делюсь своими находками, мыслями, инсайтами. анонсами и новостями.

Контент

Полезные ресурсы по теме:
- Bare Metal vs Virtual Machines vs Containers: dev.to
- MasterServer: How it works: 333Networks
- What is a Game Server and How Does it Work: ServerMania
- Архитектура мета-сервера у Tacticool: Habr.Pixonic
- Инфраструктура серверов War Robots: Habr.Pixonic
- Fast paced шутер: технологии и подходы: Habr.Pixonic
- Вторые полгода разработки нового мобильного PvP: Habr.Pixonic

📼 Игры и описание 🎮

That Time I Got Reincarnated as a Slime ISEKAI Chronicles

Присоединитесь к любимым героям аниме-сериала и станьте творцом новой истории о Федерации Джуры-Темпеста!

Nine Treasures of Liuyin

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

GUNDAM BREAKER 4

Gundam Breaker 4 позволит вам воплотить в жизнь свои самые смелые мечты о создании идеального боевого робота. Здесь вы сможете окунуться в богатую вселенную Gundam и почувствовать себя настоящим механиком, собирая своих собственных мехов из деталей более чем 250 культовых мобильных костюмов.

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

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

Crypt Custodian

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

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

Знакомьтесь и заводите дружбу с другими «непослушными» призраками, которые живут за пределами дворца. Узнайте, как они погибли и почему им пришлось столкнуться с вечным изгнанием. А потом заглядывайте в местный бар «Убежище грешника», чтобы пообщаться с друзьями-призраками и усовершенствовать своё снаряжение.

Flowstone Saga

Освойте совершенно уникальную систему головоломок и сражений в этой 16-битной JRPG с эпическим сюжетом, очаровательными персонажами, потрясающим пиксельным искусством и эпической музыкой. Пройдите грандиозную историю на таинственных островах Ocean's End, полных утраченных воспоминаний, древних руин, пиратов, сокровищ и лягушек.

Deathbound

В средневековом мире Deathbound, созданном на руинах технологий, сталкиваются фанатичная вера и противоестественная наука. Нам предстоит окунуться в священный крестовый поход Церкви Смерти против Культа Жизни.

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

Skull and Bones

Приключенческий экшен, который погружает вас в атмосферу пиратства Индийского океана.

В центре геймплея — ваш корабль. Он станет вашим домом и крепостью, потребует постоянной заботы и внимания. Выбирайте тип судна, оснащение, команду — всё это напрямую влияет на характеристики и боеспособность вашей «плавучей базы». Чем больше награбленных трофеев, тем лучше корабль и сильнее репутация среди других морских разбойников.

Океан в Skull and Bones — это своего рода PvP-зона. Здесь вы не одиноки — вас окружают как игроки, так и компьютерные противники. Все они стремятся заполучить ваш груз и нажиться на вашей погибели. Вам решать — нападать первым или избегать конфликтов, но помните о том, что рано или поздно придётся дать бой.

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

Cat Quest III

Ролевая игра с открытым миром, где вы становитесь храбрым муррским разбойником. Вас ждёт фантастический архипелаг в Муррибском море, где зловещие хвостатые пираты охотятся за Полярной звездой — легендарным сокровищем, которое скрывает тайну древнего зла. Не дайте им его найти. Возьмите под своё командование верного друга и свой собственный корабль и отправляйтесь в путешествие по морям и островам. Но будьте настороже — море полно опасностей, а за вашей шкурой гоняются крысиные наёмники по приказу Короля пиратов.

Visions of Mana

Visions of Mana представляет собой ролевую игру во вселенной Mana. Она поведает нам историю Вэла — стража душ, призванного защищать своего друга детства. Этот друг ещё в детстве был избран феями в качестве носителя Огня Алмы — великой силы, способной восстановить поток маны к Древу Маны. И вот настал момент, когда герои вынуждены отправиться в путешествие, полное опасностей и тайн.

Black Myth: Wukong

Black Myth: Wukong — ролевой боевик по мотивам китайской мифологии. Став Избранным, вы отправитесь в приключение, полное испытаний и чудес, в котором вам предстоит приподнять завесу тайны над великой легендой.

Видео и музыка предназначены для информационных целей + 18 🎮
Все авторские права принадлежат их законным владельцам. 💽
Примечание: Дата выпуска может быть изменена. 💢

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

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

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

Места обитания: любые локации с травой или глиной, может встречаться на локациях с песком, если истреблять обитающих там вжиков. Также обитает в шахтах.

Особенности: При низком уровне жизни(hp) начинает убегать, при восстановлении жизней переходит в состояние "в ярости", в котором наносит значительно больший урон, пока не будет добита.

Характерный тип атаки: Ближний бой, ударное+отравление, по ногам.
Все крысы 8+ уровня при укусе вешают парализацию.
Все крысы 12+ уровня при укусе вешают галлюцинации.

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

Стич серый - самая распространенная разновидность.

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

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

Стич золотой - при смерти выпадает большое количество ресурсов и какой-нибудь предмет.  Частичный иммунитет к некоторым пси-воздействиям.

Стич розовый - выглядит так же, как багровый, но при этом так же, как из золотого, при смерти выпадает большое количество ресурсов и какой-нибудь предмет.  Частичный иммунитет к некоторым пси-воздействиям.

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

Места обитания:заслоны с травой или глиной, может встречаться на заслонах с песком, если истреблять обитающих там вжиков. Также обитает в шахтах. Серый, Темный, и Багровый стичи могут быть вызваны в бою  Пси-лидером. Также обитает вдеревне стичей. Существуют аномальные заслоны с большим количеством 49 уровней стичами, например в локации -146/146, снимок:

Особенности: Темного, Багрового, Золотого и Стича-альбиноса, псионикам, лучше всего их убивать со Strike атаки, другие пси-атаки наносят очень слабый урон.

Характерный тип атаки: Плевки - ударное+ожоговое, в голову или руки. Ближний бой - ударное, 9+ стичи вешают при ударе панику, 14+ стичи вешают зомбирование.

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

Сайт игры funzero.ru

Помощь в освоении - https://t.me/only_smile_tz