Puede acceder al curso completo aquí: Mobile desarrollo del juego para principiantes

Tabla de contenidos

Almacenamiento en caché de objetos

En la Unidad, hay muchas funciones que podemos utilizar para conseguir fácilmente objetos / componentes.


  • GameObject.Find
  • GameObject.GetComponent
  • GameObject.FindObjectOfType
  • GameObject.FindObjectWithTag
  • Camera.main

    No se recomienda

    llamar a estos cada cuadro o con frecuencia. Lo que debe hacer, es el objeto de caché para que pueda utilizarlo fácilmente siempre que lo desee.

    Este es un ejemplo donde se encuentra la “bola” objeto cada cuadro y cambiar su color a azul. Esto es muy poco optimizada.
    vacío Update () {GameObject.Find ( «bola») getComponent () = material.color Color.blue;..}. 1234voidUpdate () {GameObject.Find ( «bola») getComponent (). material.color = Color.blue;}

    Una forma de optimizar esto, es para almacenar en caché la propiedad. Creamos una variable procesador de malla y en la función de Awake, active esta malla de render de la pelota. Luego, en la función de actualización, cambiamos el color de cada cuadro.
    MeshRenderer ballMeshRenderer privado; nula Awake () {// obtener malla de render ballMeshRenderer = GameObject.Find ( «bola») de la pelota getComponent ();.} Void Update () {ballMeshRenderer.material.color = Color.blue; } 123456789101112privateMeshRenderer ballMeshRenderer; voidAwake () {// obtener malla rendererballMeshRenderer = GameObject.Find ( «Ball») de la pelota getComponent ();.} voidUpdate () {ballMeshRenderer.material.color = Color.blue;}

    Reducción de llamadas de función

    Si usted tiene una función costosa que no es necesario llamar a cada cuadro – no lo hacen. Cosas como actualizaciones de AI, encauzamiento, etc … podemos llamarlo cada 0,2 segundos en lugar de cada cuadro. Básicamente se sentirán lo mismo, pero con importantes aumentos de rendimiento.

    Este es un ejemplo en el que estamos llamando a una función caro cada marco. A 60 fps, esto significa que estamos llamando a la función 60 veces por segundo.
    vacío Update () {ExpensiveFunction ();} void ExpensiveFunction () {} 123456789voidUpdate () {ExpensiveFunction ();} voidExpensiveFunction () {}

    Una alternativa, sería la de llamar a esa función cada 0,2 segundos. Este bajarla de 60 veces por segundo a 5 veces por segundo.
    lastCallTime privada flotador; nula Update () {// llamar a la función cada 0,2 segundos si (time.time – lastCallTime> = 0.2f) ExpensiveFunction ();} void ExpensiveFunction () {} 12345678910111213privatefloatlastCallTime; voidUpdate () {// llamar al función de cada 0,2 secondsif (time.time-lastCallTime> = 0.2f) ExpensiveFunction ();} voidExpensiveFunction () {}

    otras optimizaciones

    • Reducir las llamadas debug.log.
    • Reducir la frecuencia de Raycasts.
    • No utilice bucles en la función de actualización.
    • Si va a crear instancias de lotes de un mismo objeto:. Uso Agrupación de objetos

      Transcripción

      Hey, todo el mundo. En esta lección, que vamos a repasar un par de diferentes optimizaciones de secuencias de comandos que se puede implementar en sus proyectos con el fin de aumentar el rendimiento. Al igual que con los juegos móviles, sobre todo, el rendimiento es algo que siempre hay que tener en cuenta.

      Por lo tanto, lo primero que vamos a tener en cuenta es el almacenamiento en caché de objetos. Ahora, cada vez que Wanna acceso y en el interior de la Unidad de objetos, se podría pensar que, oh, la función GameObject.Find, sólo puede encontrar fácilmente los objetos de esa manera o conseguir un componente. Aquí, en este ejemplo, estoy encontrando el objeto, Pelota, y acceder al componente MeshRenderer para cambiar el color a azul cada fotograma. Ahora bien, esta es una línea muy caro de código y cuando digo caro, me refiero a que está utilizando una gran cantidad de potencia de procesamiento y se necesita mucho tiempo para funcionar en términos de una función.

      Y lo que podemos hacer con esto es en realidad la memoria caché del componente MeshRenderer de la pelota en lugar de tener que buscar la pelota cada cuadro y encontrar el componente MeshRenderer cada cuadro. Así que, en cambio, lo que podemos hacer es que la memoria caché. Podemos crear una variable privada para que la bola MeshRenderer y en la función de Awake, que es donde vamos a llamar a la función GameObject.Find para encontrar el objeto pelota y obtener el componente MeshRenderer.

      Lo que esto hará es en gran medida a reducir la cantidad de tiempo que se tarda en ejecutar la función de actualización, ya que sólo están llamando a la GameObject.Find y GetCompnoent por el balón una vez en todo el partido, mientras que antes, estábamos llamando probablemente alrededor 60 veces por segundo si estás a 60 fps en un móvil. Esto es sólo mucho más fácil y esto es realmente lo que usted debe hacer si usted tiene este tipo de funciones grandes y costosos de ser llamado con bastante regularidad.

      Aquí es también una lista de todos los otro tipo de funciones que realmente debería caché si está llamando a cada cuadro o si usted les está llamando bastante a menudo. Su GameObject.Find y luego verá llegamos GameObject.FindObjectOfType. Ahora, este es probablemente uno de los más caros como los que esto está haciendo es, como GameObject.Find, GameObject.Find está mirando a través de la escena para un objeto específico con un nombre específico.

      Bueno, lo que está haciendo GameObject.FindObjectOfType – está haciendo exactamente lo mismo que la Búsqueda pero para cada uno de esos objetos, en realidad es más o menos llamar a la función getComponent por lo que está mirando a través de cada objeto y cada componente para una específica y que en realidad es un buen desempeño de la función que se debe en realidad sólo llamará una vez para un objeto cuando se ha inicializado golpear.

      A continuación, hay FindObjectWithTag el que mira a través de todos los objetos de una etiqueta específica. Esto es en realidad lo que hace la cámara, el Camera.main. Siempre que llame Camera.main, esto es, detrás de las escenas, lo que está llamando. Por lo tanto, cuando se piensa que, en realidad es algo que en realidad no debería estar llamando cada cuadro también. Lo mismo con getComponent, y por supuesto, Camera.main.

      Otra cosa que también hay que tener en cuenta al crear funciones en el interior de la Unidad es reducir la cantidad de tiempo que necesita para llamarlos. A veces, usted tiene una función muy caro como algo que ver con pathfinding o calcular algo bastante grande. En este caso, que no necesariamente tiene que hacer siempre que cada fotograma. Si se trata de algo que no se requiere cada cuadro a continuación, puede reducir realmente que un poco.

      Por ejemplo, si se trata de una función de búsqueda de caminos, que no necesita estar constantemente actualizando la trayectoria del agente de cada fotograma. En su lugar, puede hacerlo cada punto de dos segundos, como vemos a la derecha. Y lo que estamos haciendo es reducir la cantidad de veces que llamamos a esta función desde 60 veces por segundo, si se está ejecutando a 60 fps, abajo a la derecha a cinco veces por segundo.

      Y todo lo que estamos haciendo es crear una variable privada denominada lastCallTime y simplemente comprobando para ver que si nuestro tiempo actual para llevar la última vez que se llama a esta función es mayor que o igual al punto dos segundos o realmente cualquier frecuencia usted quiere. Entonces estamos llamando a la función caro y, por supuesto, a continuación, en función de la cara, a continuación, desea establecer el lastCallTime a igualar la corriente time.time, por lo que entonces es restablecer y sigue en marcha en torno a llamar a esa función caro cada punto dos segundos como si fuera algo que ver con la búsqueda de caminos, en realidad no es tan notable diferencia entre cada fotograma a cinco veces por segundo.

      Por último, aquí es sólo una lista de otras optimizaciones que realmente debería tener en cuenta al crear proyectos en la Unidad y en especial en móvil. Debug.log es uno que aparece mucho, te constantemente a utilizar este material para depurar y probar las distintas funciones fuera, pero cuando realmente se suelte su juego, usted no necesita estos, como el jugador, al final de día, nunca verá estos Debug.Logs y lo que son, en realidad son bastante caros, cada vez que se llama a uno, no hay mucho que pasa detrás de las escenas y si realmente se ven en el perfilador al llamar debug.log, en realidad es bastante caro.

      También, reducir la frecuencia de Raycasts. Trate de evitar llamar Raycasts cada cuadro si es necesario, se puede usar algo similar a esta optimización llamada a la función en la que llama a todos los puntos de dos segundos. Pero sí, Raycasts y hits raycast son bastante caros también. También en Update, tratar de evitar el uso de bucles, tratar de evitar Retransmisión de cosas cada solo cuadro, ya que tiene que recorrer cada elemento dentro de esa matriz o sin embargo muchas veces que está llamando que Loop en la función de actualización.

      Así que, sí, sólo tratar de evitar eso y también si está instancias de un montón de objetos que son los mismos y que están siendo destruidas, como balas o efectos de partículas, en realidad se puede implementar la agrupación de objetos. Y lo que hace esto es, cuando se crea un objeto, no es en realidad una instancia de que, en realidad tomándolo de una piscina que en realidad se ejemplariza un montón de los mismos objetos en el inicio del juego y que tipo de reutilización de ellos así que en vez de destruyéndolos al final, que acaba de desactivar ellos y cuando se desea una nueva, que van piscina un vistazo a través de, ver si tienen uno disponible, vuelva a habilitar o si no hay uno disponible, se creará uno nuevo . Esto se conoce como la agrupación de objetos.

      Hay una gran cantidad de diferentes maneras de hacerlo, se puede pasar de opciones muy sencillas de opciones muy complejas, pero la agrupación de objetos es algo que se hace necesario tener en cuenta si va a crear un juego que utiliza balas o lotes de efectos de partículas. Así que, sí, eso es todo. Yo veré a todos en la próxima lección.

      interesado en continuar? Mira el juego móvil Desarrollo completo para Prácticas de iniciación, que es parte de nuestra Unidad de Desarrollo de Juego Mini-Grado.

      Mensajes relacionados

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *