We figure it out with our tech lead
For the educational project of the Bank of Russia, we have made a striking web game "The Mystery of the Lost Piggy Bank " . She draws the attention of schoolchildren to the topic of financial literacy, introduces the terms, teaches them how to wisely manage money. The game was liked not only by children, but also by adults from different cities of Russia - more than 30,000 people played it.
We've been asking our tech lead for a long time to tell us about the development of the web game. He not only told, but also wrote a fiery article about our experience in this project, about the difficulties encountered, and also shared life hacks in the development of browser games. The result was a material full of usefulness. Read on.
A web game is fundamentally different from both a regular computer game and a regular website in a browser. In a regular game, all game resources are available offline, the game engine knows information about the processor, memory and video card of the computer. A regular site requires few computer resources, and in case of problems, you can simply reload the page.
We had assumptions about the features of the browser game - significant restrictions on the available and used size of RAM (for example, it is stated in the TOR that 1 GB of RAM should be enough for mobile devices), the balance between the quality of game resources (images, textures, sprites, sounds, videos) and their download speed.
Added to this were the requirements from the client - the game must run and work in all declared mobile and desktop browsers (including IE 11), at the lowest possible hardware specifications. These requirements were based on the fact that the game was supposed to be shown at any convenient opportunity, on any device that came to hand - for example, at school.
How the engine was chosen
We already had experience in game development, so the directions for choosing an engine were immediately indicated:
- Phaser — /.
- Unity Web — .
- LibGDX, Godot, PlayCanvas.
Unknown options fell off for an obvious reason - they had to be mastered and studied, which, in some way, frightened, although it did not seem impossible. The Unity option fell off because the engine and export restrictions did not allow, for example, using audio in IE 11. And also because the Javascript exported from Unity was very large, and IE 11 is much slower in parsing and code execution than modern ones browsers.
Thus, it was decided to take a fresh version of the Phaser engine (at the time of development, it was version Phaser 3.11). We chose this engine also because all the logic and rendering are software, which means that we could control absolutely any aspect of the future game in the code.
As they wrote
In the beginning, we didn't have any elaborate mechanics, but we knew that it would definitely be a platformer. Therefore, we decided to put together at least some prototype to refresh our knowledge of the engine, as well as to make approximate measurements of the consumed resources and the load on the browser.
We took from the examples "character movement" and "tile map" ready in the documentation, assembled, launched - it works: the character walks, jumps, moves on platforms. Launched in all available devices - still works. Added virtual control buttons from the example "virtual buttons" and launched on mobile - still works. Added a little mechanic - hitting, enemy, dealing and receiving damage, collecting coins - was enough for the prototype.
In the prototype, there was even a little more than necessary. For example, the mechanics of controlling two characters was implemented, between which you could switch at any time.
After a successful prototype, we had an understanding of how the architecture would be implemented and the code organized. If we talk about the infrastructure part, then this is working with the engine in terms of loading resources, creating game objects, switching screens. As for the game logic itself, this is the implementation of characters, the implementation of mechanics of interaction with loot, traps, enemies.
The development stack was taken quite typical for a similar project - webpack, webpack-dev-server, babel, babel / preset-typescript.
What difficulties were
Difficulties were encountered in meeting performance requirements and in team communication. I had to work with new tools and transfer materials to each other in new formats, so everything did not always work out smoothly the first time.
For example, it was stipulated in the TOR that the game tries to determine the device's performance at startup, and in case of low performance, a corresponding notification is displayed. At this stage, we are faced with two problems. Firstly, the browser does not give practically any information on this matter. Secondly, the performance of a particular browser tab at a particular time depends very much on external factors - how many tabs are open, whether there are heavy sites in other tabs, whether the browser is minimized.
Several theoretical and practical hypotheses were tested, from which the final solution was born. The solution is as follows:
- On the loading screen of the game, where there is a progress from 0 to 100%, the actual loading of resources ends at 92%.
- After that, a scene is created outside the screen, on which heavy animations and a little physics are placed.
- Then, within 5 seconds, the average rendering time of one frame is measured.
- After that, a decision is made on the performance of the device and the progress reaches 100%.
Very important was the requirement for the game to be fully functional in IE 11, which also caused inconvenience. It turned out that with the developer tools running, the already slow Javascript execution in this browser slowed down even more.
That is, you are faced with the brakes in the game, open the developer tools to find the reason, and the game slows down even more.
Game mechanics
The game mechanics themselves are uncomplicated, largely inspired by existing games.
The main character, for example, is a one-piece animation sprite along with a weapon. This solution was chosen to avoid the out-of-sync of swing and weapon animations. Therefore, the check of damage is done as follows - at the moment of certain frames of the impact animation (frame from the third approximately), we calculate the intersection area, which is valid for several more animation frames. This is how we managed to achieve the realistic operation of the weapon.
The downside of this decision in the animation of the main character is that for each gender on each level, you need a separate set of prepared animations with weapons. And on the second level, another additional set was required - in credit sneakers. In total, we got four full sets of animations for each character.
Another funny thing here is that when you choose a weapon for the final battle, then in fact you choose the entire character from the corresponding level. So, all heroes with a sword will be in regular sneakers.
The mechanics of catching the keys from the chest was interesting. For the key that needed to be caught, the trigger area was made smaller than the visual sprite of the key, and also slightly offset to the side at random. This led to the desired effect “my key will not be assembled the first time” - sometimes you need to try to collect the key several times in order to get to the area of its actuation. Otherwise, it was too easy, although in the final release the trigger area was nevertheless slightly increased to reduce the percentage of unsuccessful attempts.
All other mechanics are actually the same - triggering the approach and intersection of the character and game objects at certain points in time and animation.
The mechanics with the Dragon of Insurance, the flight over the chasm and the final battle were a little more complicated. The techniques were the same, but pauses and inactivity were additionally orchestrated in order to reproduce the animations of other characters at this time.
Conclusions and advice
Decide on a genre very early on.
Games on the web are a real phenomenon, with their own audience and their own rules. Such games do not require installation, they allow you to arrange short game sessions, they attract more mechanics than appearance.
Tip - treat web game development like a real game, not just another "script on the page". Test, profile, and avoid memory leaks and CPU overhead. Players and their device batteries will be happy.