This repository holds the TypeScript code for the server. There is a separate repository for the client code.
It includes the API routes which handle authentication, friending, and potential future systems like clubs or group chats.
It also includes the Socket.IO server handlers and the game engine.
| Name | Description |
|---|---|
| core | The core modules of the server, contain logic swappable between APIs |
| auth | Authentication and signup handling |
| db | Database interfacing and models |
| games | Game logic and networking |
| live | Socket management and networking |
| routes | REST API routes for friending and authentication |
| utils | Utility functions for debugging and storing configuration |
The game server uses TypeScript, Express.JS, MongoDB with Mongoose, and Socket.IO as its primary dependencies.
It uses Winston for logging.
This stack allows the server to clearly separate its live and REST routes and promotes rapid but stable development.
Using the core structure, new games and features can be added without extensively modifying existing code.
When the user first opens the website, it prompts them to log in or make an account.
The authentication module handles this process and all of its related validations.
Once the user has made an account, they are redirected to the home page, which establishes a socket connection with the server.
Through this connection, the user can interact with the gaming interface. The home page allows users to create and join games.
The home page also requests friendship data through the REST API. It displays these data in boxes and live-updates as players add and remove friends.
When a user decides to create a live match, the game manager runs the required checks and then starts a new game, redirecting the user to the waiting screen.
Using the join code it returns, other users can join the live game. Once it has enough players, the host can begin the game.
As soon as the game begins, the user is redirected to that game's page, which adds the game-specific listeners and manages game state parity.
On the server side, the game manager hands control of the game loop to an asynchronously threaded instance of the game's class, which sends state updates to the clients as the game progresses.
When the host wishes to end the game, the game manager sends the termination code to all clients and the client redirects the users back to the home page.
The database consists of three models: Authtoken, Friendship, and User.
Authtoken handles the client's authentication state. It references a specific user and contains a UUIDv4-type token, which the client can use to log in without re-entering their password before the expiration date that it also specifies.
Friendship represents a friendship between two users. It simultaneously represents an active friend request with its "accepted" property set to false by default. Once the request is accepted, it turns to true.
The Friendship model also contains helper functions for retrieving users' friend lists and friend requests.
User stores the user data that ROG needs to function. Most of these fields are standard, but it has two special features: a "locked" field, representing whether a site administrator has locked the user's account, preventing a login, and "lastLogin"/"lastLogout" Date fields which will, in the future, allow other users to see if their friends are online. (This feature will be most useful once I've added messaging.)
The REST routes are structured to match the underlying database models they access.
The authentication routes contains utility methods and route handlers that allow users to create accounts and log in via the login page. (Note that the live server authentication is handled by the live module's SocketServer class.) Authentication routes depend heavily on the common authentication utility file, which contains helper functions for password and Authtoken verification. These routes relate to both the User and Authtoken models in the database.
The friends routes exclusively deal with friendships. They allow users to see their friend list, check incoming friend requests, accept/decline requests, send friend requests, and remove friends.