8 releases

0.17.1 Aug 30, 2024
0.17.0 Aug 17, 2024
0.16.4 Aug 2, 2024
0.16.3 Jul 14, 2024
0.15.1 May 16, 2024

#1036 in Game dev

Download history 88/week @ 2024-07-29 10/week @ 2024-08-05 137/week @ 2024-08-12 13/week @ 2024-08-19 130/week @ 2024-08-26 8/week @ 2024-09-02 15/week @ 2024-09-16 14/week @ 2024-09-23 5/week @ 2024-09-30 1/week @ 2024-10-07 2/week @ 2024-10-14

547 downloads per month

MIT/Apache

2MB
37K SLoC

Examples

This folder contains various examples that showcase various lightyear features.

Easy

  • simple_setup: minimal example that just shows how to create the lightyear client and server plugins
  • simple_box: example that showcases how to send inputs from client to server, and how to add client-prediction and interpolation

Medium

  • replication_groups: example that shows how to replicate entities that refer to other entities (e.g. they have a component containing an Entity id). You need to use ReplicationGroup to ensure that the those entities are replicated in the same message
  • interest_management: example that shows how to use interest management to only replicate a subset of entities to each player, via the VisibilityManager and the RoomManager
  • client_replication: example that shows how to replicate entities from the client to the server. (i.e. the client has authority)
  • priority: example that shows how to manage bandwidth by enabling priority accumulation. Messages will be sent in order of their priority.

Advanced

  • xpbd_physics: example that shows how to replicate a physics simulation using xpbd. We also use the leafwing feature for a better way to manage inputs.
  • spaceships: more advanced version of xpbd_physics with player movement based on forces, fully server authoritative, predicted bullet spawning.
  • bullet_prespawn: example that shows how to spawn player-objects on the Predicted timeline. This is useful to avoid having to wait a full round-trip before the object is spawned.
  • auth: an example that shows how a client can get a ConnectToken to connect to a server
  • lobby: an example that shows how the network topology can be changed at runtime. Every client can potentially act as a host for the game (instead of the dedicated server).

Running an example

Each example runs in a similar way.

There are different 'modes' of operation:

  • as a dedicated server with cargo run -- server
  • as a listen server with cargo run -- client-and-server. This will launch 2 independent bevy apps (client and server) in separate threads. They will communicate via channels (so with almost 0 latency)
  • as a listen server with cargo run -- host-server. This will launch a single bevy app, where the server will also act as a client. Functionally, it is similar to the "client-and-server" mode, but you have a single bevy World instead of separate client and server Worldss.

Then you can launch clients with the commands:

  • cargo run -- client -c 1 (-c 1 overrides the client id, to use client id 1)
  • cargo run -- client -c 2

You can modify the file assets/settings.ron to modify some networking settings.

Testing in wasm with webtransport

NOTE: I am using trunk to build and serve the wasm example.

To test the example in wasm, you can run the following commands: trunk serve

You will need a valid SSL certificate to test the example in wasm using webtransport. You will need to run the following commands:

  • cd "$(git rev-parse --show-toplevel)" && sh examples/certificates/generate.sh (to generate the temporary SSL certificates, they are only valid for 2 weeks)
  • cargo run -- server to start the server. The server will print out the certificate digest (something like 1fd28860bd2010067cee636a64bcbb492142295b297fd8c480e604b70ce4d644)
  • You then have to replace the certificate digest in the assets/settings.ron file with the one that the server printed out.
  • then start the client wasm test with trunk serve

Dependencies

~54–98MB
~1.5M SLoC