battle_srv | ||
charts | ||
collider_visualizer | ||
database/skeema-repo-root | ||
dnmshared | ||
dragonBonesProjects | ||
frontend | ||
jsexport | ||
nginx-templates | ||
resolv_tailored | ||
.gitattributes | ||
.gitignore | ||
ConcerningEdgeCases.md | ||
MULTIHIT_ROADMAP.md | ||
proto_gen_shortcut.sh | ||
README.md |
Preface
This project is a demo for a websocket-based rollback netcode inspired by GGPO. As lots of feedbacks ask for a discussion on using UDP instead, I tried to summarize my personal opinion about it in ConcerningEdgeCases -- not necessarily correct but that's indeed a question to face :)
The following video is recorded over INTERNET using an input delay of 4 frames and it feels SMOOTH when playing! Please also checkout these demo videos
- source video of the first gif
- phone v.s. PC over internet battle#1
- phone v.s. PC over internet battle#2
to see how this demo carries out a full 60fps synchronization with the help of batched input upsync/downsync for satisfying network I/O performance.
All gifs are sped up to ~1.5x for file size reduction, kindly note that animations are resumed from a partial progress!
Notable Features
- Backend dynamics toggle via Room.BackendDynamicsEnabled
- Recovery upon reconnection (only if backend dynamics is ON)
- Automatically correction for "slow ticker", especially "active slow ticker" which is well-known to be a headache for input synchronization
- Frame data logging toggle for both frontend & backend, useful for debugging out of sync entities when developing new features
(how input delay roughly works)
(how rollback-and-chase in this project roughly works, kindly note that by the current implementation, each frontend only maintains a lastAllConfirmedInputFrameId
for all the other peers, because the backend only downsyncs all-confirmed inputFrames, see markConfirmationIfApplicable for more information -- if a serverless peer-to-peer communication is seriously needed here, consider porting markConfirmationIfApplicable into frontend for maintaining lastAllConfirmedInputFrameId
under chaotic reception order of inputFrames from peers)
(By use of GopherJs, the frontend codes for dynamics are now automatically generated)
1. Building & running
1.1 Tools to install
Backend
- Command Line Tools for Xcode (on OSX) or TDM-GCC (on Windows) (a
make
executable mandatory) - Golang1.18.6 (brought down to 1.18 for GopherJs support, mandatory, in China please try a mirror site like that of ustc)
- GopherJs1.18.0-beta1 (optional, only for developemnt)
- MySQL 5.7 (mandatory, for OSX not all versions of 5.7 can be found thus 5.7.24 is recommended)
- Redis 3.0.503 or above (mandatory)
- skeema (optional, only for convenient MySQL schema provisioning)
- protobuf CLI (optional, only for development)
Frontend
- CocosCreator v2.2.1 (mandatory, ONLY AVAILABLE on Windows or OSX and should be exactly this version, DON'T use any other version because CocosCreator is well-known for new versions not being backward compatible)
- protojs (optional, only for development)
1.2 Provisioning
Backend/Database
It's strongly recommended that skeema
is used for provisioning the required schema in MySQL instance. When using skeema
the steps are as follows.
### Mandatory after an initial clone
user@proj-root/database/skeema-repo-root> cp .skeema.template .skeema
### Mandatory
user@proj-root/database/skeema-repo-root> skeema push
On Windows 10/11
, you can compile skeema
from source and config the host to be 127.0.0.1
instead of localhost
to use it, i.e. circumventing the pitfall for MySQL unix socket connection on Windows.
Backend/Golang
user@proj-root/battle_srv/configs> cp -r ./configs.template ./configs
Frontend
user@proj-root/frontend/assets/plugin_scripts> cp ./conf.js.template ./conf.js
1.2 Actual building & running
Backend
### The following command runs mysql-server in foreground, it's almost NEVER run in such a way, please find a proper way to run it for yourself
user@anywhere> mysqld
### The following command runs redis-server in foreground, it's OK to put it in background
user@anywhere> redis-server
### on Windows using TDM-GCC: mingw32-make run-test
user@proj-root/battle_srv> make run-test
Frontend
The easy way is to try out 2 players with test accounts on a same machine.
- Open CocosCreator v2.2.1 (mandatory, it serves the web content of the following steps)
- Open one browser instance, visit http://localhost:7456?expectedRoomId=1, input
add
on the username box and click to request a captcha, this is a test account so a captcha would be returned by the backend and filled automatically (as shown in the figure below), then click and click to proceed to a matching scene. - Open another browser instance, visit http://localhost:7456?expectedRoomId=1, input
bdd
on the username box and click to request a captcha, this is another test account so a captcha would be returned by the backend and filled automatically, then click and click to proceed, when matched abattle
(but no competition rule yet) would start. - Try out the onscreen virtual joysticks to move the cars and see if their movements are in-sync.
2 Troubleshooting
2.1 Redis snapshot writing failure
ErrFatal {"err": "MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error."}
Just restart your redis-server
process.