Table of Contents
This chapter aims to outline key issues that BigWorld has identified from experience with many customers as being important for consideration prior to your game's launch. Ideally this list would be constantly reviewed during the development process to keep focused on reducing the impact of last minute potentially critical issues.
-
Ensure that the LoginApp private key (
bigworld/res/server/loginapp.privkey
) is not distributed in your game client packages.See the Server Programming Guide's chapter Encrypting Client-Server Traffic section Generating your own RSA keypair.
-
Distributed resources have been packed with
res_packer
. -
Ensure that
.py
files are not in release package, only distribute.pyc
. -
Pre-compile shaders for supported video cards if desired.
-
Python console should be disabled.
-
CAT access is disabled.
-
Cheat modes have been disabled.
-
Packaged binary is a Consumer Release executable build.
-
Bot tests have been run.
See Testing with Bots.
-
All unnecessary development script log messages have been removed.
-
MessageLogger log profiling has been done to ensure log sizes don't grow beyond the capacity of the server tools storage.
-
Generate a custom LoginApp public keypair.
See the Server Programming Guide's chapter Encrypting Client-Server Traffic section Generating your own RSA keypair.
-
Profile entity sizes and estimate bandwidth usage.
-
Test deployment hardware for packet loss and memory usage.
-
All modified BigWorld server settings are located in
to enable better isolation of changes between your game settings and BigWorld default settings.your_game
/res/server/bw.xml -
Default BigWorld server settings have been changed from development defaults to production defaults.
See the
<parentFile>
setting in the file
.your_game
/res/server/bw.xml -
<hasDevelopmentAssertions>
set to false.See the Server Operations Guide's section General Configuration Options.
-
<dbMgr/type>
set to mysql.See the Server Operations Guide's section DBMgr Configuration Options.
-
Customised values based on development load testing and extrapolated resource usage for desired production environment for the options,
<cellAppMgr/cellAppLoadLowerBound>
and<cellAppMgr/cellAppLoadUpperBound>
.See the Server Operations Guide's section CellAppMgr Configuration Options.
-
Customised
<balance/maxCPUOffload>
.See the Server Operations Guide's section Load Balancing Configuration Options.
-
Revivers are being used.
See the Server Operations Guide section Fault Tolerance with Reviver.
-
Smoothing server load during startup.
-
bwmachined
versions are consistent within the cluster. -
Game update procedures are in place.
-
Computer hardware is sufficient.
-
Network hardware and capacity is sufficient.
-
Network interfaces have appropriate buffer sizes.
-
MySQL database correctly configured.
See the Server Installation Guide's chapter Simple Installation, section Installing, Configuring and Starting MySQL.
-
Firewalls have been correctly configured.
See the Server Installation Guide's chapter Cluster Configuration, section Security.
-
Only publicly facing machines can run LoginApps and BaseApps.
-
Log rotation is in place for all server machines.
-
BigWorld server tools are operational.
-
Cluster access has been locked down to authorised people only.
-
An appropriate BigWorld server layout is in place for starting cluster.
-
DNS round-robin in place for LoginApp load balancing.
See the Server Operations Guide's chapter BigWorld Server Across Multiple Machines, section LoginApp and Scalability.
-
Unnecessary services disabled on servers.
-
Servers are running in runlevel 3.
-
Disabled unnecessary cron jobs.
See the Server Installation Guide's chapter Cluster Configuration, section Disabling cron jobs.
-
Revivers are being used.
See the Server Operations Guide's chapter Fault Tolerance, section Fault Tolerance with Reviver.
-
Server tools have a dedicated machine.
-
Machines running BaseApp and LoginApp processes should have at least 2 network interfaces.
This will ensure that the internal network and the external network traffic is kept isolated and will help reduce overall network congestion.
-
Ensure there is a procedure in place to allow access to / send core dumps and server binaries to BigWorld for debugging.
-
Ensure there is a procedure in place to provide BigWorld support access to the cluster for debugging.
-
Ensure there is a procedure for accessing logs and sending them to BigWorld for debugging.
-
BigWorld server binaries being used are up-to-date and completely patched.
-
MySQL machine has adequate hard disk capacity.
Following standard best practice to ensure that the database data directory datadir as specified in the MySQL configuration file (by default
/etc/my.cnf
) exists on a separate drive / partition to the primary operating system installation will allow the ability to scale the size of the MySQL database as required using LVM / RAID or other appropriate solution.