In che modo aziende come Valve riescono a rilasciare giochi su tutte e tre le principali piattaforme di gioco? Sono interessato alle best practice riguardanti la condivisione del codice specificamente tra Windows, Xbox360 e PS3, poiché la soluzione ideale è riutilizzare il maggior numero possibile di codice anziché riscrivere il tutto per ogni piattaforma.Come posso conoscere lo sviluppo di giochi multipiattaforma?
Non è diverso dallo scrivere codice indipendente dalla piattaforma in altri contesti. Nascondi i dettagli specifici della piattaforma (input, interazione con le finestre, il ciclo degli eventi principale, threading, ecc.) Dietro le interfacce generiche e verifica regolarmente su tutte le piattaforme che intendi supportare.
Si noti che il modello di threading di Cell è abbastanza insolito che il threading "genericamente" richiede una certa attenzione. Non sono un dipendente di Valve e non conosco nessuno dei loro segreti, ma è a mia conoscenza che la maggior parte degli sviluppatori di giochi che desiderano utilizzare come target la PS3 utilizzano una coda di lavoro che i singoli processori di celle eliminano le attività quando necessario. Questo non è necessariamente il modo migliore di usare la cella, ma generalizza benissimo ai modelli di threading più convenzionali (come Frex, quello che usano sia il PC che il 360).
Alcuni anni fa il CEO di Opera ha dichiarato in un'intervista che la chiave per lo sviluppo di piattaforme indipendenti è quella di allontanarsi da qualsiasi singola piattaforma OS/piattaforma. Ha proseguito dicendo che hanno sviluppato le proprie librerie che migliorano le prestazioni del sistema operativo.
Il mio presupposto è che le grandi aziende avranno un comune, Xbox, PS, Windows, FooOS, squadre separate. Ogni piattaforma deve essere modificata in modo diverso e richiede diversi metodi di implementazione. Non penso che facciano una fonte per tutte le piattaforme; piuttosto, ne costruiscono uno per ciascun sistema operativo, migliorando così l'efficienza. Ricordo che EA distribuiva alcuni giochi per console prima delle versioni per PC e viceversa.
Un altro problema è che diverse console hanno hardware diverso che richiede quindi tecniche di programmazione differenti.
ci sono due estremi, costruisci una sorgente che si adatta a tutti (java per esempio) ma corri il rischio di inefficienza o scrivi 40 versioni; uno ottimizzato per ogni piattaforma
Quando avevo un amico in giochi per computer educativi (prima che The Learning Company distruggesse il campo), era un grande fan della creazione di librerie multipiattaforma per fare tutto.
Questo è più semplice per i giochi rispetto ad altre app. Ad esempio, se si dispone di un'app di elaborazione testi da eseguire su Mac e Windows, è necessario osservare e comportarsi come un'app Mac sul Mac e un'app di Windows su Windows. Scrivi un gioco e non deve conformarsi al comportamento, all'aspetto e al tatto nativi.
C'è un mucchio di articoli di Game Developer Magazine e discorsi GDC sull'argomento. Infatti, dal momento che hai citato Valve, they delivered a talk describing their approach in GDC08.
questo è davvero un oggetto enorme che ho potuto (e hanno) parlare per ore e ore, ma sintesi ascensore è:
Se volete esempi open source, si poteva guardare il codice sorgente di Quake 1, 2 e 3 motori. Sono strutturati in modo abbastanza portabile. (Naturalmente, nessun supporto PS3 o Xbox 360, ma stessi principi si applicano)
Questa domanda può essere diviso in due questioni separate. "Come posso scrivere un codice portatile?" e "Quali sono i requisiti divergenti delle piattaforme di gioco tradizionali?".
La prima domanda è relativamente facile da rispondere. Best practice per astrarre il codice non portabile sono coperte di scrivere il codice Portatile: http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcover
Passando dalla teoria alla pratica, il codice sorgente di Quake 3 fa un buon lavoro di dividere le diverse piattaforme in aree separate per una base di codice C, disponibile a http://www.idsoftware.com/business/techdownloads/ Tuttavia, non mostra modelli C++ come interfacce astratte, implementate una volta per piattaforma.
La seconda parte della domanda "Quali sono i requisiti divergenti delle piattaforme di gioco tradizionali?" è più duro. Tuttavia, è importante notare che le aree di modifica più estese sono ancora il tuo renderer, il tuo sottosistema audio e il tuo networking.
Ogni piattaforma console ha una serie di requisiti di certificazione, disponibili in base ad un accordo con i rispettivi proprietari di console. I requisiti guidano la coerenza nell'esperienza utente e non sono focalizzati sul gameplay o su problemi qualitativi di alto livello. Ad esempio, il tuo gioco potrebbe dover visualizzare uno schermo di caricamento animato ragionevolmente interessante e gli schermi neri non sono accettabili.
Mettere le mani su questa documentazione il prima possibile è la chiave per fare le scelte giuste per lo sviluppo di una piattaforma console specifica.
Infine, se non si riesce a mettere le mani su un DevKit console, vi consiglio di porta il codice per il Mac da Windows. Il Mac ti offre una porta del sistema operativo per assicurarti di non essere legato a Windows e a una porta del processore se supporti binari universali. Ciò garantisce che il tuo codice sia agnostico endian.
Se supportate sia PC che Mac, sarete in una buona posizione per supportare una terza piattaforma, se doveste accedervi in futuro.
Addendum Hai scritto:
la soluzione ideale è quella di riutilizzare il più codice come possibile, invece di riscrivere il tutto per ogni piattaforma
In molti scenari di gioco porting, la soluzione ideale è non per riutilizzare il maggior numero possibile di codice, ma per scrivere il codice ottimale per ogni piattaforma.Il codice può essere riutilizzato tra i progetti ed è relativamente economico rispetto al contenuto del motore. Un obiettivo più ragionevole è quello di puntare a un minimo comune denominatore contenuto su tutte le piattaforme senza modifiche (una fase di compilazione che racchiude il contenuto per i media va bene).
È bello fare lo sviluppo simultaneo. Troverai tutti i tipi di bug che non troveresti facendo solo una piattaforma.
mi ricordo che i programmatori in DOS avevano puntatori nulli tutto il tempo perché scrivendo a poca memoria non li ha in crash immediatamente. Quando fai il porting su un Amiga, Atari ST o Macintosh, boom! Ricordo di aver detto a un programmatore di DOS che aveva un paio di puntatori nulli in un gioco spedito con l'aready. Pensò per un paio di secondi e sorrise, "Questo spiega alcune cose."
Ora che i giochi hanno tali grandi budget, è importante per spedire tutti allo stesso tempo in modo da non sprecare budget di marketing e pubblicitarie.
Il mio consiglio per lo sviluppo simultaneo è quello di scegliere una piattaforma di piombo, ma mai lasciare che l'altra piattaforma (s) ottiene più di una settimana alle spalle. Diventerà ovvio mentre programmi quali parti del codice sono comuni a tutte le piattaforme e quali sono differenti. Estrarre le differenze in una o più aree specifiche della piattaforma.
La mia esperienza è in C/C++. È un problema più grande se devi effettuare il porting contro linguaggi diversi (ad esempio, Java e Objective-c).
"chi dice le parole 'Io non sono preoccupato per le prestazioni' o 'la memoria non è un problema' non dovrebbe essere sul libro paga." Triste ma vero. Per la maggior parte dei tipi di software queste persone possono essere di grande aiuto se la loro prospettiva li aiuta a scrivere rapidamente il codice corretto. Nello sviluppo del gioco sono veleni: - / –