Released in 1985, the classic Battle City on NES is one of the few earlier games to allow two players to play together simultaneously. The game has a simple yet addictive gameplay especially when playing together with a family or friend. For that very reason it is the perfect candidate for me to test out the capabilities of WebSocket.
Since my main goal here is to learn WebSocket, I just want to make a very basic playable game without sinking hundreds of hours into implementing the game code. You will find many aspects of the game are much more simplified than the original NES implementation. The entire project only took approximately 3 days to complete.
You can start a new game or join an existing game on the server. The game allows four players to play together which is a minor improvement over the original. Player can join the game at anytime as long as there are less than 4 players in the game. The game is only lost when the player base is destroyed.
The goal of the game is to kill all enemy tanks while defending the player base at the bottom center of the screen. Game is won after all enemy tanks are eliminated.
Three different power-ups are dropped randomly upon the death of an enemy or player tank. These are Speed Up (boot), Extra Health (armor) and Fast Attack (sword). Both enemy and player tanks can pick up these power-ups. The same power-up cannot be stacked meaning getting a second Speed Up will not further increase the tank speed.
To add some challenges to the game play, enemy tank will become stronger as the game progress and you may find it impossible to clear the stage by yourself.
At the moment only one game session is allowed on the server. Starting a new game will end the only active game on the server before a new one is started. You cannot start a new game if there are active players in the game.
The server side of the game is implemented in .NET Core 3.1. I'm using ASP.NET Core SignalR to handle the WebSocket part. The client side is JavaScript and HTML Canvas.
Server to client update rate is set to 10 times per second. This means the minimum latency is artificially kept at 100 ms which is not too bad. I should be able to improve this by optimizing the current netcode. Game update rate is also set to 10 times per second. Setting it too high will waste precious CPU cycles. Too low may cause problem with the collision detection if the game object is too small or moving too fast. Client draw rate is set to 50 times per second (50 FPS) which is more than enough for the crappy 2D animations I have at the moment.
And if you think the SFX in the game sound familiar. That is because they came from one of the most popular games in human history. If you think you figured out which game, let me know in my blog here.
As always, I'd love your feedback. Send me an email or leave me a message on LinkedIn or Blogger.