game engine to pair

[dawidmachon]

Hello, I would like to ask as I saw your blog entry. What stack curently you would advise in rust to go for multiplayer, aauthorative small game with heavy ui and 2d gameloop.

[TheRedDeveloper]

That's like exactly the type of game I'm making 🤣

It's called Stratum. You can actually play a small singleplayer demo I made for my university application (a month ago) over here: https://thereddeveloper.github.io/CGLPortfolio/demo

So of course the client is made entirely with ply-engine. For the server:

I'm starting on a cheap VPS, but I've already implemented fly.io support if I need to scale, for which I have this function:

pub async fn allocate_machine(db: &Database) -> Result<String, String> {
  if !is_on_flyio() {
    return Ok(get_machine_id());
  }

  match get_flyio_machines().await {
    Ok(machines) => {
      if machines.is_empty() {
        log::error!("Not even this machine exists, what the fuck, where are all the machines?");
        return Err("no_flyio_machines".to_string());
      }
      let mut machine_counts: Vec<(String, u32)> = Vec::new();
      for machine in &machines {
        match db.matches_on_machine(machine).await {
          Ok(count) => machine_counts.push((machine.clone(), count)),
          Err(e) => {
            log::warn!("Failed to get match count for {}: {}", machine, e);
          }
        }
      }
      machine_counts.sort_by_key(|m| m.1);
      for (machine, _) in machine_counts {
        if let Ok(true) = is_alive(machine.clone()).await {
          return Ok(machine);
        }
      }
      log::error!("All machines are unhealthy!!!!!!!!!!");
      Err("all_machines_unhealthy".to_string())
    }
    Err(e) => {
      log::error!("Failed to get machines: {}", e);
      return Err(format!("failed_to_get_machines/{}", e));
    }
  }
}

I'm using docker-compose with postgres:latest and my own Dockerfile.

My Dockerfile builds on rustlang/rust:nightly and runs on debian:bookworm-slim.

For the API I'm using actix with actix-web and with actix-web-actors for the websockets.

For the Database I'm using sqlx. While it can sometimes have issues, it's great to have the reassurance that sqlx::query! gives you.

I have a single file db.rs, that does all the database stuff:

pub struct Database {
  pool: PgPool // DO NOT MAKE THIS PUBLIC. ALL SQL MUST BE IN THE impl BELOW.
}
impl Database {

This lets me keep it out of my actual code and reuse it.

I have a create_db.sql that makes sure the database exists, and I link that up in docker compose with ./src/create_db.sql:/docker-entrypoint-initdb.d/init.sql.

Some other interesting dependencies I have in there might be env_logger, blake3 and my own ed25519fast (hopefully releasing soon).

[dawidmachon]

Many thanks for this and your work . Still some questions. Why actix? Do you aim web mostly that's why websocket? How that will scale for you for concurency users? If you would need.authorative movement handled too, still websocket? UDP, was you thinking about it?

So Ply is aimed to be more like ui tool or full engine for apps/games? Aiming for front client part only or server stuff too?

[TheRedDeveloper]

Yeah, web is the main reason for WebSockets. UDP doesn't run in the browser and isn't supported by ply-engine. actix also handles both HTTP and WS in one place, which is really convenient, since the server does a lot of HTTP stuff too. It's baked in directly and you can use HTTPS/WSS for security.

The scaling is like way overboard for me. actix is fundamentally async and loads can be spread across servers allowing for as many players as the database can handle. If you manage your database correctly, that's a ludicrous amount. The server is not the issue here.

On authoritative movement over WebSocket: for Stratum it's totally fine. If I were building something with fast-paced movement sync I'd consider UDP, but the extra complexity of handling packet loss, reordering and NAT traversal isn't worth it unless you genuinely need sub-30ms input response. For most 2D multiplayer games, WebSocket is genuinely good enough and much much easier to get right.

Ply is a full client-side engine.