RETOUR
Un jour, il y a 3 ans, l'équipe de The Codest a préparé un grand jeu Cody pour les programmeurs Ruby. Dans l'article d'aujourd'hui, j'aimerais décrire à quoi ressemblait le travail sur ce projet et surtout vous montrer le code du projet, qui est désormais disponible publiquement sur notre github.
Lors de la conception du jeu, notre objectif principal était de préparer un divertissement amusant pour les programmeurs, ainsi que de faire quelque chose d'intéressant dans le cadre du travail au sein de notre entreprise. Jusqu'à présent, nous n'avions aucune compétence en matière de création de jeux, c'est pourquoi le défi était de taille. En premier lieu, nous nous sommes concentrés sur ce qu'était réellement ce jeu. Après avoir élaboré le plan initial, nous nous sommes attelés à la tâche.
Dans le cadre du travail sur le jeu, nous avons décidé d'organiser un hackathon et de nous diviser en groupes chargés de tâches spécifiques. Avec une telle division de travail de 8 heures, nous avons pu réaliser l'apparence des adversaires dans le jeu, l'ensemble de la mise en page, et la fondation des tâches et des API du système entier. Au cours de l'étape suivante, nous nous sommes réunis pour des réunions de 4 heures une fois par mois, ce qui nous a permis de terminer le jeu en 3 réunions.
Comme nous sommes spécialisés dans RubyOnRails, nous avons choisi cette technologie comme la principale. Cependant, le jeu n'était pas censé être textuel et l'approche s'est donc reflétée dans l'application de type SPA. Dans le cadre de cette tâche, nous avons travaillé sur un pipeline bien connu d'actifs provenant de rails (en 2016, il n'y avait rien de mieux en principe) et l'ensemble de l'application a été conçu pour être utilisé dans le jeu. javascript sur la base de nos propres code avec l'aide de TypeScript. Dans l'application, il y avait une division standard des responsabilités : Rails en tant qu'actif et source d'API, javascript et related en tant qu'interaction avec l'utilisateur. Ici, cependant, il a fonctionné comme un hybride et certaines vues ont été simplement rendues à partir de rails tandis que d'autres - à partir de JS.
C'était notre première expérience dans ce domaine. C'était l'époque où l'on croyait au succès de CoffeScript. L'utilisation de TypeScript a nécessité l'introduction d'une gemme typescript-rails. Malheureusement, ce n'était pas la finalité, car typescript, étant un langage statiquement typé, le demandait aussi aux librairies attachées par défaut à rails.
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/jquery.d.ts (en particulier lors de l'utilisation du système de gestion des actifs intégré avec les rails).
Cody en tant que jeu nécessitait beaucoup de dynamique du côté du navigateur, ainsi que la modification de l'arbre du DOM. L'utilisation de TypeScript à la place du javascript vanille a été un grand pas en avant dans la qualité du code, la présence même de classes et d'encapsulation était très tentante pour nous.
En 2019, les applications SPA sont gérées à l'aide de la magnifique carte React ou Vue bibliothèques. Cependant, en 2015, nous l'avons fait d'une manière différente. Le typecript mentionné précédemment a été utile dans la mise en œuvre du jeu, tandis que jQuery a révoqué tout le travail lié à la requête http xml. Nous pouvons maintenant utiliser fetch, alors qu'à l'époque `$ .ajax` était tout ce qui était nécessaire pour le travail. Jetez un coup d'oeil à notre api client !
S'il s'agissait d'une API, il fallait résoudre le problème de l'authentification d'une manière ou d'une autre, n'est-ce pas ? C'est exact. Mais dans ce cas, nous sommes allés chercher (est-il possible d'écrire ici - nous avons utilisé le groupe ?!) le groupe et dans la session rails nous avons créé cookie_key et l'avons ensuite sauvegardé dans la base de données. Nous savions donc que tout allait bien.
https://github.com/codesthq/cody_the_game/search?q=cookie_key&unscoped_q=cookie_key
Le statut du jeu était stocké dans la base de données et les informations sur le nombre d'utilisateurs ayant des points provenaient de la base de données (s'agit-il de la même base de données ? Peut-on simplement la remplacer par un pronom ?). ACID est toujours utile lorsqu'il n'y a pas de cache du côté du système ;)
Dans le cas du spa, c'est la meilleure solution sans recharger la page. Nous avons résolu le problème de manière classique et l'ancre html était la meilleure solution sans étendre les dépendances inutiles. Car qui utiliserait des turbolinks ?
Si nous concevons un jeu, il ne doit sortir qu'avec de superbes graphismes et animations. À l'époque, nous avons passé de nombreuses heures à nous demander comment répondre à ces exigences dans notre application. D'une part, le canevas peut faire des miracles, d'autre part, dans un html propre, il est beaucoup plus facile de se rattraper, et tout le monde le sait. Après une recherche laborieuse de la meilleure solution, nous avons découvert que la combinaison de ces deux solutions est le svg. Il permet de présenter facilement des graphiques vectoriels, il est écrit dans le langage de balisage et, ce qui est le plus important, il peut être modifié à la volée. Fait important, il existe une bibliothèque pour les fichiers svg qui fonctionne de manière similaire à jQuery et permet d'effectuer des opérations sur l'image d'une manière unifiée. Il s'agit de: http://snapsvg.io, nous avons de très bons souvenirs de l'utilisation de cette solution particulière.
Vous trouverez ci-dessous un exemple d'utilisation de snap.svg :
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/intro.js.ts
Le fichier haml lui-même avec le squelette graphique :
https://github.com/codesthq/cody_the_game/blob/master/app/views/game/show.html.haml
Comme vous pouvez le voir, c'est presque comme un arbre DOM normal et une application rails normale !
Enfin, nous avons eu API, Graphics, SPA. Mais qu'en est-il de la mise en œuvre des solutions envoyées par les utilisateurs ?
La première chose qui nous vient à l'esprit est la méthode eval, mais nous ne sommes pas fous ;). En 2016, le docker avait le vent en poupe, c'était donc un choix naturel. Les conteneurs eux-mêmes ne garantissaient pas une isolation et une protection complètes, c'est pourquoi nous avons utilisé une solution prête à l'emploi dans le Ruby appelée https://github.com/vaharoni/trusted-sandbox. Elle a permis de mieux protéger le code avant qu'il ne quitte le bac à sable et de configurer de manière standardisée les exigences du système d'exploitation. Il était très important de limiter correctement le temps d'exécution du code, la mémoire nécessaire pour fonctionner et les cycles du processeur. Notre configuration est disponible ci-dessous
https://github.com/codesthq/cody_the_game/blob/master/config/trusted_sandbox.yml.example
Bien entendu, le même bac à sable de confiance ne garantissait rien, c'est pourquoi nous avons créé un site web spécial pour exécuter le code.
https://github.com/codesthq/cody_the_game/blob/master/app/services/task_runner/base_task.rb
Chacune des tâches avait son propre scénario de test, ce qui nous a permis de vérifier l'exactitude de la solution mise en œuvre. Pour ce faire, nous avons injecté le code utilisateur dans le scénario de test de manière à ce que tout soit exécuté de manière isolée.
https://github.com/codesthq/cody_the_game/blob/master/app/challenges/challenge/case.rb
Bien sûr, cette action a pris beaucoup de temps et, pendant la collecte des réponses, nous ne pouvions pas nous permettre d'exécuter le bac à sable, nous avons donc seulement sauvegardé le code dans la base de données, en créant une soumission et ensuite, en utilisant le long pooling, nous avons demandé au point de terminaison d'obtenir le statut du code. Cela nous a permis de soulager le serveur d'application et de vérifier les données de manière appropriée. Bien entendu, nous devions également nous protéger contre le "plantage du script" et nous avons donc limité le nombre de requêtes du serveur à l'aide de la variable ttl, que l'on peut voir ci-dessous.
Jusqu'en septembre 2011, les statistiques de jeu étaient les suivantes :
- le nombre de sessions : 1945 - les tâches envoyées : 4476 - ont envoyé des réponses correctes : 1624 - a terminé le match : 31
Comme vous pouvez le constater, les marches les plus importantes ont commencé dans la tâche # 2 parce qu'il ne s'agissait plus d'un exemple ordinaire de "hello world".
Lire aussi :
Une plongée rapide dans Ruby 2.6. Quelles sont les nouveautés ?
La rédaction de la documentation est devenue facile grâce à VuePress
Tutoriel sur les bases de Vue.js. Comment commencer avec ce framework ?
French 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek