Ideas on Optimizing Mining System

Help and Feedback Game Design Support
, ,
1

Hey everyone

I’m working on a mining system and I feel like it could be optimized better as the network bandwidth usage is quite heavy
Right now, whenever a mining object gets hit:

  • The client fires a RemoteEvent to the server.
  • The server checks if the object’s health is <= 0.
  • If it is, the server creates the material drop (ore, crystal, etc.).

This works, but I think it’s heavier than it needs to be.

My first idea for optimization is:

  • The client handles creating the visual materials/drops, this way the server doesn’t need to calculate all the physics, rendering, etc of the material thats been dropped
  • The server will keep the real mined materials in a table so explotiers cannot take advantage of this system

Is there another way to make this system even better? Although this could definitely help the servers side, I feel like having so many connections (possibly hundreds) that run every time an object is mined on the client side could be heavy
Edit: I js remembered my current system isnt based off of connections to to every objects health but when it runs and detects what object the mouse is hovering over when mined

Feel free to give me feedback on a better approach
Thanks everyone

1 Like
2

I’d switch the mining system to a single, low-bandwidth pattern:

Core idea

  • Server stays authoritative over HP and rewards.
  • Client only sends intent at a fixed rate (e.g., 10 Hz), not every frame or hit.
  • One RemoteEvent handles all nodes. No per-object connections.

Flow

  1. Client raycasts to a mineable, reads its MineId attribute, and every 0.1s sends: (MineId, toolPower).
  2. Server validates range/LOS and clamps power. It batches all damage for that frame per node.
  3. Server subtracts HP. When HP ≤ 0, it grants loot directly to inventory and optionally fires a cosmetic “drop FX” to clients. No heavy physics drops.
  4. Server only replicates HP on coarse steps (e.g., every 10% change) to keep traffic low.

Why this is lighter

  • Fixed-rate intents cap bandwidth. No spam per swing.
  • One remote instead of hundreds of connections.
  • Server batching = fewer messages and less work.
  • Virtualized drops remove physics and replication cost; visuals are client-only.

Anti-exploit

  • Validate player-to-node distance (e.g., ≤20 studs) and line-of-sight.
  • Token-bucket throttle per player (e.g., max 10 intents/sec).
  • Damage clamp (e.g., 0–50).
  • Nodes are tagged with CollectionService + MineId attributes so the server controls the registry.

This keeps the server in control, cuts network usage, and scales to many nodes without per-object listeners.