SOLUTIONS / GAMING
Real-time sessions, player accounts and content delivery are different workloads. When evaluating FibaCloud products, consider engine behaviour, player connectivity and persistent data together. Validate capacity with representative game sessions rather than relying on a player count taken from another project.
01 / Overview
Server capacity is not determined by RAM alone. Simulation rate, plugins, maps, engine design and single-thread usage all matter. Low average CPU utilization does not necessarily mean that the critical simulation loop has spare capacity.
Separate session servers from persistent services such as accounts, inventories and saves. Assess region and network choices from the networks your players use. This guidance does not promise a fixed player capacity, latency or immunity to DDoS attacks.
Measure engine CPU and memory behaviour. Compare shared and dedicated CPU options for sessions that run sustained processing loads.
Assess latency and packet loss from player networks. Server location alone does not determine the quality of every connection.
Identify records that must survive the end of a session. World files, inventories and account data may have different recovery requirements.
02 / Architecture
Example architecture: real-time sessions and persistent player data are separate layers. Protocols, engine behaviour and capacity depend on the project.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| Processing model | Measure single-thread and multi-thread behaviour in realistic sessions. | Resource selection reflects the engine’s actual constraint. |
| Player connectivity | Assess latency, loss and stability on target player networks. | A nearby region may behave differently across networks. |
| Persistent records | Define save frequency and acceptable recovery loss. | Progress after a session restart has a clear recovery target. |
| Version management | Plan client, server and plugin compatibility together. | You can assess how updates affect connections and world data. |
04 / Use cases
Test representative maps, plugins and concurrent players. Review simulation-loop delays separately from total CPU utilization.
Plan consistency for accounts, statistics and inventory. These services may need a different resource balance from session servers.
Try releases and plugin changes in a separate environment. Keep test worlds apart from live player progress.
05 / From planning to operation
List the engine, modifications, persistent data and player access patterns. Make test scenarios representative.
Observe CPU, memory, disk and networking in a small test setup. Do not reuse another game’s results as your own.
Preserve world data and configuration before upgrading. Check whether returning to an older release remains compatible with saved data.
Observe session failures, successful saves and resource use. Coordinate planned restarts with player communication.
A reliable answer requires the game, maps, modifications and concurrent activity. Measure the selected configuration with representative sessions.
It may suit some development or variable-load scenarios. For sustained CPU-intensive sessions, test Dedicated CPU or Bare Metal options against the workload.
No. Player providers, routes, packet loss and congestion also matter. Measure from the networks your intended players use.
That depends on scope and save consistency. Use the game’s appropriate save procedure and verify recovery of world and account data.
Connect product decisions with installation, configuration and operating knowledge.
These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.
FIBACLOUD / Gaming
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.
