In che modo gli sviluppatori di giochi prendono di mira più piattaforme (Xbox 360, PS3, PC e Linux)?

In che modo gli sviluppatori di giochi prendono di mira più piattaforme contemporaneamente? Ad esempio, Xbox 360, PS3, PC e Linux. Per i giochi 2D, è possibile scegliere come target anche l'iPhone? Mi interessano i motori utilizzati (2D / 3D, ecc.), Come viene impostata la pipeline di build e in generale quanta parte del "codice core" può essere centralizzato senza dover scrivere rami di codice specifici della piattaforma.

Oppure, se di solito vengono gestiti trunk di codice completamente separati per ciascuna piattaforma, come vengono riutilizzate le librerie / il codice (in termini di collegamento e modularizzazione)?

Per lo sviluppo di giochi per console commerciali, la configurazione di un sistema di build per il targeting simultaneo di 360, PC e PS3 è irritante ma non particolarmente difficile. Il kit di sviluppo 360 è semplicemente un nuovo obiettivo per Visual Studio + alcuni strumenti e utilizza un compilatore molto simile al compilatore MSVC ++ standard di Windows. La PS3 utilizza un back-end del compilatore GCC ma si collega facilmente al front-end di Visual Studio. Per il gameplay e il codice generale dell'utilità, in genere dovrebbe essere possibile avere un codice uguale al 99% tra le 3 piattaforme. Ci sono alcune incompatibilità tra GCC e MSVC ++, ma per fortuna se si risolvono quelle di Linux (supponendo che si usi una versione gcc vicina a quella di PS3) non ci saranno troppi problemi. L'ultimo 1% di codice che differisce normalmente può essere corretto con kludgy #defines.

Passati i passaggi di costruzione di base, il grande ostacolo saranno i sistemi grafici e tutti gli elementi ad alte prestazioni del tuo gioco. Per questi elementi realisticamente finirai per scrivere codice personalizzato della piattaforma o utilizzare un motore esistente. La memoria sarà un grosso problema ma è per un'altra domanda. Un progetto commerciale a cui ho lavorato è stato in grado di ottenere abbastanza facilmente le versioni console di una sorgente PC originariamente, ma farle funzionare bene era un problema completamente diverso.

Se desideri integrare anche iPhone, potresti optare per una sorta di soluzione motore / middleware esistente. La configurazione dell'iPhone di openGL + obiettivo C non si adatta molto bene a qualsiasi altra piattaforma. È una grande scelta da parte di Apple, in quanto scoraggiano fortemente l'uso del middleware interpretato in qualsiasi applicazione per iPhone.

Per la maggior parte delle piattaforme, è possibile scrivere sottosistemi che si allontanano dalle API specifiche utilizzate per richiamare e ottenere informazioni dalla piattaforma su cui si sta eseguendo. Le API IO sono in genere le più facili da astrarre: tutti i file system funzionano su alcuni presupposti piuttosto basilari sull'apertura, la chiusura e la lettura dei file, anche quando si tiene conto delle chiamate asincrone. Quindi hai i tuoi sistemi principali come la lettura dell'input del controller, l'interrogazione del tempo, l'accesso alla memoria e i thread primitivi, la maggior parte dei quali funzionano allo stesso modo.

Anche la grafica può essere astratta in larga misura, e in effetti lo sono nella maggior parte dei buoni motori. Ma devi imballare le cose "renderizzabili" in scatole nere in cui non ti è permesso sapere cosa sta succedendo al loro interno. Sai di avere una "cosa" che rendi in una particolare posizione nel mondo. Non sai come viene visualizzato, solo che lo è. E il livello di astrazione grafica si prende cura di tutti i dettagli per vederlo sullo schermo. Le pipeline di build specifiche della piattaforma raggruppano i dati grafici in modo tale che possano essere referenziati dal motore senza realmente sapere come sono rappresentati internamente.

Detto questo, tuttavia, quando si tratta di spedire effettivamente un gioco, ci sono alcune parti che non puoi semplicemente sottrarre. Sarebbe ridicolo pensare che potresti spedire lo stesso codice su iPhone come su 360 o PS3, in quanto i meccanismi di input, il modo di operare fondamentale e le funzionalità della piattaforma sono troppo diversi. Potresti creare un titolo di dimensioni iPhone su 360, ma dovrebbe limitare i suoi meccanismi di input solo a quelli che il 360 può supportare. Quindi, un cursore virtuale sullo schermo simula un dito ed eventualmente utilizza il joystick in cui viene utilizzato l'ingresso dell'accelerometro 3D.

Più sensatamente, parti del gioco possono essere scritte in modo riutilizzabile e i singoli moduli di codice possono essere trasferiti tra le piattaforme, anche se la maggior parte del titolo è diversa. Ad esempio, se hai una macchina a stati AI, non importa se è in esecuzione su 360, PC o iPhone. Il tuo gioco utilizzerà molti di questi componenti, e fintanto che sono stati progettati bene in modo che prendano input e output ben definiti, il resto di un gioco può essere avvolto attorno a loro, indipendentemente dalla piattaforma, ed evitare di doverli riscrivere componenti.

Questa riutilizzabilità è la chiave per uno sviluppo multipiattaforma, non alla ricerca di un motore adatto a tutte le dimensioni che funzioni su tutte le piattaforme. Anche se esistesse una cosa del genere, sarebbe così paralizzato dal dover lavorare con il minimo comune denominatore, non sarebbe molto utile fare giochi.

Un modo sta usando un motore multipiattaforma come Torque o Unity3D . Ma non penso che funzionino su tutte quelle piattaforme. C'è anche un altro modo: sviluppare un motore ...