Aims to recreate Marble Racing from the ground up, as a fully web based game
Branch: master
Clone or download
Latest commit dfc1730 Nov 10, 2018
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
public Flycam documentation + more features, cleanup editor render.js Sep 2, 2018
src/model-import 1:1 mapping of visible and physics world May 1, 2018
templates Separation of fly camera controls (WIP) Aug 30, 2018
.gitignore Basic chat functionality Aug 18, 2018
LICENSE Initial commit Apr 13, 2018
README.md Added image to readme May 12, 2018
config.example.js Basic chat functionality Aug 18, 2018
credits.txt Map uses UVs & has initial textures / materials May 5, 2018
package-lock.json Updated package file Nov 10, 2018
package.json Updated package file Nov 10, 2018
web-marbles.js

README.md

web-marbles

Cinematic shot of the environment so far

Aims to recreate Marble Racing from the ground up, as a fully web based game. The goal is to make it cost-effective, being able to run it on a relatively low-cost server leaving all rendering to the client. Inspired by the original Marble Racing Twitch game:

This project is very much a work in progress.

Project configuration

You can easily configure the game settings by tweaking the values in config.js.

nginx configuration

To make sure websockets work when using nginx, add the following to your location / section:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;

Concept

To keep server load to a minimum, all it does is handle basic game logic and the physics simulation. It runs the physics simulation locally and sends over the resulting data to all the clients. Only positions and rotations of the marbles have to be synced real-time, other data can be pre-loaded and generated based on RPCs.

Limitations

Since there is no simple UDP API / standard for the web yet, we are limited to TCP only. This means our packets will quickly clog the websocket if the client's internet is too slow or unstable. I've built around this by limiting the amount of packet requests that can be done, but it's not comparable to proper UDP.

Additionally, when there are many marbles to sync, this will significantly stress the network. This is a problem for both the server and the client as bandwidth is limited. This is likely to be the biggest issue with this implementation, so a lot of care will be put in optimizing and minimizing network impact.

Downloading assets can be costly when it comes to bandwidth, and should probably be done from a different server, ideally by a CDN. This reduces the impact on the real-time connections of the game server.

Since the client has to render their own scene, I won't be able to guarantee the same level of visual fidelity for every client.

Advantages

Since the client has to render their own scene, they can completely independently pick their own camera angles. Even so, a shared camera is still possbile through identical tracking algorithms.

Only the physics run on the server which are relatively resource efficient. My $5 DigitalOcean VPS handles it nicely up to at least 100 marbles. Slowdowns do happen with more marbles, but it keeps on going nonetheless.

Disclaimers

During the first phases of this project I will not be focusing on clean code too much. This is very much a learning project for me, and will only later accept pull requests, after I cleaned up the codebase.