¿La programación del juego no está relacionada con la programación normal?

Reescribí mi respuesta muchas veces, cada vez llegué a la conclusión de que esta pregunta está rota. Decidí que es mejor no responder, pero ahora estoy escribiendo esto por alguna razón.

La programación no es diferente según el contexto en el que se aplica.

Mencionas la Unidad. La programación en la parte superior de Unity es diferente de la programación en la parte superior de la BIOS cuando se implementa el gestor de arranque de primer nivel para el sistema operativo “en tiempo real”. O programar cualquier cosa por encima de cualquier cosa.

Incluso la programación de ensamblaje se programa sobre el conjunto de instrucciones de la CPU. Usted MOV valores entre registros / memoria, JMP a direcciones. En Unity, .lookAt () con un objeto en otro objeto. Es lo mismo, pero diferente.

Antecedentes;

• Hice el programa usando C64 con Assembler y BASIC. Sé lo que es el acumulador y sé qué hace PRINT (entre muchas otras cosas).
• También programado usando Telmac TMC-600, Sony MSX Hit-Bit, Amiga 500, PC (DOS, OS / 2, Win1.0-10, Linux), Embebido (uC / OSII, Linux), Sparc’s.
• Sé cómo hacer cosas bastante complejas en muchos lenguajes de programación.
• He escrito software para cargar sistemas embebidos en todo el mundo. Sistemas de planificación de recursos empresariales que se ejecutan en todo el mundo.
• He programado juegos usando todo tipo de hardware, sistemas operativos, bibliotecas, motores. Incluyendo Unidad.

Les digo a los programadores más jóvenes que “¿qué es tan difícil de programar? Solo modifican y mueven los números”. No importa si está escribiendo la función “en tiempo real” para la unidad de control de refuerzo de cohetes, o ese sistema hinchado de Visual Basic 4.0 Enterprise que utiliza la base de datos de acceso almacenada en el recurso compartido de red.

Todo es lo mismo. El nivel de abstracción hace que sea difícil ver que “solo modifica algunas direcciones de memoria”.

¿La programación del juego no está relacionada con la programación normal?

Este fin de semana hicimos un juego muy básico de Tower Defense en Unity con C #. Utilizamos algunos códigos especiales como .lookAt ().

Entiendo que la programación del juego no se trata en absoluto de la programación normal. ¿Tengo razón o no?

No, la programación del juego es solo programación. Los juegos son un tipo particular de software que implica algunas características distintas (simulación semi-en tiempo real frente a eventos, por ejemplo, más trabajo de gráficos y, por lo general, problemas de rendimiento), pero el código del código. También trabajo con C # todos los días, pero no lo uso para crear juegos, lo uso para aplicaciones web de negocios. Sin embargo, es todo lo mismo.

Ese método LookAt () que menciona es una llamada a la biblioteca; alguien construyó un método para alinear la cámara con un vector hacia un punto o algo así, y lo envolvieron en esa llamada al método y lo empaquetaron en una biblioteca para que pueda usarlo sin preocuparse por los detalles. Casi todo el software funciona de esa manera, ya sean juegos o no: la modularidad, la abstracción y la reutilización del código son principios fundamentales de toda la programación.

He desarrollado software de seguridad durante décadas, incluidos controladores de dispositivos, servicios móviles, de escritorio y en la nube.

Como proyecto personal, he estado desarrollando un juego en Unity durante el último medio año. Las API y las estructuras de datos en el juego son similares a muchos proyectos ajenos al juego en los que he trabajado en el pasado. El uso de colas, listas, tablas hash, objetos, clases, bibliotecas y comunicaciones no es muy diferente de los programas que no son juegos.

La mayor diferencia que he visto es que la codificación del juego va más rápido. Esto se debe en parte a que soy el único desarrollador, pero también porque la mayoría de los juegos tienen entradas y salidas limitadas, por lo que las herramientas (motores y marcos) pueden enfocarse para los juegos y hay menos casos marginales.

Si bien el uso de herramientas de nivel superior y API protegen a los desarrolladores de lo que hay debajo, escribir herramientas de juego, API y servidores también es parte del desarrollo del juego. Hay mucho que aprender si quieres bucear profundamente.

Cada “tipo” de programación implicará algunas habilidades y especialización específicas del dominio. Pero eso no significa que no estén relacionados.

La programación de juegos a menudo implica muchas matemáticas en 2D y / o 3D: calcular posiciones de objetos, hacer movimiento / colisión / física, transformar cosas para renderizar en 3D. Si bien es poco probable que haga mucho de esto mientras, por ejemplo, desarrolla software empresarial, es común en áreas como la informática científica.

La programación del juego tiene limitaciones de tiempo: si no haces todo el cálculo / renderizado para un fotograma a tiempo, el juego tartamudea o se engancha, y eso es malo. A su vez, esto lleva a un deseo de alto rendimiento. Si bien esto es menos importante en la mayoría del desarrollo de aplicaciones de escritorio, es común en cosas como servidores web donde es importante completar las solicitudes rápidamente.

La programación de juegos para consolas de juegos requiere tratar con hardware específico y limitado. Esto es común en sistemas embebidos de todo tipo.

¿La programación del juego no está relacionada con la programación normal?

Definitivamente están relacionados, pero no son idénticos. Si se acerca lo suficiente, los detalles de las diferentes aplicaciones variarán significativamente entre sí. Por ejemplo, el código de un sistema operativo se verá muy diferente del de una aplicación de juego, que a su vez se verá muy diferente del software de pronóstico del tiempo. Y cada uno usará diferentes herramientas para lograr sus objetivos. Pero en el fondo, todas son aplicaciones del mismo concepto: diseñar algoritmos para resolver problemas. El proceso general tendrá muchas similitudes en cada caso.

En resumen, el principio subyacente entre los programas es el mismo, pero los detalles varían mucho (¡que es lo que mantiene las cosas emocionantes!).

Sí, la programación de juegos se basa en los conceptos de programación general.

Escribir un juego no trivial y de alta calidad en cualquier plataforma implicaría usar algún tipo de motor de desarrollo de juegos que haga mucho trabajo pesado para cosas que son importantes para juegos como la física, la representación de la interfaz de usuario, el aprovechamiento de la GPU / equilibrar el rendimiento de la CPU, etc. .

La creación de juegos con estos motores de juegos requiere que el programador tenga un conocimiento profundo de su lenguaje y la capacidad de aprender / dominar el SDK / API del marco de desarrollo de juegos que utilizan.

No, eso no es verdad. En primer lugar, lo que está haciendo es más secuencias de comandos de juegos que programación de juegos. Eso es muy similar a la mayoría de los otros tipos de codificación.

Cuando construyes un juego desde cero (o un motor de juego), lo que estás construyendo es un programa “casi en tiempo real”, que es un tipo de programación.

En cualquier caso, se basan en principios fundamentales de la informática. Cuanto mejor los conozca, mejor será su código.

Por supuesto, la programación del juego es programación “normal”. He programado en Unity 3D y Unreal Engine, además de hacer juegos en Java en la escuela. También he contribuido a un juego basado en web hecho con php y javascript. En términos generales, no hay diferencia en los juegos que en cualquier otra programación que haya hecho. Estás usando un marco especial cuando usas un motor de juego, pero eso no es diferente a usar bibliotecas para otros tipos de programación.

Esos códigos especiales no son especiales.

Son solo códigos que alguien más escribió para ti y son parte de la unidad. Toda la programación tiene cosas así. Se llaman bibliotecas.

Como mínimo, ejecuta con su biblioteca estándar de idiomas. Todo lo demás que incluyas más adelante.

La unidad no es un lenguaje. La unidad es como el chasis de un auto en funcionamiento en el que conectas tu juego (se llama un juego _engine_ por una razón).