Framework o libreria di Game Engine [chiuso]

Sono in fase di pianificazione per un motore di gioco interno che sto per iniziare a creare, che verrà utilizzato per tutti i miei giochi in futuro. Ma sto lottando un po 'con come dovrebbe essere costruito.

Le scelte si riducono a: framework o libreria.

Il mio obiettivo di base è nascondere il più possibile i dettagli del motore per mantenere il più possibile lo sviluppo di giochi di alto livello su script e file di configurazione. Ma anche per riutilizzare il motore principale per tutti gli strumenti che potremmo sviluppare in futuro.

I framework possono rendere le cose belle e facili per lo sviluppo, ma poi sei bloccato. Le librerie sono buone se sei interessato solo a un sottosistema specifico. Ma dobbiamo incollare tutto insieme in base al gioco.

Bene, ce n'è anche un altro, che costruisce il motore come un exe autonomo che gestisce tutte le risorse di gioco e tutti i sottosistemi. La logica di gioco (e altre cose dinamiche per gioco) viene eseguita esclusivamente su script con file di configurazione per configurare ciascun sottosistema motore interno.

Quale mi darà più flessibilità in futuro.

Grazie.

Modifica: grazie a tutti, suppongo che stavo guardando questo nella prospettiva sbagliata. Non possiamo davvero progettare qualcosa del genere senza una conoscenza a priori di ciò di cui i giochi hanno bisogno, immagino sia per questo che non esiste un motore generale per tutti i generi.

Mi concentrerò prima sul gioco corretto, quindi analizzerò iterativamente alla fine di ogni gioco come realizzare astrazioni decenti per librerie o framework a seconda del mio flusso di lavoro (o forse di quello di una squadra futura).

Non preoccuparti ancora del futuro. Preoccupati per il tuo gioco attuale, ora. Altrimenti non andrai da nessuna parte perché ti preoccupi dei dettagli.

Dovresti concentrarti prima sulla costruzione del gioco e poi, se il gioco ha avuto successo, puoi estrarlo in qualcosa di riutilizzabile per il tuo prossimo gioco. Questo ti impedirà di essere bloccato in qualcos'altro e ti darà il pieno controllo sul tuo progetto.

Costruisci un framework.

Ho esperienza con la costruzione di entrambi. Preferisco usare le librerie rispetto ai framework. I quadri sembrano molto restrittivi e "prepotenti" . Quindi, quando ho realizzato il mio primo gioco, volevo costruire un motore composto da molte librerie che potevano essere facilmente riutilizzate in altri progetti.

È stato un disastro. Ho trascorso metà del mio tempo a scrivere il codice colla tra le mie varie librerie. Anche le mie librerie tendevano ad essere gonfiate di astrazioni extra, quindi è diventato un compito enorme aggiungere funzionalità alle librerie / componenti.

Ora, tuttavia, i miei motori sono costruiti pensando al gioco che sto scrivendo. Tengo ancora gli occhi aperti per le astrazioni che mi permetteranno di riutilizzarlo o le nuove funzionalità che aggiungerò nei giochi successivi. Sono molto più felice e produttivo.

Per me il punto di svolta è stato decidere di non pubblicare il mio motore. Potrei ancora pubblicarlo, ma per ora sapere che non ho bisogno di giustificare i miei hack specifici per il gioco ad altri utenti mi ha permesso di costruire un motore più adatto ai miei giochi.

Lo vedo così spesso.
Perché costruire un motore, da utilizzare nei giochi futuri, quando non sai di quali giochi hanno bisogno?
Perché non costruire prima il gioco e poi un altro e un altro, riutilizzandoli il più spesso possibile.
Quindi hai una libreria di codice, probabilmente non organizzata, ma mostrata utile.
Quindi puoi organizzarti.

E per "framework vs library", baserei su quanto sei stanco di scrivere ripetutamente un loop di gioco e cose del genere. ;)

Un framework non ha necessariamente bisogno di bloccarti. Guarda XNA.

Mantienilo semplice.

Se non sei sicuro di quale strada fare, fai semplicemente tutto ciò che il tuo gioco richiede. Prova a scrivere piccole librerie di base per cose che ritieni possano essere utilizzabili in futuro. Analizza lo sviluppo di software basato sui dati. Suggerisco di esaminare i sistemi di entità basati su componenti. Non basare il codice su elementi unici come un giocatore. Un giocatore è solo un altro oggetto, proprio come qualsiasi altra cosa. Un'entità ha componenti, forse un elenco di componenti.

Scrivendo librerie piccole e contenute che interagiscono tra loro, puoi andare avanti e determinare quali riutilizzare per il tuo prossimo gioco. Personalmente ho cose come una libreria "container" per i tipi di archiviazione dei dati. Ho una biblioteca di matematica per queste cose. Esistono diverse cose come queste che puoi risolvere e scrivere come moduli. Telecamera, effetti, input, entità, movimento, fisica, rendering, gestione delle risorse, threading, l'elenco continua.

La scrittura di piccoli componenti autonomi spesso aumenta la leggibilità e le possibilità di debug del codice.

Mike Acton e i giochi insonni (www.insomniacgames.com) hanno scritto molti argomenti e discussioni sullo sviluppo di giochi, in particolare basati sui dati. Cercali e vedi che tipo di informazioni sono troppo complesse e che trovi interessanti e comprensibili. Sono grandi sviluppatori con una tonnellata di esperienza.

Penso che tu stia facendo una generalizzazione prematura. Non rimanere troppo bloccato su domande di uso futuro in questo momento. Scegli una risposta e corri con essa, impara da essa. Lancia una moneta se non hai preferenze.

Inizia costruendo un gioco. Quando costruisci il tuo secondo gioco avrai un'idea migliore di quali parti sono riutilizzabili e possono essere trasformate in solide funzioni di libreria. Quando costruisci il tuo terzo gioco avrai un'idea migliore di quale struttura è riutilizzabile e può essere trasformata in un solido framework.

In termini di flessibilità, penso che tu abbia risposto alla tua domanda: "I framework possono rendere le cose belle e facili per lo sviluppo, ma poi sei bloccato ". Ciò non significa che i framework debbano essere inflessibili; ogni gioco, ad esempio, ha un loop di gioco. Framework XNA di Microsoft è libreria del 99%, ma il vostro gioco estende la classe di gioco, che fornisce solo alcune funzioni in bianco per le cose che sono garantiti per essere in ogni partita: LoadContent, Update,Draw . È un ottimo esempio di un framework non restrittivo.

Si potrebbe dire che un framework non è altro che una libreria combinata con una (e) classe (i) di template che sono collegate alla libreria, almeno questa è stata la mia esperienza.

Tendo a preferire le biblioteche rispetto ai framework. jMonkeyEngine , ad esempio, è fantastico ma è un framework e di conseguenza ho notato che riceve tonnellate di flak.SDL , d'altra parte, è incredibilmente popolare; è solo una biblioteca. Fornisce ciò di cui hai bisogno, ma fa di tutto per fare ciò che vuoi.

Con una libreria, non c'è necessariamente molta incollatura da fare gioco per gioco, specialmente se si scrivono parti della libreria per supportare ogni parte del ciclo di gioco; un timer / contatore per fotogrammi al secondo, ad esempio, impedirebbe che quella parte riscritta comunemente debba essere reinventata con ogni gioco.

Inoltre, le librerie possono essere generali o specifiche come si desidera crearle. Se stai realizzando un gioco di corse e vuoi che la tua libreria abbia funzionalità specifiche per le corse, va bene. È la tua creazione e puoi scegliere esattamente quanto flessibile la desideri. Ciò sarebbe molto fattibile in una situazione in cui hai un contratto a lungo termine con Nascar per sviluppare numerosi giochi di corse, per esempio. Non vorrai necessariamente un framework per legarti potenzialmente a un classico gioco di corse in un cerchio quando Nascar arriva e chiede un gioco offroad, ma vorresti una biblioteca specifica per il gioco di corse poiché sai che Nascar non è chiederò un tiratore.

Ecco anche un suggerimento per lo sviluppo: se scrivi la libreria insieme a un gioco, finirai inevitabilmente per accoppiare accidentalmente la libreria al gioco o renderla troppo flessibile, non importa quanto pianifichi. Lo scoprirai non appena proverai a fare un gioco diverso con esso e passerai il tempo a separarlo; questa non è necessariamente una brutta cosa e potresti decidere consapevolmente di farlo, dato che avrai più tempo libero dopo il rilascio del tuo primo gioco. Ma se si sta puntando per una libreria stellare dal get-go, prova a creare due giochi completamente diversi allo stesso tempo ed estrai i pezzi simili nella tua libreria. Otterrai MOLTO meno accoppiamento, sarà molto più flessibile e il tuo terzo gioco probabilmente esporrà ancora alcuni punti deboli ma alla fine la tua libreria sarà molto migliore. Tuttavia, è ovviamente molto più difficile e richiede più tempo.