Classic marble game in HTML
The game is quite simple: players go around in a set order, placing marbles of their color onto a board. The goal of the game is to get at least five marbles of your color in a line (vertically, horizontally, or diagonally). As the board gets more and more marbles on it, players have to keep track of more potential wins and decide whether to interfere with them or continue with their own efforts.
Anyone can create a game, with some configurable parameters like board width/height and maximum number of players. Users connect to a created game and communicate with a Socket.io server that tracks game state, storing it in a MongoDB database. The server uses Express and builds its static content (CSS/JS) via Webpack.
The frontend is a ReactJS/Redux web application and uses CSS-in-JS for styling.
The socket server can either be run as a standalone Express application or inline as part of the same server that serves the website. The static content can be served either from a directory on the filesystem that Webpack writes its results into, or via webpack-dev-server (the latter is better for development, as it contains some usefule features like hot module reloading, filesystem watching and linting.
Clone this repo and run npm install from within its root directory.
The application requires a few things at minimum to run correctly. Configuration values are set via a .env file. A sample file with the relevant keys is available at .env.example.
The app uses a MongoDB database to back its sessions, game state, etc. There are a couple of keys in the .env file relevant to the database:
-
CREDENTIALS_DB_URL: this should be a MongoDB connection string uri to the database where the application data is stored (game state, user profiles, etc.) -
SESSION_DB_URL: this should be a connection string to the database where the session data is stored. This can be the same asCREDENTIALS_DB_URL; if it's not specified, it will default to be the same.
The application can be served with or without SSL. To serve it over SSL, specify the following .env variables:
APP_SSL_KEY: a file path to an SSL key fileAPP_SSL_CERT: a file path to an SSL cert file
See here for instructions on how to create self-signed SSL keys and certificates--these are fine for development, but not good for production purposes.
In addition to the SESSION_DB_URL setting, you must also set the SESSION_SECRET setting; this is used to encrypt secure cookies.
"Static content" refers to things like Javascript files, CSS stylesheets, images, sound files, etc. It can be served from the same server that serves the rest of the application, or from a separate server, such as a CDN. If you don't want to bother with that, you can leave the STATIC_CONTENT_URL setting empty. Otherwise, set it to the base URL for your static content server.
The game interactions (players joining, placing marbles, etc.) are done via Websockets, using Socket.IO. The server side component is implemented as a separate sub-app (see /server/apps/socket). This is so that (in theory) the socket app can be run as a separate server (this is currently untested). If you don't want to run it as a separate app, it will be run as part of the HTTP server (you don't need to do anything to enable this). If you run it on a separate server, set the WEB_SOCKETS_URI variable to the root of the socket server (the URL to which to connect the Socket.IO client).
For development purposes, just run npm start with the $NODE_ENV environment variable set to development or not set at all. This will start a server on localhost on the port specified by the $PORT environment variable, defaulting to 4000if not specified. The server includes a Webpack dev server instance that watches for changes to static content and automatically recompiles them and triggers a reload of the browser.
For production purposes, build a production bundle via npm run build and start the server by running npm start with the $NODE_ENV environment variable set to production.
There are some other configuration options you can set in your .env file, including options for logging and social login flows like Facebook and Twitter. For descriptions of these options, look at the example .env file.