Come decidi quando l'elenco delle funzionalità è abbastanza lungo?

Conosco un po 'questa domanda ma trovo che ci siano molte opinioni diverse sull'argomento?

So dal punto di vista dei giocatori che più opzioni sono quasi sempre buone. D'altra parte, se ha più giocatori significa più complessità (meta gioco) sia per gli sviluppatori che per i giocatori.

La complessità dello sviluppo e i vincoli temporali vanno sempre di pari passo. Un altro sarebbe vincoli di risorse e piattaforma. Le possibili ramificazioni economiche di trattenersi per dopo sono talvolta anche un motivo.

Quindi, dall'esperienza della gente qui a parte quanto sopra, quando le funzionalità dovrebbero essere tagliate o essere rilasciate successivamente?

Direi che è un processo in due fasi per noi:

• Stabilisci gli obiettivi del gioco.
• Determina quali funzionalità ci aiutano a raggiungere questi obiettivi.

L'elenco delle caratteristiche è abbastanza lungo quando quei due punti corrispondono. Così:

1. Stabilisci i nostri obiettivi - Scopri tutte le cose che vogliamo che il gioco faccia per il giocatore / revisore / chiunque, quindi dichiarale in modo misurabile. Ad esempio, con il nostro ultimo ( vedi vid test alfa qui ), vogliamo fare questi:

• Immagini: Vogliamo che ogni recensione menzioni che le immagini sono insolite e sexy, specialmente per un titolo indipendente. Questo è importante per noi perché i giocatori spesso usano i loro occhi come una rapida metrica di qualità (anche se, ovviamente, è solo uno dei tanti!), E vogliamo che li attiri.
• Esplorazione: Vogliamo anche premiare la gente per aver esplorato il gioco. Per dirla in modo misurabile, desideriamo che circa un quinto del tempo di gioco del giocatore sia trascorso facendo piccole cose ordinate al di fuori del gameplay principale. Questo è importante per noi perché (IMO), gran parte della delizia di un gioco viene fuori dalle aree centrali attese (pensiamo a come fare clic sui pezzi in Starcraft ci diverte).
• Community: Vogliamo che tutti parlino ad almeno un amico del gioco.

2. Determinare le caratteristiche che ci aiutano a raggiungere quegli obiettivi - Questi quasi cadono naturalmente da quanto sopra. Quindi, le caratteristiche che corrispondono agli esempi sopra potrebbero apparire così:

• Elementi visivi: come piccolo studio, se vogliamo elementi visivi sexy, non possiamo andare contro EA o Sony sul realismo. Quindi, per affrontare l'obiettivo di effetti visivi straordinari, una delle caratteristiche del gioco è un'estetica surreale. (Da questo, siamo in grado di determinare quali strumenti abbiamo bisogno e così via.)
• Esplorazione: i bocconcini corollari dell'azione del gioco cadono da questo. Nel nostro titolo più recente , abbiamo lasciato un rapido riferimento alla discutibile ricerca di Ryo per i marinai a Shenmue . È stato uno sciocco lancio, ma alla gente piaceva e ne parlava!
• Community: ci stiamo chiedendo tutti i modi per rendere un gioco degno di nota ad un amico. Renderlo divertente è ovviamente il numero 1. Ma potremmo anche premiare i giocatori con un oggetto o un livello speciale se lo twittano. Pokemon ha valso la pena di fare in modo che gli amici prendessero il gioco: ci sono alcune creature che puoi ottenere solo interfacciarsi con altre persone.

Quando attraversiamo questo processo, ci aiuta a determinare:

• Quanto dobbiamo implementare per un prodotto minimo sostenibile ( MVP ).
• Cosa è più importante, cosa può aspettare e cosa possiamo lasciar perdere del tutto.
• Quando finalmente avremo tutte le funzionalità di cui abbiamo bisogno.

Vale la pena notare che non ci atteniamo con rispetto a queste regole! Il più delle volte, alcune cose incredibilmente interessanti nascono come risultato della prototipazione di metà progetto e solo del vortice generale in giro. Soprattutto per i piccoli giochi come i nostri.

La complessità non rende divertente il tuo gioco.

La giusta combinazione ed equilibrio di elementi di gioco fa. Il giocatore deve essere spinto fino al livello del suo livello di abilità e avere una sensazione di padronanza dalle sfide da vincere.

L'elenco delle funzionalità dovrebbe cambiare ogni volta che ritieni che il gameplay attuale non sia divertente. Queste modifiche devono essere apportate entro i limiti di budget / tempo. Assicurati che tutte le modifiche apportate aggiungano valore al gioco.

Inoltre, prototipo in anticipo, non solo scrivere un enorme elenco di funzionalità e supporre che sarà tutto divertente quando messo insieme.

La perfezione si ottiene, non quando non c'è altro da aggiungere, ma quando non c'è più niente da togliere.

-- Antoine de Saint-Exupéry

Quando il tempo e lo sforzo necessari per includerli è maggiore del valore aggiunto al gioco .

Ad esempio, se stavi creando un gioco sportivo o qualcosa in cui i giocatori potrebbero voler mostrare le loro abilità, il multiplayer è un must. Guitar Hero non sarebbe lo stesso senza di essa. Tuttavia, un gioco esclusivamente individuale, in cui arrivi a finire per conto tuo, seguendo una storia o una trama non ha bisogno del multiplayer. Il scadente sistema multiplayer di Grand Theft Auto San Andreas ne è la testimonianza (anche se quella compagnia probabilmente non ha trovato il multiplayer troppo difficile).

Inoltre, le funzionalità che non si adattano perfettamente alla storia del gioco, ci sono solo perché possono esserlo. Se non è completamente essenziale per il gameplay, è probabilmente un buon segno che possono essere spinti a una versione successiva se il tempo è un problema.

Il fatto è che le funzionalità extra non sono l'elemento per eccellenza di un gioco. Una trama emozionante unita a un gameplay divertente è.

Sebbene ci sia un grado in cui la varietà di funzionalità è eccezionale (essere in grado di fare tonnellate di cose casuali in un gioco GTA-ish, avere tonnellate di varietà di armi e accessori in un gioco di ruolo o Call of Duty-ish, ecc.), Penso che un gameplay più minimale incentrato su alcune funzionalità di base possa essere altamente efficace.

Guarda Portal, ha preso il suo unico meccanico di base e ha davvero costruito i suoi enigmi attorno a quello senza bisogno di un sacco di ingombri extra.

Penso che essere rigoroso nel mantenere l'elenco delle funzionalità il più minimale possibile e concretizzare alcune funzionalità di base consenta un progetto più fattibile e spesso un'esperienza più piacevole (se il portale ha aggiunto elementi di gioco di ruolo e sequenze di guida e slowmo e qualunque altra "bella funzionalità" ", sarebbe stato altrettanto bello? La meccanica di base sarebbe stata altrettanto raffinata?).

Ora, come sviluppatore indipendente sono sicuramente di parte, ma penso che di solito "less is more" nelle funzionalità, e anche se qualcosa potrebbe essere bello o popolare al momento, se non rende l'esperienza complessiva notevolmente migliore dovrebbe essere tagliato.

Dalla mia esperienza personale ho scoperto che è meglio evitare di aggiungere nuove funzionalità non pianificate il più presto possibile.

Da un punto di vista del design, una funzione che è stata aggiunta in un attimo del momento "non sarebbe bello avere un periodo di funzionalità x" aggiungerebbe molto tempo di sviluppo, potrebbe non integrarsi bene con il codice e potrebbe non si adatta perfettamente al resto del tuo design.

Nel peggiore dei casi, un progetto che ha vissuto molti di questi momenti può sembrare una combinazione disordinata di elementi combinati, che in realtà avrebbe dovuto trascorrere molto più tempo in fase di progettazione e, di conseguenza, apparire meno professionale.

Come linea guida generale cerco di seguire queste regole:

• Se una nuova funzionalità viene visualizzata all'inizio del progetto, prenditi il ​​tempo per tornare alla fase di progettazione e vedere davvero come questa funzionalità può funzionare con il tuo prodotto pur rimanendo coerente con il resto del design.

• Se il progetto si avvicina al rilascio, è consigliabile creare un elenco di funzionalità da aggiungere a una nuova versione.

• Se scopri che continuano a emergere molte funzionalità che desideri davvero implementare, forse dovresti prendere in considerazione l'idea di tornare al design e di capire perché queste nuove funzionalità non sono state prese in considerazione in precedenza, probabilmente a causa della mancanza di impegno la fase di progettazione.

Ovviamente questo si adatta ad alcuni progetti meglio di altri, ma in realtà se si dispone di una funzionalità presentata in ritardo nel progetto, probabilmente andrà bene senza di essa, almeno fino a quando non si inizia a lavorare su una nuova versione.

Mantieni le liste brevi, sii agile

Non creare affatto elenchi di funzionalità o, se lo fai, crearli molto brevi, vale solo alcune settimane di sviluppo.

Sviluppa con stile agile: inizia con le poche funzionalità più importanti, testa, in base a ciò che funziona e cosa no, e poi pensa a se vale la pena aggiungere altre funzionalità (sarai in grado di giudicarle molto meglio se hai già esperienza con il gameplay di base).

Come giudicare le singole funzionalità

A parte questo, sarei d'accordo con il criterio di bennybdbc, "Quando il tempo e lo sforzo necessari per includerli è maggiore del valore che aggiungono al gioco".

Detto questo, devi anche considerare il mondo "esterno":

• stai esaurendo i soldi o il tempo concesso da un contratto?
• stai esaurendo lo spazio dei media di pubblicazione (DVD pieno)
• stai esaurendo lo spazio delle prestazioni (le nuove funzionalità potrebbero rallentare il gioco)?
• un gioco in competizione verrà presto pubblicato?

È necessario prendere in considerazione anche semplici problemi della vita reale come quello, a meno che non si sviluppi il gioco solo per divertimento.

Quando finisci la carta per scriverlo.

Il limite definito sarà la dimensione del supporto; ad esempio, non è possibile inserire 10 GB di funzionalità su un DVD da 4,7 GB.

Non vuoi nemmeno troppe funzionalità da complicare troppo il gioco. Il modo migliore è chiedersi "sarà molto divertente per il giocatore? divorerà troppo il nostro tempo di sviluppo? è anche possibile?