Il blog Games from Within di Noel Llopis ha toccato questo argomento di recente nel post "Remote Game Editing" . Il paragrafo iniziale:
Sono stato a lungo un fan di runtime di gioco minimi. Tutto ciò che può essere fatto offline o in uno strumento separato, dovrebbe essere fuori dal runtime. Ciò lascia l'architettura e il codice di gioco molto snelli e semplici .
(L'articolo è una lettura altamente raccomandata, come con la maggior parte delle cose di Noel, sia che tu sia d'accordo al 100% o meno.)
Credo che la chiave qui sia mantenere la complessità al di fuori del motore. Puoi ancora avere flessibilità, ma è flessibilità nella pipeline di contenuti. E ottieni prestazioni migliori non impiegando tempo a convertire e spostare i dati.
Prestazioni migliori possono tradursi in tempi di iterazione più bassi, stranamente, nonostante la perdita di alcune delle capacità di modifica interne al motore: è più facile provare qualcosa se riesci a caricare il gioco in un secondo.
L'adozione di alcuni dei principi della " filosofia unix " ti aiuterà a mantenere flessibile la tua toolchain: una piccola pipeline modulare.
La mia filosofia personale: cuocere quanti più dati possibile offline, ma fornire supporto al motore per ricevere nuovi dati in qualsiasi momento. (Nota che questi nuovi dati non hanno bisogno di entrare in gioco fino a un punto conveniente: viene premuto il pulsante "aggiorna", inizia il livello successivo, si passa a una nuova area, qualunque sia. Il tasto sta trovando il punto debole che minimizza tempo di iterazione con complessità minima del codice e sforzo di codifica.)
Nella nostra azienda la maggior parte dei nostri strumenti rivolti ad artisti / designer sono focalizzati su problemi di interfaccia utente: facilità di manipolazione di singoli asset o loro lotti, ecc. A volte sono solo strumenti di terze parti come Photoshop o 3DS Max. Questi strumenti vengono esportati in un formato intermedio (spesso XML che fa riferimento a dati binari di origine, ma non sempre). Il formato intermedio viene raccolto da uno strumento "data make" di backend, che lo trasforma in qualcosa di utile e di caricamento rapido per la piattaforma di destinazione.
La portabilità si ottiene aggiungendo ulteriori strumenti di creazione di dati di back-end o espandendo gli strumenti di creazione di dati di back-end esistenti, il che ha l'ulteriore vantaggio di essere invisibile ai creatori di contenuti.
Ora, con una corretta creazione di dati incrementali, puoi avere cambiamenti nel formato cotto in pochi secondi; il tuo motore può spider o uno strumento può spider e quindi questi appariranno nel tuo sistema di risorse, pronti per essere ricaricati quando è conveniente.
Gli strumenti, in particolare i dati di backend che creano strumenti, sono spesso più sciatti e più complessi del codice del motore. Va bene, perché sono più facili da refactoring / riscrivere, estendere e testare; hai specifiche per il loro comportamento ed è abbastanza facile testarle in unità rispetto ad alcuni codici motore.
Le mie opinioni sulle tue domande:
Il motore dovrebbe essere in grado di caricare vari formati di immagine? Un caricatore solo TGA è un codice abbastanza semplice da gestire.
(A parte: anche se usi un decodificatore TGA nel motore, non codificarlo manualmente. Stai solo chiedendo problemi - ci sono molte sottigliezze con la maggior parte dei formati di immagine e molti strumenti che non aderiscono esattamente nel formato probabilmente non specificato. È meglio trovare il codice libreria esistente ben collaudato per l'elaborazione delle immagini.)
Vorrei che lo strumento qui venisse convertito da TGA a qualunque sia il tuo formato di trama interno, oltre ai metadati.
E i formati audio? È possibile supportare solo il caricamento di file wav? Che dire dei file musicali ambient che sono spesso enormi.
Qui utilizziamo tre formati: musica tracciata (.xm), ADPCM (.wav) e Speex (.spx). Ciò è dovuto principalmente al fatto che siamo su palmari e questi formati sono molto leggeri da decodificare.
Il motore dovrebbe essere in grado di analizzare in modo dinamico TTF e generare atlanti? Imballaggio di trama.
L'atlante è un problema difficile: vedi le risposte alla tua domanda recente . Vale quasi sempre la pena farlo offline.
Inoltre, puoi trasformare i metadati per carattere in una struttura al forno con codice di carico quasi zero.
In chiusura, puoi ripulire e impacchettare questa pipeline con il tuo gioco, per la community mod. Puoi sempre aggiungere altri formati di origine. E non c'è nulla che ti impedisca di colmare il divario tra gli strumenti di creazione di contenuti e il motore in casi specifici; si spera che il codice di cottura dei dati e il codice ragno / trasferimento possano essere rifattorizzati in librerie che potrebbero in alcuni casi essere utilizzate direttamente dagli strumenti di creazione dei contenuti. Ma non vorrei che il mio primo obiettivo, necessariamente ... Sii solo consapevole del fatto che sarà un obiettivo finale e lascia che questo influenzi un po 'il tuo design, e scegli prima il frutto basso.
Come aggiornamento, potresti prendere in considerazione l'utilizzo del Formato file KTX per le trame. Ha il vantaggio di essere per lo più "read in structand go" per la maggior parte dei casi d'uso GL (e dai tuoi commenti sembra che tu stia prendendo di mira GL) pur essendo flessibile e ben definito.
L'overhead dell'intestazione KTX potrebbe essere un po 'alto per i dati completamente cotti, a seconda del target, e potresti voler rinunciare al supporto di swap endian, a seconda del tuo caso d'uso ... ma sicuramente vale la pena almeno uno sguardo per considerazioni di progettazione.