Node.js + HTML5 + js = online action game. Game on Node.js
I have been wondering for a long time, why is writing online games on node.js such a rare occurrence, especially on the Habré?
After all, what praises were sung by the node when it appeared, and how many prophesied this platform was good (or bad), and something new was not very much added.
I decided to check whether such an approach to gaming is doomed to failure, and why. I will say right away that the results encouraged me!
Under cat details and problems that I encountered during the development process.
Brief Background
As a 4th year student in cybernetics, I received a proposal from a programming teacher to participate in a contest held by STEP and several other companies in combination. The Golden Byte contest has been held for several years and I thought it was a great opportunity to test myself in the field of gaming. Having 1.5 years of experience in the web studio as a developer (php, js, html, well, as usual), I decided not to hesitate for a long time and applied for the " Game design " nomination . Fortunately, my friend and I (an amateur artist) had some ideas (in thoughts) about the concept of a browser game.
Go!
The essence of the game in a nutshell.
Browser time killer. Two teams of plastic soldiers run around the computer table and destroy each other, fighting for possession of the table. The team wins by typing a certain number of kills. Management: WASD + mouse.
The design document was completed in a couple of days, sent and approved by the jury. At this point, I have already determined the platform on which the server part will be based, the client, in general, the main architecture. The decision was made in favor of Node.js (server), js + html5 (client). Data on the map, items, available units are stored in xml format and lie on the server.
Outlines of units were drawn while I sawed the code.
Features and background to the game here to spread, I think, is not appropriate.
Logics
So, I faced several implementation problems, and since I still had no business with the node, I had to adapt to the situation.
As a way of client-server communication, I chose Web sockets, connected socket.io, a couple of shamanism and dancing and voila, there is a connection. The first sketches a la movement and synchronization were carried out with pictures drawn clumsily in a pint (for clarity).
Data flies in json format.
The process going on in the background was something like this.
- The user visits the site, receives primary data about the card, all the necessary service information, first packet.
- The user sees the main screen. - Download the necessary pictures (preload).
- The user anonymously connects socket.io with the server, logs it into the session.
- The user chooses which side he will play for - a request is sent, a mark is placed on the side.
- The user chooses which character he will play for - a request is sent, a note about the character is placed.
- The player is placed on the respawn point, based on the map settings.
- The process of exchanging data with the server begins, well, the game itself (the algorithm below).
The action synchronization algorithm was invented as follows:
- On the server there is an interval of 50 ms, which sends all the connected users the necessary info about the location and actions of the players. (A list of players' objects is sent).
- Users have a catch-event for messages and when they catch it, they check which package arrived, main / first / system, etc.
- In response, a packet with the current user action flies from the user. Only the pressed keys fly, all the calculations take place on the server (is it possible to go there, where you find yourself, etc. etc.).
And so in a circle.
Drawing
As a field for drawing, I used canvas. After a short look at popular libraries, I thought that I still do it more for myself, and not for the competition. But it’s much more pleasant to write your bike, especially in a new field for me, so it was decided to write your own small rendering engine.
Well, as expected, setInterval, requestAnimationFrame, and all the knowledge that remained in geometry and elementary algebra were used.
After rendering the background, the active area of the screen that the user sees is selected, minus the difference in the area of the object being drawn. In this perimeter, the core is rendered. On the server, everything is regularly sorted according to the distance from the screen (in height) so that the picture of a soldier standing farther does not overlap with a soldier standing closer to the screen.
At this point, I already had a ready-made set of sprites for rendering the unit. I added a sprite animation rendering method to the engine, as a result I got the following:
So, at the moment I was ready:
- Drawing units with animation
- Drawing objects
- Uneven Table Borders (inability to pass beyond them)
- Map movement
Unit sprites were rendered in 3Dmax and glued together. It looked like this (clickable):
And, of course, the action
The warhead is implemented quite simply. When left-clicking on the field, the character turns in that direction and hits. Right mouse button - block to the side in the direction of the mouse. The character has certain characteristics that determine its speed / vitality / fatigue / range_stroke / DMG, etc.
And again, all the calculations take place on the server, the player receives only the result of his pressing the keys.
Some background information / statistics
VPS server for 5 euros per month:
CPU 1200 Mhz, RAM 256Mb, OS Debian.
Map 3000 to 3000 (one-dimensional array with subsequent conversion). When the server starts, it initializes, takes 900 ms. When it was a two-dimensional array, it took 6500 ms.
5Mb customer channel. 40 connections (20 to 20). Data exchange was provided and a constant FPS was maintained without subsidence of 30-60.
A few more pictures:
Main screen:
Scrolled with the mouse wheel:
Victory of the blue team:
Cross-browser compatibility is provided for Chrome, Mozilla, Opera, Explorer 10+. In general, everything that supports canvas and Websockets.
There was also an adapted version for those who logged in from the phone (the interface is unfinished, but it works).
Total
All the work took about a month and a half of labors after study and work.
I won’t give a link to the game, the poor server will not stand the habra effect, and I’m not ready for stress testing yet.
At a contest in our city, my friend and I took the 2nd place, which, in principle, did not upset me, but only spurred me. I made the game more for myself, but in the future, we may redo the schedule, and it will be possible to put it in the public domain, but it's too early to talk about it.
For those who want to see my clumsy code, here is the git repository. Just don’t spit, now I can see how clumsy everything is, although I did it only half a year ago: https://github.com/amikstrike/wn
Thank you for your attention!