Sospecho que los cambios a los que se refiere son diferencias de marco y no el lenguaje C #. En Unity3d está utilizando .Net framework (Via Mono) y elementos de marco específicos de Unity con el lenguaje C #.
Mike B
Es solo una versión muy antigua. Si desea la última versión de C # y Mono y desea programar en lugar de crear un motor prefabricado, considere algo como monogame.net
Den
Noté ligeras diferencias en la biblioteca, por ejemplo, en Unity hay una clase Mathf para funciones matemáticas, en lugar de la clase Math. No he prestado atención si hay otras diferencias, pero esa es la que se destacó.
Alex
@Alex System.Math todavía está disponible, y aparentemente es en realidad más rápido que UnityEngine.Mathf . Entonces, la única razón real para usar la versión Unity es evitar muchos lanzamientos (flotantes) ... a costa de un poco de rendimiento.
FlintZA
Respuestas:
9
Como se indicó en otras respuestas, Unity 4.x utiliza una versión modificada de Mono basada en Mono 2.6
En su mayor parte, esto es compatible con .Net 2.0 , aunque no he logrado rastrear una lista de compatibilidad específica de Mono 2.6.
Se ve diferente de C # normal, pero hay algunos elementos de C # regulares allí.
Como se menciona en uno de los comentarios sobre su pregunta, esto probablemente se deba a la API de scripting particular de Unity en lugar del lenguaje en sí.
Como ejemplo, una gran cantidad de código en un proyecto típico de Unity está contenido en subclases de una clase llamada MonoBehavior. Estos son componentes que se colocan en GameObjects dentro del entorno de Unity Editor. Esta arquitectura conduce al código C # que se ve diferente al código C # típico (para mí de todos modos) de varias maneras:
Hasta que se lanzó Unity 4, estos objetos no podían estar contenidos en espacios de nombres, por lo que siempre están en el espacio de nombres global
Exponen los campos al entorno del editor al hacerlos públicos (o al usar el atributo SerializeField, pero encuentro que muy pocas personas usan esto), lo que conduce a un número inusualmente grande de campos públicos en las clases
Las convenciones de privacidad y de casos de Unity no siguen las de Microsoft, por lo que esto también puede parecer extraño para un desarrollador de C # "tradicional"
Hacen uso de una serie de métodos especiales en estos componentes, como Inicio y Actualización, que no se anulan como se esperaría, sino que se accede a ellos mediante reflexión.
Hablando en términos prácticos, la característica más grande del lenguaje C # que echo de menos en la versión actual de C # de Unity es el soporte para funciones asíncronas y palabras clave relacionadas. Un concepto similar en Unity son las corutinas . Estos se ejecutan en el subproceso principal, por lo que no son asíncronos verdaderos, pero sí permiten que el código de larga ejecución se divida en varios cuadros. El subprocesamiento múltiple de nivel inferior todavía es compatible.
Solo para aclarar, asyncen C # tampoco es asíncrono verdadero como en multihilo: también se ejecuta en el hilo principal. Las mayores diferencias, desde una perspectiva de uso, entre las rutinas y asíncrono son los tiempos en que se ejecuta el código.
Rhughes
Gracias. Sí async! = Multiproceso, aunque diría que es mucho más común usar async para ocultar / interactuar con operaciones multiproceso que hacer lo mismo con las rutinas. He escrito una rutina de envoltura que inicia las tareas de delegado en un conjunto de subprocesos que me da un nivel de flexibilidad muy similar, pero aún así no me importaría tener un soporte asíncrono "adecuado". Por supuesto, un GC moderno decente sería aún mejor;)
FlintZA
21
Unity 4 usa Mono 2.6 , que es una implementación completa del marco .NET, incluido el lenguaje C #.
No estoy seguro de cómo se ve diferente, pero tenga en cuenta que Unity admite varios idiomas, todos los cuales funcionan además del mismo tiempo de ejecución Mono. ¿Es posible que estés confundiendo C # con UnityScript ?
Por otra parte, cuando escriba C # en Unity, utilizará muchas de sus bibliotecas, pero que yo sepa, todo lo posible en C # es posible en Unity, aparte de las diferencias que se enumeran a continuación:
Las áreas más específicas de .Net relacionadas con Windows Forms y ASP están fuera de los límites a través de Unity.
Si bien puede usar Visual Studio para editar y errores en tiempo de compilación, debe compilar y ejecutar en Unity IDE.
Unity usa Mono, que es una implementación de código abierto de .Net, lo que significa que hay ligeras diferencias.
Para ampliar su segunda viñeta, también puede depurar en Visual Studio utilizando UnityVS . Microsoft adquirió recientemente a los desarrolladores, por lo que lanzarán el complemento de forma gratuita en un futuro próximo.
mrohlf
Lo sentimos, pero no está cerca de C # normal.
Alper
0
La pregunta de si la versión de C # utilizada por Unity es diferente de una C # "normal" ha sido respondida por otras publicaciones. Dado que está solicitando explícitamente ciertos elementos que pueden diferir de una versión tan regular, compartiré la única diferencia menor que noté al comparar el C # que uso en el trabajo (es decir, C # 4.0 en Visual Studio 2010 y superior) y C # en Unity, que es que no puedo usar los valores predeterminados para los parámetros en las definiciones de funciones. es decir, debe configurar su proyecto con más cuidado para usar una versión más nueva de C #. Vea este enlace para más explicaciones.
Editar:
dejo esta respuesta ya que hasta donde sé, este es un malentendido que le sucede a mucha gente.
Como esa característica solo se agregó a C # en la versión 4.0 y no estaba presente antes, su ausencia realmente no se puede llamar una "diferencia" a "C #".
O Mapper
1
La versión 4 de C # se lanzó en 2010. Creo que mucha gente lo está usando y siente, como yo, su ausencia al programar en Unity.
Nessuno
¿Estás seguro de que no puedes usar los valores predeterminados? Estoy bastante seguro de que lo hago y tengo ...
NPSF3000
Bueno, lo intenté y no se compilará con un mensaje que me dice que no puedo usar los valores predeterminados. ¿Estás usando una versión especial de Unity? ¿Te gusta la versión pro?
Nessuno
1
Puede usar absolutamente los valores predeterminados, y no tiene nada que ver con pro o no pro. Unity y MonoDevelop tienen una relación extraña. Los proyectos generados automáticamente en MonoDevelop a menudo se configuran en versiones anteriores de C # que no admiten valores predeterminados. Sin embargo, si cambia esa configuración en el proyecto, funcionará bien. Si ignora la compilación en MonoDevelop y simplemente regresa a Unity, notará que Unity no se queja de los parámetros predeterminados.
Respuestas:
Como se indicó en otras respuestas, Unity 4.x utiliza una versión modificada de Mono basada en Mono 2.6
En su mayor parte, esto es compatible con .Net 2.0 , aunque no he logrado rastrear una lista de compatibilidad específica de Mono 2.6.
Como se menciona en uno de los comentarios sobre su pregunta, esto probablemente se deba a la API de scripting particular de Unity en lugar del lenguaje en sí.
Como ejemplo, una gran cantidad de código en un proyecto típico de Unity está contenido en subclases de una clase llamada MonoBehavior. Estos son componentes que se colocan en GameObjects dentro del entorno de Unity Editor. Esta arquitectura conduce al código C # que se ve diferente al código C # típico (para mí de todos modos) de varias maneras:
Hablando en términos prácticos, la característica más grande del lenguaje C # que echo de menos en la versión actual de C # de Unity es el soporte para funciones asíncronas y palabras clave relacionadas. Un concepto similar en Unity son las corutinas . Estos se ejecutan en el subproceso principal, por lo que no son asíncronos verdaderos, pero sí permiten que el código de larga ejecución se divida en varios cuadros. El subprocesamiento múltiple de nivel inferior todavía es compatible.
fuente
asyncen C # tampoco es asíncrono verdadero como en multihilo: también se ejecuta en el hilo principal. Las mayores diferencias, desde una perspectiva de uso, entre las rutinas y asíncrono son los tiempos en que se ejecuta el código.Unity 4 usa Mono 2.6 , que es una implementación completa del marco .NET, incluido el lenguaje C #.
No estoy seguro de cómo se ve diferente, pero tenga en cuenta que Unity admite varios idiomas, todos los cuales funcionan además del mismo tiempo de ejecución Mono. ¿Es posible que estés confundiendo C # con UnityScript ?
fuente
La unidad usa C # regular.
Por otra parte, cuando escriba C # en Unity, utilizará muchas de sus bibliotecas, pero que yo sepa, todo lo posible en C # es posible en Unity, aparte de las diferencias que se enumeran a continuación:
Las áreas más específicas de .Net relacionadas con Windows Forms y ASP están fuera de los límites a través de Unity.
Si bien puede usar Visual Studio para editar y errores en tiempo de compilación, debe compilar y ejecutar en Unity IDE.
Unity usa Mono, que es una implementación de código abierto de .Net, lo que significa que hay ligeras diferencias.
fuente
La pregunta de si la versión de C # utilizada por Unity es diferente de una C # "normal" ha sido respondida por otras publicaciones. Dado que está solicitando explícitamente ciertos elementos que pueden diferir de una versión tan regular, compartiré la única diferencia menor que noté al comparar el C # que uso en el trabajo (es decir, C # 4.0 en Visual Studio 2010 y superior) y C # en Unity,
que es que no puedo usar los valores predeterminados para los parámetros en las definiciones de funciones.es decir, debe configurar su proyecto con más cuidado para usar una versión más nueva de C #. Vea este enlace para más explicaciones.Editar: dejo esta respuesta ya que hasta donde sé, este es un malentendido que le sucede a mucha gente.
fuente