Riempi tutti i tuoi dati di gioco in enormi tabelle Excel? Esistono metodi migliori?


8

Voglio davvero sapere quanti game designer preferiscono lavorare con un enorme tavolo per tutti gli oggetti, un altro tavolo per tutte le abilità e persino un altro tavolo per tutti i mob in un MMORPG. E queste tabelle possono raggiungere diverse centinaia di MB con migliaia di record, ma la maggior parte dei record utilizza solo pochi campi in una tabella.
So che alcuni game designer lavorano in questo modo. Esistono metodi migliori?


1
Wow! Di 'al tuo amico game designer di considerare almeno qualcosa come SQLite :)
bummzack

@bummzack: SQLite è un database relazionale. Excel è un foglio di calcolo. Un RDB può essere (malamente) sostituito da un programma per fogli di calcolo, ma non è possibile sostituire un programma per fogli di calcolo con un solo RDB.

(Ho infiniti aneddoti professionali sul perché Excel è fantastico / orribile per questo tipo di cose, che potrei scrivere in un giorno o due se penso di poterlo fare senza essere citato in giudizio, ma spero che qualcuno abbia più prove di risposta.)

1
Immagino di aver frainteso il contesto qui. Ho pensato che questo sarebbe stato usato come nell'origine dati del gioco e non come "strumento di progettazione".
Bummzack,

Qualcuno ha pensato di utilizzare i file XML per questo scopo?
James P.

Risposte:


4

Non volevo rispondere qui, ma quando ho visto un'altra risposta / commenti ho cambiato idea. SQL non è un'ottima soluzione di questo. SQL definisce le tabelle e inserisce molti dati in tali tabelle. Non è così. Quando crei / collaudi il design del gioco, devi principalmente verificare se l'enorme sistema è bilanciato. Ciò significa che molte tabelle si influenzano a vicenda. Niente di buono per SQL in realtà - o lo è, ma non è facile da gestire, perché devi fare una programmazione che non è necessaria. E il game designer non deve saperlo.

Come programmatori / sviluppatori di giochi possiamo disdegnare Excel e il suo utilizzo per qualsiasi cosa, ma è un ottimo strumento per questo caso, specialmente quando il game designer può usarlo bene e il documento è ben creato.

Non posso raccomandare nessun altro strumento, ma posso dire di conoscere designer di giochi professionisti che usano anche Excel. Quindi presumo sia uno strumento comune.


Sì, Excel è uno strumento comune. Il punto della domanda è: "un unico enorme tavolo per tutti gli oggetti", gli oggetti includono attrezzature, consuma, ecc. È necessario dividere quello grande in quelli piccoli? Hai anche un file di configurazione separato per ogni elemento? Temo che l'enorme tavolo possa ferire i loro occhi: o)
Huang F. Lei

Mi dispiace non lo so. Sono programmatore di motori. Volevo solo dire "Ehi, perché dici tutti SQL e fai battute su Excel, quando è uno strumento comune?". La domanda è buona e sono interessato a una risposta sofisticata, migliore della mia.
Notabene,

La mia risposta SQl originale era dovuta al fatto che mi mancava la parte del "game designer" della domanda e l'ho cancellata perché sarebbe fuorviante.
Il comunista Duck

3

Concordo con la maggior parte dei rispondenti che a volte i fogli di calcolo possono creare strumenti di sviluppo decenti, specialmente per i designer.

Se sei interessato ad approfondire questo approccio, il programma per fogli di calcolo Resolver One utilizza python per gli script, rendendo semplice l'impostazione di un foglio di calcolo per i progettisti che eseguono sia modelli complessi che esportazione in un formato dati intuitivo. Trovo molto più facile lavorare con il VBScript di Excel.


1
divertiti ad aspettare diversi secondi per aprirlo! Bah è lento (anche su macchine veloci)
Spooks

2

Excel è una soluzione eccellente. Mi chiedevo come si potesse fare. Ma a pensarci bene, Excel è uno strumento molto popolare e abbastanza adeguato per questo compito, non consiglierei questa pratica. Inoltre, il database reale, come suggerisce @notabene, porta un sacco di costi extra che non ti servono davvero. Vedo un paio di opzioni, una delle quali è simile all'utilizzo di Excel:

  • Open Office Calc: gratuito. C'è anche un download del connettore MySql (credo open source) per Calc.
  • dati serializzati: XML o binari (crittografati)

... in entrambi i casi, gratis e hai il controllo completo.

Personalmente sarei propenso ad andare con dati binari serializzati e crittografati . Due motivi:

  • i dati di gioco non possono essere facilmente manomessi
  • Posso lavorare con i database piuttosto che con la serializzazione Xml dei set di dati, ovvero ho l'opzione.

È necessaria una libreria di dati dedicata e orientata al gioco ? Forse ... a meno che qualcuno non sappia di una simile biblioteca già esistente.

Al punto della domanda del PO, guardare ogni file csv di pagina come una singola tabella di dati, simile a una tabella in un database. Ogni file di pagina deve contenere dati correlati:

  • Competenze o
  • Gear, o
  • Statistiche NPC

Questo ti aiuta a mantenere un alto livello di organizzazione che sarà molto importante man mano che il contenuto dei dati cresce, il contenuto del gioco si espande, ecc.

Modifica
Dopo aver effettivamente tentato di utilizzare .ODS (file OpenOffice Calc) e aver effettuato la connessione da un'applicazione, in realtà non è possibile in quanto implicano i post iniziali sul sito OO. Non sono riuscito a trovare nulla che mostri specificamente il codez sull'implementazione.

Inoltre, l'utilizzo di file Excel potrebbe andare bene durante lo sviluppo di un gioco in modo che i dati possano essere modificati senza sovraccarico da un database. Tuttavia, e questo è importante, se hai intenzione di farlo, devi avere MS Office installato in modo da poter fare riferimento a COM di interoperabilità di Microsoft Excel. All'inizio questo può essere utile, ma non vorrei rimuovere o modificare un sacco di codice per preparare un'applicazione per Alpha, Beta o RC. Una biblioteca molto semplificata richiederebbe uno sforzo maggiore di quanto potrei ritenere utile.

Ho intenzione di utilizzare i file CSV per l'archiviazione dei dati nella fase iniziale. Ci sono alcuni svantaggi, ma nel complesso ritengo che questa sia un'opzione molto migliore. Tutto è contenuto nelle mie librerie. .Net ha classi molto utili per leggere questi file di testo. Inoltre, come file .CSV, i dati possono essere facilmente manipolati; e, per le fasi successive dello sviluppo, tutto ciò che devo fare è serializzare i miei file di dati in XML, quindi successivamente in binario crittografato serializzato.


Non mi dispiace affatto i voti negativi ... tranne quando non so perché. C'è qualcosa di sbagliato nelle opzioni che ho fornito o nei miei consigli sull'organizzazione di un foglio di calcolo? O a qualcuno non sono piaciute le mie opzioni?
Estratto

Ti ho dato -1 perché hai confrontato un foglio di calcolo con un formato di dati del disco e poi hai fatto dichiarazioni come "i dati di gioco non possono essere facilmente manomessi". Un programma / interfaccia e un formato di dati del disco non sono realmente comparabili e rendere binari i dati di gioco fa ben poco per dissuadere i modder. Inoltre, lo schema del foglio di calcolo proposto è orribile, poiché conserva tutti i dati in un file. Certamente le abilità e gli NPC dovrebbero essere in file separati ; forse tutti gli NPC dovrebbero trovarsi in pagine separate nello stesso file , anche se se usi un RCS bloccante sarà anche orribile.

Non sono d'accordo. Prendi Open Office Calc con il connettore MySql. Sicuro che puoi creare un file diverso per ciascuno. Ma non mi aspetterei di conservare i miei dati in questo formato una volta che avrò un RC.
Estratto

Se i progettisti stanno usando Excel, essi potranno passare i dati tra di loro in formati come .xls o .csv. Se non vuoi perdere quei dati in un buco nero di Outlook o quando il loro computer si arresta in modo anomalo, devi insegnare loro a tenerli nell'RCS.

1

Fintanto che la natura dei tuoi dati consente di archiviarli in un foglio di calcolo senza saltare troppi cerchi, crea un formato molto buono, specialmente per il lavoro di sviluppo. Alla fine potresti voler memorizzarlo in altri formati per l'uso, ma il foglio di calcolo ti offre un editor molto potente che può essere MOLTO bello se decidi di cambiare il modo in cui gestisci qualcosa!

Se stai usando Excel vai a ottenere una copia delle utility ASAP - trasforma il foglio di calcolo in un editor ancora migliore.


AL PIÙ PRESTO??? Puoi fornire un collegamento?
Estratto


-2

Bene, per me, penso che i programmi di speartesheet non possano gestire queste cose correttamente ed efficacemente. RDB è stato progettato, in realtà, per gestire enormi dati e tabelle. I moderni RDB sono stati progettati per gestire il tipo di cose "Enormi" e lo stanno facendo molto bene.

Il punto è che per ottenere il miglior output dell'RDB è necessario progettare il database in modo corretto. Se il tuo schema di dati era scarso o non copriva tutti i dati del tuo progetto, finirai con risultati, prestazioni e output molto negativi.

L'idea di RDB è quella di scomporre la tabella enorme in tabelle più piccole in modo da poter migliorare le prestazioni e la leggibilità. Se hai una tabella molto grande (attributi saggi o persino record saggi) o molte ripartizioni, e non le usi quasi tutte, ciò significa che il tuo progetto del DB presenta degli errori.

Nella tua domanda Huang F. Lei, se mi chiedessero di progettare un database MMORPG, non aggiungerei tutte le abilità in una tabella e tutti i mob in una tabella. Dividerò le abilità in base alle loro classi e al loro utilizzo in più tavoli. Ogni tipo di abilità avrà il proprio tavolo o addirittura tavoli. Per i mob, li dividerò in base al loro tipo o in base alla loro posizione in mondi diversi. E così via.

In questo modo posso ridurre le dimensioni della tabella, semplificarmi il monitoraggio dei dati e migliorare le prestazioni del DB.

In Excel, d'altra parte, tutti i dati saranno "sbriciolati" in un unico posto. e trovare un dato è quasi impraticabile, epicamente quando si hanno dati ripetuti. Inoltre, con l'aumentare delle dimensioni dei dati, aumenterà il tempo di apertura del file.

Alla fine, Excel - a mio avviso - è un modo molto scarso per gestire enormi dati correlati.


Hai ragione, ma questa non è una risposta corretta. Se leggi attentamente la domanda o leggi altre risposte o commenti, saprai che la domanda riguarda la progettazione del gioco, non la memorizzazione dei dati.
Notabene,

So che riguarda il design e rosso le domande e le risposte. Quello che capisco è che Huang F. Lei sta cercando di scegliere tra RDB e foglio di calcolo. La mia risposta cercando di mostrare la differenza tra i due!
Ali Albahrani,

Cita: Huang F. Lei: "Sì, Excel è uno strumento comune. Il punto della domanda è:" un unico enorme tavolo per tutti gli oggetti ", gli oggetti includono attrezzature, consuma, ecc. È necessario dividere l'enorme in quelli piccoli? Anche file di configurazione separati per ogni oggetto? Temo che l'enorme tavolo possa ferire i loro occhi: o) "
Notabene,

2
Grazie per la risposta: o) La domanda riguarda il modo in cui il game designer fornisce i dati per creare il gioco, non il modo in cui il programmatore memorizza / accede ai dati del giocatore nel gioco.
Huang F. Lei,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.