photon bolt что это

PUN vs. Bolt

Introduction

PUN and Photon Bolt are two powerful game networking middlewares. Choosing between the two is no easy task. The goal of this document is to provide a comprehensible summarised comparison between these two tools to help the developers decide which one best fits their needs.

PUN (Photon Unity Networking) is a clone of the original Unity networking API, powered by the reliable Photon infrastructure. Besides the omnipresent matchmaking, PUN basic building blocks are: serialization of game object states (with built in support for transforms, etc); and remote procedure calls (RPC). PUN gives the developer direct and complete control of what to send/receive, and, coupled with its flexible multicast-like room relay communication model, is a powerful game networking workhorse.

Photon Bolt

Photon Bolt is a higher level API, which lets the developer define the networkable gamestate through a set of data structures (called bolt assets: states, objects, events and commands) and associate these assets to game objects prefabs. Augmented by callbacks and triggering of events and commands, Bolt’s networking model brings state of the art compression, client-side prediction and lag compensated raycasts to Unity with minimum effort from the developer.

Quick Comparison

Features Comparison

Both Photon Bolt and PUN approaches have their strengths and reasons to be. Here we try to explain important differences between them by comparing individual features of each one that impact similar areas of game networking.

Host Client (Bolt) Vs. Dedicated Server (PUN)

With PUN, you already have a real dedicated server you can connect to and where rooms actually exist. The client that creates a room is the first one to join it. It will be marked as a Master Client known by everyone inside the room. A Master Client is not a host nor a server but just a special client that can do extra stuff (pseudo-authoritative).

In Bolt however, one of the Bolt clients needs to act as a server, a true dedicated server or real host. This can be a bit confusing, so let’s clear things up:

So to sum up, in Bolt, if host disconnects the game is over. Also ping and latency will depend on the connection to the hosting player.

Events (Bolt) Vs. RPCs (PUN)

Automatic State Replication (Bolt) Vs. Flexibility (PUN)

With Bolt, you don’t have to write serialisation code. Everything is generated by Bolt’s compiler based on the assets you create to represent the game state. This is a great time-saver, and also means you benefit from other features out of the box such as compression. However, it also means you don’t have total control of what goes to the network and how.

With PUN, you write your own serialisation routines, deciding what to send and what to receive. This way, you can write custom dead-reckoning functions, and decide which clients receive each piece of information with your own code.

Bit Compression (Bolt) Vs. Message Efficiency (PUN)

Since Bolt code generation takes care of objects state serialisation, it benefit from state of the art compression, which greatly reduces the traffic for networking a complex gamestate. However, Bolt’s messages must always pass through the hosting machine, even when running a game through relay and not using authoritative server logic. This adds a bit more latency to Bolt-based games.

PUN doesn’t suffer from that caveat, as it’s serialisation code sends data from a client to all the other peers through the relay by default (without having to pass through the master-client). The issue for PUN here is that since the developer writes his own serialisation code, state of the art compression can not be achieved out of the box (the programmer may have to implement it himself).

Client-Side Prediction & Lag Compensation (Bolt) Vs. Lite Authoritative-Server Possibilities (PUN)

Bolt greatly simplifies the implementation of an authoritative server game with its built in client-side prediction architecture (commands + responses) and lag compensated shooter first raycasts (based on server-time approximative hitbox buffers). This means the developer automatically benefit from years of industry experience from FPS and action games with a very comprehensible API.

The issue with such fully authoritative (often dedicated) server approach is cost. Hosting servers that need to cope with the high CPU loads of complete simulations might render the game economically impractical.

With PUN, it is possible to write server-side plugins that match 1-to-1 every custom serialisation message from the clients, which can be intercepted and either blocked or modified before passed through to the others. This is a very flexible API to implement only the minimum logic needed on the Photon servers themselves, leading to a much smoother scaling of servers costs.

Bolt’s message packing and compression (a benefit in its own right) makes such approach impractical, if not impossible.

In thoery, it is possible to achieve pseudo authoritative functionality with PUN without server plugins and based on Master Client. This require Master Client (and maybe all Master Client candidates) to maintain a 100% true state of each client, which is tricky.
Bolt solves this by introducing exactly that; client states.

In an FPS game, a typical «player state» would contain information about each player’s position, velocity, camera pitch, etc. With Bolt, these states are defined in Bolt’s own Unity editor extension, which makes everything user friendly and type-safe to work with. Bolt takes care of synchronizing states over the network for you, with the server being in charge of each client’s real state, thereby hindering cheating.

Источник

Get the Unity Package.

We have the fitting plan!

All applications run conveniently in the Photon Cloud.
Hosting, operations and scaling services are all cared for by us.
You build it, we run it.

Photon PUBLIC Cloud

20 CCU FREE LICENSE

3 GB traffic per CCU included.
No further traffic can be used. Overage fees do not apply.

Start on a free plan: perfect for evaluation and development. You can down- or upsize at any time as your app grows. Apps access worldwide for least ping.

Traffic Overage Fees

Traffic Overage Fees

Traffic Overage Fees

Traffic Overage Fees

Unparalleled Features
You Won‘t Find Anywhere Else

Photon PREMIUM Cloud

Our worry-free service with maximum flexibility,
for up to 50,000 CCU

Example Calculation:

$ 580 fee is paid up front.

Sum of peak CCU across all regions is 4,830 CCU.

Traffic Overage Fees

Autoscaling ensures that required CCU capabilities are always provided automatically. Fair and transparent usage-based billing per CCU and GB.

Photon ENTERPRISE Cloud

The Photon Enterprise Cloud provides you with a dedicated cloud environment for multiple, high CCU titles. Guaranteed service levels and plugins for server authoritative logic make it the trusted choice for the world’s top studios.

Contact us for options and further details on enterprise plans.

Concurrent Users (CCU)

The number of users allowed to connect to your application is defined by its CCU. For plans the CCU total is defined by the sum of peaks for all regions.

Sample Month: EU peak 420 CCU, US peak 230 CCU, Other regions 0 CCU — CCU total = 420 + 230 = 650, matching 1000 CCU subscription plan.

CCU Burst, Overage

Traffic Calculation

Sample: 1000 CCU plan * 3 GB incl. per CCU = 3 TB included traffic.

Monthly Active Users (MAU)

We assume, as rule of thumb and based on our experience, 1 CCU to match 20 daily active users (DAU). Each DAU translates to 20 monthly actives (MAU).

One-Time Plans

One-time plans apply to one application and for 12 months, no recurring fees. You can add 100 CCU to any other existing monthly subscription plan, e.g. 100 + 500 = 600 CCU in total.

Regions

For optimum round-trip-times your application can connect the nearest region we host in. Choose from multiple regions around the globe.

Down- and Upgrade at any Time

Downgrade and upgrade subscription plans at any time. Additional CCU are available immediately. Any fees paid but unused will be credited automatically. Termination takes effect at the end of the month.

Peers per Room

Using Photon, users are connected to «Rooms» to play a multiplayer match, collaborate or communicate. «Peers per Room» represents the actual amount of connected game or application clients («Peers») per Room at the same time.

Msg / Sec

Total inbound and outbound messages of all connected Peers (as counted by Photon) divided by the number of Photon Rooms. The more Peers are joining a room, the more Messages per Second («Msg / Sec») will be sent around (N messages x M clients) and the amount of used traffic will be increased. Check our FAQ-page on how to calculate messages and traffic consumption for your app.

Support and SLAs

All packages include free forum access and e-mail support. Agreements with service levels, priority support are available on request.

Источник

PUN vs. Bolt

Introduction

PUN and Photon Bolt are two powerful game networking middlewares. Choosing between the two is no easy task. The goal of this document is to provide a comprehensible summarised comparison between these two tools to help the developers decide which one best fits their needs.

PUN (Photon Unity Networking) is a clone of the original Unity networking API, powered by the reliable Photon infrastructure. Besides the omnipresent matchmaking, PUN basic building blocks are: serialization of game object states (with built in support for transforms, etc); and remote procedure calls (RPC). PUN gives the developer direct and complete control of what to send/receive, and, coupled with its flexible multicast-like room relay communication model, is a powerful game networking workhorse.

Photon Bolt

Photon Bolt is a higher level API, which lets the developer define the networkable gamestate through a set of data structures (called bolt assets: states, objects, events and commands) and associate these assets to game objects prefabs. Augmented by callbacks and triggering of events and commands, Bolt’s networking model brings state of the art compression, client-side prediction and lag compensated raycasts to Unity with minimum effort from the developer.

Quick Comparison

Features Comparison

Both Photon Bolt and PUN approaches have their strengths and reasons to be. Here we try to explain important differences between them by comparing individual features of each one that impact similar areas of game networking.

Host Client (Bolt) Vs. Dedicated Server (PUN)

With PUN, you already have a real dedicated server you can connect to and where rooms actually exist. The client that creates a room is the first one to join it. It will be marked as a Master Client known by everyone inside the room. A Master Client is not a host nor a server but just a special client that can do extra stuff (pseudo-authoritative).

In Bolt however, one of the Bolt clients needs to act as a server, a true dedicated server or real host. This can be a bit confusing, so let’s clear things up:

So to sum up, in Bolt, if host disconnects the game is over. Also ping and latency will depend on the connection to the hosting player.

Events (Bolt) Vs. RPCs (PUN)

Automatic State Replication (Bolt) Vs. Flexibility (PUN)

With Bolt, you don’t have to write serialisation code. Everything is generated by Bolt’s compiler based on the assets you create to represent the game state. This is a great time-saver, and also means you benefit from other features out of the box such as compression. However, it also means you don’t have total control of what goes to the network and how.

With PUN, you write your own serialisation routines, deciding what to send and what to receive. This way, you can write custom dead-reckoning functions, and decide which clients receive each piece of information with your own code.

Bit Compression (Bolt) Vs. Message Efficiency (PUN)

Since Bolt code generation takes care of objects state serialisation, it benefit from state of the art compression, which greatly reduces the traffic for networking a complex gamestate. However, Bolt’s messages must always pass through the hosting machine, even when running a game through relay and not using authoritative server logic. This adds a bit more latency to Bolt-based games.

PUN doesn’t suffer from that caveat, as it’s serialisation code sends data from a client to all the other peers through the relay by default (without having to pass through the master-client). The issue for PUN here is that since the developer writes his own serialisation code, state of the art compression can not be achieved out of the box (the programmer may have to implement it himself).

Client-Side Prediction & Lag Compensation (Bolt) Vs. Lite Authoritative-Server Possibilities (PUN)

Bolt greatly simplifies the implementation of an authoritative server game with its built in client-side prediction architecture (commands + responses) and lag compensated shooter first raycasts (based on server-time approximative hitbox buffers). This means the developer automatically benefit from years of industry experience from FPS and action games with a very comprehensible API.

The issue with such fully authoritative (often dedicated) server approach is cost. Hosting servers that need to cope with the high CPU loads of complete simulations might render the game economically impractical.

With PUN, it is possible to write server-side plugins that match 1-to-1 every custom serialisation message from the clients, which can be intercepted and either blocked or modified before passed through to the others. This is a very flexible API to implement only the minimum logic needed on the Photon servers themselves, leading to a much smoother scaling of servers costs.

Bolt’s message packing and compression (a benefit in its own right) makes such approach impractical, if not impossible.

In thoery, it is possible to achieve pseudo authoritative functionality with PUN without server plugins and based on Master Client. This require Master Client (and maybe all Master Client candidates) to maintain a 100% true state of each client, which is tricky.
Bolt solves this by introducing exactly that; client states.

In an FPS game, a typical «player state» would contain information about each player’s position, velocity, camera pitch, etc. With Bolt, these states are defined in Bolt’s own Unity editor extension, which makes everything user friendly and type-safe to work with. Bolt takes care of synchronizing states over the network for you, with the server being in charge of each client’s real state, thereby hindering cheating.

Источник

Использование Photon Cloud в Unity3D

В процессе создания своей первой игры на Unity3D я осознал необходимость организации сетевого режима, в котором игроки могли бы калечить компьютерных аватаров своих противников. Если вы раньше не занимались созданием клиент-серверных приложений, не поднимали своих игровых серверов, не желаете вкладывать силы и средства в их установку и поддержку, а хотите просто понять принципы организации мультиплеера и за 15-20 минут модернизировать свой проект так, чтобы с чистой совестью добавить к его названию слово Online, то эта статья для вас.

Немного о самом Photon. Это компания специализируется на серверных движках. Удобный сайт, на котором вы можете зарегистрироваться и получить AppID буквально за пару минут. Обширная документация, правда на языке оригинала, куча руководств и демопроектов. В сети есть даже видео уроки на русском, правда всё это относится к Photon Server. Если же вы не хотите заморачиваться с установкой и настройкой сервера, то можно воспользоваться облачным сервисом Photon Cloud, для этого необходимо лишь получить AppID при регистрации, который гарантирует вам лицензию на 20 одновременно подключенных пользователей.

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

Итак, что нам нужно для счастья?

1. Подключиться к Облаку.
2. Создать тестовую комнату, либо присоединиться к ней, если она уже существует.
3. Убедиться, что все игроки взаимодействуют друг с другом в одной и той же сцене.

Подключение организуется с помощью встроенного статичного класса PhotonNetwork:

Думаю, значения параметров понятны. Последний параметр нужен для того, чтобы отличать версии ваших приложений друг от друга.
Если же в каталоге Assets\Photon Unity Networking\Resources у вас лежит скрипт PhotonServerSettings, ,
то вы можете использовать процедуру

Создание или присоединение к тестовой комнате:

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

Примечание: При загрузке новой сцены соединение с сервером и комнатой не разрывается.

Теперь осталось синхронизировать сцены и движения игроков на ней. Тут всё зависит от самого проекта. Есть несколько основных вариантов:
1. Вам требуется, чтобы какой-то объект синхронно перемещался для всех игроков. Для этого достаточно добавить к синхронизируемым объектам компонент PhotonView — «Components/Miscellaneous/PhotonView» .
В качестве Observe укажите синхронизируемый объект, а в Serialization синхронизируемые параметры.
Каждый компонент PhotonView имеет View ID.
2. Вам необходимо создавать один и тот же объект во время игры по желанию пользователя. Например, игрок должен кидать гранату. Для этого, нужно создать игровой объект, где вместо Instaniate используется процедура

В отличие от Instaniate сперва необходимо указать название префаба, а в конце указать его группу (просто любое целое число). Созданный, одним из игроков, такой объект появляется у всех остальных.
Именно с помощью данной процедуры нужно создавать главного героя. Однако, вы столкнётесь с тем, что все персонажи будут реагировать на ваше управление. Чтобы избежать этого, вы должны добавить в скрипт управления персонажем условие определяющее локального игрока. Что-то вроде:

Примечание: Чтобы воспользоваться свойством photonView.isMine необходимо в качестве родительского класса для скрипта указать Photon.MonoBehaviour.
Создавать можно только префабы, находящиеся Assets\Photon Unity Networking\Resources

3. Для управления объектами вам помогут RCP (Remote Call Procedure), с помощью которых вы сможете выполнять процедуры на удалённых приложениях передавая им необходимые аргументы. Для этого нужно перед объявлением процедуры в скрипте добавить тег [RPC], а к объекту, к которому прикреплён скрипт добавить компонент PhotonView, чтобы потом была возможность к ней обратиться.
Например:

Соответственно, чтобы удалённо запустить процедуру на клиенте, необходимо определить PhotonView:

А затем выполнить процедуру

где в качестве аргументов указать название вызываемой процедуры, получателей, и аргументы исходной функции.
Примечание: В качестве параметров RPC понимает только основные типы, т.е. int, float, bool, string и т.п.

4. В качестве объекта синхронизации компонент PhotonView, по умолчанию выбирает компонент Transform, отвечающий за положение объекта в пространстве. Если же нам нужно передавать какую-то информацию, то в качестве объекта синхронизации нужно указать скрипт

,

а в самом скрипте вставить процедуру

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

Благодарю, за внимание. В следующий раз я планирую подробнее разобрать функционал Photon Cloud.

Источник

Photon bolt что это

Client-hosted Networking for Unity that Always Connects Your Players

Photon BOLT

now supports Multiplayer on Nintendo Switch

Perfect for FPS/TPS, Action Games
or Battle Royale

Build multiplayer games with a dedicated server architecture for Unity.
Find everything to build the next PUBG or Fortnite.

Unparalleled Features
You Won‘t Find Anywhere Else

Authoritative
Movement

BOLT offers truly unique support for authoritative games: Authoritative movement with client-side prediction and lag compensated ray-casting are both built in. A feature that no other product on the market is offering.

Authoritative
Movement

Authoritative
Movement
BOLT offers truly unique support for authoritative games: Authoritative movement with client-side prediction and lag compensated ray-casting are both built in. A feature that no other product on the market is offering.

Powerful
Event System

Bolt has a built-in event system which distributes the event to the correct receivers. Highly configurable and automatically, of course. Events can also be targeted at a specific game object or raised globally. Finetune delivery of events in three modes: Unreliable, Unreliable Synced and Reliable.

Powerful
Event System

Powerful
Event System
Bolt has a built-in event system which distributes the event to the correct receivers. Highly configurable and automatically, of course. Events can also be targeted at a specific game object or raised globally. Finetune delivery of events in three modes: Unreliable, Unreliable Synced and Reliable.

State Replication

State Replication
Replicate game object transforms and user-definable properties automatically without the need for any code. Everything is neatly accessible through a visual editor which lets you define and customize properties at a detailed level.

Mecanim Replication

Mecanim Replication
Mecanim animations replicate automatically over the network. Find all your character animations perfectly synchronized without any custom code being required.

Prioritization and Scoping

Prioritization and Scoping
Bolt supports both scoping of entities (which entities should a player be aware of) and prioritization of scoped entities (of two entities A and B that are scoped, which one is the most important for a player).

Lag Compensation / Hitbox Recording

Lag Compensation / Hitbox Recording
Bolt has built-in support for recording hitboxes and rewinding and ray-casting against them, allowing you to implement complex techniques like lag compensation in first person shooters with just a few lines of code.

Dedicated Server & Listen Server

Dedicated Server & Listen Server
Bolt supports the classic DEDICATED SERVER and LISTEN SERVER where the server is just another player. Session discovery allows your game to automatically find servers running on a local LAN or WiFi.

Networked Scene Loading

Networked Scene Loading
Networked scene-loading gives you an easy way to load scenes in Unity over the network and assures that you know when all players are loaded into the map.

Cloud Matchmaking

Cloud Matchmaking
Match players into games randomly or by parameterized searches. Create a list of open rooms and let players pick one.

Источник