La liste suivante fournit une vue d'ensemble des principales exigences de conception techniques que nous avons envisagées lorsque nous avons travaillé sur Le mystère de Duvall Drive.Pour plus d'informations sur le design visuel de ces éléments, voir le Mystère du showcase de Duvall Drive, qui met en évidence les différentes fonctionnalités et outils de Studio que nous avons utilisés pour créer l'environnement immersif.
Missionnes
Il existe plusieurs types de missions que les joueurs doivent résoudre pour progresser dans l'expérience, y compris la navigation dans une série de plateformes rotatives jusqu'à ce que les joueurs puissent récupérer un itemspécial, ou trouver différents ingrédients dans une réserve étendue et les placer dans une marmite bouillante.Pour organiser le processus de scripting de création et de débogage de missions, nous avons créé un cadre de mission et une version de débogage.
Cadre de mission
Pour nous assurer que nous avons unifié chaque étape de la mission tout au long de l'expérience, nous avons conçu un cadre de mission simple puzzle pour chaque mission qui comprenait des crochets pour le début et la fin du puzzle, un endroit pour lire les données de configuration et un bouton pour terminer le puzzle pour des fins de débogage.Pour plus d'informations détaillées sur ce processus et ses paramètres, voir logique des missions.
Séals et états de jeu
Lorsque les joueurs entraient dans des pièces spécifiques, nous voulions qu'ils interagissent avec de petits objets spéciaux appelés phoques pour déclencher des missions.Après avoir résolu la mission, nous voulions qu'ils prennent le sceau et le placent dans un emplacement prédéfini dans le hall afin de progresser dans le partieglobal.Après avoir placé le sceau à l'endroit correct, ils pouvaient ensuite poursuivre dans une autre pièce de la maison et commencer la prochaine mission en cliquant sur l'objet spécial de cette pièce.
Pour implémenter cela, nous avons créé états de jeu , qui spécifieraient la période de temps pendant laquelle les joueurs pourraient commencer le processus comme:
- Recherche d'un sceau « corrompu » dans une salle pour déclencher la mission.
- Prenez le sceau "restauré" lorsqu'ils résolvent la mission.
- Placez le sceau dans le cercle du foyer.
Les états de jeu contrôlent en grande partie le flux de l'expérience et la façon dont les joueurs interagissent avec la narration de l'expérience narrative.Pour plus d'informations, voir GameStateManager.
Salles normales et corrompues
Nous voulions avoir deux états de six chambres dans la maison : un état normal et un état corrompu.Lorsqu'un joueur toucherait un sceau corrompu dans une salle pour déclencher l'état corrompu de la salle, l'environnement changerait pour une atmosphère plus sombre avec une lumière modifiée, des objets environnementaux et des effets spéciaux modifiés.Les joueurs devraient ensuite résoudre la mission pour retourner à l'état normal de la salle.
Pour mettre en œuvre cela, nous avons préparé un espace spécial dans l'expérience qui était très loin de la maison, à environ 6 500 studs de distance dans la direction X qui pouvait accueillir l'état corrompu d'une salle.Lorsqu'un joueur déclenche n'importe quel état corrompu, l'état corrompu de cette salle spécifique se clone dans cette zone de ServerStorage à TempStorage/Cloned , puis les joueurs se téléportent dans cette salle.Les petites Parts existent dans chaque pièce normale et corrompue qui sert de points d'apparition pour les joueurs lors de l'entrée ou de la sortie des pièces.Après avoir résolu la mission, nous téléportons simultanément les joueurs dans l'état normal de la salle et détruisons tous les objets dans l'état corrompu de la salle.Pour plus d'informations sur les états de jeu qui contrôlent ce processus de téléportation, voir GameStateManager .
Version de débogue
Pour nous aider à déboguer périodiquement des missions, nous avons créé une version de l'expérience où nous n'aurions pas à attendre dans le lobby ou pour les scènes coupées.Cette version avait des raccourcis et des boutons basés sur le clavier qui nous permettraient d'effectuer automatiquement des missions afin que nous puissions rapidement tester des aspects de l'expérience.Nous copierions périodiquement cette version et la publierions dans la version que nous avions prévue de libérer avec le bon flux de jeu.Pour distinguer ces deux versions, nous avons créé un script DemoGlobalSettings pour vérifier l'ID du lieu, voir s'il est exécuté dans Studio, et activer/désactiver diverses astuces et boutons de jeu.Pour plus d'informations, voir Logique des missions et Scripts de configuration.
Téléportation
Il existe trois types de téléportation qui se produisent dans l'expérience :
- Téléportation des joueurs du simple lobby vers la zone de jeu principale dans un serveur réservé.
- Téléportation des joueurs de l'état normal d'une salle vers l'état corrompu, puis retour en arrière tout en montrant une scène de coupe.
- Téléportation des joueurs dans certains puzzles, ou lorsqu'ils réapparaissent après être tombés de la zone de jeu.
Serveurs réservés
Nous avons décidé de regrouper les joueurs en groupes de cinq dans un simple lobby avant de les téléporter vers un serveur réservé pour la zone principale du jeu de la maison.Le lobby a fourni du temps pour que les joueurs supplémentaires rejoignent et jouent ensemble, et les serveurs réservés ont empêché les joueurs supplémentaires de manquer des aspects du gameplay et de la narration de rejoindre l'expérience plus tard.Cette téléportation ne se produit qu'une seule fois.
Scènes coupées
Nous voulions être en mesure de transporter les joueurs tout au long du jeu chaque fois qu'ils accomplissent certaines tâches, comme toucher un seal ou terminer une mission.Pour implémenter cela, nous avons développé une version simple d'un outil basé sur des scripts appelé Gestionnaire d'événements qui contrôlait diverses propriétés et attributs, exécutait des scripts et de l'audio, et effectuait des secousses de caméra pendant une période de temps.Cela nous a permis de déplacer les joueurs et de diffuser dans et hors de différentes pièces tout en cachant ce processus au joueur en utilisant des effets spéciaux.Pour plus d'informations, voir gestionnaire d'événements.
Faire réapparaître les joueurs
Le troisième type de téléportation que nous voulions implémenter était un téléport court avec seulement un changement de coordonnées du joueur CFrame dans certains puzzles et lorsque les joueurs tombent et réapparaissent.Contrairement aux deux types précédents de téléportation, ce type ne demande pas explicitement de streaming en aval.
scriptingdu jeu
La programmation nous a permis d'exécuter sur des éléments spécifiques du jeu, tels que l'effacement des éléments d'interface utilisateur, la création de volumes déclencheurs pour les événements clés et la mise en évidence des objets lorsqu'ils étaient en focus avec le curseur du joueur.Beaucoup de ces systèmes reposaient sur la marquage d'objets pour effectuer un comportement personnalisé, puis utilisaient une variété de scripts clients ou serveurs pour contenir des flux de travail spécifiques en fonction de l'action qui devait se produire à des points définis dans l'expérience.Pour plus d'informations sur la manière dont nous avons implémenté ces systèmes, voir systèmes de jeu fondamentaux et systèmes de soutien.
Comportement personnalisé avec des balises
Nous voulions un moyen d'ajouter un comportement personnalisé pour les objets, comme verrouiller les portes afin que les joueurs doivent rester dans la salle jusqu'à ce qu'ils aient terminé la mission active.Pour implémenter cela, nous avons décidé d'utiliser des balises pour des objets spécifiques, puis nous avons utilisé CollectionService pour trouver ces objets et connecter tout comportement correspondant Scripts pour ajouter un comportement personnalisé.Nous avions un Script pour chaque catégorie de balise qui a agi en tant que gestionnaire pour gérer tous les objets étiquetés dans cette catégorie afin que nous puissions garder le Script dans un seul emplacement plutôt que d'être copié plusieurs fois dans DataModel .Pour plus d'informations, voir DoorManager , MasterAnimator , DrawerManager , KillVolumes , PlayerMissionRespawn et PianoManager.
Le "gestionnaire" Script utilise une fonction Init pour trouver tous les objets étiquetés lors du démarrage de l'expérience et les connecter à un comportement personnalisé.Par exemple, DoorManager trouve tout objet étiqueté avec porte , puis il attache le bon comportement aux objets de porte (déplace la porte ouverte lorsqu'elle est cliquée, joue un effet sonore de balancement de porte, etc.).Cependant, tous les objets qui sont ajoutés ou supprimés pendant l'temps d'exécution, tels que tout objet ajouté à une salle corrompue après que le joueur interagisse avec un sceau corrompu, manquent cet appel initial et n'obtiennent jamais le comportement attendu.Pour résoudre cela, nous utilisons CollectionService.GetInstanceAddedSignal et CollectionService.GetInstanceRemovedSignal pour accorder le même comportement aux nouveaux objets qui sont étiquetés et non étiquetés, respectivement.
Scripts client et serveur
Nous voulions réduire la bande passante pour différents aspects du jeu qui seraient coûteux en termes de performance.Nous avons décidé que lorsque la fonctionnalité d'un objet peut affecter la simulation pour d'autres joueurs, comme déplacer un objet par collision, nous exécuterions cela sur le serveur , mais si quelque chose est plus lié au design de l'environnement, comme des lumières, des animations environnementales qui n'affectent pas le partie, des effets spéciaux et de l'audio, nous les exécuterions sur les clients .Cela réduirait la bande passante et garderait les changements de mouvement et d'environnement plus doux sur les appareils des utilisateurs.