No description
  • Rust 99.3%
  • Shell 0.7%
Find a file
2022-10-30 16:46:07 +02:00
certs Generate TLS certs for testing 2022-10-23 04:50:56 +03:00
client Fix misc issues spotted while perf testing 2022-10-30 04:12:31 +02:00
common Add docs for the server module 2022-10-27 04:18:42 +03:00
server Fix misc issues spotted while perf testing 2022-10-30 04:12:31 +02:00
.gitignore Add a .tmx loader, a .tmx map, tweak various parts 2022-10-26 04:25:04 +03:00
Cargo.lock Update docs 2022-10-27 02:24:37 +03:00
Cargo.toml Sketch out game logic architecture 2022-10-03 21:02:39 +03:00
LICENSE Update docs 2022-10-27 02:24:37 +03:00
README.md Tweak the README some more 2022-10-30 16:46:07 +02:00

Unnamed multiplayer game

This is the repository for an unnamed game built for the Networked Systems and Services course at the University of Helsinki. The game follows a client-server architecture, that is, a server is hosted somewhere, and clients can connect to it and play in a shared world. The traditional MMO model. This repository is split into three main parts:

  • client/: Contains the client-side code, and is split into two binaries: a graphical client, and a bot client for running some automatically controlled player characters in the world. The clients rely on the server to run the game, and get information about their characters' surroundings over the wire.
  • server/: Contains the server-side code, i.e. server-side parts of the gameplay code, and always has the whole game world loaded.
  • common/: Contains code that's shared by the client and server: the gameplay communication protocol implementation, data types for describing game state, and gameplay features that are also used client-side (i.e. deterministic simulation parts).

Documentation

For an implementation-oriented overview of the modules, see the API documentation which covers all of the public interfaces, as well as every function and type in the clients: client, server, common.

These docs can be built locally by running cargo doc in this repository. The results can then be found in the target/doc directory, e.g. target/doc/client/index.html.

Status of the project

The planned networking parts are entirely done and working. The parts of the project that did not end up being implemented are:

  • Gameplay features. Currently players can hop around the world, but there's nothing to do. I had reserved this for the last, as it it the part that is least related to networking, and it turned out that I did not have time to implement any.
  • Parallellization. The game was architected to make it trivial to parallellize game logic and ideally any message handling as well, but none of this has been implemented, the game loop of the server is entirely single-threaded.

License

This game is available under the GNU AGPLv3 license.

The game uses Kenney's public domain assets for the graphics, and the graphical client uses SDL2 which is available under the zlib license.

The Rust dependencies (including transitive dependencies) are used under various licenses compatible with the AGPL, listed here per-license (list generated by cargo-license, slightly edited to group them better):

  • MIT: unicode-ident, adler, wasi, rustls, sct, ahash, android_system_properties, anyhow, autocfg, bitflags, bumpalo, cc, cfg-if, chrono, core-foundation-sys, crc32fast, cxx, cxx-build, cxxbridge-flags, cxxbridge-macro, flate2, getrandom, hashbrown, hermit-abi, iana-time-zone, iana-time-zone-haiku, js-sys, lazy_static, libc, link-cplusplus, log, num-integer, num-traits, once_cell, png, ppv-lite86, proc-macro2, quote, rand, rand_chacha, rand_core, roxmltree, scratch, serde, serde_derive, stderrlog, syn, thread_local, time, ttf-parser, unicode-width, version_check, wasm-bindgen, wasm-bindgen-backend, wasm-bindgen-macro, wasm-bindgen-macro-support, wasm-bindgen-shared, web-sys, winapi, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, xmlparser, miniz_oxide, atty, bincode, fontdue, fontdue-sdl2, sdl2, sdl2-sys, spin, version-compare, termcolor, winapi-util
  • ISC: untrusted
  • BSD-3-Clause: snap
  • Apache-2.0: codespan-reporting
  • Custom License File: ring, webpki

Note that the sdl2 and sdl2-sys entries listed within the Rust libraries refer to the Rust bindings of SDL2, not SDL2 itself, which is zlib, as previously mentioned.

Building

The game is, by far, easiest to build and run on Linux, but can be built for Windows and MacOS as well. Since the game is written in Rust, all of them require the Rust toolchain to be installed. Note for the rest of the readme: 'crate' is the Rust ecosystem's term for a library.

Linux

Simply install the SDL2 development packages for your distribution (libsdl2-dev for Ubuntu and Debian, SDL2-devel for Fedora, sdl2 for Arch), and build the game like any other Rust program:

cargo build --release

This will build the server and client binaries into the following paths:

Windows, method 1

Install the SDL2 development libraries as instructed in the sdl2 crate's README (note: the link is to the MSVC guide, if you installed the GNU version of the Rust toolchain, scroll down to "Windows (MinGW)"). After the development libraries are installed, run:

cargo build --release

Which will build the server and client binaries into:

Note that to run sdl_client.exe, you need to copy SDL2.dll to the same directory. It's included in the development libraries, under the "dll" directory, next to "lib", where you had to copy the development libraries from.

Windows, method 2

If you have the MSVC version of the Rust toolchain, as well as CMake and the C compiler toolchain installed from the Visual Studio Installer, you can launch the Visual Studio development prompt and build SDL2 on the spot with the following features:

cargo build --release --features "bundled static-link"

This will build SDL2 using MSVC, and statically link it into the resulting sdl_client.exe, which also means that you don't need SDL2.dll next to it. The resulting binaries are in the same paths as in method 1.

MacOS

I have the least experience in building on MacOS, but installing the SDL2 dependency as described in the sdl2 crate's README should work. Aside from that, the rest should be identical to the Linux instructions.

Running the game

Since this is just a course project, the game server isn't being hosted anywhere public. The repository is set up with testing certificates to allow you to simply run your own server, and connect to it. To play the game:

  1. Execute the server binary, and leave it running.
  2. Run sdl_client. This should open up a new window showing the game world, and a notification in the top-left corner for a few seconds, reading "Connected to the server!"
    • The game doesn't contain much gameplay, but you can move around using WASD, HJKL, and the arrow keys, depending on your preference.
  3. If you want to see some other players in the game, you can run the bot_client executable (a CLI program like the server) to simulate other players. For 100 bots, you'd run the following:
    bot_client 100
    

TLS certificates

The initial connection to the game server is done over TLS, for which the server and certificate-authority private keys and certificates are included in the certs/ directory. The appropriate files are built into the server and client binaries. The server gets the server private key and certificate, and the client gets the certificate authority certificate.

It should go without saying, but the certificates and keys included within this repository are not secure at all, as they are publicly shared. If this game were to be distributed as a real game, these certs should be replaced with new ones, and they shouldn't be committed into the repository. The server binaries should be kept secret as well, since anyone who gets their hands on them could impersonate the real server, TLS-wise.