tag - ¿Cómo funciona Unity con las clases de C#

unity static inspector

Question

Viniendo del estudio de C # puro, encuentro que las secuencias de comandos en Unity (con C #) son un poco intuitivas.

Por ejemplo, parece que la forma más común en que las personas (¿principiantes?) Usan scripts en Unity es creando un script de "uso único" y adjuntándolo al objeto de juego real (haciendo clic y arrastrándolo a un componente de scripts). De esa manera, parece haber muy poco uso para la herencia. O tal vez lo tengo al revés. ¿Debo crear las clases / herencia fuera de adjuntar a Game Objects, y luego solo adjuntar scripts a Game Objects que hacen referencia a esas clases externas? Estoy seguro de que algunos de ustedes pueden simplemente decir "hagan lo que quieran". o "hacer lo que funciona", pero no quiero comenzar con una metodología de codificación pobre para terminar refaccionando en una fecha posterior.

Otra cosa con la que estoy confundido son las instancias de clase en Unity. Por alguna razón, parece que puedo trabajar con clases integradas como Animator sin instanciarlo [casi nunca veo una = nueva clase (); ] y sin embargo estas clases no son estáticas. ¿Cómo funciona? Y si construyo mis propias clases a las que los objetos de mi juego hacen referencia, ¿tengo que crear instancias para trabajar con ellas o el motor está haciendo todo esto bajo el capó?

¿Y dónde está el objeto de juego (el elemento real en el editor) en todos estos scripts? ¿Hay una clase creada para cada objeto de juego? Y, si es así, ¿cómo lo encuentro y miro lo que está pasando con él?

Answer 1

He hecho algunos juegos en la unidad y, en mi experiencia, la herencia casi nunca es útil. Esto se debe a que la unidad no se hace con oop en mente, sino con programación orientada a componentes, es decir, se crea un pequeño componente de un solo propósito (script) y se pegan para crear los objetos del juego.

Cuando agrega una secuencia de comandos a un objeto de juego, el motor hace la nueva Clase (); trabajo para ti. Esto significa que cada objeto de juego tiene una instancia de cada secuencia de comandos que se le atribuye. Esto es cierto para todos los guiones tanto los que haces como los que ya están en unidad como Transform y Animator. Por supuesto, esto solo es cierto para tu script de unidad que hereda de MonoBehaviour ya que son lo único que puedes agregar a un objeto de juego.

Los objetos de juego que ves en la jerarquía de escenas son instancias de la clase GameObject. Para entender cómo funciona, recomiendo simplemente leer la documentación, pero si quieres echar un vistazo al objeto del juego, debes desmontarlo usando algo como Telrik JustDecompile o Reflector.

Answer 2

La herencia es totalmente relevante en la Unidad tal como es en otro marco.

Considere que desea implementar dos tipos de enemigos, ambos tienen algunos comportamientos comunes (caminar, atacar) y ambos tienen comportamientos específicos (A puede volar, pero B usa el pathfinding para atacar). Diseñarías una clase Enemy abstracta que hereda de MonoBehaviour (el script btw hereda de MonoBehaviour que hereda de Behavior, ..., así que la herencia está ahí) y luego cada una hereda de Enemy.

Esto es mejor para mantener pero también para usar a tus enemigos. FlyingEnemy y PathEnemy se pueden almacenar en una colección de tipo Enemigo, lo que te permite iterar en él para realizar acciones enemigas comunes (como morir).

La interfaz también es muy útil ya que puedes tener un proyectil que golpee cualquier cosa en el nivel. El proyectil verificará si el GameObject golpeado contiene un componente dañado y, de ser así, llama al método de Daño de la interfaz. Esto permite golpear cualquier cosa sin saber si es el Jugador, y Enemigo o un muro. Cada uno implementa la interfaz en su propio script y el método simplemente realiza la acción relevante.

Sin esto, su proyectil tendría que pasar por una larga lista de comprobaciones para saber si es esto o aquello.

Answer 3

La herencia en la unidad viene de una manera simple porque Unity intenta usar un modelo de Component en su lugar y un modelo de jerarquía. Pero decir que es simple no significa que no existe.

Cuando creas una nueva clase hereda de MonoBehaviour, que es la clase que tiene muchas de las funciones que el objeto necesita para trabajar en el motor.

Si desea crear un modelo de jerarquía con sus scripts, puede necesitar crear toda su clase base como hija de MonoBehaviour y luego heredar de ella. Por favor, lea el ejemplo de @Everts

Considere que desea implementar dos tipos de enemigos, ambos tienen algunos comportamientos comunes (caminar, atacar) y ambos tienen comportamientos específicos (A puede volar, pero B usa el pathfinding para atacar). Diseñarías una clase Enemiga abstracta heredando de MonoBehaviour y luego cada una heredará de Enemy.