Merge pull request #169 from garryod/docs-0.6

Docs updates ahead of 0.6

README.md

@@ -1,4 +1,4 @@
-# [![Matchbox](matchbox_logo.png)](https://github.com/johanhelsing/matchbox)
+# [![Matchbox](https://raw.githubusercontent.com/johanhelsing/matchbox/main/images/matchbox_logo.png)](https://github.com/johanhelsing/matchbox)
 
 [![crates.io](https://img.shields.io/crates/v/matchbox_socket.svg)](https://crates.io/crates/matchbox_socket)
 ![MIT/Apache 2.0](https://img.shields.io/badge/license-MIT%2FApache-blue.svg)
@@ -10,15 +10,20 @@ Painless peer-to-peer WebRTC networking for rust's native and wasm applications.
 The goal of the Matchbox project is to enable udp-like, unordered, unreliable
 p2p connections in web browsers or native to facilitate low-latency multiplayer games.
 
-- [Introductory blog post](https://johanhelsing.studio/posts/introducing-matchbox)
+|  Channel   | Ordered | Unordered |
+| ---------- | ------- | --------- |
+| Reliable   | ✓ | ✓   |
+| Unreliable | ✓ | ✓   |
+
 - [Tutorial for usage with Bevy and GGRS](https://johanhelsing.studio/posts/extreme-bevy)
 
 The Matchbox project contains:
 
-- A socket abstraction, [matchbox_socket](https://github.com/johanhelsing/matchbox/tree/main/matchbox_socket)
-  - With a feature, `ggrs` for providing a [ggrs](https://github.com/gschup/ggrs) compatible socket.
-- A tiny signaling server, [matchbox_server](https://github.com/johanhelsing/matchbox/tree/main/matchbox_server). Written in rust, uses only a couple of megabytes of memory. Also available as a docker image. Compatible with all demos.
-- A signaling server API, [matchbox_signaling](https://github.com/johanhelsing/matchbox/tree/main/matchbox_signaling). For DIY signaling servers and hookable callbacks, this may be useful if you plan a complicated matchmaking procedure.
+- [matchbox_socket](https://github.com/johanhelsing/matchbox/tree/main/matchbox_socket): A socket abstraction for Wasm or Native, with:
+  - `ggrs`: A feature providing a [ggrs](https://github.com/gschup/ggrs) compatible socket.
+- [bevy_matchbox](https://github.com/johanhelsing/matchbox/tree/main/bevy_matchbox): A `matchbox_socket` integration for the [Bevy](https://bevyengine.org/) game engine
+- [matchbox_signaling](https://github.com/johanhelsing/matchbox/tree/main/matchbox_signaling): A signaling server library, with ready to use examples
+- [matchbox_server](https://github.com/johanhelsing/matchbox/tree/main/matchbox_server): A ready to use full-mesh signalling server
 
 ## Examples
 
@@ -29,20 +34,22 @@ The Matchbox project contains:
 
 ## How it works
 
+![Connection](https://raw.githubusercontent.com/johanhelsing/matchbox/main/images/connection.excalidraw.svg)
+
 WebRTC allows direct connections between peers, but in order to establish those connections, some kind of signaling service is needed. `matchbox_server` is such a service. Once the connections are established, however, data will flow directly between peers, and no traffic will go through the signaling server.
 
 The signaling service needs to run somewhere all clients can reach it over http or https connections. In production, this usually means the public internet.
 
 When a client wants to join a p2p (mesh) network, it connects to the signaling service. The signaling server then notifies the peers that have already connected about the new peer (sends a `NewPeer` event).
 
-Peers then negotiate a connection through the signaling server. The initiator sends an "offer" and the recipient responds with an "answer." Once peers have enough information relayed, a WebRTCPeerConnection is established for each peer, which comes with a data channel.
+Peers then negotiate a connection through the signaling server. The initiator sends an "offer" and the recipient responds with an "answer." Once peers have enough information relayed, a [RTCPeerConnection](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection) is established for each peer, which comes with one or more data channels.
 
 All of this, however, is hidden from rust application code. All you will need to do on the client side, is:
 
 - Create a new socket, and give it a signaling server url
 - `.await` the message loop future that processes new messages.
-  - If you are using Bevy, it can be spawned as a Bevy io task (see the [`bevy_ggrs`](examples/bevy_ggrs/) example).
-  - If you are using WASM, `wasm-bindgen-futures` can help (see the [`simple`](examples/simple/)).
+  - If you are using [Bevy](https://bevyengine.org), this is done automatically by `bevy_matchbox` (see the [`bevy_ggrs`](examples/bevy_ggrs/) example).
+  - Otherwise, if you are using WASM, `wasm-bindgen-futures` can help (see the [`simple`](examples/simple/)).
   - Alternatively, the future can be polled manually, i.e. once per frame.
 
 You can hook into the lifecycle of your socket through the socket's API, such as connection state changes. Similarly, you can send packets to peers using the socket through a simple, non-blocking method.