RustCycles is a FOSS third person multiplayer arena shooter that's about movement, not aim. You have to be smart and think fast.

This is just barely a prototype. There's no real gameplay yet, just basic physics and some networked projectiles.

RustCycles is developed in lockstep with RecWars. Even though they are very different, built on different engines, they share the general architecture. Ideas are tested in one game, then ported to the other.

The ultimate goal is to create a fully moddable multiplayer game playable in the browser and natively on Linux, Windows and macOS. RecWars is built in the spirit of everlasting games.

Currently RustCycles is the only open source Fyrox game which uses networking. If you're also writing a multiplayer game in Fyrox, feel free to ping me on Fyrox's or RustCycles' discord to exchange notes and ideas.

Multiplayer shooters are large and complex projects and 80% of the code is not game specific. I am looking to collaborate with anyone making a similar game. The plan is to identify generic parts and build RustCycles into a FPS-specific Fyrox "subengine" that provides a solid foundation for first/third person shooters so everyone can focus on the parts that make their game unique.

There are no prebuilt binaries and no web version yet, you have to build the game yourself.

• RustCycles uses git submodules for its assets. To clone the repo, use git clone --recurse-submodules git@github.com:rustcycles/rustcycles.git. If you have already cloned it without submodules, use git submodule update --init --recursive.

• If on linux, install dependencies (debian example): sudo apt install libasound2-dev libudev-dev pkg-config xorg-dev libxcb-shape0-dev libxcb-xfixes0-dev libxkbcommon-dev libfontconfig1-dev

• After that, just use cargo run.
  • No need to use --release it should run fast enough in debug mode because deps are optimized even in debug mode (see Cargo.toml).

Currently using git submodules for assets because GitHub's LFS has a tiny 1 GB per month bandwidth limit that's not sufficient already with just a couple MB of data and won't scale. Committing assets into the main repo would cause its size to grow irreversibly. A separate repo as a submodule allows us to keep the main repo small without overwriting history. The data repo can then be either squashed or replaced with a fresh one if the history gets too large.

You can make the game compile significantly faster and iterate quicker:

• Run this in project root: ln -s rust-toolchain-example.toml rust-toolchain.toml; cd .cargo; ln -s config-example.toml config.toml; cd -
• Reduction from 12 s to 2.5 s

If you're using RA with clippy instead of check, add this to your VSCode config (or something similar for your editor):

"rust-analyzer.server.extraEnv": {
    "CARGO_TARGET_DIR": "target/ra"
}

Explanation: Normally, if rust-analyzer runs cargo clippy on save, it locks target so if you switch to a terminal and do cargo run, it blocks the build for over a second which is currently a third of the build time. This will make rust-analyzer make use a separate target directory so that it'll never block a build at the expense of slightly more disk space (but not double since most files don't seem to be shared between cargo and RA). Alternatively, you could disable saving when losing focus, disable running check on save or use the terminal inside VSCode to build RustCycles.

• ~/your/path/to/mold -run cargo build
• Reduction from 2.5 s to 2.3 s
• Might not be worth it for now (you need to compile it yourself), maybe when the game gets larger

Enable extra checks before every commit: copy/symlink pre-commit-example to pre-commit and run git config core.hooksPath git-hooks. It gets checked on CI anyway, this just catches issues faster.

AGPL-v3 or newer