Creating a multiplayer 3D shooter on Webgl without experience and money
This is the first part of the story of how a small team of web developers developed a multiplayer 3d shooter with no experience in game development, big money and staff.
Disclaimer: Some of the solutions described in this article may cause a facepalm.
')
In 2011, we were a small St. Petersburg web studio of 4 people. Timlid / SEO, programmer (or rather, considered himself a programmer), designer and sales manager. At that time, the team leader and programmer had been involved in websites for 3 years, but they did not achieve much success in this field. Although we already had several regular customers on promotion and service, taxes, office rent and other expenses ate the lion's share of income. The remaining kopecks for four people was clearly not enough. Chronic lack of money and the lack of prospects oppressed. The designer already pricked up his skis, and the rest of the team barely held on. It was in such a situation that an amazingly naive idea came up with the thought: “what are we doing for all sorts of uncles we do projects, but let's do our own thing, for example, play a browser game and write it on VKontakte”. Everyone except the designer took the idea with enthusiasm.
Like most "beginner" game developers, they decided to make MMORPG. I must say that none of us had any experience in game dev. Apart from a small lineage2 freeshard, which the programmer contained and finished homemade chronicles there. Dopilivanie mainly limited server geymdatoy, more was not enough - no mind, no knowledge. Anyway, it gave some ideas about the server-side device. The experience of administering and communicating with a contingent of players was firmly convinced of one thing: the client cannot be trusted - everything that can be done on the server must be done on the server.
Let's return to our project.
Responsibilities distributed as follows:
Timlid - became a game designer;
Manager - took over the sound;
Programmer - remained a programmer.
Initially, it was assumed that this would be some kind of a follaut and a marauder (on the 7.62 engine), with isometry, but realtime.
The place of action was to be post-apocalyptic St. Petersburg.
The technical implementation was then presented as follows:
The game location consists of img and div tags.
The overlapping of each other was given by the z-index, which was calculated based on the position of the object along the y axis.
There was no character, his duties then performed a white square.
Contact server through comet connections.
Management through mouse clicks.
Connections from comet were quickly abandoned in favor of websockets. Then they were still quite raw and were not supported by half of browsers, for which a flash crutch was inserted (then we naively thought that a beta release was possible in six months or a year and cross-browser compatibility was needed now).
When all this was implemented and the character-square learned to move around the screen, a new task emerged - it was necessary to somehow limit the freedom of its movement. It was decided to mark the boundaries of objects with the help of stop segments, as well for the future there were separate types of segments blocking the shooting and review.
When you click with the mouse, a segment was constructed from the current coordinates of the character to the point of the click. Further, all the stop segments were checked at the intersection with the segment-route. If no intersections were found, the client received the coordinates of the destination point and started moving, the same process occurred on the server. But in the case of crossing the character remained motionless. This resulted in the following task - finding a circumvention path.
It took many days and nights to find a solution. At first there were attempts to make a real-time search, but it was not possible to achieve an acceptable calculation speed. Then, googling, they decided to use pre-calculated paths. To do this, the waypoints were placed at the corners of the objects and a generator was written that looked for all possible routes from each point to each, then the shortest route was selected, which was recorded.
Now the server, in case of impossibility to go in a straight line, took all the available points from the point of departure and from the destination, selected all routes connecting them, and from them chose the shortest and started the movement. Now the square famously maneuvered between all the obstacles itself, and most importantly, the calculations now took a fraction of a second.
Closed areas remained inside objects that could not be reached, but this was not very embarrassing.
Turn came to the visualization of the character. The difficulty consisted in the following: It was assumed that the character could have 3 positions - standing, sitting, lying and all this multiplied by 8 orientations in space.
Assumed various types of weapons: pistols, rifles, machine guns and various armor.
The first thought is to do it all on sprites, but even with the new css3 transform, the number of sprites seemed enormous, and the possibilities for customization are very limited. Began to look for other solutions. It was necessary that something would draw the character on the fly.
Such a solution was found - WebGL .
The first experience was the designer of games CopperCube. We made an export of an empty scene with an animated character and stuck it entirely instead of a white square. When running, the corresponding animation was turned on, the character turned in space, somehow. Not bad, maybe the whole scene can be built on WebGL?
The decision was made and it remained to choose the tool. CopperCube was a ready-made engine designer, but closed, paid, and how to make a network game in it and even with the mechanics of the sideways was completely incomprehensible.
It was necessary to have something lower-level, which would allow us to create our game mechanics, but at the same time, we did not work directly with WebGL (in 3D programming, then in our team no one understood anything).
Having tested a number of libraries, we stopped at three.js. Despite the fact that with the documentation then it was a little better than nothing, the network had a huge number of demos where you could see how certain things are done. Actually, this determined the choice.
The rest of the year was spent on moving the client to 3D.
Also editors of objects and maps were ported.
Almost a year has passed since the start of development, but the results have not yet been impressive. Gamediz gave ideas, sketches of the interface, a description of the characters and future locations, but it never came to realization. There was no intelligible plot in the beginning either. There was a general idea - as a consequence of the apocalypse, or a sudden unknown attack, pure water became worth its weight in gold. And we decided to name the game on this basis WasteWater (wastewater).
The manager, who took the sound, did not start the work, he also stopped working with websites, and as a result our paths diverged from him. So from the original composition of the two of us left.
But the most important thing is that we didn’t have game content, moreover, there wasn’t even any idea where to get it.
The obvious has become obvious - we will never do an MMORPG with our forces.
Then they decided to simplify everything to the command shooter. In general, the game should now look like this:
The lobby, where the player could do such things as: buying equipment, equipping the character, leveling skills.
Battle mode, where the player got by pressing the red button "Into the battle."
The top view was left, and the management decided to remake at WASD. Looking ahead, I will say that WASD turned out to be “not like everyone else.” If usually with this type of W is always up, and S is always down, then we are all about where the character is looking. Such management is unusual, but it gives more tactical possibilities and you get used to it after a couple of fights.
The gameplay was supposed to become more dynamic, so the character’s lying and sitting positions were thrown out.
Only the key feature remained the same - all locations should be based on the real places in St. Petersburg.
It did not solve the problem of lack of content in any way, but significantly reduced the minimum amount required for launch.
Began to rewrite the client. By the summer, a prototype lobby with working inventory was ready. The character is taken from action quake (mod for q2, grandfather cs).
All summer was spent on the combat system. The WASD control was screwed over the old mouse-pointer control system: the character patfiding was turned off, and the click point was emulated in front of the character at a certain distance. If the player moved the mouse or the character reached the calculated coordinates, then the point was calculated again. Patfayding same useful for mobs. Their models were also taken from some q2 mod. It was written primitive AI, chasing the player, well, but all the main work to achieve the goal was done by the system of patfiding. Despite all the primitiveness, the observation of this artificial life was fascinating.
Shooting was attached while it was still silent and flameless, but the mobs could already be mowed in bursts, and they learned to bite back painfully.
The attack / shot algorithm was also based on segments and checks for interception - a conditional segment was taken from the shooter to the maximum range of the current weapon and collisions were checked. “Living” objects were also designated as crossed segments.
In general, by the fall of the prototype was more or less ready.
In the meantime, gamediz did not waste time in vain and was scouring websites where ready-made 3D models were sold, in search of content suitable for us. He managed to pick something up, but it was not enough.
With the decrease in costs, we had some free finance and decided to hire freelancers.
The first order was a new character with animation. And the first pancake, as usual, came out in a lump - taking the advance, the performer did not show anything intelligible by the stipulated time. If we knew then with some fantastic characters we still had to work ...
By the end of the year we found the performers who made us a character and animated it, but a new problem surfaced. The fact is that from 3DsMax, in which the work was done, at that time there was no direct export of animation in three.js, so I had to use the intermediate format md2, which was already distilled into native json via an online converter.
In addition to the common drawbacks for frame-by-frame animation — a lot of weight and memory consumption, md2 had another one — the coordinates of the vertices were rounded off, which caused the entire model to float. It was not so noticeable on low-poly Quake characters, but on our more detailed one, it looked disgusting.
To export somehow it was not possible otherwise, it turned out an outrageous volume with which the browser simply could not cope with the output of the button. Then we were not mentally ready to redo everything again, and in general there was still no clear idea how to redo it, so we decided to keep it as it is.
We also had no luck with 3D environment modelers. At first they took up the new lobby, managed to make it with grief in half - only from the second freelancer.
Started working on the first map. Initially, they wanted to use the Ozerki metro station and the surrounding territory, but they abandoned this idea even at the design stage. The fact is that this terrain has a significant elevation difference, and although the client has become three-dimensional, the server logic remains 2D. In other words, the situation when a character stands on top of a mountain and shoots a character standing at the foot, and the bullets do not fly at the same time, but high above the head of the target, looked ugly.
It was necessary to have a flatter place, and this place was chosen as the intersection of Lanskoye Highway and Omsk Street, perhaps remarkable, passing high-voltage transmission lines along it.
Mark up a location plan for Yandex.Maps and proceeded to implementation. We started with drawing the future of the terrain, a new web designer took on this work. The area of ​​the real territory was about a hectare and soon the designer had to improve the computer, because the old two cores with 4GB of memory could not cope with the amount of data.
This has already hinted that it would not be possible to simply pull a single texture onto the plane, unless of course you squeeze the quality to the state of laundry soap. We decided to cut everything into small pieces and assemble it like a mosaic, repeating segments where possible. Tile, decals? “No, we didn't know those words then.”
He was mainly engaged in game-building of the map, becoming, in combination, also a level designer. As it turned out, to assemble a map in this way was very difficult. The slightest mistake led to the fact that half of the card had to reassemble again. The self-written editor, who was more likely a tool of torture than a tool of development, amplified the suffering.
Having made titanic efforts, the map was nevertheless collected.
In parallel with the work on the map was working with sound. A pair of lobbies and battle mode tracks was purchased.
The author of these tracks ordered other game sounds: shots, footsteps and the like.
The background music was simply hung on the audio tag, and the game sounds were implemented through the new-fangled web audio api, which at that time was still damp and supported only in chrome and its relatives, but already provided rich possibilities, in particular, allowed positioning sound in space in accordance with with the position of its source in the 3D scene.
On May 8, 2013, we launched pre-alpha testing for living people. There were few experimenters, but it was still possible to collect some feedback and play by myself.
1. The animation system must be changed;
2. The obstacle system, built on the stop-segments, does not work well: the players are hooked on hardly noticeable obstacles;
3. By itself, the manual stroke is labor intensive and does not fully correspond in the case of complex geometries;
4. There is no scalability - you have to go through all the stop segments on the map;
5. Terrain-mosaic of planes subsides FPS, and the joints are visible everywhere;
6. The full server-side movement of the character on the real Internet does not work as well as we would like - visually visible is the delay between pressing a button and the reaction of the game;
7. Grafon as a whole "niochen".
It became clear that almost everything needs to be redone. But a negative result is also a result. Mainly, all this gave at least some experience and understanding how not to do it.
The next year and a half, we reworked our game, but this is already in the next article.
Work on the game continues, implemented only the main of his plans.
Screenshot from the lobby in 2015:
Screenshot from the map of the Vasilyevsky Island Strelka 2015:
Thanks for attention.
Disclaimer: Some of the solutions described in this article may cause a facepalm.
')
2011. How it all began
In 2011, we were a small St. Petersburg web studio of 4 people. Timlid / SEO, programmer (or rather, considered himself a programmer), designer and sales manager. At that time, the team leader and programmer had been involved in websites for 3 years, but they did not achieve much success in this field. Although we already had several regular customers on promotion and service, taxes, office rent and other expenses ate the lion's share of income. The remaining kopecks for four people was clearly not enough. Chronic lack of money and the lack of prospects oppressed. The designer already pricked up his skis, and the rest of the team barely held on. It was in such a situation that an amazingly naive idea came up with the thought: “what are we doing for all sorts of uncles we do projects, but let's do our own thing, for example, play a browser game and write it on VKontakte”. Everyone except the designer took the idea with enthusiasm.
Like most "beginner" game developers, they decided to make MMORPG. I must say that none of us had any experience in game dev. Apart from a small lineage2 freeshard, which the programmer contained and finished homemade chronicles there. Dopilivanie mainly limited server geymdatoy, more was not enough - no mind, no knowledge. Anyway, it gave some ideas about the server-side device. The experience of administering and communicating with a contingent of players was firmly convinced of one thing: the client cannot be trusted - everything that can be done on the server must be done on the server.
Let's return to our project.
Responsibilities distributed as follows:
Timlid - became a game designer;
Manager - took over the sound;
Programmer - remained a programmer.
Initially, it was assumed that this would be some kind of a follaut and a marauder (on the 7.62 engine), with isometry, but realtime.
The place of action was to be post-apocalyptic St. Petersburg.
The first steps
The technical implementation was then presented as follows:
The game location consists of img and div tags.
The overlapping of each other was given by the z-index, which was calculated based on the position of the object along the y axis.
There was no character, his duties then performed a white square.
Contact server through comet connections.
Management through mouse clicks.
Connections from comet were quickly abandoned in favor of websockets. Then they were still quite raw and were not supported by half of browsers, for which a flash crutch was inserted (then we naively thought that a beta release was possible in six months or a year and cross-browser compatibility was needed now).
Obstacles
When all this was implemented and the character-square learned to move around the screen, a new task emerged - it was necessary to somehow limit the freedom of its movement. It was decided to mark the boundaries of objects with the help of stop segments, as well for the future there were separate types of segments blocking the shooting and review.
When you click with the mouse, a segment was constructed from the current coordinates of the character to the point of the click. Further, all the stop segments were checked at the intersection with the segment-route. If no intersections were found, the client received the coordinates of the destination point and started moving, the same process occurred on the server. But in the case of crossing the character remained motionless. This resulted in the following task - finding a circumvention path.
Obstacle avoidance
It took many days and nights to find a solution. At first there were attempts to make a real-time search, but it was not possible to achieve an acceptable calculation speed. Then, googling, they decided to use pre-calculated paths. To do this, the waypoints were placed at the corners of the objects and a generator was written that looked for all possible routes from each point to each, then the shortest route was selected, which was recorded.
Now the server, in case of impossibility to go in a straight line, took all the available points from the point of departure and from the destination, selected all routes connecting them, and from them chose the shortest and started the movement. Now the square famously maneuvered between all the obstacles itself, and most importantly, the calculations now took a fraction of a second.
Closed areas remained inside objects that could not be reached, but this was not very embarrassing.
Webgl
Turn came to the visualization of the character. The difficulty consisted in the following: It was assumed that the character could have 3 positions - standing, sitting, lying and all this multiplied by 8 orientations in space.
Assumed various types of weapons: pistols, rifles, machine guns and various armor.
The first thought is to do it all on sprites, but even with the new css3 transform, the number of sprites seemed enormous, and the possibilities for customization are very limited. Began to look for other solutions. It was necessary that something would draw the character on the fly.
Such a solution was found - WebGL .
The first experience was the designer of games CopperCube. We made an export of an empty scene with an animated character and stuck it entirely instead of a white square. When running, the corresponding animation was turned on, the character turned in space, somehow. Not bad, maybe the whole scene can be built on WebGL?
The decision was made and it remained to choose the tool. CopperCube was a ready-made engine designer, but closed, paid, and how to make a network game in it and even with the mechanics of the sideways was completely incomprehensible.
It was necessary to have something lower-level, which would allow us to create our game mechanics, but at the same time, we did not work directly with WebGL (in 3D programming, then in our team no one understood anything).
Having tested a number of libraries, we stopped at three.js. Despite the fact that with the documentation then it was a little better than nothing, the network had a huge number of demos where you could see how certain things are done. Actually, this determined the choice.
The rest of the year was spent on moving the client to 3D.
Also editors of objects and maps were ported.
year 2012. Lower the bar
Almost a year has passed since the start of development, but the results have not yet been impressive. Gamediz gave ideas, sketches of the interface, a description of the characters and future locations, but it never came to realization. There was no intelligible plot in the beginning either. There was a general idea - as a consequence of the apocalypse, or a sudden unknown attack, pure water became worth its weight in gold. And we decided to name the game on this basis WasteWater (wastewater).
The manager, who took the sound, did not start the work, he also stopped working with websites, and as a result our paths diverged from him. So from the original composition of the two of us left.
But the most important thing is that we didn’t have game content, moreover, there wasn’t even any idea where to get it.
The obvious has become obvious - we will never do an MMORPG with our forces.
Then they decided to simplify everything to the command shooter. In general, the game should now look like this:
The lobby, where the player could do such things as: buying equipment, equipping the character, leveling skills.
Battle mode, where the player got by pressing the red button "Into the battle."
The top view was left, and the management decided to remake at WASD. Looking ahead, I will say that WASD turned out to be “not like everyone else.” If usually with this type of W is always up, and S is always down, then we are all about where the character is looking. Such management is unusual, but it gives more tactical possibilities and you get used to it after a couple of fights.
The gameplay was supposed to become more dynamic, so the character’s lying and sitting positions were thrown out.
Only the key feature remained the same - all locations should be based on the real places in St. Petersburg.
It did not solve the problem of lack of content in any way, but significantly reduced the minimum amount required for launch.
Began to rewrite the client. By the summer, a prototype lobby with working inventory was ready. The character is taken from action quake (mod for q2, grandfather cs).
All summer was spent on the combat system. The WASD control was screwed over the old mouse-pointer control system: the character patfiding was turned off, and the click point was emulated in front of the character at a certain distance. If the player moved the mouse or the character reached the calculated coordinates, then the point was calculated again. Patfayding same useful for mobs. Their models were also taken from some q2 mod. It was written primitive AI, chasing the player, well, but all the main work to achieve the goal was done by the system of patfiding. Despite all the primitiveness, the observation of this artificial life was fascinating.
Shooting was attached while it was still silent and flameless, but the mobs could already be mowed in bursts, and they learned to bite back painfully.
The attack / shot algorithm was also based on segments and checks for interception - a conditional segment was taken from the shooter to the maximum range of the current weapon and collisions were checked. “Living” objects were also designated as crossed segments.
In general, by the fall of the prototype was more or less ready.
Content
In the meantime, gamediz did not waste time in vain and was scouring websites where ready-made 3D models were sold, in search of content suitable for us. He managed to pick something up, but it was not enough.
With the decrease in costs, we had some free finance and decided to hire freelancers.
The first order was a new character with animation. And the first pancake, as usual, came out in a lump - taking the advance, the performer did not show anything intelligible by the stipulated time. If we knew then with some fantastic characters we still had to work ...
By the end of the year we found the performers who made us a character and animated it, but a new problem surfaced. The fact is that from 3DsMax, in which the work was done, at that time there was no direct export of animation in three.js, so I had to use the intermediate format md2, which was already distilled into native json via an online converter.
In addition to the common drawbacks for frame-by-frame animation — a lot of weight and memory consumption, md2 had another one — the coordinates of the vertices were rounded off, which caused the entire model to float. It was not so noticeable on low-poly Quake characters, but on our more detailed one, it looked disgusting.
To export somehow it was not possible otherwise, it turned out an outrageous volume with which the browser simply could not cope with the output of the button. Then we were not mentally ready to redo everything again, and in general there was still no clear idea how to redo it, so we decided to keep it as it is.
year 2013. First results
We also had no luck with 3D environment modelers. At first they took up the new lobby, managed to make it with grief in half - only from the second freelancer.
First location
Started working on the first map. Initially, they wanted to use the Ozerki metro station and the surrounding territory, but they abandoned this idea even at the design stage. The fact is that this terrain has a significant elevation difference, and although the client has become three-dimensional, the server logic remains 2D. In other words, the situation when a character stands on top of a mountain and shoots a character standing at the foot, and the bullets do not fly at the same time, but high above the head of the target, looked ugly.
It was necessary to have a flatter place, and this place was chosen as the intersection of Lanskoye Highway and Omsk Street, perhaps remarkable, passing high-voltage transmission lines along it.
Mark up a location plan for Yandex.Maps and proceeded to implementation. We started with drawing the future of the terrain, a new web designer took on this work. The area of ​​the real territory was about a hectare and soon the designer had to improve the computer, because the old two cores with 4GB of memory could not cope with the amount of data.
This has already hinted that it would not be possible to simply pull a single texture onto the plane, unless of course you squeeze the quality to the state of laundry soap. We decided to cut everything into small pieces and assemble it like a mosaic, repeating segments where possible. Tile, decals? “No, we didn't know those words then.”
He was mainly engaged in game-building of the map, becoming, in combination, also a level designer. As it turned out, to assemble a map in this way was very difficult. The slightest mistake led to the fact that half of the card had to reassemble again. The self-written editor, who was more likely a tool of torture than a tool of development, amplified the suffering.
Having made titanic efforts, the map was nevertheless collected.
Sound
In parallel with the work on the map was working with sound. A pair of lobbies and battle mode tracks was purchased.
The author of these tracks ordered other game sounds: shots, footsteps and the like.
The background music was simply hung on the audio tag, and the game sounds were implemented through the new-fangled web audio api, which at that time was still damp and supported only in chrome and its relatives, but already provided rich possibilities, in particular, allowed positioning sound in space in accordance with with the position of its source in the 3D scene.
Prealfa
On May 8, 2013, we launched pre-alpha testing for living people. There were few experimenters, but it was still possible to collect some feedback and play by myself.
According to the results of the pre-alpha the following conclusions were made.
1. The animation system must be changed;
2. The obstacle system, built on the stop-segments, does not work well: the players are hooked on hardly noticeable obstacles;
3. By itself, the manual stroke is labor intensive and does not fully correspond in the case of complex geometries;
4. There is no scalability - you have to go through all the stop segments on the map;
5. Terrain-mosaic of planes subsides FPS, and the joints are visible everywhere;
6. The full server-side movement of the character on the real Internet does not work as well as we would like - visually visible is the delay between pressing a button and the reaction of the game;
7. Grafon as a whole "niochen".
Total
It became clear that almost everything needs to be redone. But a negative result is also a result. Mainly, all this gave at least some experience and understanding how not to do it.
The next year and a half, we reworked our game, but this is already in the next article.
Work on the game continues, implemented only the main of his plans.
Screenshot from the lobby in 2015:
Screenshot from the map of the Vasilyevsky Island Strelka 2015:
Thanks for attention.
Source: https://habr.com/ru/post/254627/
All Articles