¿Cómo se dirigen los desarrolladores de juegos a múltiples plataformas (Xbox 360, PS3, PC y Linux)?

¿Cómo se dirigen los desarrolladores de juegos a múltiples plataformas a la vez? Por ejemplo, Xbox 360, PS3, PC y Linux. Para juegos 2D, ¿es posible apuntar también al iPhone? Me interesan los motores utilizados (2D / 3D, etc.), cómo se configura la canalización de compilación y, en general, cuánto del "código central" se puede centralizar sin tener que escribir ramas de código específicas de la plataforma.

O, si generalmente se mantienen troncales de código completamente separadas para cada plataforma, ¿cómo se reutilizan las bibliotecas / código (en términos de vinculación y modularización)?

Para el desarrollo de juegos de consola comerciales, configurar un sistema de compilación para apuntar 360, PC y PS3 simultáneamente es irritante, pero no es particularmente difícil. El kit de desarrollo 360 es simplemente un nuevo objetivo para Visual Studio + algunas herramientas y utiliza un compilador muy similar al compilador estándar de Windows MSVC ++. La PS3 utiliza un compilador GCC, pero se conecta fácilmente a la interfaz visual del estudio. Para el juego y el código de utilidad general, generalmente debería ser posible tener un código que sea 99% igual entre las 3 plataformas. Hay algunas incompatibilidades entre GCC y MSVC ++, pero afortunadamente si las soluciona Linux (suponiendo que use una versión de gcc cercana a la PS3) no habrá muchos más problemas además de eso. El último 1% del código que difiere normalmente se puede arreglar con kludgy #defines.

Más allá de los pasos básicos de construcción, el gran obstáculo serán los sistemas gráficos, así como cualquier elemento de alto rendimiento de su juego. Para estos elementos, de manera realista, terminará escribiendo código personalizado de la plataforma o utilizando un motor existente. La memoria será un gran problema, pero eso es para otra pregunta. Un proyecto comercial en el que trabajé fue capaz de obtener versiones de consola de una base fuente original de PC con bastante facilidad, pero hacer que realmente funcionen bien fue un problema completamente diferente.

Si desea integrar también el iPhone, puede optar por algún tipo de solución de motor / middleware existente. La configuración de iPhone de OpenGL + Objective C no encaja muy bien con ninguna otra plataforma. Esa es una gran elección por parte de Apple, ya que están desalentando en gran medida el uso de middleware interpretado en cualquier aplicación de iPhone.

Para la mayoría de las plataformas, puede escribir subsistemas que se abstraen de las API específicas utilizadas para llamar y recuperar información de la plataforma en la que se está ejecutando. Las API de E / S suelen ser las más fáciles de abstraer: todos los sistemas de archivos funcionan con algunas suposiciones bastante básicas sobre abrir, cerrar y leer archivos, incluso cuando se tienen en cuenta las llamadas asincrónicas. Luego tiene sus sistemas principales, como leer la entrada del controlador, consultar el tiempo, acceder a la memoria y las primitivas de subprocesos, la mayoría de los cuales funcionan de la misma manera.

Incluso los gráficos pueden abstraerse en gran medida, y de hecho en la mayoría de los buenos motores lo son. Pero tiene que empaquetar las cosas 'renderizables' en cajas negras donde no se le permite saber qué sucede dentro de ellas. Usted sabe que tiene una 'cosa' que representa en una posición particular en el mundo. No sabes cómo se representa, solo que es así. Y la capa de abstracción de gráficos se encarga de todos los detalles para obtenerla en pantalla. Los canales de compilación específicos de la plataforma empaquetan los datos gráficos de tal manera que puedan ser referenciados desde el motor sin saber realmente cómo se representan internamente.

Todo lo dicho, sin embargo, cuando se trata de enviar un juego, hay ciertas partes que simplemente no puedes abstraer. Sería ridículo pensar que podría enviar el mismo código en iPhone que lo haría en 360 o PS3, ya que los mecanismos de entrada, la forma fundamental de operar y las capacidades de la plataforma son demasiado diferentes. Podría crear un título del tamaño de un iPhone en 360, pero tendría que limitar sus mecanismos de entrada solo a aquellos que el 360 puede admitir. Entonces, un cursor virtual en pantalla simulando un dedo, y posiblemente usando el joystick donde se usa la entrada del acelerómetro 3D.

De manera más sensata, partes del juego se pueden escribir de una manera reutilizable, y los módulos de código individuales se pueden portar entre plataformas, a pesar de que la mayoría del título es diferente. Por ejemplo, si tiene una máquina de estado AI, eso realmente no le importa si se ejecuta en 360, PC o iPhone. Su juego usará muchos de esos componentes, y siempre que hayan sido diseñados correctamente para que tomen entradas y salidas bien definidas, entonces el resto del juego puede envolverse alrededor de ellos, independientemente de la plataforma, y ​​evitar tener que reescribirlos. componentes.

Esa reutilización es la clave para un desarrollo multiplataforma, no busca un motor de talla única que funcione en todas las plataformas. Incluso si tal cosa existiera, sería tan lisiado tener que trabajar en el mínimo común denominador, no sería muy útil hacer juegos con él.

Una forma es usar un motor multiplatafom como Torque o Unity3D . Pero no creo que funcionen en todas esas plataformas. También hay otra forma: desarrollar un motor ...