1 - Verificar si un objecto es nullo mediante ? crea un objeto que indica si el valor es nulo o igual al default y el valor en si, esto genera una sobre carga de memoria por lo que usarlo dentro del Update generara bastante basura. Lo mejor es utilizar el simple flag de siempre en casos de constanste actualización y hacerlo con "is null" if (obj is null) o if (!(obj is null)). Sin embargo esta aplicación tiene sentido en Eventos donde los registros pueden contener una referencia nulas.
 
2 - Los String con Format complex utilizando "$" son mucho mas complicados para el CLR, costosa, y con mayor cantidad de memoria derrochada, que la simple concatenación. Para crear String lo mejor es utilizar StringBuilder. Sin embargo, para realizar la concatenación esto es mas practico y simple, anteriormente se utilizar String.Format que tenia un costo mayor y era bastante menos practico.
 
¡En resumen, estos tips son para practicidad sacrificando rendmiento y recursos!
 
Los otros me parecen bien, esta bueno tener estos tips de forma sintetica, y que cada cual busque por su cuenta el ¿POR QUE? - 

Tranquilo, no sos el unico, hay algo que no funciona correctamente, pero creo que es una sección de la WEB. Depende desde que parte de la web estas logean funciona o no.
 
@pioj ¿Estas teniendo problema con este apartado?

Cita de: lightbug date=1584740481Gracias.
   
   
      Me parece que por esto no utilicé el scrollrect.
   
   
      Para detectar el final simplemente comparé la posición de los créditos con la de la máscara, cuando este valor superaba tal "y" de referencia de llamaba un evento.
   

Puede ser, en uno de los proyecto me toco desarrollar UI (lo cual odio con todo el corazón) tuve bastantes problemas con la UI, los Anc***d, las posiciones, las escalas, etc. La verdad es que la implementación de Unity tiene cosas que toda la vida fueron "normales" mezclada con ideas raras. Como por ejemplo el PIVOTE de un elemento JAMAS deberia ser dinamico y siempre deberia esta situado en la esquina superior izquierda, esto genera una inconsistencia con los Anc***d que es muy desagradable, crear algo que funcione con UI relacionado a Animaciones es un DOLOR de HUEVO. 
 
Creo que ElementUI si se termina de desarrollar con WebKit como referencia va a llevar al exito a Unity, pero si siguen haciendo esto de seudo soluciones entonces empezara a caer por su peso. En lo personal ya me estan pidiendo conocimientos en Unreal con la intención de que los nuevos proyectos esten basados en este motor y abandonar Unity por el momento.
 
 
 
¡LO ANTERIOR FUE UN DESCARGO!
 
En lo personal creo que la mejor opción es usar mascaras, el SCROLL hace un CALCULO ridiculo para calcular el SIZE de KNOB lo cual no tiene ningun sentido. En este caso no se utilizara ScrollBar, por lo que una Mascara para el contenido y calculando el OFFSET para saber cuando la posición es la final es mas que suficiente!
 
Tambien hay que tener cuidado donde pones esto de los TITULOS por que estas forzando la actualización del MESH constantemente.

La comunida dispone de una sección Aportes para realizar este tipo de topic!
 
Saludos!

Yield return Null y WaitFroEndOfFrame es excatamente lo mismo, la corrutina no volvera a iterar hasta que el bucle Update termine, por lo cual no tiene diferencia. No hice las pruebas pero lo dedusco.. 
 
Por otro lado deberia ver que velocidad necesitas y interpolar los valores, lo mio fue un simple ejemplo, pero verticalNormalizedPosition deberia ser asignado con un valor interpolado para que funcione de forma Smooth.
 
Deberas tener presente el STEP del tiempo, este puede varia con el contenido, digamos que un scroll de un contenido de 100 palabras no es igual de "sensible" que 10000

Tienes que aprender -> Instancia, Niveles de accesibilidad, Tipos estaticos y No estaticos, Propiedades, Campos, Herencia. 

verticalNormalizedPosition deberia contener un valor de 0-1 donde 0 es la posición final.
 
Si quieres lograr un desplazamiento automatico podrias hacer lo siguiente
 

IEnumerator MueveCreditos()
{
  ScrollRect rect = creditos.GetComponent<ScrollRect>();
  rect.verticalNormalizedPosition = 1;
  while (ventanaCreditos.enabled && rect.verticalNormalizedPosition > 0.01f)
  {
    rect.verticalNormalizedPosition -= Time.deltaTime; 
    yield return null; //Tiempo de espera entre letras.
  }
  
  rect.verticalNormalizedPosition = 0;
}

 
 

Dentro del TAG del Subshaders podes asignar el valor de Queue, ya existen constantes definidas para no sobre poner las geometrias o demas aplicaciones de Unity, Background es 1000, Geometry es 2000, AlphaTest es 2450, Transparent es 3000 y Overlay es 4000, para que se renderize por encima del UI el valor debe ser entre 4000 y 5000 <- EN TEORIA!
 
Se usa este orden para poder renderizar todo tipo de materiales de forma correcta,
 

1. 
      Renderiza el Background.
   


2. 
      Renderiza los Materiales con Shaders (MCS) opacos.
   


3. 
      Renderiza Alpha Test.
   


4. 
      Renderiza otra vez la geometria con MCS Opaco (Esto suele ser mas complicado de explicar el porque..)
   


5. 
      Renderiza los materiales transparentes tomando información del segundo y tercer paso.
   


6. 
      Renderiza todo lo que debe estar superpuesto, efectos como flares, etc..
   

Crear algo similar a RenderQueue es bastante complejo, diria que sin conocimientos seria muy frustrante, por esta razón Unity deja libre 1000 posibilidades por cada sección para que crees el orden de renderizado de tus objetos, es posible que nunca termines de usarlos, seria raro encontrar 1000 materiales con un orden unico.
 
 
 
¿Como funcionan las camaras?

SIMPLE, las camaras son entidades que se encargan de renderizar una sección de la escena, esta sección se ve delimitada por varios factores, FOV, FAR, SIZE, etc. 
 
¿Que renderiza la camara?

La camara renderia los objectos que pertenezcan al LAYER que tenga como Renderizado, y luego tienen un orden de renderizado, por lo que puede renderiar todos los UI en Una Camara, Los Efectos en otra, Las Particulas en otras ETC... Cuando mas o menos entiendas este ejemplo podes aplicarlo a la vista del Personaje dentro de un MENU o el efecto que estas intentando lograr!

Hola @maauri16, siempre es recomendable utilizar un formato de dato relacionado para que la pérdida de información sea controlada.
 
¿Que puedes utilizar?
 
Deberías ver XML, JSON y YAML, en ese orden y quedarte con cual mejor te quede. 
 
¿Como no perder información?
 
Lo mejor para perder información es crear un archivo independiente que guarde únicamente la última versión del BUILD que se utilizó, y crear un sistema de actualización por versión, esto debería funcionar de forma recursiva.
 
Por ejemplo la primer versión es 0.1 y se crear el archivo de guardado, la versión 0.2 contiene el código de migración de 0.1 a 0.2, la versión 0.5 contiene el código de migración de 0.1, 0.2, 0.3,0.4,0.5,0.6. Y así sucesivamente, sin embargo, no es necesario actualizar siempre el código de migración, solo cuando cambie la estructura de datos.
 
¿Se puede realizar de forma dinámica?
 
Si, con YAML y JSON puede serializar y deserializar un objeto sin tener que importar la pérdida de datos, de esta forma no sería controlado pero el juego seguiría funcionando.
 
 

Hola @Jhonatan00_00, lo que estás buscando es crear formas de representar la geometría, esto se conoce como Shaders, veo que estás tratando de encontrar el camino pero no tienes la suficiente información.
 
Aplicar shaders para que la geometría se dibuje frente a cualquier otra es bastante simple, pero no es algo genérico, de hecho deberias implementar un sistema de RenderQueue para todos los objetos que se renderizan en primer plano. La idea de @nomoregames es lo que en realidad estas buscando... ¡Solución genérica!.
 
Pero esto soluciona 1 de varias aplicaciones, digamos, dibujar un personaje sobre el UI debería ser con una CÁMARA extra que renderize únicamente la capa del personaje (siempre que la vista sea interactiva), de lo contrario se podría realizar tranquilamente con RenderTexture.
 
Para una solución mediante shaders en el caso de Tomb Rider, o Vista de Águila de Assassin's Creed, deberias utilizar Z Test e ingeniarte que Pixeles dibujar y de que manera.
 

 
Esto es un apartado complejo pero una vez que dominas para que sirve cada cosa es bastante simple lograr el efecto deseado, luego con el tiempo vas aprendiendo a optimizar y demás.
 
 
 
 
 
Para tu ejemplo de renderizar el jugador con un plano negro, podrias usar 2 camaras y renderizar el jugador en 1 cámara y todo el resto en otra cámara, luego puedes indicar el orden de la cámara!

Muy buen aporte.
 
¿Que es Native-Managed Bridge? Se trata de llamadas que deben ser ejecutadas fuera de la "zona segura" del CLR de .NET, por esta razón es bastante costoso aparte de otras muchas desventajas.
 
--------------------------------------------
 
Se puede evitar la llamada del GC si los TAG se almacenan como CONSTANTES. Esto tiene algo de cierto según la prioridad con la que se llama ya que el hash de los STRING es relativo a su contenido.
 
--------------------------------------------
 
Para el Update Global se puede utilizar un evento estático.
 

public class GameBehaviour : MonoBehaviour
{  
  private void Awake()
  {
    GameManager.UpdateEvent += OnUpdate;
  }
  
  private void OnDestroy()
  {
    GameManager.UpdateEvent -= OnUpdate;
  }
  
  protected virtual void OnUpdate()
  {
    
  }
}

 
Por lo general a "GameManager" lo llamo "RuntimeUtilities" y lo instancio mediante una función estática con InitializeOnLoad para asegurarse de que siempre esté presente antes de la llamada Awake en cualquier Escenario.
 
Saludos.

Para mi esta bien, pero optaria por que la fuerza de la piña sea diferente, quizas presionando click y la velocidad horizontal del mouse.

Pon el link de Google Drive aquí.
 
Las mecánicas de los juegos se fueron puliendo poco a poco hasta lograr lo que hoy en día son, realmente esto no define nada e intentar hacer las cosas de forma diferente es una forma de experimentar. 

Muchas veces el GamePlay se siente mal por otros aspectos y no solo por los controles.
 
 

@iRobb en este topic di una respuesta correcta y completa de propiedades.

 
 

Fijate si tenes un solo EventSystem. Por otro lado forza la selección de object en EventSystem.
 
Este error pasaba para Android hace un tiempo, y era por que se pierde el "Focus" del control, digamos que seleccionas el InputField , se abre el teclado y se pierde el foco, por lo cual se cierra el teclado