¿Cómo empresas como Valve logran lanzar juegos a las tres principales plataformas de juego? Estoy interesado en las mejores prácticas con respecto al uso compartido de códigos específicamente entre Windows, Xbox360 y PS3, ya que la solución ideal es reutilizar la mayor cantidad de código posible en lugar de volver a escribir todo para cada plataforma.¿Cómo puedo aprender sobre el desarrollo de juegos de plataformas cruzadas?
No es diferente de escribir código independiente de la plataforma en otros contextos. Oculte los detalles específicos de la plataforma (entrada, interacción de ventana, el bucle de evento principal, subprocesamiento, etc.) detrás de las interfaces genéricas, y realice pruebas regularmente en todas las plataformas que pretenda admitir.
Tenga en cuenta que el modelo de subprocesamiento de la celda es lo suficientemente inusual como para que el enhebrado "genérico" tenga algún cuidado. No soy un empleado de Valve y no conozco ninguno de sus secretos, pero entiendo que la mayoría de los desarrolladores de juegos que quieren apuntar a la PS3 usan una cola de trabajos en la que los procesadores de celdas individuales toman las tareas necesarias. Esta no es necesariamente la mejor manera de usar la Celda, pero se generaliza muy bien a los modelos de subprocesamiento más convencionales (como, frex, el que tanto la PC como la 360 usan).
Hace unos años, el CEO de Opera dijo en una entrevista que la clave para desarrollar plataformas independientes es alejarse de cualquier biblioteca de OS/plataforma. Continuó y dijo que desarrollaron sus propias bibliotecas que mejoran el rendimiento del sistema operativo.
Mi suposición es que las grandes compañías tendrán un equipo común, Xbox, PS, Windows, FooOS, equipos separados. Cada plataforma necesita ser ajustada de manera diferente y requiere diferentes métodos de implementación. No creo que hagan una fuente para todas las plataformas; más bien, construyen uno para cada sistema operativo de ese modo, mejorando las eficiencias. Recuerdo que EA solía lanzar algunos juegos de consola antes que las versiones para PC y viceversa.
Otro problema es que las diferentes consolas tienen hardware diferente por lo que requieren diferentes técnicas de programación.
hay dos extremos, construya una fuente que se ajuste a todos (java por ejemplo) pero corre el riesgo de ineficacia o escriba 40 versiones; uno optimizado para cada plataforma
Cuando tenía un amigo en juegos de computadora educativos (antes de que The Learning Company destruyera el campo), era un gran fan de crear bibliotecas multiplataforma para hacer todo.
Esto es más fácil para juegos que otras aplicaciones. Si tiene una aplicación de procesamiento de textos para ejecutar en Mac y Windows, por ejemplo, realmente necesita verse y comportarse como una aplicación de Mac en la Mac y una aplicación de Windows en Windows. Escribe un juego y no tiene que conformarse con el comportamiento, el aspecto y la sensación del nativo.
Hay un montón de artículos de Game Developer Magazine y conversaciones de GDC sobre el tema. De hecho, desde que mencionó Valve, they delivered a talk describing their approach en GDC08.
Este es realmente un tema muy amplio que podría (y tienen) hablar por horas y horas, pero Resumen ascensor es:
Si desea ejemplos de código abierto, puede consultar el código fuente de los motores Quake 1, 2 y 3. Están estructurados de manera bastante portátil. (Por supuesto, no se aplican PS3 o Xbox360 apoyo, pero mismos principios)
Esta pregunta se puede dividir en dos preguntas separadas. "¿Cómo puedo escribir un código portátil?" y "¿Cuáles son los requisitos divergentes de las plataformas de juego convencionales?".
La primera pregunta es relativamente fácil de responder. Las mejores prácticas para la abstracción de su código no portátiles están cubiertas de escribir código portable: http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcover
De la teoría a la práctica, el código fuente de Quake 3 hace un muy buen trabajo de dividir a cabo diferentes plataformas en áreas separadas para una base de código C, disponible en http://www.idsoftware.com/business/techdownloads/ Sin embargo, no muestra patrones C++ como interfaces abstractas, implementadas una vez por plataforma.
La segunda parte de su pregunta, "¿Cuáles son los requisitos divergentes de las plataformas de juego convencionales?" es más difícil. Sin embargo, es notable que sus áreas de cambio más grandes siguen siendo su procesador, su subsistema de audio y su red.
Cada plataforma de consola tiene una serie de requisitos de certificación, disponibles bajo un acuerdo con los respectivos propietarios de la consola. Los requisitos generan coherencia en la experiencia del usuario y no se centran en jugabilidad ni en problemas cualitativos de alto nivel. Por ejemplo, es posible que su juego necesite mostrar una pantalla de carga de animación razonablemente interesante, y las pantallas negras son inaceptables.
Ponerse las manos en esta documentación tan pronto como sea posible es la clave para tomar las decisiones correctas al desarrollar una plataforma de consola específica.
Por último, si no puede tener en sus manos una consola devkit, le sugiero que transmita su código a la Mac desde Windows. La Mac le proporciona un puerto de sistema operativo que le garantiza que no está vinculado a Windows ni a un puerto de procesador si es compatible con los binarios universales. Esto asegura que su código es agnóstico endian.
Si admite tanto PC como Mac, estará en una buena posición para admitir una tercera plataforma, en caso de que tenga acceso a ella en el futuro.
Adición Usted escribió:
la solución ideal es reutilizar tanto código como sea posible en lugar de volver a escribir toda la cosa para cada plataforma
En muchos escenarios de juego de portabilidad, la solución ideal es no para reutilizar la mayor cantidad de código posible, pero para escribir el código óptimo para cada plataforma.El código puede reutilizarse entre proyectos y es relativamente económico en comparación con el contenido que capta el motor. Un objetivo más razonable es apuntar al contenido de denominador común más bajo que se ejecuta en todas las plataformas sin modificación (una fase de compilación que empaqueta el contenido para medios está bien).
Es genial hacer un desarrollo simultáneo. Encuentra todo tipo de errores que no encontraría haciendo una sola plataforma.
Recuerdo que los programadores en DOS tenían punteros nulos todo el tiempo porque escribir en memoria baja no los bloqueaba inmediatamente. Cuando transfirió a un Amiga, Atari ST o Macintosh, ¡boom! Recuerdo haberle dicho a un programador de DOS que tenía un par de punteros nulos en un juego enviado con prontitud. Pensó por un par de segundos y sonrió, "Eso explica algunas cosas".
Ahora que los juegos tienen presupuestos tan grandes, es importante enviarlos todos al mismo tiempo para que no pierda los presupuestos publicitarios y de publicidad.
Mi consejo sobre el desarrollo simultáneo es elegir una plataforma líder, pero nunca permita que la (s) otra (s) plataforma (s) se retrasen más de una semana. Se volverá obvio a medida que programe qué partes del código son comunes a todas las plataformas y cuáles son diferentes. Saque las diferencias en una o más áreas específicas de la plataforma.
Mi experiencia es en C/C++. Es un problema mayor si tiene que portar en contra de diferentes idiomas (por ejemplo, Java y Objective-c).
"Cualquiera que diga las palabras" No me preocupa el rendimiento "o" la memoria no es un problema "no debería estar en la nómina". Triste pero cierto. Para la mayoría de los tipos de software, estas personas pueden ser de gran ayuda si su perspectiva les ayuda a escribir el código correcto rápidamente. En el desarrollo del juego son veneno: - / –