Devo usare un database SQL per archiviare i dati in un gioco desktop? [chiuso]

Sviluppare un motore di gioco

Sto programmando un gioco per computer e il suo motore. Ci sarà un mondo tridimensionale con visuale in prima persona e per ora sarà giocatore singolo. Il linguaggio di programmazione è C ++ e utilizza OpenGL.

Decisione di progettazione centrata sui dati

La mia decisione di progettazione è quella di utilizzare un'architettura centrata sui dati in cui sono presenti un gestore eventi globale e un gestore dati globale . Esistono molti componenti come fisica, input, suono, renderer, ai, ... Ogni componente può attivare e ascoltare eventi . Inoltre, ogni componente può leggere, modificare, creare e rimuovere dati .

La domanda riguarda il gestore dei dati.

Se utilizzare un database relazionale

Dovrei usare un database SQL, ad esempio SQLite o MySQL, per archiviare i dati di gioco? Questo contiene praticamente tutti i contenuti di gioco come oggetti, personaggi, inventari, ... Tranne mesh e trame che sono ancora più legate alle prestazioni, quindi le terrò in memoria.

Un database SQL è abbastanza veloce da usarlo per leggere e scrivere in tempo reale informazioni sul gioco, come la posizione di un personaggio in movimento? Devo anche preoccuparmi della compatibilità multipiattaforma. Oltre a tenere tutto in memoria, quali alternative ho?

I vantaggi sarebbero

I vantaggi dell'utilizzo di un database relazionale come MySQL sarebbero la struttura orientata ai dati che consente un calcolo rapido. Non avrei bisogno di oggetti per rappresentare entità. Potrei facilmente interrogare i dati degli oggetti vicino al lettore necessari per il rendering. E non devo occuparmi dei dati degli oggetti lontani. Inoltre, non è necessario utilizzare i salvataggi in quanto lo stato della buca viene salvato nel database. Ultimo ma non meno importante, espandere il gioco in un gioco online sarebbe relativamente semplice perché esiste già un luogo in cui è memorizzato lo stato del gioco a buche.

Un database SQL non è abbastanza veloce da usare per leggere e scrivere informazioni sul gioco in tempo reale. Tali dati sono quasi sempre tenuti in memoria, nelle strutture di dati tradizionali.

Potrebbero esserci dei vantaggi nell'utilizzare un database incorporato come SQLite per determinati tipi di dati, ad es. dati statici che non cambiano durante il gioco ma cambiano durante lo sviluppo. Questo potrebbe quindi essere distribuito come parte del gioco finale in cui SQLite viene realmente utilizzato solo quando si carica il gioco per la prima volta o quando si avvia un nuovo livello, ecc.

Tuttavia ci sono anche molti aspetti negativi: è difficile patchare singole parti dei dati quando sono memorizzati in un singolo file di database, non è l'ideale per molti tipi di dati complessi di cui i giochi hanno bisogno (e che hai detto che avresti archiviato esterno - ma con riferimenti a e da cose all'interno), non è molto flessibile quando è necessario modificare lo schema, non è necessariamente retrocompatibile dopo aver modificato lo schema, ecc.

Per questi motivi, la maggior parte degli sviluppatori di giochi utilizzerà il proprio formato. Gli sviluppatori professionisti che sono attenti alle prestazioni a volte vanno oltre e salvano la struttura dei dati in memoria direttamente sul disco in modo che possa essere caricata con un minimo di elaborazione.

E se hai davvero bisogno di dati tabulari basati su testo che possono essere facilmente modificati, puoi usare un semplice formato basato su testo, come CSV, XML, JSON, YAML, ecc.

Un database non è veloce, l'utilizzo di un database è molto più lento dell'accesso tradizionale alla memoria. Il motivo è semplice, un database è dinamico, c'è un mucchio di sovraccarico collegato ad esso, le query devono essere analizzate, gli hash devono essere calcolati e altre cose.

L'utilizzo di un database ha solo un vantaggio: la persistenza. È possibile eseguire una o più applicazioni con un database per un lungo periodo di tempo senza dover temere dati lass. Ma i clienti del gioco non ne hanno assolutamente bisogno.

Quindi, vuoi ottenere ogni oggetto che è a meno di 1000 px?
Sarebbe:

List<Entity> retVal;
for(entity in entities)
  if(Distance(entity.pos(), to) < 1000)
     retVal.append(entity);
return retVal;

Ora cosa pensi che farebbe un database se gli chiedessi di allontanare ogni oggetto a meno di 1000 px?
Farebbe esattamente lo stesso! Solo con un mucchio di costi generali che renderebbero questa operazione estremamente semplice costa circa 100 volte il tempo del processore (a seconda di quante entità hai). I database non sono magici.

Non utilizzare database per nient'altro che applicazioni server.