keshav2010 / rtsmultiplayerpoc

Multiplayer RTS Game Server written in NodeJS . The project serves 2 purpose, first my love for RTS games, 2nd me trying to see how much performance i can squeeze out of nodejs server. Hosted on railway.app, Check out the url below (the url may need some 2-3 refreshes, as it takes a while for the server to spin up from sleep)

RTSMultiplayerPOC

Multiplayer RTS Dedicated Game Server written in NodeJS for a small-scale game.

Approach

1. Client send their Inputs/State
2. Server pushes client requests in a FIFO approach
3. Server update game state in each tick (gameserver may ideally have a tick rate of say 10, i.e 100ms are allocated for each tick)
4. Server also builds a cumulativeUpdate packet (delta updates)
5. Server send back delta updates (stored in cumulativeUpdate array) back to all clients

This is a timestep based approach that makes sure server only send delta updates back to all clients instead of whole game state.

Preview (Debug info is displayed for each unit)

Both the GIFs shows basic boid avoidance behaviour

Getting Started

1. Build the client side code, this includes phaser related code that is used to draw/render game on the browser.

npm run build

2. Once done, simply run the server.

npx ts-node server.ts

3. Check the port where server is running and you're good to go.
   1. Create game room
   2. open another window on same url, click on join room (it may take few seconds)

rtsmultiplayerpoc's Issues

Fix Soldiers Attack

Issues in attack code, assumes different state machine (which isn't implemented yet)

Move Backend + Common functionality from JS to Typescript, Integrate Colyseus for Multiplayer Support

Scope

1. Code Refactoring - Once ported backend code to Typescript, refactor it to avoid using "any" type and implement common reusable interfaces & types.
2. Fix Testcase Files
3. Abstract away Scene class to make it more generic/reusable.
4. Integrate Colyseus.

Basic Economy and spawn mechanism

Auto spawn units at a dedicated spawn point selected by user during spawn-selection-state.
The cost of spawning unit must be deducted from player's resources, which are also incrementing slowly over period of time.

Gameplay Mechanic : Allow one-to-many, and one-to-one conversation

allow players to send short msg to each other (Max : 15 chars)

Improve Soldier Mechanics

• Fix bug : When selecting more than 1 unit for an attack, only 1 proceeds with the order rest do not follow the command immediately (and requires multiple attempts)
• Fix : Use UUID to generate soldier unit IDs
• Fix : Scenario when target unit is killed while some attackers are still in "ChaseTarget" mode. (possible that unit in chaseTarget state can have reference to target that is not registered anymore) ( setAttackTarget, getAttackTarget functions added)

handle client disconnection gracefully

client should be disconnected completely and be redirected to menu scene.

Allow player to move soldier while in attack/defense state

Prioritize move command over all other commands!

Game Objective Implementation : [Last Man Standing]

Game Mode : Last Man Standing

Last-Man-standing requires player to select their spawn position (by placing their castle on the map)

Each player starts with some 100 resources, and can spend them on following

1. Spawn Soldiers (spearman, knights)
3. Territory Flag
4. Resource Mine

Note: Soldiers are not immediately spawned, rather they are queued and are spawned after their training is completed (takes around 10-15 seconds). Only 1 soldier can be trained at a time.

Territory Flag 🏴 : A TF / Territory-Flag enables you to capture a region, it takes 10 seconds to complete a TF.
It is important to note that other individuals on the map can see your TF during its construction phase.

Resource Mine 🏛️ : enables you to increase your storage limit, by default you can only have maximum of 100 resources, and each resource-mine grants you +20 extra storage capacity.
A Resource-Mine can only be built within your territory (that is occupied by building TF or main castle).
Each TF, can have only 1 RM

By destroying enemy's Territory-Flag, and building your own at that point you can get access to their resource-mine.

---

Economy

All players start with 100 resources.

The rate of growth of resources slowly degrades, and eventually stops. (unless you have a RM)

• Each Resource-Mine grants you 0.2 resources / second. (exact value may change) (in #39 )

Each Kill grants you same resources as cost of the killed unit. (may change eventually)

There is a upper limit to resources, by default you can have maximum of 100 resources, but each RM grants you +20 extra storage space.

When your RM is captured / destroyed, your storage capacity is immediately affected, therefore if you've 150 resources and your RM is destroyed, your resource will fallback to 100, as well as your resource-growth rate will also be affected.

When you capture enemy's RM, you gain full control of RM, and you also get usual benefits out of it.
When you destroy enemy's RM, you will get limited loot but not all of the resources of an RM.

Ranking

Ranking is based on following parameter
% of area captured + army size

Allies and Conversation

• Players can send emojis to each other
• Players can donate their resources to others.

Simple Session/Room implementation

• - Game Server and Web server (serving HTML) still managed by same node server instance
• - User can create a session (socket.io namespace) and share sessionId (max 5 people per room, and we can expect each server instance to manage few 100s client connection, good enough for a basic test prototype.
• - main server spawns child processes (node's cluster module), which are responsible for managing sessions.
• - unique id for each session, and investigate socket.io's namespace functionality

State Machine Manager : Improve code design

Redo state machine code design.

Implemented in
#8

Gameplay: Allow user to schedule new soldiers in barracks/factory.

1. UI Buttons for different units (soldier, knight)
2. Allow player to schedule units for spawn.
3. Allow player to queue multiple units at once.
4. Clientside UI to show upcoming units and associated timer.

Procedurally Generate Scene Map from Server

Procedurally Generate tilemap when in session lobby, once generated, and update acknowledged by client, mark client as loaded and continue.

Bug : Territory Ownership : Upon killing/destroying a player, ensure occupied territory is released (occupied by capture flag)

Game Objective - Capture Flag

CF

• 1. captures nearby territory
• 2. can be deleted (player gets back some 70-80% of the resources back)
• 3. can be destroyed by enemy soldiers (enemy unit gains some resources)
• 4. **can only be built over unoccupied land

PlayerState --- has-a --- CF

A Player can have atmost 4 CFs

property:

1. health
2. state ( READY or IN_PROGRESS)

render scene area seperately at client side

The server side scene where all the soldiers movements are being simulated, should be rendered properly at client side.

as of now, the scene is being rendered as part of the whole canvas, instead it be rendered as an object over which several instances
then are placed (including soldiers, and other units).

This eventually will be transformed to support isometric view later

Player should be able to host a session with specific setting (max & min players in a session, countdown time during spawn-selection phase, etc)

Implement Isometric View for the game

We'd like the final version to look similar to the phaser example shown here:

1. Backend maintains the quadtree and a 2D representation of scene, and is unaware of the isometric nature.
2. Backend for now, will have only 1 single scene, though eventually we will be generating maps procedurally.

--

1. Client renders the isometric view of the scene grid, which it receives from client.

Add Docker Support

Terminate Session on win

Refactor code for packet handling at server side and refactor related code

1. Retire PendingUpdateManager
2. retire seperate queue for server side events and client init packets, all events including server side events should be queued to the same culumativeUpdate array.
3. code refactoring, mostly related to handling of socket instance associated with a player, remove dependency of GameStateManager over user defined classes to make it more generic and reusable.

Bug : Fix issue with Scene's quadtree item representation, should be a SAT.Box instead of SAT.Circle

As per the quadtree-lib, the items to be inserted in the quadtree should be rectangular

Work-Around:
Since for this game objective we're dealing with circlular hitbox,
the idea is to have a square of size 32px as the main hitbox
and within this square, we'll have a circle of diameter 32px at center of the square hitbox.

Add movement Animation and Attack Animation

Fix : Units should be able to detect on-going attack in their surrounding and defend their ally.

Game Objective - Tile Ownership

part of game objective, players can capture the territory by

1. creating a capture flag
2. spawning main castle

Allow Player to input custom player name and custom session settings.

• 1. Player should be able to enter their custom name.

PLAYER_INIT event lost in spawn-selection-state due to late subscription of its event-listener.

Reproduce

1. Connect two clients in local environment.
2. 2nd client may fail to connect because StateManager (client-side) contains no connected-player entry.
3. The game may start for 2nd client but the resource counter will show "--NA--"" message, due to missed PLAYER_INIT event.