En raison du battage médiatique omniprésent à propos de Tchernobyl au début de l'été (au moins dans l'industrie de l'énergie nucléaire), ainsi que des mots à la mode de la numérisation et de la gamification, nous, à IBRAE RAS , avons décidé de créer une sorte d'application de quête dans laquelle le fonctionnement d'une unité d'énergie nucléaire est conceptuellement modélisé et réalisé. ses tests dans le parc Bitsevsky.

Introduction

L'objectif initial de la création d'une telle application est bien sûr de savoir comment simuler simplement et facilement le processus de gestion d'un objet aussi complexe, non seulement du point de vue technique, mais aussi du côté psychologique (en raison de la relation de trois parties différentes: opérateurs de gare, gouvernement et saboteurs). Un autre objectif est de faire en sorte que les gens se sentent comme l'une des parties au processus et de voir comment ils se comportent à leur place dans la vie réelle. Je ne parle pas d'éducation et de programme éducatif, en principe, tous les participants à notre quête sont plus ou moins familiers avec ce domaine de l'activité humaine, mais néanmoins, vous pouvez toujours apprendre quelque chose de nouveau. Et bien sûr, nous voulions nous amuser lors des derniers jours chauds de cette 2019.

L'essence de la quête est la suivante: les participants sont répartis en trois équipes (opérateurs de gare, gouvernement et saboteurs), puis chacun d'eux est envoyé pour effectuer des tâches de géolocalisation. Parallèlement à la course à pied et à la résolution d'énigmes, chacune des équipes agit sur le réacteur via une application s'exécutant sur un site Internet. Dans le même temps, les équipes peuvent influencer le réacteur dans une mesure limitée, notamment en dépensant des points d'action qu'ils reçoivent une fois les tâches terminées avec succès (sous la forme de codes promotionnels pour l'application).

À la fin de la quête, le temps passé à terminer la quête est ajusté en fonction du succès avec lequel les équipes ont contacté le réacteur. Je dois dire tout de suite qu'à la suite des premiers et seuls tests en ce moment, tout le monde a cessé de prêter attention au temps, et a juste marché autour des beaux endroits de la forêt de Bitsevsky, en particulier, la montagne chauve et l'ancien temple slave, a effectué des tâches et a profité du soleil de septembre si doucement réchauffé avec du miel ...

App

L'application est écrite en Python. Le frontend (c'est l'entrée / sortie des données du lecteur) a été créé en utilisant vuejs, jquery et flask. Le backend (logique du réacteur et traitement des événements) a été écrit en python pur. La communication entre frontend et backend a été réalisée à l'aide d'une base de données (SQLite). La base de données était enveloppée de sqlachemy. Pour déployer l'application, utilisez Yandex Cloud.

Frontend

La partie serveur est écrite en Python (flacon). La partie client (interface pour le player) a été créée en utilisant vuejs, jquery et un petit rendu des modèles de page sur le serveur.
Lorsque vous accédez au site Web, le participant est invité à entrer un code unique à chaque équipe, après quoi il entre dans le menu principal.


Le menu principal se compose de 5 éléments:

1. Graphiques avec paramètres du réacteur
2. Entrez le code promotionnel
3. Panneau de contrôle
4. La carte
5. Sortez

Dans la fenêtre de visualisation du graphique, le lecteur peut suivre l'état actuel et plusieurs états précédents du réacteur. Regardez également le taux de changement de puissance, les risques d'accident, leur nombre, et voyez également les marqueurs des points de victoire.


Dans la fenêtre de saisie des codes promotionnels. Un participant peut activer un code promotionnel reçu d'une manière ou d'une autre, en règle générale, après qu'une équipe ait réussi un test.


Un état du réacteur est également disponible dans le panneau de commande, similaire au panneau d'affichage graphique. Ensuite, une pile d'événements en cours s'affiche avec le nom, l'équipe, le compteur jusqu'à la fin de l'événement, ainsi que la possibilité de son annulation (uniquement la vôtre).


Et bien sûr les actions elles-mêmes. Ils sont uniques à chaque équipe. Par exemple, un large éventail d'actions est disponible pour que les opérateurs contrôlent le réacteur (barres de contrôle, débit du fluide de travail, ajout de bore, etc.). Pour le gouvernement, il s'agit de toutes sortes d'exigences et de restrictions sur le fonctionnement de l'unité (augmenter la charge, mettre la pression sur le personnel de la station). Pour les saboteurs, c'est l'échec des pompes, des soudeurs, etc.

Pour chaque équipe, des actions sont disponibles qui annulent les actions des autres, comme une opération anti-terroriste, l'introduction d'un espion dans le gouvernement ou la corruption de fonctionnaires (bien sûr, il n'y a rien de tel dans la vraie vie, mais pour équilibrer le jeu, nous avons dû inventer des choses).

Toutes les actions des parties sont décrites dans le tableau:


Dans l'onglet Carte, une carte est disponible à partir de l'application Yandex Maps créée à l'aide du concepteur de carte (pour plus de détails, voir Préparation du jeu ).

Backend

L'ensemble du backend est écrit en Python pur. En fait, le code entier se compose d'un objet Reactor (réacteur, unité de puissance, station) avec un paramètre de puissance ou d'état. À chaque pas de temps (réglé manuellement, nous définissons 1 seconde), l'état change en fonction des événements survenus à cette étape. La pile des événements actuels est mise à jour à chaque étape en accédant à la base de données, qui à son tour est remplie par les participants au jeu depuis l'interface de l'application Web.

Pour plus de commodité, tous les événements sont collectés dans une fabrique d'événements et reçoivent l'objet réacteur et son identifiant unique (numéro de ligne dans la base de données) en entrée. Étant donné que l'objet de classe de réacteur sait tout ce qui se passe dans l'application, les événements en savent donc tout, ce qui rend le processus de création très flexible.

Pour les tests, des bots ont également été créés qui agissaient selon une stratégie. Pour décrire ces logiques, une fabrique de stratégies a également été créée.

Une usine a également été créée pour compter les points, afin de varier la logique de comptage d'un jeu à l'autre. La logique de base a créé un point de victoire à chaque pas de temps et l'a donné à l'une des équipes en fonction du niveau de puissance à ce pas (50-75 - opérateurs, 75-100 - gouvernement, 0 et plus de 100 - saboteurs, dans d'autres cas à personne).

Quête

La préparation

La préparation principale a consisté à trouver des emplacements pour la quête, ainsi que des tests préliminaires de l'application en laboratoire.

Pour préparer les lieux, une semaine avant l'événement, l'organisateur a été abandonné dans la forêt de Bitsevsky. Il a parcouru le territoire et a trouvé des endroits intéressants et accrocheurs, à chaque endroit, il a effectué trois opérations:

1. J'ai enregistré la géolocalisation (en utilisant l'application Yandex Maps yandex.ru/maps );
2. Qualité du réseau mesurée (à l'aide de l'application Speedtest www.speedtest.net );
3. A pris une photo ou une vidéo.

En conséquence, 30 emplacements ont été collectés (10 pour chaque équipe).

Yandex Maps a permis de simplifier considérablement la création d'une carte, grâce au constructeur de cartes yandex.ru/map-constructor . Il vous permet d'ajouter votre position, vos zones et toutes sortes de marques sur la carte. Intégrez-le ensuite dans votre application sous forme de code JavaScript ou iframe ou placez-le sous forme de lien, et au pire, imprimez-le. Les emplacements peuvent être ajoutés en les important à partir d'un fichier XLSX, CSV, KML, GPX ou GeoJSON. Le seul inconvénient était l'impossibilité d'importer des emplacements de cartes Yandex ordinaires directement au constructeur (au moins, nous ne l'avons pas trouvé), j'ai dû les interrompre dans une table xlsx et les importer déjà. Les zones avec une mauvaise qualité de réseau ont été mises en évidence dans le concepteur de carte comme une zone rouge.


La veille du match (enfin, comme d'habitude) nous avons testé le jeu avec 3 personnes (1 de chaque équipe). En général, il n'y a pas eu de commentaires particuliers, nous n'avons que légèrement ajusté l'estimation préliminaire du coût des actions des équipes. Je note tout de suite que le jeu lui-même a révélé quelques problèmes (en conclusion), et la conclusion est que nous pouvions à peine les découvrir dans des conditions de serre.

Le jeu

Le matin du 14 septembre 2019, nous avons réuni des participants dans la forêt de Bitsa. Au début, notre athlète, membre du Komsomol et juste un bon scientifique ont effectué des exercices incendiaires le matin.

Ensuite, les participants ont été divisés en équipes, leur ont donné un code promotionnel de départ et ont annoncé le début du jeu.

Les équipes se sont lentement dispersées dans des endroits (maintenant je comprends, probablement parce qu'elles ont essayé de comprendre l'application en cours de route). Au cours des 10 à 15 premières minutes, les joueurs ont eu des difficultés, mais ils se sont habitués à cela et leur attention s'est tournée vers l'obtention de codes promotionnels.

Pour plus d'enthousiasme, nous avons mis en évidence un personnage spécial dans une coiffure visible de loin, qui a rendu visite aux équipes et a posé des questions sur les codes promotionnels (en même temps, il a corrigé les jambages dans la quête).


Je dois dire que, après nous être entièrement concentrés sur l'application, nous avons complètement abandonné la préparation de la quête, en conséquence, nous avons terminé une partie des accessoires déjà la nuit avant la quête et oublié d'en acheter une. Par exemple, étant donné que nous avons oublié d'acheter un nombre suffisant de seaux, nous avons dû rivaliser mentalement avec le versement d'eau, car nos joueurs avaient une imagination bien développée.

En général, les équipes ont commencé à faire des tâches non pas pour passer tous les points plus rapidement, mais pour obtenir plus que des codes promotionnels en or . Il en est venu à une mendicité impudente, qui a bien sûr été sévèrement réprimée. À un moment donné, nous avons épuisé les codes promotionnels bonus, mais les équipes n'ont aucune envie de les obtenir. La conclusion est donc de préparer plus de codes promotionnels et de questions / tâches pour les recevoir.

Le moment peut-être le plus mémorable pour moi a été l'appel d'un participant de l'équipe gouvernementale à l'équipe des opérateurs, indigné par la qualité de leur travail et les exigences:

1. Augmenter la puissance plus rapidement (à un moment donné, l'équipe de l'opérateur, ayant une grande marge de points de victoire, n'était pas rentable pour l'augmenter et ils ont gardé l'unité à faibles charges),
2. Il vaut mieux réguler la puissance à fortes charges (puisque c'est avec eux que les saboteurs ont commencé à faire toutes sortes de sales tours, et que les opérateurs n'ont pas toujours eu le temps d'y répondre).

Ce à quoi les opérateurs ont raisonnablement répondu qu'ils n'avaient pas suffisamment de points d'action (lire: financement) pour répondre à leurs souhaits et seraient heureux si l'équipe gouvernementale en partageait un peu. Malheureusement, le transfert de points n'a pas été mis en œuvre, mais à l'avenir, compte tenu de ce précédent, nous allons certainement le mettre en œuvre. À l'avenir également, il serait intéressant d'ajouter le chat à l'application de correspondance entre les équipes afin d'encourager les équipes à interagir plus activement les unes avec les autres.

En général, cette photo caractérise bien le processus de travail dans des endroits: quelqu'un résout la tâche, quelqu'un contrôle le réacteur, quelqu'un aime la vie et quelque part en arrière-plan, un chien se cache.

En fin de compte

Quelque chose s'est passé, quelque chose non. Les principaux problèmes n'étaient pas des paramètres de réacteur très bien choisis, ce qui a affecté négativement le gameplay:

1. taux de croissance des accidents;
2. inertie du réacteur.

Le premier a presque immédiatement effondré le réacteur à 0 après avoir atteint des valeurs de puissance critique (plus de 100) et les opérateurs n'ont tout simplement pas eu le temps de réagir, car ils n'avaient que quelques secondes pour le faire (bien qu'il existe des exemples où ils ont réussi à le faire, par exemple, en ajoutant du bore à cœur du réacteur).


Le second a rendu les événements assez rapides et n'a pas permis aux participants d'évaluer la situation et de prendre une décision éclairée. En réalité, bien sûr, c'est probablement ce qui se passe, mais n'oubliez pas que les équipes couraient toujours autour des emplacements et effectuaient diverses tâches, ce qui les détournait du bloc. Il fallait, au minimum, prévoir dans le programme la possibilité de contrôler les paramètres en temps réel, ce que nous n'avons pas fait.

Dans le cadre de la quête, nous avons spécifiquement échoué à la question avec les accessoires, à la suite de quoi nous avons dû trouver une tâche en temps réel avec du matériel improvisé. Eh bien, le sens même de la quête a été transformé en se déplaçant rapidement dans des endroits afin d'être le premier à recevoir des codes promotionnels pour générer des points bonus (oh, cette soif de profit ...). Mais le plus important, à la fin, nous avons eu une bonne humeur, de nombreux moments mémorables, ainsi que la satisfaction de notre propre curiosité.

Les statistiques du jeu peuvent être trouvées dans réacteur - quest.imtqy.com , un calendrier interactif (sur les ordinateurs personnels), en bas, vous pouvez sélectionner la plage de temps d'intérêt pour une vue plus détaillée de celui-ci.

Le code d'application est publié sur GitHub github.com/reactor-quest/reactor-quest vous pouvez l'utiliser librement.

Tout bon et paisible atome, une équipe de jeunes scientifiques IBRAE RAS!