Come affrontare mentalmente un lavoro molto lungo [chiuso]


8

Questo è il mio primo lavoro nell'industria dei giochi e il mio compito è quello di estrarre un componente di gioco principale e inserirne uno nuovo.

Finora sono passate 5 settimane e sto ancora fissando gli errori. Penso che potrebbero passare mesi prima che sia possibile compilare. Mi sta davvero buttando giù. Sto solo cambiando le cose, non sto davvero scrivendo nulla da solo. è infinito. Risolvo mille errori e novemila prendono il loro posto.

Sono sicuro che questa deve essere una cosa comune, quindi mi stavo solo chiedendo, come puoi farcela? Non mi sembra di poterlo scomporre in piccoli pezzi.


3
Eeek. Chi scriverebbe un codice così cattivo che ci vorrebbero mesi solo per la compilazione !? Potresti voler ripensare a come lo stai facendo ... Una volta compilato, sarà pieno di errori logici.
MichaelHouse

7
Questa domanda è probabilmente più adatta a programmers.stackexchange.com (se non del tutto).
George Duckett,

3
@GeorgeDuckett Una risposta specifica del settore dei giochi potrebbe essere fornita a questa domanda che si occupa di problemi che incontreresti solo durante la programmazione in questo settore. Citata alla lettera, la parte delle FAQ che decide se le domande sul codice appartengono qui o su SO offre saggezza anche qui: uno sviluppatore di giochi professionale mi darebbe una risposta migliore / diversa / più specifica a questa domanda rispetto ad altri programmatori? Se sì, allora sentiti libero di chiedere qui.
doppelgreener,

5
Voto anche questo come una domanda di programmazione generale. Sta refactoring un grosso pasticcio di codice, che sembra essere un gioco. Ha bisogno di consigli generali di programmazione / refactoring, non di consigli sullo sviluppo di giochi.
Tim Holt,

1
Questo post e le sue risposte non possono essere migrati anziché essere chiusi?
SirYakalot,

Risposte:


21

Benvenuti nel settore dei giochi :)

Quindi stai facendo un massiccio refactoring. Il refactoring massiccio è il Male, ma non è questo l'argomento. Probabilmente ti è stato dato questo compito di testare i tuoi nervi comunque, quindi non arrenderti.

La mia risposta è: si deve scomposizione in piccoli pezzi. Tra qualche mese sarà la tua routine quotidiana, quindi devi imparare a dividere e conquistare. Fondamentalmente è il tuo lavoro. Alcuni suggerimenti:

  • Assicurati di capire cosa dovrebbe fare questo componente . Gioca con ciò che devi eliminare e vedi cosa fa, chiedi ai tuoi colleghi se i tuoi presupposti sono giusti.

  • Stai riscrivendo questo modulo per un motivo. Potrebbe non essere ovvio per te, ma se ti è stato assegnato questo compito è molto probabile perché qualcosa era così schifoso che la gente sente che è meglio ricominciare da capo. Chiedi in giro: quali sono questi difetti ?

  • Prova a trovare la funzionalità principale del componente che stai riscrivendo, la sua stessa sostanza, il motivo per cui esiste e inizia a farlo funzionare. Deve essere davvero minuscolo, il più piccolo possibile. Chiedi ai tuoi colleghi cosa pensano che questa funzionalità sarebbe. Se è un sistema GFX, basta visualizzarlo con un poligono. Se si tratta di un sistema di animazione, basta posizionare correttamente un osso. Se si tratta di un sistema di intelligenza artificiale, fallo riprodurre un'animazione. Ecc. Ecc. Basta spazzare via tutto ciò che si frappone e ti dà tutti quegli errori scoraggianti. Non essere disturbato dai dettagli, fai in modo che questa funzionalità di base funzioni il più rapidamente possibile. La tua implementazione sarà brutta, piena di bug, hack e numeri magici e non lasceresti che nessuno guardi il tuo codice, ma non è un problema.

  • Una volta che hai questa caratteristica fondamentale, inizierai già a sentirti meglio. È essenziale vedere il risultato del tuo lavoro il prima possibile 1) per il tuo morale 2) per poterlo testare. Quindi, testalo, stress test, torturalo . Se si arresta in modo anomalo o mostra un bug davvero grave, risolvilo. È il cuore del tuo modulo, quindi rielaboralo un po 'e puliscilo finché non ti senti a tuo agio con esso.

  • Quindi mostralo ai tuoi colleghi e chiedi loro se questo è ciò di cui il gioco ha bisogno. Chiedi una recensione del codice : i tuoi colleghi probabilmente ti parleranno di un sacco di cose a cui non hai pensato. Dovrai eseguire nuovamente il refactoring per assicurarti che l'implementazione si adatti a ciò che desidera il resto del team.

  • Quindi, quando ti senti pronto, scegli una delle altre funzionalità che hai cestinato in precedenza, risciacqua, ripeti. Fallo funzionare il più velocemente possibile, rielabora, chiedi una recensione, rielabora.

Devo porre l'accento un'ultima volta su questo: comunicare . Chiedete a voi colleghi, non solo il vostro esempio, non solo i programmatori, tutti coloro che useranno o testeranno o valuteranno questo sistema. Non temere di fare domande stupide: in caso di dubbio, è sempre meglio ottenere le informazioni adesso piuttosto che aspettare settimane per una riunione o una recensione.

La realtà della programmazione di gioco è che non creerai nuovi sistemi luccicanti ogni giorno, è un lavoro di concentrazione e di fare le cose in modo rapido ed efficiente. Mettiti insieme, mettiti al lavoro e buona fortuna!

MODIFICARE

Ci sono informazioni extra che trovo utili nel commento di Leo e nella risposta di Dhasenan, sto spudoratamente sostenendo che da loro per completare questa risposta.

Non ho scritto su come gestire le interdipendenze . Il modulo che stai riscrivendo è probabilmente profondamente associato al resto del gioco, ecco perché ricevi così tanti errori quando cambi qualcosa. Quindi ci sono due soluzioni:

  • Se ci sono solo alcune dipendenze, allora sei fortunato. Il vecchio e il nuovo modulo possono essere mantenuti in parallelo per un po ', puoi anche avere un interruttore per i tuoi utenti in modo che possano decidere di cambiare tra il vecchio e il nuovo modulo ogni volta che ne hanno bisogno. Basta inserire un interruttore da qualche parte, in un file di configurazione o in un menu di debug, e usarlo ovunque il tuo modulo sia collegato al resto del gioco. Quando il nuovo modulo è pronto per la produzione, attivare l'interruttore per impostazione predefinita. Successivamente, quando il vecchio modulo non viene più utilizzato o quando la produzione deve continuare, rimuovere il vecchio modulo e l'interruttore.

  • Se ce ne sono moltidipendenze, è necessario scollegare e ricollegarli uno per uno. Cerca di mantenere entrambi i moduli in background e ogni volta che ottieni una nuova funzionalità, passa al nuovo modulo per quella funzione. Vale a dire scollegare e ricollegare ciò che è legato a questa funzione. Ci vorrà del tempo perché probabilmente è più lavoro che cambiare una sola chiamata di funzione: alcune strutture di dati potrebbero cambiare, il flusso del programma potrebbe cambiare, ecc. Ma è ancora meglio che riscrivere tutto una volta e impiegare settimane per uccidere la bestia della compilazione. Se è davvero impossibile mantenere in parallelo sia il vecchio che il nuovo modulo perché il modulo è così vitale per il gioco, potresti prendere in considerazione la riscrittura in atto. Ma attenzione che ciò potrebbe significare che se i difetti si trovano nell'interfaccia del vecchio modulo, si otterranno gli stessi difetti. Comunque, se questo accade,

Se c'è qualcosa di specifico nello sviluppo di videogiochi, è questo: non stiamo facendo scienza missilistica, o un complicato lavoro di ricerca, facciamo parte di un processo creativo. Quando fai qualcosa, devi creare una prima versione il più rapidamente possibile in modo che possa essere testata, giocata, disapprovata e modificata. Non puoi passare settimane a fare "un lavoro molto lungo" senza consegnare un po '.


Buona risposta, chiaramente applicabile non solo ai giochi ma a qualsiasi progetto.
Tim Holt,

1
+1, chiave da asporto per me: non solo test , ma codice di tortura :) Per me, questo è un consiglio eccellente.
Stefan Hanke,

5
+1, DEVI dividere una grande rifattorizzazione in piccoli pezzi. Concordo pienamente sul fatto che sia l'unico modo per completare una massiccia rifattorizzazione. Idealmente, cambia il codice pezzo per pezzo, assicurandoti che ogni modifica lasci il sistema funzionante (questo ridurrà molto il numero di bug). Se questo è impossibile per la piena funzionalità, almeno fallo per alcune funzionalità di base. Cambiare tutto in una volta è un modo sicuro per creare tonnellate di bug difficili da trovare.
Leo,

1

Devi dividere il tuo compito, ma nessuno offre consigli su come farlo.

  • I moduli vecchi e nuovi funzionano insieme? Cioè, puoi compilare il tuo progetto con entrambi? Questo ti permetterà almeno di compilare e probabilmente eseguire test automatizzati su alcune pietre miliari.
  • Stai scrivendo il nuovo modulo? O è il vecchio codice che possiedi? Riscrivi sul posto (nella misura in cui l'API esterna rimane la stessa). Se correggi una funzione alla volta, dovresti essere in grado di continuare a utilizzare l'API ibrida combinata, in una certa misura.
  • Ci sono altri progetti in azienda che faranno una transizione simile? Scrivi wrapper attorno a questi moduli per rendere il processo più semplice la prossima volta. Potrebbe valere la pena farlo nel frattempo.
  • Puoi commentare o evitare di compilare blocchi della tua catena di dipendenze? Se hai mezzo milione di righe di codice in totale, forse puoi dividerlo in venti blocchi che vengono compilati in modo indipendente, farne funzionare uno in un paio di settimane e quindi passare al successivo. Forse non sempre blocchi completamente indipendenti, ma poi puoi farlo in ordine di dipendenze.

Inoltre: chiedi consiglio al tuo manager. Probabilmente inizierei descrivendo il problema: ci vuole così tanto tempo per compilare correttamente le cose che è difficile tenere traccia delle modifiche, il che renderà più difficile il debug una volta che hai qualcosa che puoi testare. Quindi menzionerei una potenziale soluzione e chiedo: "Come mi consigliate di implementare questa soluzione o esiste un modo migliore per farlo interamente?"

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.