Che tipo di documento per il game design? [chiuso]


9

Che tipo di supporto / formato usi per archiviare e diffondere la tua documentazione di progettazione del gioco? Wiki? File doc? File nel repository? Cartella condivisa? Google Doc?

Si prega di fornire pro e contro per ognuno.

Risposte:


14

Sto utilizzando Google Documenti perché tutto ciò di cui ho veramente bisogno è un editor di testo online. Posso collaborare con le persone online con relativa facilità e so che le mie informazioni sono al sicuro in caso di crash del mio computer.

Un'altra opzione degna di nota è l'utilizzo di Dropbox . Rilascia un documento Word e avrai immediatamente un ambiente collaborativo con controllo della versione.


5
PS Google Docs è completamente INCREDIBILE per l'editing collaborativo in tempo reale a partire dal recente aggiornamento (metà settembre, credo). Dropbox, d'altra parte, non ha una risoluzione dei conflitti (rinomina un file in conflitto, il che può creare ancora più confusione), quindi è piuttosto terribile per la modifica simultanea dei file ma ottimo per il backup e la condivisione / modifica non simultanea.
Ricket,

Esiste un modo per avere documenti google aziendali locali (come server aziendali installati)?
Klaim,

1
@Klaim, se ottieni Google Apps per il tuo dominio puoi farlo. google.com/apps/intl/en/business/index.html
Jesse Dorsey

4
Noctrine, è ancora ospitato da google. Appare solo sul tuo dominio per gentile concessione di una voce CNAME. Se richiedi che i dati si trovino fisicamente sulla tua rete locale, ciò non funzionerà. OTOH, a meno che tu non abbia bisogno di un nulla osta di sicurezza per lavorare sul tuo "gioco", quest'ultimo requisito è di solito più un'indicazione di paranoia e megalomania che altro.
drxzcl,

1
Sì, lo so già per i domini (ho già diverse app google per i miei domini) ma diciamo che non hai accesso a Internet ma solo a una rete locale?
Klaim,

5

wiki

Professionisti:

  • Ultima versione sempre accessibile via web, da fuori sede, ecc.
  • Abbastanza facile da usare (se ti allontani da quelli con un disastro ferroviario per la formattazione come MediaWiki, cioè)
  • Indicizzazione automatica, ricerca, facile categorizzazione
  • Facile attribuire le modifiche alle persone e renderle responsabili delle modifiche
  • Supporta il collegamento e rende semplice ed efficace la fattorizzazione dei dettagli
  • Può collegarsi direttamente alle pagine wiki da segnalazioni di bug interne e altre corrispondenze, rendendo molto semplice la verifica di un bug
  • Cronologia delle versioni e controllo delle revisioni in genere integrati

Contro:

  • A volte TROPPO facile da cambiare (* vedi sotto) e richiede disciplina
  • Le pagine possono non essere sincronizzate se modificate in modo isolato (spesso, ad esempio, nessuna "ricerca globale e sostituzione")
  • Le pagine diventano orfane o sostituite e lasciate come potenziali campi minati per i programmatori in seguito. ( "Cosa vuoi dire con questo non lo stiamo più implementando? È ancora nel wiki del design!" )
  • La sintassi può essere un po 'esoterica a meno che non si ottenga il pacchetto giusto
  • Devi organizzare l'hosting o accettare ciò che è disponibile online gratuitamente
  • Nessun percorso chiaro nel documento: come lo leggi "tutto"?
  • Difficile da stampare. Riesci a stampare tutto con un clic? Riesci a stampare facilmente tutto ciò che è rilevante per una determinata funzione al fine di portarlo in una riunione? Puoi annotare facilmente la versione digitale senza oscurare il documento sottostante?

(* Abbiamo utilizzato un wiki per un progetto e i progettisti sono sempre stati tentati di entrare e "migliorarne" parti, anche su funzionalità che erano state firmate e inviate per essere codificate. Quindi, quando il QA è riuscito a testare la funzionalità, sarebbe un incubo perché spesso il design suggerisce qualcosa di diverso da ciò che è stato effettivamente codificato, e ci vorrebbe un bel po 'di lavoro frustrante per scoprire che cosa è successo prima, la modifica del design o del codice.)


1
Tutti i tuoi contro sono davvero un problema se stai usando Confluence, con l'eccezione per l'hosting che non è gratuito a meno che non lo host sul tuo server LAN e consenti ad altri di unirsi tramite DynDNS o un servizio simile.
LearnCocos2D,

La cosa divertente è che abbiamo usato JIRA per il nostro progetto. Immagino che nessuno considerasse Confluence o il costo era troppo alto. Ho comunque votato la tua risposta.
Kylotan,

Documenti di progettazione basati su Wiki ... Per favore, per favore ... No.
Laurent Couvidou,

3

File di testo

Nel mio progetto attuale, sto usando semplici file di testo semplice nella mia cartella "Documenti" del progetto, memorizzata nel repository accanto al codice.

Professionisti:

  • La documentazione viene mantenuta vicino al lavoro effettivo, quindi è facile da trovare.
  • La formattazione semplice significa che è facile e veloce mantenere la documentazione.
  • Il formato semplice significa anche che c'è poco rischio di perdere la documentazione a causa di arresti anomali del server, danneggiamento dei file, ecc.
  • I tempi di installazione assolutamente minimi lo rendono un ottimo inizio per team single-developer o piccoli team (2-3 persone).
  • L'uso del controllo della versione significa che le modifiche vengono monitorate e spesso è possibile collegare direttamente le modifiche alla documentazione con una modifica del codice.
  • Facile da usare come il testo, quindi la ricerca, la modifica e così via possono spesso essere eseguite con gli strumenti da riga di comando.

Contro:

  • Più di un paio di utenti e il documento si sincronizzerebbero facilmente.
  • Nessun collegamento, quindi o si utilizza un documento di grandi dimensioni o diversi documenti più piccoli ma disconnessi.
  • Opzioni di formattazione e pubblicazione limitate (anche se la conversione, ad esempio tramite Markdown, è facile da fare.)
  • Facile da usare come il testo, così spesso l'unico modo per ottenere ricerche, modifiche avanzate e così via è utilizzare gli strumenti da riga di comando.

Non è qualcosa su cui vuoi fare affidamento per qualsiasi tipo di lavoro di gruppo, ma la potenza dei file di testo nel repository per farti andare al lavoro non dovrebbe essere sottovalutata per il singolo sviluppatore. Attualmente uso un documento come una specie di panoramica / master planner che contiene il design generale, un secondo documento che funge da elenco di cose da fare di cui il gioco ha bisogno, un terzo documento come bug tracker libero e documenti ausiliari per elaborare "feature x" secondo necessità.


2

Non utilizzare un formato / editor di documenti che non sia multiutente (ad es. MS Word, Open Office Writer). Solo una persona può modificare il documento e anche con il controllo del codice sorgente è troppo facile iniziare a lavorare su una versione obsoleta e salvando sostanzialmente si distrugge tutto ciò che gli altri utenti hanno fatto dall'ultima volta che l'utente ha aggiornato la sua versione del documento.

Le cartelle condivise sono di gran lunga la soluzione peggiore e assolutamente inutile per qualsiasi tipo di risorsa su cui si dovrebbe lavorare in modo collaborativo. Non puoi mai essere sicuro che qualcun altro stia lavorando su quel file in questo momento, o lo farà nei prossimi due minuti. Inoltre non hai il rilevamento delle modifiche e non puoi tornare a una versione precedente in caso di disastro (errore umano o stupidità umana o negligenza umana).

Preferibilmente usa un Wiki, ma uno che sia facile da usare ed è veramente WYSIWYG. Personalmente lo giuro su Confluence , che viene utilizzato anche nei più grandi studi di sviluppo di giochi e costa solo $ 10 per un massimo di 10 utenti e utenti illimitati.

La maggior parte degli altri wiki (MediaWiki, TikiWiki, ecc.) Hanno il rovescio della medaglia che hanno una ripida curva di apprendimento o sono persino praticamente inutilizzabili da personale non tecnico. Non che non potessero impararlo, ma (giustamente) non accettano di usare un sistema di documenti che in sostanza richiede di scrivere codice come HTML. Questa è la mia peeve: i wiki che dicono di essere WYSIWYG ma tutto ciò che fanno è inserire la sintassi nel testo che stai scrivendo. Questo non è WYSIWYG!

La linea guida per l'utilizzo di una wiki è quella di mettere ogni titolo in una pagina separata, in modo da poter tagliare il documento in molte parti gestibili. Confluence offre funzionalità con le quali è quindi possibile aggregare tutte quelle sottopagine in un unico sito o documento, che ad esempio può essere esportato in PDF.


1

Penso che One Note sia una buona opzione. È qualcosa di simile a un Wiki ma con un sacco di supporto per l'editing di testi. Oltre al client desktop standard fornito con Office, esiste una versione web con la suite Office Live . Onestamente, penso che la versione basata sul web, che è gratuita, dovrebbe essere sufficiente per la maggior parte delle esigenze e quando combinata con Skydrive hai un sistema abbastanza buono per collaborare a un documento dal vivo.


evernote.com è anche una possibilità per le persone che desiderano un'alternativa gratuita a OneNote. Ha un client Web e client per varie piattaforme (desktop, telefoni) e memorizza tutti i tuoi appunti "nel cloud". Penso che abbia anche funzionalità di collaborazione, ma potrebbero essere premium.
CodexArcanum,

0

Per uno dei miei progetti open source, abbiamo utilizzato SharePoint (gasp) per archiviare documenti e supporti. La gestione degli utenti e delle autorizzazioni è piuttosto semplice e supporta la cronologia completa delle versioni. Abbiamo il sito di SharePoint da circa quattro anni, quindi al giorno d'oggi potrebbero esserci opzioni migliori. Tuttavia, ha funzionato abbastanza bene per noi. È ospitato da una terza parte (per circa $ 20 al mese), quindi dopo l'installazione iniziale non abbiamo praticamente avuto manutenzione da parte nostra. Oltre a supportare le raccolte di documenti e immagini, SharePoint ha il supporto Wiki, anche se non sono sicuro di come si adatti ai più popolari motori Wiki.

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.