Que s'est-il passé derrière la fin unique de « SINoALICE » [CEDEC 2024]

Lors du CEDEC 2024, les ingénieurs de production de PokeLab Yui, Misato Takada et Junya Etsuda, ont donné une session « Comment mettre fin à un jeu social qui reste profondément ancré dans la mémoire de l'utilisateur ~ L'utilisateur lui-même entrera-t-il dans la tombe ?! qui le soutient~'' a eu lieu.

"SINoALICE" (iOS / Android / PC. SINoALICE), développé par M. Takada et M. Etsuta, a mis fin à son service le 15 janvier 2024, mais juste avant cela, un événement à grande échelle a eu lieu en guise de fin. En plus des projets, diverses autres mesures ont été prises, comme la version hors ligne de l'application ``Sino Alice Da Nanika'' , et c'est devenu un sujet brûlant.
Revenons sur la séance au cours de laquelle les histoires des coulisses ont été racontées.

Fin du festival

Sino Alice est un RPG de dark fantasy dans lequel des personnages tels qu'Alice, le Petit Chaperon Rouge et Cendrillon se battent pour faire revivre leur créateur. Il proposait également des batailles de guilde en temps réel allant jusqu'à 15 contre 15.

On dit que Sino Alice avait un plan pour créer une fin solide dès le début, et avec le désir de « ne pas simplement y mettre fin » et « d'en profiter comme un festival jusqu'à la fin », ils ont créé divers plans intitulés ``Plan Finale Sino Alice'' Des mesures ont été élaborées.

Le point culminant est lorsque l'application Sino Alice se transforme en tombe du joueur, « Nanika qui était Sino Alice », mais pour y graver son nom, il doit mener une bataille de raid avec un membre de la guilde et regarder la fin du jeu.

Cependant, le chemin pour y arriver est assez difficile. Les joueurs doivent terminer les chapitres 1 à 6 de « Yokubou-hen » distribué le 20 décembre 2023, puis se battre avec les membres de la guilde dans le chapitre 7, le véritable chapitre final, distribué le 26 décembre. Le service prendra fin le 15 janvier 2024, il ne restera donc qu'environ deux semaines à compter de la mise en œuvre du chapitre 7.

De plus, pour la bataille finale, tous les membres de la guilde devaient se réunir en même temps et participer à la bataille. De plus, pour pouvoir jouer à l'arc Yokubou, vous devez également effacer les histoires distribuées jusqu'à présent. La durée de jeu prévue est de 16 heures, ce qui est une condition assez difficile pour les joueurs qui reviennent.

C'est pourquoi M. Takada et ses collègues ont pensé à un remède. Nous avions décidé d'implémenter une fonction d'assistance au combat qui faciliterait la fin du jeu même avec une faible force, mais en plus de cela, nous avons décidé de fournir une fonction de saut qui vous permettrait de démarrer le jeu depuis l'arc Yokubo.

Cette idée est née après qu'un planificateur ait déclaré : « Je voulais quelque chose comme une astuce secrète qui pourrait générer du buzz. »

Lorsqu'un ingénieur a entendu parler de cela, il a eu l'idée : « Si vous utilisez le tremblement de l'appareil, vous pouvez le mettre en œuvre dans un court laps de temps. » « Si vous secouez votre appareil 100 fois sur l'écran d'accueil, vous serez conduit à l'endroit où vous pourrez démarrer l'arc Yokubo.'' Cela a été réalisé en fonction de ce que vous avez fait.

Comme il ne s’agissait que d’une astuce, la direction ne l’a pas annoncé lors de sa première mise en œuvre et a attendu que les joueurs le remarquent. Il semble que M. Takada et ses collègues regardaient le match en suspens chaque jour, mais alors que de plus en plus de joueurs prenaient progressivement conscience de la situation, le responsable a divulgué l'information sous la forme d'un tweet chiffré le 1er janvier. Le code aurait été créé par un spécialiste du marketing.

De plus, la personne en charge du son a eu l'idée que « chaque fois que vous le secouez, un son sortait, jouant la chanson qui joue dans le gacha », et cette idée a également été adoptée.

Une fois que le tour a été reconnu, le nombre de joueurs qui ont atteint la fin comme prévu a augmenté, et M. Takada a déclaré : « C'était une bonne mesure. »

Technologie qui a soutenu la fin

Ici, M. Etsuda est monté sur scène et a expliqué le travail qui a été effectué pour garantir le bon déroulement de l'événement final.

Les problèmes majeurs étaient la « synchronisation des raids de guilde » et les « restrictions de connexion » .
Parlons d’abord de la synchronisation Guild Raid. Comme mentionné ci-dessus, la bataille finale du raid de guilde exigeait que tous les membres participent à la bataille. De plus, il y avait un ordre selon lequel le scénario qui se jouait avant et après la bataille se déroulerait en même temps.

Pour y parvenir, les problèmes étaient « comment démarrer la synchronisation » et « comment récupérer si l'application plante ».

Par conséquent, M. Etsuda a mis en place une nouvelle « zone d'attente des membres » avant la bataille. De plus, le chemin vers « Sino Alice was Nanika » a été divisé en phases telles que « scénario pré-bataille », « bataille » et « scénario post-bataille », afin que le joueur dispose d'informations sur l'endroit où ils se trouvent. S'il devait abandonner, cette information servirait de base pour déterminer le moment où il reviendrait.



Une autre raison pour laquelle des « restrictions de connexion » étaient nécessaires était que nous visions à augmenter le DAU (Daily Active Users) lors de l'événement de fin. Comme il s’agissait d’un projet sans précédent, il était difficile de prédire combien d’acteurs augmenteraient, et des inquiétudes se posaient quant à leur capacité à faire face à l’augmentation de la charge et s’il y aurait des problèmes de coûts même s’ils le faisaient.

Par conséquent, si le nombre de joueurs dépassait les attentes, nous avons décidé de limiter les connexions en utilisant une méthode appelée limite de taux de demande, mais comme mentionné ci-dessus, étant donné que les batailles de raid de guilde nécessitent la participation de tous les membres, des conditions détaillées ont été définies.

Plus précisément, « Afin d'éviter que la progression ne soit arrêtée en raison de restrictions pendant le jeu, des restrictions sont uniquement placées sur l'API de connexion utilisée lors du démarrage de l'application. » « Si l'un des membres de la guilde joue, l'API de connexion du la même guilde sera restreinte.'' Les joueurs peuvent contourner l'API de connexion.''

M. Etsuda a résumé son point de vue en disant que les restrictions de connexion sont d'une grande importance en tant que contre-mesure contre l'augmentation imprévisible de l'accès.

Gestion des tâches lorsque des personnes sont parties

Ici, M. Takada est remonté sur scène et est revenu sur la gestion des tâches lors du développement de la fin.

Le développement de la fin devait se dérouler parallèlement au travail sur les événements saisonniers/anniversaires réguliers.
Les spécifications pour la fin ont été élaborées au coup par coup à travers des rapports et des auditions des personnes impliquées, et un ingénieur a déclaré : « Il semble qu'il y ait beaucoup de travail, mais je pense que nous pouvons le faire avec le nombre actuel de personnes. » mais les spécifications ne sont pas encore officiellement publiées. Une fois le développement décidé, cela ne s'est pas très bien passé.

L'un des facteurs majeurs a été le changement de personnel. À mesure que la fin du projet approche, certaines personnes déménageront vers d'autres sites et le personnel ne sera plus embauché. Nous nous sommes retrouvés dans une situation difficile car nous n'avions pas suffisamment d'ingénieurs pour gérer les tâches à accomplir.

À ce stade, M. Takada a décidé de « suivre fidèlement les bases de la gestion des tâches », en partie parce qu'il avait peu d'expérience dans la gestion des tâches dans le cadre d'un développement à grande échelle.

Plus précisément, divisez les tâches importantes en tâches plus petites pour comprendre les heures de travail et vérifier si la mise en œuvre peut être terminée à temps. Nous avons essayé de rendre les choses visibles en les priorisant et en envisageant la compression pour des spécifications qui nécessitaient beaucoup d'heures de travail.

Comme le manque de personnel se produisait également parmi les planificateurs, on a dit que les ingénieurs se plaignaient plus fréquemment sur le site de développement, disant : « Nous n'avons pas de spécifications fixes, nous ne pouvons donc pas consacrer d'heures de travail. » '

En réponse à cela, M. Takada a confirmé les spécifications par des contrôles réguliers. À ce moment-là, les ingénieurs ont proposé des spécifications en demandant : « Est-ce que ces spécifications nous conviennent ? »

Grâce à leurs efforts, la fin a pu être mise en œuvre sans aucun retard, et M. Takada a cité "l'établissement de jalons" comme raison principale.
Ils ont décidé qu'ils seraient en mesure de vérifier cette pièce sur la machine réelle à ce moment-là et ont organisé des sessions de jeu toutes les deux semaines.

Bien sûr, tout ne s'est pas passé comme prévu, mais grâce à la séance de jeu, ils ont signalé que « cette partie serait retardée » et le suivi est devenu plus facile. M. Takada a décrit ce type de communication comme « comme effectuer un examen médical ». La séance de jeu présentait un autre avantage. L'équipe, qui travaillait sur le développement selon un calendrier strict, avait certaines inquiétudes, telles que : « Pouvons-nous vraiment le publier ? » et « Sommes-nous en train de créer quelque chose d'intéressant ? » Cependant, c'était formidable de voir ce que nous avions créé un fonctionnement sur un appareil réel. Il a donc pu l'effacer.



En repensant à la session, M. Takada a conclu en disant : « C'était vraiment formidable que les ingénieurs, les planificateurs et le marketing aient pu mettre au premier plan l'idée de « profiter pleinement de la fin du service ». 'ce qui est unique à Sinoalis.''

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!