Nous le trouvons avec notre responsable technique
Pour le projet éducatif de la Banque de Russie, nous avons réalisé un jeu Web saisissant "Le mystère de la tirelire perdue" . Elle attire l'attention des écoliers sur le sujet de la littératie financière, présente les termes, leur apprend à gérer judicieusement l'argent. Le jeu a été apprécié non seulement par les enfants, mais aussi par les adultes de différentes villes de Russie - plus de 30 000 personnes y ont joué.
Nous demandons depuis longtemps à notre responsable technique de nous parler du développement du jeu Web. Il a non seulement raconté, mais aussi écrit un article enflammé sur notre expérience dans ce projet, sur les difficultés rencontrées, et a également partagé des hacks de vie dans le développement de jeux par navigateur. Le résultat est un matériau plein d'utilité. Continuer à lire.
Un jeu Web est fondamentalement différent d'un jeu d'ordinateur ordinaire et d'un site Web régulier dans un navigateur. Dans un jeu normal, toutes les ressources du jeu sont disponibles hors ligne, le moteur de jeu connaît des informations sur le processeur, la mémoire et la carte vidéo de l'ordinateur. Un site régulier nécessite peu de ressources informatiques, et en cas de problème, vous pouvez simplement recharger la page.
Nous avions des hypothèses sur les fonctionnalités du jeu par navigateur - des restrictions importantes sur la taille de RAM disponible et utilisée (par exemple, il est indiqué dans le TOR que 1 Go de RAM devrait suffire pour les appareils mobiles), l'équilibre entre la qualité des ressources du jeu (images, textures, sprites, sons, vidéos) et leur vitesse de téléchargement.
À cela s'ajoutaient les exigences du client - le jeu doit fonctionner et fonctionner dans tous les navigateurs mobiles et de bureau déclarés (y compris IE 11), avec les caractéristiques matérielles les plus basses possibles. Ces exigences étaient basées sur le fait que le jeu était censé être diffusé à toute occasion convenable, sur n'importe quel appareil disponible - par exemple, à l'école.
Comment le moteur a été choisi
Nous avions déjà de l'expérience dans le développement de jeux, donc les directions pour choisir un moteur ont été immédiatement indiquées:
- Phaser — /.
- Unity Web — .
- LibGDX, Godot, PlayCanvas.
Les options inconnues sont tombées pour une raison évidente: elles devaient être maîtrisées et étudiées, ce qui, d'une certaine manière, effrayait, même si cela ne semblait pas impossible. L'option Unity a échoué parce que le moteur et les restrictions d'exportation ne permettaient pas, par exemple, d'utiliser l'audio dans IE 11. Et aussi parce que le Javascript exporté depuis Unity était très volumineux, et IE 11 est beaucoup plus lent dans l'analyse et l'exécution du code que les versions modernes. navigateurs.
Ainsi, il a été décidé de prendre une nouvelle version du moteur Phaser (au moment du développement, il s'agissait de la version Phaser 3.11). Nous avons choisi ce moteur aussi parce que toute la logique et le rendu sont logiciels, ce qui signifie que nous pourrions contrôler absolument n'importe quel aspect du futur jeu dans le code.
Comme ils ont écrit
Au début, nous n'avions aucune mécanique élaborée, mais nous savions que ce serait certainement un jeu de plateforme. Par conséquent, nous avons décidé de rassembler au moins un prototype pour rafraîchir nos connaissances du moteur, ainsi que pour faire des mesures approximatives des ressources consommées et de la charge sur le navigateur.
Nous avons pris des exemples «mouvement de personnage» et «carte de tuiles» prêts dans la documentation, assemblés, lancés - cela fonctionne: le personnage marche, saute, se déplace sur des plates-formes. Lancé dans tous les appareils disponibles - fonctionne toujours. Ajout de boutons de contrôle virtuels à partir de l'exemple "boutons virtuels" et lancé sur mobile - fonctionne toujours. Nous avons ajouté un peu de mécanique - frapper, ennemi, infliger et recevoir des dégâts, collecter des pièces - suffisait pour le prototype.
Dans le prototype, il y avait même un peu plus que nécessaire. Par exemple, les mécanismes de contrôle de deux personnages ont été mis en œuvre, entre lesquels vous pouvez basculer à tout moment.
Après un prototype réussi, nous avons compris comment l'architecture serait mise en œuvre et le code organisé. Si nous parlons de la partie infrastructure, alors cela fonctionne avec le moteur en termes de chargement de ressources, de création d'objets de jeu, de changement d'écran. Quant à la logique du jeu elle-même, il s'agit de la mise en œuvre de personnages, de la mise en œuvre de mécanismes d'interaction avec des proies, des pièges, des ennemis.
La pile de développement a été prise assez typique pour un projet similaire - webpack, webpack-dev-server, babel, babel / preset-typescript.
Quelles difficultés étaient
Des difficultés ont été rencontrées pour répondre aux exigences de performance et pour communiquer en équipe. J'ai dû travailler avec de nouveaux outils et transférer des matériaux entre eux dans de nouveaux formats, donc tout ne s'est pas toujours bien déroulé la première fois.
Par exemple, il était stipulé dans le TOR que le jeu essaie de déterminer les performances de l'appareil au démarrage, et une notification correspondante est affichée en cas de faible performance. À ce stade, nous sommes confrontés à deux problèmes. Premièrement, le navigateur ne donne pratiquement aucune information à ce sujet. Deuxièmement, les performances d'un onglet de navigateur particulier à un moment donné dépendent fortement de facteurs externes - combien d'onglets sont ouverts, s'il y a des sites lourds dans d'autres onglets, si le navigateur est minimisé.
Plusieurs hypothèses théoriques et pratiques ont été testées, à partir desquelles est née la solution finale. La solution est la suivante:
- Sur l'écran de chargement du jeu, où la progression est de 0 à 100%, le chargement réel des ressources se termine à 92%.
- Après cela, une scène est créée en dehors de l'écran, sur laquelle sont placées des animations lourdes et un peu de physique.
- Ensuite, dans les 5 secondes, le temps de rendu moyen d'une image est mesuré.
- Après cela, une décision est prise sur les performances de l'appareil et la progression atteint 100%.
Il était très important que le jeu soit entièrement fonctionnel dans IE 11, ce qui causait également des inconvénients. Il s'est avéré qu'avec les outils de développement en cours d'exécution, l'exécution déjà lente de Javascript dans ce navigateur ralentissait encore plus.
Autrement dit, vous êtes confronté aux freins du jeu, vous ouvrez les outils de développement pour trouver la raison, et le jeu ralentit encore plus.
Mécanique de jeu
Les mécanismes de jeu eux-mêmes sont simples, largement inspirés des jeux existants.
Le personnage principal, par exemple, est un sprite d'animation d'une seule pièce avec une arme. Cette solution a été choisie pour éviter la désynchronisation des animations de swing et d'armes. Par conséquent, les dommages infligés sont vérifiés comme suit - au moment de certaines images de l'animation d'impact (image à partir de la troisième environ), nous calculons la zone d'intersection, qui est valable pour plusieurs images d'animation supplémentaires. C'est ainsi que nous avons réussi à réaliser le fonctionnement réaliste de l'arme.
L'inconvénient de cette décision dans l'animation du personnage principal est que pour chaque sexe à chacun des niveaux, vous avez besoin d'un ensemble séparé d'animations préparées avec des armes. Et au deuxième niveau, un autre ensemble supplémentaire était nécessaire - dans les baskets de crédit. Au total, nous avons quatre ensembles complets d'animations pour chaque personnage.
Une autre chose amusante ici est que lorsque vous choisissez une arme pour la bataille finale, vous choisissez en fait tout le personnage du niveau correspondant. Ainsi, tous les héros avec une épée porteront des baskets ordinaires.
La mécanique pour attraper les clés du coffre était intéressante. Pour la clé qui devait être capturée, la zone de déclenchement a été rendue plus petite que le sprite visuel de la clé, et également légèrement décalée sur le côté au hasard. Cela a conduit à l'effet souhaité «ma clé ne sera pas assemblée la première fois» - il faut parfois essayer de récupérer la clé plusieurs fois pour accéder à la zone de son actionnement. Sinon, c'était trop facile, même si dans la version finale, la zone de déclenchement a néanmoins été légèrement augmentée pour réduire le pourcentage de tentatives infructueuses.
Tous les autres mécanismes sont en fait les mêmes - déclenchant l'approche et l'intersection du personnage et des objets du jeu à certains moments dans le temps et dans l'animation.
La mécanique avec le Dragon of Insurance, le vol au-dessus du gouffre et la bataille finale étaient un peu plus compliqués. Les techniques étaient les mêmes, mais les pauses et l'inactivité étaient en outre orchestrées afin de reproduire les animations d'autres personnages à ce moment.
Conclusions et conseils
Choisissez un genre très tôt.
Les jeux sur le web sont un vrai phénomène, avec leur propre public et leurs propres règles. De tels jeux ne nécessitent pas d'installation, ils vous permettent d'organiser des sessions de jeu courtes, ils attirent plus de mécanique que d'apparence.
Astuce - considérez le développement de jeux Web comme un vrai jeu, pas simplement comme un autre "script sur la page". Testez, profilez et évitez les fuites de mémoire et la surcharge du processeur. Les joueurs et les batteries de leurs appareils seront ravis.