Unity3D, ¿cuánto código escribes? [cerrado]

Tengo curiosidad por saber el flujo de trabajo al crear un juego en Unity3D?

¿Genera mucho código para ti?

Tengo entendido que usted describe el juego en Unity y hace secuencias de comandos en el back-end para hacer la lógica. Al igual que usas Unity para describir los títeres y usas un lenguaje de script como el maestro de títeres.

Unity3D consta de un motor de juego más un editor 3D (bastante rudimentario). Proporciona mallas, texturas, sombreadores, terreno, cámaras, animaciones, sistemas de partículas, muestras de audio y otros tipos de objetos que son útiles en los videojuegos. Incluye PHYSX (un motor de física patentado propiedad de Nvidia) y Mono (la implementación de código abierto de Common Language Runtime, también conocido como .NET).

Cuánto de esto usa depende de usted. Puede representar todas sus estructuras de datos como objetos de Unity, construir su mundo en el editor de Unity, activar la física y dejar que los eventos sigan su curso, con un mínimo de secuencias de comandos. Alternativamente, puede apagar el motor de física, construir su mundo algorítmicamente y programar explícitamente todo el comportamiento y la física de los objetos.

Puede elegir programar el comportamiento completamente en Mono (usando uno de los lenguajes C #, JavaScript o Boo), o puede escribirlo en otro idioma y vincularlo con su proyecto de Unity. (La integración real con los objetos del juego debe ser a través de Mono, pero esto puede ser una capa bastante delgada si lo desea).

El flujo de trabajo es muy similar al de cualquier motor de juego. Los artistas hacen modelos, texturas y animaciones, los especialistas en audio hacen los sonidos, los programadores escriben sombreadores y comportamiento.

La comunidad de programadores de Unity es muy útil, tanto en answers.unity3d.com como en forum.unity3d.com . (¿Y tal vez aquí en Stack Exchange?)

La mejor manera de averiguarlo es probarlo : la versión básica es gratuita y obtienes un período de prueba de 30 días para la versión "Pro".

Unity3D es más un contenedor / biblioteca que un motor de juego de "arrastrar y soltar". No genera código ni viene con scripts 'listos para usar'.

Por ejemplo, Unreal tiene una cámara predeterminada en primera persona, controlador de personaje, detección de colisión e IA.

No tienes nada de eso en Unity3D. Lo que obtienes de Unity3D es un bucle de juego, un sistema de entidad basado en componentes, una biblioteca matemática integral, medios para cargar medios, manejo de mallas, cámara, GUI de modo inmediato, sombreadores, canalización de renderizado y otras funcionalidades de bajo nivel. Además de un buen editor. Solo tiene que preocuparse por la funcionalidad de alto nivel. Por ejemplo, todavía tiene que codificar su propia cámara en primera persona (si no está usando la predeterminada). Sin embargo, no necesita lidiar con el cálculo de los vectores de observación y demás.

Unity3D no genera ningún código para su juego, estrictamente (sí genera código para ejecutar su juego, para ser más precisos, pero ninguno para su juego)

Tendrás que usar la API para definir tu juego. Puede ver los ejemplos que vienen con Unity3D y reutiliza ese código; hay un par de secuencias de comandos predefinidas, pero generalmente debe personalizarlas para satisfacer sus necesidades.

Usted crea el juego a través de secuencias de comandos; escribe scripts para comportamientos, diseña el nivel en Unity3D y asigna esos comportamientos a entidades (u objetos de juego). Es muy flexible, pero aún requiere esfuerzo para escribir un juego. Lo compararía con Flash para 3D.

La superficie de Unity3D parece súper fácil, y casi todo está preconstruido, pero nada de eso es cierto. Si ignora el uso de scripts ya existentes (que existe para cada motor, punto negativo contra Unity) y complementos que describe como algo extremadamente poderosos, lo que definitivamente no son, Unity es solo una interfaz de programación con editor.

Tienes la mayoría del código por tu cuenta. Experimenté eso en 2 proyectos diferentes.

La analogía con flash es bastante correcta, pero realmente no entiendo tu analogía con los títeres.

Las cosas buenas de la unidad son:

• multiplataforma: Esa es una gran ventaja, diría que la razón más grande.
• Motor e implementación de alta calidad, me refiero a usar los objetos de juego de Unity, etc.
• Es muy fácil hacer un juego simple desde cero, por lo que es una ventaja para hacer prototipos.

Las cosas malas:

• No se puede vincular con C ++ o C, por lo que su proyecto solo podría funcionar en Unity. Con C # one podría argumentarse que funcionará en XNA, pero C ++ hubiera sido bueno. Con este comentario quiero decir que no es una herramienta que usarían profesionales veteranos o autodidactas, ya que no tienes un control total sobre tu aplicación, pero esto no significa que hay algo que no puedes hacer con Unity. Por otro lado, un equipo con una gran idea y artistas talentosos puede hacer cosas increíbles sin necesidad de programadores experimentados.
• Es bastante nuevo, por lo que obviamente nadie sabe a dónde llevará esta herramienta.

Lo que no me gusta de Unity es que parece que todo el trabajo duro está hecho, por lo que los programadores son mucho menos valiosos. Por otro lado, es excelente para enseñar rápidamente a las personas cómo construir cosas rápidamente.

Para concluir: Unity (o una herramienta como Unity) es más para artistas que no pueden llegar a grandes programadores, pero aún pueden saber hacer un pequeño script de juego. Por supuesto, puedes hacer un juego con todas las funciones, agregar IA realista, hacer un código de red mmo y lo que no, pero las grandes empresas no usarían Unity.

La programación de modelos le permite a uno proponer una solución que se adapte a 3/4 de las herramientas de desarrollo para que se ajuste a los creadores de juegos "independientes". Valora una herramienta en particular y también valora a los artistas, pero no a los programadores (excepto los del equipo de la unidad, por supuesto).

La unidad es un buen acceso directo para los no programadores, pero deben entender que los videojuegos provienen de líneas de código y que no se puede hacer todo con una herramienta increíble. En algún momento requiere saber algo sobre programación de bajo nivel.

Teniendo un proyecto personal en mente, no usaría Unity, porque no me gusta C # o Boo (Panda es bueno con python, entonces ¿por qué molestarse con un software comercial?), Y porque si muestro mi proyecto y está hecho con unidad, será mucho menos impresionante.

La unidad requiere que escribas, pero sin todas las repeticiones. En un juego OpenGL típico, deberás inicializar las matrices y cámaras como locos. En Unity, crea un script para indicar el comportamiento de algo, luego lo adjunta a un objeto para que se comporte.

Si al generar una gran cantidad de código para usted, incluiría funciones predefinidas que puede usar para facilitarle la vida con respecto a la detección de colisiones y los cálculos de rotación (Biblioteca), entonces sí, toma mucha codificación de la imagen y le da Has optimizado las versiones disponibles y listas para usar. Principalmente funciones que necesitará específicamente para el desarrollo del juego en todas las compilaciones.

Puede sonar redundante decir esto, pero en mi experiencia, cuando Unity3D no está ocupado chocando o construyendo, me hace la vida más fácil al permitirme cambiar lo que quiera y dejar las matemáticas basadas en Quaternion a las personas que tienen una maestría en matemáticas y aún confía en mí lo suficiente como para dejarme cambiar lo que quiera.

No escribirá nada para usted, más bien lo ayudará de la manera que considere mejor y le permitirá escribir lo que quiera.

En una palabra, flexible