La siguiente lista proporciona una visión general de los principales requisitos de diseño técnico que pensamos mientras trabajábamos en El misterio de Duvall Drive.Para obtener más información sobre el diseño visual de estos elementos, vea el Mystery of Duvall Drive Showcase, que destaca las diversas funciones y herramientas de Studio que usamos para crear el entorno, ambienteinmersivo.
Misiones
Hay varios tipos de misiones que los jugadores deben resolver para progresar a través de la experiencia, incluida la navegación por una serie de plataformas giratorias hasta que los jugadores puedan recuperar un objetoespecial, o encontrar diferentes ingredientes en un almacén expandido y colocarlos en una olla hirviendo.Para organizar el proceso de escritura y depuración de misiones, creamos un marco de misiones y una versión de depuración.
Marco de misión
Para asegurarnos de que unificamos cada paso de la misión a lo largo de la experiencia, diseñamos un marco simple de misión de rompecabezas para cada misión que consistía en ganchos para el comienzo y el final del rompecabezas, un espacio para leer datos de configuración y un botón para completar el rompecabezas para propósitos de depuración.Para obtener información más detallada sobre este proceso y sus parámetros, consulte Lógica de misiones.
Sellos y estados de juego
Cuando los jugadores entraban en habitaciones específicas, queríamos que interactuaran con objetos pequeños especiales conocidos como focas para activar misiones.Después de que resolvieron la misión, queríamos que agarraran el sello y lo colocaran en una ubicación predefinida dentro del vestíbulo con el fin de progresar a través del juego general.Después de que colocaron el sello en la ubicación correcta, podían continuar a otra habitación dentro de la casa y comenzar la siguiente misión haciendo clic en el objeto especial de esa habitación.
Para implementar esto, creamos estados de juego , que especificarían el período de tiempo en que los jugadores podrían comenzar el proceso como:
- Buscando un sello "corrupto" en una habitación para activar la misión.
- Recoge el sello "restaurado" cuando resuelvan la misión.
- Coloca el sello en el círculo del vestíbulo.
Los estados del juego controlan en gran medida el flujo de la experiencia y cómo los jugadores interactúan con la narrativa de la experiencia n.Para obtener más información, vea GameStateManager.
Habitaciones normales y corruptas
Queríamos tener dos estados de seis habitaciones en la casa: un estado normal y un estado corrupto.Cuando un jugador tocaría una insignia corrupta en una habitación para activar el estado corrupto de la habitación, el entorno cambiaría a una atmósfera más oscura con iluminación modificada, objetos ambientales y efectos especiales.Los jugadores entonces tendrían que resolver la misión para volver al estado normal de la sala.
Para implementar esto, preparamos un espacio especial en la experiencia que estaba muy lejos de la casa, a unos 6,500 metros de distancia en la dirección X que podía albergar el estado corrupto de una habitación.Cuando un jugador trigue cualquier estado corrupto, el estado corrupto de esa habitación específica se clona en esta área desde ServerStorage hasta la carpeta Almacenamiento temporal/clonada , luego los jugadores se teletransportan a esa habitación.Pequeñas Parts existen dentro de cada habitación normal y corrupta que sirve como puntos de generación para jugadores al entrar o salir de habitaciones.Después de que resuelvan la misión, teletransportamos simultáneamente a los jugadores de vuelta al estado normal de la sala y destruimos todos los objetos en el estado corrupto de la sala.Para obtener más información sobre los estados del juego que controlan este proceso de teletransporte, consulte GameStateManager.
Versión de depuración
Para ayudarnos a depurar periódicamente misiones, creamos una versión de la experiencia en la que no tendríamos que esperar en el vestíbulo o para las escenas de corte.Esta versión tenía trucos y botones basados en el teclado que nos permitirían completar automáticamente misiones para que pudiéramos probar rápidamente aspectos de la experiencia.Periódicamente copiaríamos y publicaríamos esta versión en la versión que planeábamos lanzar que tuviera el flujo de juego adecuado.Para distinguir estas dos versiones, hicimos un script DemoGlobalSettings para verificar el placeID, ver si se está ejecutando en Studio y habilitar/deshabilitar varios trucos y botones de juego.Para obtener más información, consulte Lógica de misiones y Guiones de configuración.
Teletransportación
Hay tres tipos de teletransportación que ocurren dentro de la experiencia:
- Teletransportar jugadores desde el sencillo vestíbulo a la zona principal de juego en un servidor reservado.
- Teletransportar jugadores desde el estado normal de una habitación al estado corrupto, y luego regresar mientras muestra una escena corta.
- Teletransportar jugadores dentro de algunos puzles, o cuando reaparecen después de caer del área de juego después de caer del área de juego.
Servidores reservados
Decidimos agrupar a los jugadores en grupos de cinco en un vestíbulo simple antes de teletransportarlos a un servidor reservado para la zona principal de juego de la casa.El vestíbulo proporcionó tiempo para que los jugadores adicionales se unieran y jugaran juntos, y los servidores reservados evitaron que los jugadores adicionales se perdieran aspectos del juego y la narrativa de unirse a la experiencia tarde.Esta teletransportación solo ocurre una vez.
Escenas cortadas
Queríamos poder transportar a los jugadores a lo largo del juego cada vez que cumplieran ciertas tareas, como tocar a un sello o completar una misión.Para implementar esto, desarrollamos una versión simple de una herramienta basada en scripts llamada EventManager que controló varias propiedades y atributos, ejecutó scripts y sonido, audioy realizó sacudidas de cámara durante un período de tiempo.Esto nos permitió mover tanto a los jugadores como transmitir dentro y fuera de diferentes habitaciones mientras ocultamos este proceso al jugador usando efectos especiales.Para obtener más información, vea Gestor de eventos.
Reaparecer jugadores
El tercer tipo de teletransportación que queríamos implementar fue un teletransporte corto con solo un cambio de coordenadas de un jugador CFrame dentro de algunos puzles y cuando los jugadores caigan y reaparezcan.A diferencia de los dos tipos anteriores de teletransportación, este tipo no solicita explícitamente transmisión asíncrona.
scriptingde juego
La programación nos permitió ejecutar en elementos específicos del juego, como desapariciendo elementos de la interfaz de usuario, crear volúmenes de gatillos para eventos clave y resaltar objetos cuando estaban en foco con el cursor del jugador.Muchos de estos sistemas dependían de etiquetar objetos para realizar un comportamiento personalizado, luego usando una variedad de scripts de cliente o servidor para contener flujos de trabajo específicos dependiendo de qué acción necesitaba ocurrir en puntos específicos de la experiencia.Para obtener más información sobre cómo implementamos estos sistemas, vea Sistemas de juego fundamentales y Sistemas de soporte.
Comportamiento personalizado con etiquetas
Queríamos una forma de agregar comportamiento personalizado para objetos, como bloquear puertas para que los jugadores tuvieran que permanecer dentro de la habitación hasta que completaran la misión activa.Para implementar esto, decidimos usar etiquetas para objetos específicos, luego usamos CollectionService para encontrar estos objetos y conectamos cualquier comportamiento correspondiente Scripts para agregar comportamiento personalizado.Teníamos una Script por cada categoría de etiqueta que actuaba como gerente para manejar todos los objetos etiquetados bajo esa categoría para que pudiéramos mantener el Script en una ubicación única en lugar de ser copiados muchas veces en DataModel.Para obtener más información, vea DoorManager , MasterAnimator , DrawerManager , KillVolumes , PlayerMissionRespawn y PianoManager.
El "gerente" Script usa una función Init para encontrar cualquier objeto etiquetado cuando la experiencia comienza y conectar un comportamiento personalizado a ellos.Por ejemplo, DoorManager encuentra cualquier objeto etiquetado con Puerta , luego le asigna el comportamiento correcto a los objetos de la puerta (mueve la puerta al abrirse, reproduce un efecto de sonido de columpio de puerta, etc.).Sin embargo, cualquier objeto que se agregue o elimine durante el tiempo de ejecución, como cualquier objeto que se agregue a una habitación corrupta después de que un jugador interactúe con un sello corrupto, pierda esta llamada inicial y nunca obtenga el comportamiento esperado.Para resolver esto, usamos CollectionService.GetInstanceAddedSignal y CollectionService.GetInstanceRemovedSignal para otorgar el mismo comportamiento a nuevos objetos que están etiquetados y no etiquetados, respectivamente.
Scripts de cliente y servidor
Queríamos reducir la banda ancha para diferentes aspectos del juego que serían costosos en el ejecución.Decidimos que cuando la funcionalidad del objeto pueda afectar la simulación para otros jugadores, como mover el objeto a través de la colisión, ejecutaríamos esto en el servidor , pero si algo está más relacionado con el diseño del entorno, como las luces, las animaciones ambientales que no afectan el juego, los efectos especiales y el sonido, audio, los ejecutaríamos en clientes >.Esto reduciría la velocidad de banda y mantendría más suaves las cambios de movimiento y de entorno en los dispositivos del usuario.