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.