Compare commits
No commits in common. "main" and "upm" have entirely different histories.
|
|
@ -1,29 +0,0 @@
|
|||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
paths:
|
||||
- TestVelGameServer/**
|
||||
jobs:
|
||||
split-upm:
|
||||
name: split upm branch
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
with:
|
||||
fetch-depth: 0
|
||||
token: ${{ secrets.WORKFLOW_TOKEN }}
|
||||
- name: split upm branch
|
||||
run: |
|
||||
git subtree split -P "$PKG_ROOT" -b upm
|
||||
git checkout upm
|
||||
if [[ -d "Samples" ]]; then
|
||||
git mv Samples Samples~
|
||||
rm -f Samples.meta
|
||||
git config --global user.name 'github-bot'
|
||||
git config --global user.email 'github-bot@users.noreply.github.com'
|
||||
git commit -am "Rename Samples to Samples~"
|
||||
fi
|
||||
git push -f -u origin upm
|
||||
env:
|
||||
PKG_ROOT: TestVelGameServer/Packages/VelNetUnity
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
env:
|
||||
SUBFOLDER: Documentation
|
||||
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- Documentation/**
|
||||
|
||||
jobs:
|
||||
publish-docs:
|
||||
defaults:
|
||||
run:
|
||||
working-directory: ${{env.SUBFOLDER}}
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
contents: read
|
||||
deployments: write
|
||||
name: Publish to Cloudflare Pages
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- uses: actions/setup-python@v4
|
||||
with:
|
||||
python-version: 3.x
|
||||
|
||||
- run: echo "CACHE_ID=$(date --utc '+%V')" >> $GITHUB_ENV
|
||||
|
||||
- uses: actions/cache@v3
|
||||
with:
|
||||
key: mkdocs-material-${{ env.CACHE_ID }}
|
||||
path: .cache
|
||||
restore-keys: |
|
||||
mkdocs-material-
|
||||
|
||||
- run: pip install -r requirements.txt
|
||||
|
||||
- name: Build
|
||||
run: mkdocs build --site-dir public
|
||||
|
||||
- name: Upload
|
||||
env:
|
||||
PROJECT_NAME: velnet-docs
|
||||
CLOUDFLARE_ACCOUNT_ID: 8077b5b1f8e2ade41874cbaa3f883069
|
||||
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
|
||||
run: npx wrangler@3.1.1 pages deploy public --project-name="${{env.PROJECT_NAME}}" --branch="${{env.GITHUB_REF_NAME}}"
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.DS_Store
|
||||
my.secrets
|
||||
.git.bfg-report/
|
||||
Documentation-old/
|
||||
env/
|
||||
Documentation/public/
|
||||
node_modules/
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
{
|
||||
"configurations": [
|
||||
|
||||
]
|
||||
}
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
# Default ignored files
|
||||
/shelf/
|
||||
/workspace.xml
|
||||
# Editor-based HTTP Client requests
|
||||
/httpRequests/
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<module type="WEB_MODULE" version="4">
|
||||
<component name="NewModuleRootManager">
|
||||
<content url="file://$MODULE_DIR$">
|
||||
<excludeFolder url="file://$MODULE_DIR$/.tmp" />
|
||||
<excludeFolder url="file://$MODULE_DIR$/temp" />
|
||||
<excludeFolder url="file://$MODULE_DIR$/tmp" />
|
||||
</content>
|
||||
<orderEntry type="inheritedJdk" />
|
||||
<orderEntry type="sourceFolder" forTests="false" />
|
||||
</component>
|
||||
</module>
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="ProjectModuleManager">
|
||||
<modules>
|
||||
<module fileurl="file://$PROJECT_DIR$/.idea/Documentation.iml" filepath="$PROJECT_DIR$/.idea/Documentation.iml" />
|
||||
</modules>
|
||||
</component>
|
||||
</project>
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="VcsDirectoryMappings">
|
||||
<mapping directory="$PROJECT_DIR$/.." vcs="Git" />
|
||||
</component>
|
||||
</project>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
|
|
@ -1,10 +0,0 @@
|
|||
There are several steps that need to happen before a client can join a room. Most of these can happen automatically using the default `VelNetManager` script.
|
||||
|
||||
## 1. Connecting
|
||||
First, the TCP connection to the server must be established. If this step fails, offline mode is activated.
|
||||
|
||||
## 2. Logging in
|
||||
Logging in registers this client with the server. The inputs for this are an app name and device id. `VelNetManager` automatically provides an appName that is appended with the version number if `onlyConnectToSameVersion` is true. The device id is generated from Unity's `SystemInfo.deviceUniqueIdentifier` and the app name to guarantee a different id per app and device.
|
||||
|
||||
## 3. Joining a room
|
||||
Only after joining a room can normal networking take place between clients in that room. The client can send any string room name to join, and other clients that send the same string will be in that room with them.
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# VelNetUnity
|
||||
|
||||
### NetworkManager
|
||||
|
||||
Deals with instantiating NetworkPlayers, and dealing with join, left, new master client events. Also manages the list of NetworkObjects. It maintains a list of prefabs that can be instantiated, as well as the prefab to use for players.
|
||||
|
||||
### NetworkPlayer
|
||||
|
||||
One of these will be instantiated for each player that joins the "room". Most application communication happens by calling methods on this object. Voice comms are also handled within this object. Only one NetworkPlayer "isLocal". The others are remote. The local network player is the one that can modify it's "owned" network objects. It also has a special networkobject representing itself (setup within the prefab, not part of the networkmanager list). This is where most of the user behavior is going to go (e.g. an avatar).
|
||||
|
||||
### NetworkObject
|
||||
|
||||
Something that can be owned by a network player, who is responsible for updating it. Only the owner network player can/should modify a network object, whether locally or in response to a received message from the local version. NetworkObjects are delineated by an session-unique id, which consists of the creator's userid + "-" + an increasing number designated by the creator. Only local NetworkPlayers should send instantiate message, which contain this id. This class should be extended to sync and send messages. Scenes are basically built from NetworkObjects. Scene's can also start with network objects. Those are known by all, and start with "-1-increasing". That should happen the same on all clients, and is done locally at the start of the networkmanager. An example of a NetworkObject is SyncTransform, which is a simple one that keeps an object's position and orientation synchronized.
|
||||
|
||||
### Ownership
|
||||
|
||||
Ownership of objects changes regularly. Any local networkplayer can send a message to take ownership of a networkid. That client immediately assumes ownership. The message is sent to the network, and will be ordered with any other ownership messages. So, if two clients try to get ownership at the same time, both will assume ownership, but one will happen after the other. This means that the one who was first will quickly lose ownership.
|
||||
|
||||
### Joining
|
||||
|
||||
An interesting problem is what to do when new clients join. This is partially left up to the developer. Any objects that are instantiated (or scene objects that are deleted) will be automatically handled.
|
||||
|
||||
### Message Groups
|
||||
|
||||
Clients can manage network traffic using messaging groups. This is especially useful for audio, where you can maintain a list of people close enough to you to hear audio
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
VelNet supports an offline mode that lets you write client code in the same way even in a situation where there is no internet or no server available.
|
||||
|
||||
Offline mode is activated automatically if no initial TCP connection can be established by `VelNetManager.cs`
|
||||
|
||||
Messages are intercepted by VelNetManager and send to a "FakeServer" function instead of to the server, and realistic response messages are constructed and sent to the callback functions.
|
||||
|
|
@ -1 +0,0 @@
|
|||
# Quick Start
|
||||
|
|
@ -1,120 +0,0 @@
|
|||
VelNet uses a single-byte header on all messages that denotes the message type. The set of message types for sent messages is different from the set used when receiving messages.
|
||||
It is generally not necessary to know or modify these internal data types.
|
||||
|
||||
!!! note
|
||||
|
||||
The server encodes ints with a Big-Endian format, but C# uses Little-Endian on almost all platforms. Use the `BinaryWriter.WriteBigEndian()` extensions to encode in Big-Endian on the C# side.
|
||||
|
||||
## MessageSentType
|
||||
```cs
|
||||
public enum MessageSendType
|
||||
{
|
||||
MESSAGE_OTHERS_ORDERED = 7,
|
||||
MESSAGE_ALL_ORDERED = 8,
|
||||
MESSAGE_LOGIN = 0,
|
||||
MESSAGE_GETROOMS = 1,
|
||||
MESSAGE_JOINROOM = 2,
|
||||
MESSAGE_OTHERS = 3,
|
||||
MESSAGE_ALL = 4,
|
||||
MESSAGE_GROUP = 5,
|
||||
MESSAGE_SETGROUP = 6,
|
||||
MESSAGE_GETROOMDATA = 9
|
||||
};
|
||||
```
|
||||
### MESSAGE_LOGIN = 0
|
||||
This message contains:
|
||||
- `byte` - The length of the deviceId string
|
||||
- `byte[]` - UTF8 encoding of the deviceId string
|
||||
- `byte` - The length of the appName string
|
||||
- `byte[]` - UTF8 encoding of the appName string
|
||||
### MESSAGE_GETROOMS = 1
|
||||
This message contains no data, just the single-byte header.
|
||||
### MESSAGE_JOINROOM = 2
|
||||
This message contains:
|
||||
- `byte` - The length of the roomName string
|
||||
- `byte[]` - UTF8 encoding of the roomName string
|
||||
### MESSAGE_OTHERS = 3
|
||||
### MESSAGE_ALL = 4
|
||||
### MESSAGE_GROUP = 5
|
||||
### MESSAGE_SETGROUP = 6
|
||||
### MESSAGE_OTHERS_ORDERED = 7
|
||||
### MESSAGE_ALL_ORDERED = 8
|
||||
### MESSAGE_GETROOMDATA = 9
|
||||
|
||||
## MessageReceivedType
|
||||
```cs
|
||||
public enum MessageReceivedType
|
||||
{
|
||||
LOGGED_IN = 0,
|
||||
ROOM_LIST = 1,
|
||||
PLAYER_JOINED = 2,
|
||||
DATA_MESSAGE = 3,
|
||||
MASTER_MESSAGE = 4,
|
||||
YOU_JOINED = 5,
|
||||
PLAYER_LEFT = 6,
|
||||
YOU_LEFT = 7,
|
||||
ROOM_DATA = 8
|
||||
}
|
||||
```
|
||||
### LOGGED_IN = 0
|
||||
This message contains:
|
||||
- `int` - The userid given by the server to this user.
|
||||
### ROOM_LIST = 1
|
||||
This message contains:
|
||||
- `int` - The length of the room mesesage string. This is an int instead of a byte because of the possible string length with many rooms.
|
||||
- `byte[]` - A UTF8-encoded string for the room message
|
||||
- This string is encoded as a comma-separated list of rooms, with the format `name:numUsers` for each room.
|
||||
- e.g. `Common_1:0:3,Auditorium_123:0,room1:10`
|
||||
### PLAYER_JOINED = 2
|
||||
This message contains:
|
||||
- `int` - The userid of the player that joined
|
||||
- `byte` - The length of the room name string
|
||||
- `byte[]` - A UTF8-encoded string for the room name
|
||||
### DATA_MESSAGE = 3
|
||||
This message contains:
|
||||
- `int` - The userid of the player that sent this message
|
||||
- `int` - The size of the payload
|
||||
- `byte[]` - The message data
|
||||
- Decoding the actual message data is handled in `VelNetPlayer.cs`
|
||||
- Within DATA_MESSAGE messages, there is an additonal type header:
|
||||
```cs
|
||||
public enum MessageType : byte
|
||||
{
|
||||
ObjectSync,
|
||||
TakeOwnership,
|
||||
Instantiate,
|
||||
InstantiateWithTransform,
|
||||
Destroy,
|
||||
DeleteSceneObjects,
|
||||
Custom
|
||||
}
|
||||
```
|
||||
### MASTER_MESSAGE = 4
|
||||
This message contains:
|
||||
- `int` - The new master client id. The sender of this message is the master.
|
||||
### YOU_JOINED = 5
|
||||
This is returned after you join a room.
|
||||
This message contains:
|
||||
- `int` - The number of players in the room
|
||||
- For each player:
|
||||
- `int` - The player's userid
|
||||
- `byte` - The length of the room name string
|
||||
- `byte[]` - A UTF8-encoded string for the room name
|
||||
### PLAYER_LEFT = 6
|
||||
This message contains:
|
||||
- `int` - The player's userid
|
||||
- `byte` - The length of the room name string
|
||||
- `byte[]` - A UTF8-encoded string for the room name
|
||||
### YOU_LEFT = 7
|
||||
This message contains:
|
||||
- `byte` - The length of the room name string
|
||||
- `byte[]` - A UTF8-encoded string for the room name
|
||||
### ROOM_DATA = 8
|
||||
This message contains:
|
||||
- `byte` - The length of the room name string
|
||||
- `byte[]` - A UTF8-encoded string for the room name
|
||||
- `int` - The number of client data blocks to read
|
||||
- For each client data block:
|
||||
- `int` - The userid of this client
|
||||
- `byte` - The length of the username string
|
||||
- `byte[]` - A UTF8-encoded string for the username
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
# Samples
|
||||
|
||||
This page has a brief explanation of each of the samples included in VelNetUnity. To install a sample, go to the Package Manager, and use the Import buttons in the Samples tab on the VelNet package (`Window->Package Manager->VelNet->Samples`).
|
||||
|
||||
## Basic Example
|
||||
This sample is designed to be as minimal as possible. It automatically joins a room and spawns a controllable player character for every client that joins.
|
||||
|
||||
## Full Example
|
||||
|
||||
## VEL Voice Example
|
||||
|
||||
## Dissonance Example
|
||||
|
|
@ -1 +0,0 @@
|
|||
# VEL Voice
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
# VelNet
|
||||
|
||||
VelNet is an easy-to-use networking library for Unity. VelNet is architected similar to [Photon PUN](https://doc.photonengine.com/pun/current/getting-started/pun-intro), with a single server that acts as a relay for information sent by all clients.
|
||||
|
||||
VelNet consists of two main parts, [VelNet Server](/server) and [VelNetUnity](/client).
|
||||
|
||||
<!-- ### [VelNet Server](/server)
|
||||
|
||||
[GitHub Link :simple-github:](https://github.com/velaboratory/VelNetServerRust)
|
||||
|
||||
### VelNet Unity
|
||||
|
||||
[GitHub Link :simple-github:](https://github.com/velaboratory/VelNetUnity) -->
|
||||
|
||||
## Installation
|
||||
|
||||
1. Set up the [server](/server), or use the default server at `velnet-example.ugavel.com`
|
||||
|
||||
- Install the UPM package in Unity:
|
||||
|
||||
=== "**Option 1:** Add the VEL package registry"
|
||||
|
||||
{ align=right }
|
||||
|
||||
Using the scoped registry allows you to easily install a specific version of the package by using the Version History tab.
|
||||
|
||||
- In Unity, go to `Edit->Project Settings...->Package Manager`
|
||||
- Under "Scoped Registries" click the + icon
|
||||
- Add the following details, then click Apply
|
||||
- Name: `VEL`
|
||||
- URL: `https://npm.ugavel.com`
|
||||
- Scope(s): `edu.uga.engr.vel`
|
||||
- Install the package:
|
||||
- In the package manager, select `My Registries` from the dropdown
|
||||
- Install the `VelNet` package.
|
||||
|
||||
=== "**Option 2:** Add the package by git url"
|
||||
|
||||
1. Open the Package Manager in Unity with `Window->Package Manager`
|
||||
- Add the local package:
|
||||
- `+`->`Add package from git URL...`
|
||||
- Select the path to `https://github.com/velaboratory/VelNetUnity#upm`
|
||||
|
||||
To update the package, click the `Update` button in the Package Manager, or delete the `packages-lock.json` file.
|
||||
|
||||
=== "**Option 3:** Add the package locally"
|
||||
|
||||
1. Clone the repository on your computer:
|
||||
`git clone git@github.com:velaboratory/VelNetUnity.git`
|
||||
- Open the Package Manager in Unity with `Window->Package Manager`
|
||||
- Add the local package:
|
||||
- `+`->`Add package from disk...`
|
||||
- Select the path to `VelNetUnity/TestVelGameServer/Packages/VelNetUnity/package.json`
|
||||
|
||||
To update the package, use `git pull` in the VelNetUnity folder.
|
||||
|
||||
Then check out the [samples](client/samples), or follow the [quick start](/client/quick-start).
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# VelNet Server
|
||||
|
||||
[GitHub Link :simple-github:](https://github.com/velaboratory/VelNetServerRust){ .md-button }
|
||||
|
||||
The VelNet server acts as a relay between users of your application. It is not aware of the details of your application, and a single server can be used to serve many different applications.
|
||||
|
||||
To get started, either use the demo server at `velnet-demo.ugavel.com`, or [host it yourself](self-host.md)
|
||||
|
||||
This basic, single-file relay server is designed to be used for network games, and is similar to Photon Realtime in design. It is written in Rust, with a single-threaded, non-blocking design and does not rely on any network frameworks (pure TCP/UDP). A Unity/C# client implementation can be found in our [VelNetUnity](https://github.com/velaboratory/VelNetUnity) repository.
|
||||
|
||||
Like Photon, there is no built-in persistence of rooms or data. Rooms are created when the first client joins and destroyed when the last client leaves.
|
||||
|
||||
The only game logic implemented by the server is that of a "master client", which is an easier way to negotiate a leader in a room that can perform room level operations.
|
||||
|
||||
The "group" functionality is used to specify specific clients to communicate with. Note, these client ids can bridge across rooms.
|
||||
|
||||
The server supports both TCP and UDP transports.
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
# Self-hosting the Server
|
||||
|
||||
VelNet's server can be self-hosted with modest resources. The limiting factor will almost always be network bandwidth.
|
||||
|
||||
=== "Option 1: Pull from Docker Hub"
|
||||
|
||||
Make sure you have [Docker](https://www.docker.com/) installed, then pull the Docker image using:
|
||||
|
||||
```sh
|
||||
docker run -p 5000:5000 -p 5000:5000/udp velaboratory/velnet
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```sh
|
||||
docker run -p 5050:5000 -p 5050:5000/udp --name velnet velaboratory/velnet
|
||||
```
|
||||
|
||||
to run on a different port and change the name of the container.
|
||||
|
||||
=== "Option 2: Use docker-compose"
|
||||
|
||||
1. Clone the repo
|
||||
- `git clone https://github.com/velaboratory/VelNetServerRust.git`
|
||||
|
||||
- Make sure you have [Docker](https://www.docker.com/) and [docker-compose](https://docs.docker.com/compose/) installed.
|
||||
|
||||
- The docker compose file runs both the control panel and the server.
|
||||
- To start:
|
||||
```sh
|
||||
docker compose up -d
|
||||
```
|
||||
- To stop:
|
||||
|
||||
```sh
|
||||
docker compose stop
|
||||
```
|
||||
|
||||
|
||||
This builds the images from the local data in the folder, and doesn't pull anything from Docker Hub.
|
||||
|
||||
=== "Option 3: Run Rust natively"
|
||||
|
||||
1. Clone the repo
|
||||
- `git clone https://github.com/velaboratory/VelNetServerRust.git`
|
||||
- Edit `config.json` to an open port on your firewall
|
||||
- Modify the `user` field in `control-panel/config.json` to be your username.
|
||||
- Install rust through using [rustup](https://rustup.rs/)
|
||||
- Install: `sudo ./install.sh`
|
||||
- Run server: `sudo systemctl start velnet`
|
||||
- Run control panel: `sudo systemctl start velnet-control-panel`
|
||||
- Install tuptime: `cargo install tuptime`
|
||||
- Install onefetch: `cargo install onefetch`
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
:root {
|
||||
--md-primary-fg-color: #ba0c2f;
|
||||
--md-primary-fg-color--light: #ffffff;
|
||||
--md-primary-fg-color--dark: #e4002b;
|
||||
--md-primary-bg-color: hsla(0, 0%, 100%, 1);
|
||||
--md-primary-bg-color--light: hsla(0, 0%, 100%, 0.7);
|
||||
|
||||
/* --md-accent-fg-color: #ffffff;
|
||||
--md-accent-fg-color--transparent: #ffffff11;
|
||||
--md-accent-bg-color: hsla(0, 0%, 100%, 1);
|
||||
--md-accent-bg-color--light: hsla(0, 0%, 100%, 0.7); */
|
||||
}
|
||||
[data-md-color-scheme="slate"] {
|
||||
--md-hue: 34;
|
||||
--md-default-bg-color: #191818;
|
||||
}
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
site_name: VelNet Docs
|
||||
site_url: https://docs.velnet.ugavel.com
|
||||
repo_url: https://github.com/velaboratory/VelNetUnity
|
||||
repo_name: velaboratory/VelNetUnity
|
||||
edit_uri: edit/main/Documentation/docs
|
||||
|
||||
theme:
|
||||
name: material
|
||||
features:
|
||||
- content.action.edit
|
||||
- navigation.instant
|
||||
# - navigation.sections
|
||||
- navigation.expand
|
||||
- navigation.path
|
||||
- navigation.indexes
|
||||
- toc.follow
|
||||
- toc.integrate
|
||||
|
||||
palette:
|
||||
scheme: slate
|
||||
primary: custom
|
||||
accent: red
|
||||
# background: custom
|
||||
font: false
|
||||
# text: Oswald
|
||||
# text: Merriweather
|
||||
# text: Merriweather Sans
|
||||
logo: assets/logo.png
|
||||
favicon: assets/logo.png
|
||||
|
||||
plugins:
|
||||
- search:
|
||||
# - social:
|
||||
# cards_layout_options:
|
||||
# font_family: Oswald
|
||||
- git-revision-date-localized:
|
||||
enable_creation_date: true
|
||||
|
||||
markdown_extensions:
|
||||
- attr_list
|
||||
- md_in_html
|
||||
- pymdownx.emoji:
|
||||
emoji_index: !!python/name:materialx.emoji.twemoji
|
||||
emoji_generator: !!python/name:materialx.emoji.to_svg
|
||||
- pymdownx.superfences
|
||||
- pymdownx.tabbed:
|
||||
alternate_style: true
|
||||
|
||||
extra_css:
|
||||
- stylesheets/extra.css
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
mkdocs-material
|
||||
mkdocs-git-revision-date-localized-plugin
|
||||
21
LICENSE
21
LICENSE
|
|
@ -1,21 +0,0 @@
|
|||
MIT License
|
||||
|
||||
Copyright (c) 2022 kjjohnsen
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
31
README.md
31
README.md
|
|
@ -1,31 +0,0 @@
|
|||
# VelNetUnity
|
||||
Custom networking package for Unity
|
||||
|
||||
<img src="velnet_logo.png" width="100" alt="VelNet Logo">
|
||||
|
||||
---
|
||||
|
||||
See [VelNetServerRust](https://github.com/velaboratory/VelNetServerRust) for description of the server.
|
||||
|
||||
By contrast to the server, the Unity side is pretty complex.
|
||||
|
||||
### NetworkManager
|
||||
Deals with instantiating NetworkPlayers, and dealing with join, left, new master client events. Also manages the list of NetworkObjects. It maintains a list of prefabs that can be instantiated, as well as the prefab to use for players.
|
||||
|
||||
### NetworkPlayer
|
||||
One of these will be instantiated for each player that joins the "room". Most application communication happens by calling methods on this object. Voice comms are also handled within this object. Only one NetworkPlayer "isLocal". The others are remote. The local network player is the one that can modify it's "owned" network objects. It also has a special networkobject representing itself (setup within the prefab, not part of the networkmanager list). This is where most of the user behavior is going to go (e.g. an avatar).
|
||||
|
||||
### NetworkObject
|
||||
Something that can be owned by a network player, who is responsible for updating it. Only the owner network player can/should modify a network object, whether locally or in response to a received message from the local version. NetworkObjects are delineated by an session-unique id, which consists of the creator's userid + "-" + an increasing number designated by the creator. Only local NetworkPlayers should send instantiate message, which contain this id. This class should be extended to sync and send messages. Scenes are basically built from NetworkObjects. Scene's can also start with network objects. Those are known by all, and start with "-1-increasing". That should happen the same on all clients, and is done locally at the start of the networkmanager. An example of a NetworkObject is SyncTransform, which is a simple one that keeps an object's position and orientation synchronized.
|
||||
|
||||
### Ownership
|
||||
Ownership of objects changes regularly. Any local networkplayer can send a message to take ownership of a networkid. That client immediately assumes ownership. The message is sent to the network, and will be ordered with any other ownership messages. So, if two clients try to get ownership at the same time, both will assume ownership, but one will happen after the other. This means that the one who was first will quickly lose ownership.
|
||||
|
||||
### Joining
|
||||
An interesting problem is what to do when new clients join. This is partially left up to the developer. Any objects that are instantiated (or scene objects that are deleted) will be automatically handled.
|
||||
|
||||
### Message Groups
|
||||
Clients can manage network traffic using messaging groups. This is especially useful for audio, where you can maintain a list of people close enough to you to hear audio
|
||||
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue