Мультиплеер туториал 1: основы

2

Index

Tagged

Contributors

Stats

48,716 visits, 74,585 views

Tools

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

Published on 19 Dec, 2016. Last updated 25 Feb, 2019

Construct 2 мультиплеер плагин

Общий дизайн многопользовательской игры в Construct 2 выглядит примерно следующим образом

Фрагмент многопользовательской игры

Жизненный цикл многопользовательской игры будет примерно таким:

1. Подключение к сигнальному серверу и логин.

2. Выбор комнаты.

3. Другие пиры могут присоединяться и выходить из игры во время работы.

4. Данные объекта и другие сообщения, такие как чат обмениваются с другими подключенными пирами.

5. В конце концов, игра заканчивается, все выходят из комнаты и, возможно, могут искать новую комнату (вернуться к шагу 2).

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

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

Обзор дизайна

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

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

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

Действие Мультиплеер объекта Sync object является основным способом, чтобы указать, что вы хотите передать данные об объектах через сеть. Это указывает хосту передать информацию об этих объектах к пирам и указывает пирам ждать получения. Мультиплеер движок автоматически создает и уничтожает объекты, представляющие пиры, как только они присоединяются или уходят. ( Sync object действие также может быть использовано для других объектов, которые не представляют пиры но чаще всего он используется для пиров.)

Каждый пир имеет Peer ID назначенный сигнальным сервером . Это строка с короткой последовательностью случайных символов, чтобы однозначно идентифицировать его. Peer ID обычно используются, чтобы иметь возможность постоянно ссылаться на того же игрока, даже если их псевдоним изменён. Peer ID должен быть сохранен в переменной экземпляра, так что вы знаете, каким пиром представлен объект . Когда объект для пира создается мультиплеер движком, Multiplayer.PeerID выражение устанавливается в его PeerID так что оно может быть сохранено в переменной экземпляра. Для контроля вашего собственного пир-объекта , вы можете легко найти его путём тестирования, если его переменная экземпляра равна Multiplayer.MyID , а затем изменить этот экземпляр.

Режимы надёжности

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

Самый надежный режим Reliable ordered . Он посылает сообщение, которое отслеживается: если оно потеряется в сети он будет повторно отправлять его, пока он не проверит, что оно прибыло адресату. Он также помечает сообщения, так, что бы они гарантированно прибыли в том же порядке, в котором были отправлены. Это полезно, но не быстро: если одно сообщение не доставлено, все последующие сообщения будут задержаны, пока первое не дойдёт. Это также означает, что отдельные сообщения могут принимать множественные задержки, поскольку ждут обратного уведомления. Это, как правило, подходит только для важных низкочастотных сообщений, таких как сообщения чата.

Следующим, более быстрым является Reliable unordered . Он посылает сообщение, которое отслеживается а также будет повторно отправлено, пока не подтвердится его доставка. Однако сообщения могут прибывать в любом порядке. Это предотвращает задержку всей очереди. Однако отдельные сообщения еще могут иметь множественную задержку. Это подходит для игровых событий, которые должны прибыть, но не связаны друг с другом, как открытие двери и взрыв.

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

Готов к запуску!

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

If you're ready to start learning more, head on to Multiplayer tutorial 2: chat room!

  • 0 Comments

Want to leave a comment? Login or Register an account!