Space-themed game with electronJS and a cool C++ server. This is an over-the-weekend project, to have some fun with electron JS. So not really a game, but a scaffolding to do things, right now each person can just move a spaceship. It has the basics of a multiplayer, real-time game. The client is with electron js and the server is with C++ (uses Winsock2, so it is basically limited to windows, but fairly easy to make it multi-platform, as the threading is done using std::thread but why bother? The client is most important to be multi-platform which it is). Dependencies are kept at minimum, the server uses glm for some vector stuff and that is it.
The physics of driving a spaceship is based on a simple model for throttle: by hitting space key, you add an external force in the forward direction. Now friction won't let you keep speeding into infinity, there is a friction force -kv (v: velocity vector) which means there is a maximum velocity you cannot go over. To make calculations independent of time spent by the program, the time spent since last update of the physics dt is measured (std::chrono) and used in the calculations. Also similar to friction force, for rotation, you use arrow keys to impose a torque on the spaceship and again there is a frictional torque countering that, (negatively) proportional to the angular velocity at any moment.
What I wanted to really perfect here, was making the server really, really fast. That is why I chose C++ and the way it works is that there is a thread on which the physics of the game is run, and then for each client which is connected a thread for receiving and a thread for sending data. Everything is raw TCP, data is serialized in a very packed manner and so it is very performant. The typical memory the server uses is 1MB.
The Broadcaster class is in charge of managing the broadcasting threads, these threads send a frame and then wait until new frame is available and then wake up and send it. To achieve it std::condition_variable is used, you need to do it on different threads to send them out to the clients simultaneously (real simultaneously depends on how many cores you have but still as parallel as possible is good right?) and this approach of waiting on new frames, means you don't keep making new threads which would incur overhead AND this thin broadcaster class holds a copy of the frame, thus it does not lock the df (holding a frame of the game) in the main game thread so again helps keeping things fast.