Comment les développeurs de jeux ciblent-ils plusieurs plateformes (Xbox 360, PS3, PC et Linux)?

Comment les développeurs de jeux ciblent-ils plusieurs plateformes à la fois? Par exemple, Xbox 360, PS3, PC et Linux. Pour les jeux 2D, est-il possible de cibler également l'iPhone? Je m'intéresse aux moteurs utilisés (2D / 3D, etc.), à la façon dont le pipeline de construction est configuré et généralement à la quantité de "code de base" qui peut être centralisée sans avoir à écrire des branches de code spécifiques à la plate-forme.

Ou, si des troncs de code complètement séparés sont généralement maintenus pour chaque plate-forme, comment les bibliothèques / codes sont-ils réutilisés (en termes de liaison et de modularisation)?

Pour le développement de jeux sur console commerciaux, la configuration d'un système de build pour cibler 360, PC et PS3 simultanément est irritante mais n'est pas particulièrement difficile. Le kit de développement 360 est tout simplement une nouvelle cible pour Visual Studio + quelques outils et utilise un compilateur très similaire au compilateur Windows MSVC ++ standard. La PS3 utilise un back-end de compilateur GCC mais se branche facilement au frontal de Visual Studio. Pour le gameplay et le code utilitaire général, il devrait généralement être possible d'avoir un code identique à 99% entre les 3 plateformes. Il y a des incompatibilités entre GCC et MSVC ++, mais heureusement, si vous travaillez sur Linux (en supposant que vous utilisez une version gcc proche de la PS3), cela ne posera pas trop de problèmes. Le dernier 1% de code qui diffère, vous pouvez normalement le corriger avec kludgy #defines.

Après les étapes de construction de base, le gros obstacle sera les systèmes graphiques ainsi que tous les éléments de haute performance de votre jeu. Pour ces éléments, vous allez vraisemblablement finir par écrire du code personnalisé de plate-forme ou utiliser un moteur existant. La mémoire sera un énorme problème, mais c'est pour une autre question. Un projet commercial sur lequel j'ai travaillé a été en mesure d'obtenir assez facilement les versions console d'une base de source PC d'origine, mais les rendre réellement performantes était un problème complètement différent.

Si vous souhaitez également intégrer l'iPhone, vous pouvez utiliser une sorte de solution de moteur / middleware existante. La configuration iPhone d'OpenGL + objectif C ne correspond pas vraiment très bien à aucune autre plate-forme. C'est un choix de la part d'Apple, car ils découragent fortement l'utilisation d'intergiciels interprétés dans toutes les applications iPhone.

Pour la plupart des plates-formes, vous pouvez écrire des sous-systèmes qui s'éloignent des API spécifiques utilisées pour appeler et récupérer des informations de la plate-forme sur laquelle vous exécutez. Les API d'E / S sont généralement les plus faciles à résumer - tous les systèmes de fichiers fonctionnent sur des hypothèses assez basiques concernant l'ouverture, la fermeture et la lecture des fichiers, même lorsque vous tenez compte des appels asynchrones. Ensuite, vous avez vos systèmes de base comme la lecture des entrées de contrôleur, l'interrogation de l'heure, l'accès à la mémoire et aux primitives de thread, dont la plupart fonctionnent de la même manière.

Même les graphiques peuvent être abstraits dans une large mesure, et en fait dans la plupart des bons moteurs, ils le sont. Mais vous devez emballer les choses `` rendables '' dans des boîtes noires où vous n'êtes pas autorisé à savoir ce qui se passe à l'intérieur. Vous savez que vous avez une «chose» que vous rendez dans une position particulière dans le monde. Vous ne savez pas comment il est rendu, juste que c'est. Et la couche d'abstraction graphique s'occupe de tous les détails pour l'obtenir à l'écran. Les pipelines de construction spécifiques à la plate-forme regroupent les données graphiques de manière à ce qu'elles puissent être référencées à partir du moteur sans vraiment savoir comment elles sont représentées en interne.

Cela dit, quand il s'agit de réellement expédier un jeu, il y a certaines parties que vous ne pouvez pas supprimer. Il serait ridicule de penser que vous pourriez expédier le même code sur iPhone que sur 360 ou PS3, car les mécanismes d'entrée, le mode de fonctionnement fondamental et les capacités de la plate-forme sont tout simplement trop différents. Vous pourriez créer un titre de taille iPhone sur 360, mais il faudrait limiter ses mécanismes de saisie à ceux que le 360 ​​peut prendre en charge. Donc, un curseur virtuel sur l'écran simulant un doigt, et éventuellement en utilisant le joystick où l'entrée d'accéléromètre 3D est utilisée.

Plus judicieusement, des parties du jeu peuvent être écrites de manière réutilisable et des modules de code individuels peuvent être portés entre les plates-formes, même si la majorité du titre est différente. Par exemple, si vous avez une machine d'état AI, peu importe qu'elle fonctionne sur 360, PC ou iPhone. Votre jeu utilisera de nombreux composants de ce type, et tant qu'ils sont bien conçus pour prendre des entrées et sorties bien définies, le reste du jeu peut être enroulé autour d'eux, quelle que soit la plate-forme, et éviter d'avoir à les réécrire Composants.

Cette réutilisation est la clé d'un développement multiplateforme, ne recherchant pas un moteur universel qui fonctionne sur toutes les plates-formes. Même si une telle chose existait, elle serait tellement paralysée en devant travailler sur le plus petit dénominateur commun, il ne serait pas très utile de faire des jeux avec.

Un moyen consiste à utiliser un moteur multiplatefom tel que Torque ou Unity3D . Mais je ne pense pas qu'ils fonctionnent sur toutes ces plates-formes. Il y a aussi une autre façon: développer un moteur ...