Los scripts son un componente esencial de cualquier aplicación desarrollada con Unity. La mayoría de las aplicaciones requieren scripts para responder a las entradas del jugador y programar eventos que deberían ocurrir durante el juego. El comportamiento de los objetos del juego está controlado por componentes adjuntos. Aunque Unity tiene muchos componentes integrados, aún podemos usar scripts para crear componentes personalizados. Unity admite el lenguaje de script de programación C# (si no está familiarizado con él, puede aprenderlo por separado y consultar el curso de C# que publiqué antes), y la herramienta de desarrollo utiliza Visual Studio. Generalmente creamos scripts de C# en Unity, luego escribimos el código en VS y finalmente lo ejecutamos nuevamente en Unity.
Crear un script C# es muy simple. Necesitamos crearlo en la vista Proyecto. Puede hacer clic derecho en el área en blanco de la vista Proyecto y seleccionar "Crear" -> "Script C#", o puede usar el menú barra "Activos" -> "Crear" -> "C# Script" para crear. Se seleccionará el nombre del archivo de script recién creado y se le solicitará un nuevo nombre. Es mejor ingresar el nombre del nuevo script en este momento en lugar de editarlo más tarde. Haga doble clic en el archivo de script recién creado, que se abrirá con Visual Studio de forma predeterminada. El archivo de script recién creado no es un archivo en blanco, sino una clase C# que hereda "MonoBehaviour".
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Test : MonoBehaviour
{
// Start is called before the first frame update
void Start()
{
}
// Update is called once per frame
void Update()
{
}
}
Tenga en cuenta que el nombre de la clase y el nombre del archivo deben ser los mismos y que el script debe estar adjunto a un objeto del juego para poder ejecutarse.
Este MonoBehaviour es una clase integrada de Unity. Hay dos métodos en esta clase: Inicio y Actualización.
Sabemos que el juego es un bucle infinito. Cada bucle recibirá y responderá a la entrada del usuario, renderizará objetos del juego (mallas modelo), reproducirá animaciones del juego, sonidos de efectos especiales o música de fondo, etc. Podemos entender cada ciclo como un cuadro (una representación). Sabemos que el principio de la animación se logra reproduciendo imágenes estáticas cuadro por cuadro. Para que el ojo humano sienta que esto no es una imagen, sino un efecto de animación, se deben reproducir al menos 24 imágenes consecutivas en 1 segundo para lograr el efecto final. Lo mismo ocurre con la naturaleza del juego. El motor del juego renderizará cíclicamente todos los objetos del juego en la escena N veces en 1 segundo. Este valor N es lo que llamamos FPS (cuadros por segundo). Cuanto mayor sea el FPS, mejores serán los efectos visuales del juego. Normalmente, FPS=30 para juegos móviles está bien, FPS=60 para juegos de PC está bien y FPS=90 para juegos de realidad virtual está bien. Eso sí, si nuestro hardware lo permite, alcanzar los 120 FPS es el mejor efecto. No entraremos en detalles sobre este tema, volvamos a los métodos Inicio y Actualización en MonoBehaviour. El método de actualización es el lugar principal para colocar el código, que se utiliza para manejar las actualizaciones de fotogramas de los objetos del juego (el valor de FPS es cuántas veces se ejecuta la actualización en 1 segundo). Esto podría incluir el movimiento de los personajes, responder a las entradas del usuario, básicamente cualquier cosa que deba manejarse a lo largo del tiempo mientras se ejecuta el juego. Al procesar la lógica de negocios del juego, a menudo usamos varios componentes adjuntos a los objetos del juego (la mayoría de los comportamientos de los objetos del juego se completan a través de componentes), usaremos componentes para completar diferentes funciones y relaciones entre componentes. Para que el método de actualización se ejecute normalmente, antes de realizar cualquier operación del juego, generalmente es necesario asegurarse de que los componentes del objeto del juego se puedan obtener correctamente, lo que equivale a una operación de inicialización. Por lo tanto, antes de que comience el juego (es decir, antes de que se llame al método Actualizar por primera vez), Unity llamará al método Inicio, que es donde se inicializa el objeto del juego. Podemos obtener varios componentes del objeto del juego con este método.
Cabe señalar aquí que, aunque nuestro script C# es una clase, no podemos agregarle un constructor. Esto se debe a que Unity crea una instancia de la construcción de objetos de clase de script de C#. Si intenta definir un método constructor para un componente de script, interferirá con el funcionamiento normal de Unity y puede causar problemas importantes al proyecto. Si desea completar la lógica del código en el método constructor, puede trasplantarlo al método Inicio.
A continuación, creamos un nuevo proyecto (ScriptDemo) y luego creamos un script "Test.cs" para probar los métodos Inicio y Actualización. Una vez que el archivo se haya creado correctamente, el archivo cambiará automáticamente de nombre y solo necesitamos generar "Prueba". Después de completar la entrada, haga doble clic para abrir automáticamente el script "Test.cs" usando Visual Studio.
A continuación, todo lo que tenemos que hacer es agregar las siguientes dos líneas de código.
// Start is called before the first frame update
void Start()
{
Debug.Log("start method...");
}
// Update is called once per frame
void Update()
{
Debug.Log("update method...");
}
Para reducir la longitud del documento, hemos omitido otros códigos.
Debug.Log es un comando simple que simplemente envía mensajes al panel de la Consola de Unity.
Dado que solo hay dos objetos del juego "Cámara principal" y "Luz direccional" en la escena creada de forma predeterminada, adjuntemos el archivo de script "Test.cs" al objeto del juego "Cámara principal" por ahora. Esta operación es muy simple: primero seleccionamos el objeto del juego "Cámara principal" en el panel Jerarquía, y luego los diversos controles de propiedades de la "Cámara principal" se mostrarán en el panel Inspector. Finalmente, arrastramos el archivo de script en la vista Proyecto a la vista Inspector de la "Cámara principal".
A continuación, reproducimos el proyecto actual y deberías ver este mensaje en la vista Consola en la parte inferior del Editor de Unity.
Si no puede encontrar la vista Consola, puede volver a abrirla en la barra de menú Ventana -> General -> Consola.
Descubrimos que el método de Inicio se ejecutó una vez, mientras que el método de Actualización se ejecutó continuamente hasta que el proyecto dejó de ejecutarse. En la captura de pantalla anterior, encontraremos el botón "Contraer", que superpondrá la salida del mismo código. El número de superposiciones se mostrará como un número en el extremo derecho. Por ejemplo, la salida del método de actualización "método de actualización..." en la imagen de arriba se ejecuta repetidamente 94 veces. Entonces, ¿cuántas veces por segundo se ejecuta este método de actualización (valor FPS)?
Podemos usar código para calcular el número de ejecuciones de Actualización en 1 segundo para obtener:
public class Test : MonoBehaviour
{
private int count = 0;
private float detaTime = 0.0f;
void Update(){
//Debug.Log("update method...");
// 累加帧数
count++;
// 累加时间
detaTime += Time.deltaTime;
// 累加时间超过1秒
if (detaTime >= 1.0f)
{
// 计算FPS值
float fps = count / detaTime;
Debug.Log("FPS = " + fps);
// 帧数和累加时间清零
count = 0;
detaTime = 0;
}
}
}
La lógica del código anterior es muy simple: utiliza una variable para acumular el número de veces que se ejecuta el método de actualización y, al mismo tiempo, acumula el tiempo de ejecución actual. Time.deltaTime es un valor de atributo que nos proporciona Unity . que representa el tiempo entre el fotograma actual y el fotograma anterior.Diferencia de tiempo. Por lo tanto, solo necesitamos acumular el valor de este atributo para obtener el tiempo de ejecución de la actualización detaTime. Dado que nuestro código se ejecuta en el nivel de milisegundos, cuando detaTime excede o iguala 1 segundo, podemos usar count/detaTime para obtener el valor de FPS. ¿Por qué no generar directamente el valor de conteo cuando detaTime es igual a 1 segundo? Debido a que este detaTime no puede ser igual con mucha precisión a 1. En la mayoría de los casos, su valor puede ser 1.001 o similar, por lo que también necesitamos usar count/detaTime para hacer un cálculo de división Obtener un valor de FPS que contenga decimales.
A continuación, reproducimos el proyecto actual y vemos el resultado de la vista de consola.
Descubrimos que este valor de FPS no es un valor fijo, probablemente esté entre 300 y 400 (dependiendo de la configuración de la computadora).
Hay una fila de botones en la esquina superior derecha de la ventana del Juego, uno de los cuales es "Estadísticas". Cuando hacemos clic en él, aparecerá una nueva ventana emergente. En esta nueva ventana emergente, también podemos vea el valor de FPS.
Ambos son más o menos iguales. Dado que FPS no es un valor fijo, mencionamos anteriormente que los valores de FPS del teléfono móvil (30), PC (60) y VR (90) son en realidad solo un valor promedio esperado. ¿El valor de FPS que se muestra en nuestro proyecto está entre 300 y 400, que es significativamente más alto que el valor promedio de FPS de 60 en el lado de la PC? No necesitamos un valor de FPS tan alto en absoluto (una pérdida de rendimiento de la computadora) ¿Cómo lo configuramos en 60? Esta cuestión es un poco más complicada.
En primer lugar, debemos comprender la relación entre el valor de FPS y la tarjeta gráfica y el monitor.
La tarjeta gráfica se encarga de dibujar las imágenes y enviarlas al monitor, a cada imagen se le puede llamar fotograma. Los fotogramas del juego (FPS) son la cantidad de imágenes que la tarjeta gráfica dibuja por segundo. El monitor mostrará en la pantalla la imagen dibujada por la tarjeta gráfica. La frecuencia de actualización del monitor es la cantidad de imágenes que se muestran en la pantalla del monitor por segundo. En circunstancias normales la frecuencia de refresco de la pantalla de nuestro ordenador es de 60HZ, lo que significa que el monitor muestra 60 imágenes por segundo, por supuesto, también podemos modificar este valor manualmente. Entonces, ahora surge la pregunta: ¿qué pasará si el valor de FPS y la frecuencia de actualización del monitor son diferentes? Si el FPS es mayor que la frecuencia de actualización del monitor, las imágenes adicionales no se mostrarán en la pantalla. Debido a que la animación se genera a través de imágenes continuas, si la pantalla solo muestra una parte de la imagen, entonces el efecto de animación es obviamente incoherente. Si el FPS es inferior a la frecuencia de actualización del monitor, el efecto de animación se bloqueará y el efecto no será consistente. Tenga en cuenta que en el primer caso, la animación es incoherente debido a que faltan imágenes y, en el último caso, la animación está bloqueada e incoherente debido a que la visualización es demasiado lenta. Pensando en esto, todos deberían ser más claros. El mejor efecto debería ser hacer que los dos valores sean aproximadamente iguales. Es mejor si el FPS es ligeramente mayor que la frecuencia de actualización del monitor, para que el efecto de animación sea el mejor. Para solucionar este problema, apareció la tecnología de sincronización vertical . Después de activar la sincronización vertical, la computadora esperará a que se complete la renderización de la imagen anterior antes de emitir un comando para iniciar la siguiente renderización, lo que significa que la tarjeta gráfica dibujará la imagen de acuerdo con la salida del monitor (forzando el número máximo de fotogramas del juego no debe exceder la frecuencia de actualización). La única desventaja de hacer esto es que limita el rendimiento de la tarjeta gráfica. Sin embargo, lo que todos deben entender es que cuanto mayor sea el valor de FPS, más fluida será la reproducción de la animación, lo que brindará a los jugadores una excelente experiencia de juego. Esto permanece sin cambios.
En Unity, el promedio de FPS utilizado por el juego se puede especificar a través de Application.targetFrameRate . El targetFrameRate predeterminado es un valor de -1, lo que indica que el juego debe renderizarse a la velocidad de fotogramas predeterminada de la plataforma.
Esta tasa predeterminada depende de la plataforma:
- En plataformas independientes (por ejemplo, PC), la velocidad de fotogramas predeterminada es la velocidad de fotogramas máxima alcanzable.
- En plataformas móviles, la velocidad de fotogramas predeterminada suele ser de 30 fotogramas por segundo.
- En WebGL, el valor predeterminado permite al navegador elegir la velocidad de cuadros para que coincida con el tiempo del bucle de renderizado.
- Al usar VR, Unity usará la velocidad de fotogramas objetivo especificada por el SDK e ignorará el valor especificado por el juego.
Al ver la explicación anterior, no nos resulta difícil entender que el FPS del proyecto que acabamos de ejecutar está entre 300 y 400, porque el valor predeterminado de la plataforma de PC es lograr todo lo que pueda, esto está relacionado con el Grado de la tarjeta gráfica de la computadora personal. En este caso, configuraremos Application.targetFrameRate en 60, porque la frecuencia de actualización del monitor de mi computadora es 60.
Establecemos el valor de FPS en el método "Inicio" en el script "Test.cs", de la siguiente manera:
void Start()
{
//Debug.Log("start method...");
Application.targetFrameRate = 60;
}
Reproduzca nuestro proyecto nuevamente y vea la salida de la consola y la ventana emergente "Estadísticas".
Descubrimos que los dos son más o menos iguales, ambos son aproximadamente iguales a 60, lo que demuestra que nuestra configuración funciona. No te preocupes, hemos ignorado una tecnología de sincronización vertical. En Unity, podemos usar QualitySettings.vSyncCount para establecer si activar la tecnología de sincronización vertical: 0 significa no activada y mayor que 0 significa activada. Al mismo tiempo, también podemos hacer clic en Editar->Configuración del proyecto->Calidad en la barra de menú.Hay un parámetro VSync Count, que también representa la sincronización vertical.
Tiene tres valores para elegir: No sincronizar, Cada V en blanco y Cada segundo V en blanco
No sincronizar: valor 0, no se establece ninguna sincronización vertical y la velocidad de cuadros la especifica Application.targetFrameRate
Cada V en blanco: valor 1, velocidad de fotogramas 60, Application.targetFrameRate no es válido
Cada segundo V en blanco: valor 2, velocidad de fotogramas 30, Application.targetFrameRate no es válido
El valor predeterminado es Cada V en blanco (valor 1). Según la explicación oficial, si se establece la propiedad QualitySettings.vSyncCount, se ignorará targetFrameRate y el juego utilizará vSyncCount y la velocidad de renderizado predeterminada de la plataforma para determinar la velocidad de fotogramas objetivo. La relación entre el valor de configuración de vSyncCount y la velocidad de cuadros también se proporciona arriba. Además, este vSyncCount no funcionará en plataformas móviles, sino que se utiliza targetFrameRate para establecer la velocidad de fotogramas. Además, en la plataforma de realidad virtual, vSyncCount no funcionará, pero se configura a través del SDK de realidad virtual. Esta brecha es realmente enorme para el desarrollo de juegos de Unity. Pero cuando configuramos VSync Count en Cada segundo V en blanco, el valor de FPS no cambia. No sé cuál es el problema, parece que vSyncCount no ha funcionado desde el principio, así que no lo discutiré.