Vale la pena aggiungere funzionalità "futuristiche" al nostro gioco o dovremmo concentrarci altrove?

Sono programmatore principale in uno studio di giochi indie di medie dimensioni. Questa è la nostra prima partita in squadra. Stiamo lavorando a un futuristico gioco FPS, con un piano aziendale a ripartizione degli utili.

Ad ogni modo, abbiamo dei programmatori molto bravi, che hanno la capacità di creare funzionalità mai viste prima (fluidi realistici reali, distruzione di mesh procedurali, skybox procedurali, ecc.) E mi chiedo: c'è motivo di implementare queste cose? Richiedono molto tempo, ma sembrano brillanti. Puntiamo a un ciclo di sviluppo di 12 mesi. Quindi dovremmo farlo, o semplicemente fare un gioco standard.

Non provare a farlo perché sai che puoi farlo.

Il gameplay dovrebbe essere il primo, tutte le cose (anche la grafica) sono secondarie. Se il gioco è divertente e piacevole ma ha una grafica scadente (o meno della prossima generazione), sarà comunque divertente e piacevole e le persone lo giocheranno, e anche il tuo metacritic sarà buono. Altrimenti se il gioco ha una grafica e caratteristiche fantastiche (fluidi realistici, distruzione di mesh procedurali, ecc.) Ma non è divertente o difficile da giocare (controlli errati, ecc.), Le persone non lo giocheranno. Nessun giocatore = niente soldi e anche cattivo metacritico.

Quindi prima pianifica il gioco che vuoi fare e pensa alle sue caratteristiche di gioco, alle sue situazioni giocabili. Non provare a spingere cercando di far entrare quella caratteristica X nel gioco solo perché sembra bello. Se non ha davvero senso, o se non rappresenterà una parte importante del gameplay, lascialo semplicemente cadere.

Inoltre, evita di provare a costruire un gameplay attorno a una di quelle fantastiche funzionalità se non ha senso o pensi che non sarà divertente. Ad esempio: potresti pensare "Ho una distruzione procedurale delle maglie, quindi costringiamo il giocatore a distruggere tutto prima di poter continuare ad avanzare nel gioco (in modo che possa vedere le maglie essere distrutte proceduralmente").

Per riassumere: prima pensa al tuo gioco e alle sue esigenze. Da quella base, pianifica la tua fase di sviluppo, e poi vedrai se c'è abbastanza spazio per adattarsi a una o più di queste fantastiche funzionalità (e se ha senso aggiungerle al tuo specifico tipo di gioco).

Tenendo presente che un ciclo di 12 mesi non significa che smetti di scrivere codice alla settimana 52 e lo spingi fuori dalla porta, mi schierò con le risposte già date che il gioco deve venire prima di tutto e di aggiungere funzionalità pulite solo se aiutano il gioco giocare.

Idealmente, avrai il tempo di eseguire il beta test con i candidati al rilascio, quindi la maggior parte funziona tranne le correzioni di bug di emergenza e la messa a punto della settimana 50.

Le funzionalità complete dovrebbero essere attive molto prima della beta, quindi forse non tutte le attività entro la settimana 46, quindi puoi fare dei test interni per rendere tutto solido prima della lucidatura in beta. Quindi sono davvero solo 46 settimane di lavoro prima di iniziare a preparare il gioco.

Il pensiero chiave è decidere se far lavorare il tuo ingegnere a caldo su un sistema vale la pena per quel tecnico che non sta già lavorando al tuo prossimo titolo. "Cos'altro potrebbe fare" è il costo nascosto di qualsiasi decisione.

A proposito, volumi fluidi simulati, distruzione procedurale, sky box dinamici, ecc ... sono stati tutti fatti in giochi commerciali e la ragione per cui non ne senti parlare così tanto è che il gioco stesso è stato sempre più importante.

Buona fortuna, qualsiasi cosa tu faccia sarà eccitante!

Se i tuoi programmatori sono così bravi, usa quelle abilità per consegnare in tempo e sotto budget. E tra adesso e l'inizio del tuo prossimo grande progetto, pensa a come sfruttare al meglio quelle abilità che il tuo team ha, con il budget maggiore che ha un buon track record.

Ma se devi fare le cose in questo modo, scegli UNA cosa interessante. Non tutti, nemmeno due - Non introdurre mai troppi fattori di rischio contemporaneamente. E quello che scegli DEVE essere in qualche modo centrale nel gameplay, perché tutto il resto è solo lanugine. Quando sei Blizzard, puoi permetterti di sederti attorno aggiungendo funzionalità pulite, anche se le loro decisioni sono sempre IMHO orientate al business.

Ma cercare di implementare tutte o anche solo alcune delle cose che i tuoi programmatori possono fare, perché sembra bello e in un certo senso pensi di poterti fare, ti dirigeranno verso una caduta molto grande.

Ancora una volta, la chiave è NON aggiungere nulla che non contribuisca con certezza alla dinamica del gioco principale, qualunque essa sia (sembra che abbia ancora TBD).

"abbiamo alcuni programmatori molto bravi, che hanno la capacità di creare funzionalità mai viste prima"

Niente di personale, ma devo dire che ne dubito. Valve (per sceglierne solo uno) ha alcuni dei migliori programmatori del settore, se non del mondo. Havoc ha anche delle persone piuttosto intelligenti: ci sono dozzine di altri esempi. Hanno tutti più programmatori di te, più tempo e budget più alti.

Ora, forse sei in qualche modo riuscito a riunire un gruppo di geni assoluti. Ma sarei molto attento al divario tra ciò che i programmatori pensano di poter fare e ciò che possiamo effettivamente fare in un tempo limitato e ad uno standard rilasciabile. Come altri hanno già detto, puoi (se sei molto sicuro) sceglierne uno. Personalmente vorrei passare attraverso il processo di immissione sul mercato di un gioco almeno una volta prima di provare a sparare per la luna.