Perché MVC e TDD non sono più impiegati nell'architettura di gioco? [chiuso]

Prefarrò questo dicendo che non ho visto un'enorme quantità di fonti di gioco, né costruito molto nel modo di giochi.

Ma provando a impiegare pratiche di codifica "enterprise" nelle app Web, guardare il codice sorgente del gioco mi fa molto male alla testa: "Cosa sta facendo questa logica della visione con la logica aziendale? Questo ha bisogno di refactoring ... così fa questo, refactor, refactorrr "

Questo mi preoccupa mentre sto per iniziare un progetto di gioco, e non sono sicuro se provare a mvc / tdd il processo di sviluppo ci ostacolerà o ci aiuterà, poiché non vedo molti esempi di giochi che usano questo o molto spingere per migliori pratiche architettoniche nella comunità.

Quello che segue è un estratto di un grande articolo sui giochi di prototipazione , sebbene a me sembrasse esattamente l'atteggiamento che molti sviluppatori di giochi sembrano usare quando scrivono codici di giochi di produzione:

Errore n. 4: costruire un sistema, non un gioco

... se mai ti ritrovi a lavorare su qualcosa che non sta andando direttamente avanti, fermati proprio lì. Come programmatori, abbiamo la tendenza a cercare di generalizzare il nostro codice, renderlo elegante ed essere in grado di gestire ogni situazione. Troviamo che un prurito terribilmente difficile non graffi, ma dobbiamo imparare come. Mi ci sono voluti molti anni per capire che non si trattava del codice, ma del gioco che alla fine spedisci.

Non scrivere un elegante sistema di componenti di gioco, saltare l'editor completamente e cablare lo stato nel codice, evitare la follia basata sui dati, auto-analisi, XML e semplicemente codificare la cosa maledetta.

... Basta avere roba sullo schermo il più velocemente possibile.

E non usare mai l'argomento "se prendiamo del tempo extra e lo facciamo nel modo giusto, possiamo riutilizzarlo nel gioco". MAI.

è perché i giochi sono (principalmente) orientati visivamente, quindi ha senso che il codice sarà pesantemente ponderato nella vista, quindi qualsiasi beneficio derivante dallo spostamento di roba su modelli / controller, è abbastanza minimo, quindi perché preoccuparsi?

Ho sentito l'argomentazione secondo cui MVC introduce un overhead delle prestazioni, ma questa mi sembra un'ottimizzazione prematura, e che ci sarebbero problemi di prestazioni più importanti da affrontare prima che ti preoccupassi delle spese generali di MVC (ad es. Pipeline di rendering, algoritmi AI, infrastruttura di dati traversal, ecc.).

Stessa cosa per quanto riguarda TDD. Non capita spesso di vedere giochi che utilizzano casi di test, ma forse ciò è dovuto ai problemi di progettazione di cui sopra (visione mista / business) e al fatto che è difficile testare componenti visivi o componenti che si basano su risultati probablistici (ad esempio operare all'interno di simulazioni fisiche ).

Forse sto solo guardando il codice sorgente sbagliato, ma perché non vediamo più queste pratiche "enterprise" impiegate nella progettazione dei giochi? I giochi sono davvero così diversi nelle loro esigenze o è un problema di persone / cultura (ovvero gli sviluppatori di giochi provengono da un background diverso e quindi hanno abitudini di codifica diverse)?

Come dice la citazione, molti programmatori commettono l'errore di (provare a) costruire un sistema, non un gioco. In genere quel sistema mantiene il controllo della mongolfiera fuori controllo fino a quando non è così complesso che teoricamente può gestire qualsiasi cosa, ma in pratica tutto ciò che hai è un grosso fascio di codice. O più spesso, prima ancora di arrivare a una fase lavorativa, sei così ingarbugliato nel codice che non corre che perdi attenzione (se ne avevi qualcuno per cominciare) e motivazione (poiché nulla funziona davvero).

I prototipi e l'iterazione tendono a funzionare molto meglio. Alla fine, potrebbe venirne fuori un grande design, ma più spesso ne viene fuori qualcosa di più semplice e raffinato. KISS e YAGNI vengono in mente.

Personalmente credo che ci debba essere un equilibrio. Se c'è una meccanica di base del tuo gioco, lavoraci su. Hai ancora bisogno di iterare, ma devi perfezionarlo. Suggerimento: l'organizzazione del codice non è una meccanica di base del tuo gioco.

Caso in questione: Peggle , di PopCap Games. Una meccanica di base del gioco è la fisica della palla. L'hanno perfezionato! Sono sicuro che hanno trascorso parecchio tempo a assicurarsi che fosse assolutamente perfetto, perché è ciò che rende il gioco. Ma allo stesso tempo, posso completamente immaginare un primo prototipo del loro gioco che forse attira semplicemente gli sprite sullo schermo e fa un qualche tipo di rilevamento e rimbalzo delle collisioni più primitivo, solo per vedere se l'idea del gioco è divertente. Quindi, una volta scoperto che sparare una palla e vederla rimbalzare può effettivamente essere divertente, hanno perfezionato il rimbalzo della palla. _{(questa è solo una speculazione, ovviamente)}

Dipende anche dai tuoi requisiti tecnici, che dovresti definire presto (non dal design del tuo gioco, ma solo dai requisiti tecnici). La piattaforma su cui gira il tuo gioco non dovrebbe cambiare, o se dovrebbe essere permesso di cambiare, devi conoscere esattamente la misura in cui prevedi che cambi, né più né meno. Progettare su quello. Se stai sviluppando un gioco per OpenGL e non ti interessa DirectX, in realtà non ti interessa. Ciò significa che se è più conveniente per te disegnare ciascuna entità e non preoccuparti di Fabbriche e altri modelli di design come quello, allora fallo. Va bene, perché soddisfa i requisiti. Non dovresti cambiarlo più tardi, nonostante quello che dici a te stesso. E davvero, lo scenario peggiore? Refactor più tardi., ottenere un gioco funzionante su una piattaforma anche se ciò significa che non può funzionare simultaneamente e automaticamente sul tuo tostapane.

La progettazione guidata dai test, tuttavia, è un argomento più ponderato. Sono convinto che gli sviluppatori di giochi dovrebbero fare di più. Penso anche che gli sviluppatori di giochi abbiano alcuni dei programmi più rigorosi e rigorosi e pensano che non possono permettersi di passare il tempo su TDD quando vogliono solo far partire un gioco. Inoltre, sempre con la motivazione, TDD è molto più lento e puoi vedere molto meno di un gioco funzionante (almeno all'inizio). Ciò può avere gravi effetti negativi sulla motivazione del programmatore.

Penso che sia anche solo una generale mancanza di conoscenza e pratica. Non penso che il TDD sia prevalente in altre aree, ma come lo sviluppo agile, penso che si stia diffondendo. Potresti dire che è in anticipo sui tempi (o forse no, come potrebbe essere il caso tra anni). Più importante di TDD è "RDD" - Sviluppo guidato dai requisiti. _{L'ho appena inventato.}Qual è il tuo obiettivo? Fare un gioco. Tutto il resto viene secondo. Se riesci a dimostrare che TDD aumenta la produttività e aiuta i team a raggiungere le scadenze, non pensi che tutti lo userebbero? E forse è così. Ma in questo momento, il nostro settore è più competitivo che mai, ci sono scadenze più difficili e prima e le cose devono solo funzionare. Gli operai edili non costruiscono prima le impalcature; gettano le fondamenta, poi sollevano muri e pavimenti e solo allora costruiscono pezzi selettivi di ponteggi per svolgere compiti specifici che i ponteggi rendono più conveniente. Penso che lo stesso valga per lo sviluppo del software.

Ci scusiamo per un post così lungo. Spero che tu ne abbia tratto un po 'di saggezza. Sono solo uno studente, sto parlando delle mie osservazioni, con un'esperienza del settore molto limitata ma molta lettura da parte di esperti del settore. Quindi prendi le mie parole con un granello di sale.

Ehi, fai quello che pensi funzionerà. Puoi sempre cambiarlo o scartarlo e ricominciare. Questa è la cosa bella di qualsiasi forma di ingegneria; se all'inizio non ci riesci, prova qualcosa di diverso. (o qualcosa del genere :-P) Non stai versando cemento; il software è malleabile.

A proposito, sto ponendo questo stesso tipo di domanda e alla ricerca di questi tipi di principi di progettazione da qualche tempo. Ecco alcune domande, sia qui che in Stack Overflow, che potresti trovare rilevanti:

• "Come puoi organizzare il codice di un gioco per adattarlo al modello MVC?"
• "Come progettare un software di gioco in modo che sia facile testare l'unità?"
• "Progettazione del motore di gioco basato sui componenti"
• "Esistono buoni tutorial o risorse per imparare a progettare un" framework "di gioco scalabile e basato su" componenti "?"
• "Separazione della logica di gioco e di rendering"
• "Il test unitario è praticabile nella programmazione del gioco?"
• "Il modello di progettazione MVC è utilizzato nei giochi per computer commerciali"
• "Lo sviluppo guidato dai test è un approccio normale nello sviluppo dei giochi?"
• "Qualcuno di voi usa Scrum per lo sviluppo di giochi?"
• "Architecture for Game - Fare coppia o non fare coppia?"
• "Domanda sul design del gioco OO"

Ecco la mia risposta originale a una domanda simile su SO di qualche tempo fa, almeno per quanto riguarda la parte MVC della tua domanda:

È usato raramente nei giochi. Mi ci è voluto un po 'per capire perché, ma ecco i miei pensieri:

MVC esiste per fare una distinzione tra due rappresentazioni. Il modello è la rappresentazione astratta dei tuoi dati. È come la macchina visualizza lo stato della tua applicazione. La vista (e i controller) rappresentano un'istanza visibile più concreta di quel sistema in un modo significativo per l'uomo.

Nella maggior parte delle app aziendali, questi due mondi sono piuttosto diversi. Ad esempio, il modello di un foglio di calcolo è semplicemente una griglia di valori 2D. Non deve pensare alla larghezza delle celle in pixel, dove sono le barre di scorrimento, ecc. Allo stesso tempo, la vista del foglio di calcolo non sa come vengono calcolati o memorizzati i valori delle celle.

In un gioco, quei due mondi sono molto più vicini tra loro. Il mondo di gioco (modello) è in genere un insieme di entità posizionate in uno spazio virtuale. La vista di gioco è anche un insieme di entità posizionate in uno spazio virtuale. Volumi limitanti, animazione, posizione, ecc., Tutte le cose che considereresti parte della "vista" sono anche utilizzate direttamente dal "modello": l'animazione può influenzare la fisica e l'intelligenza artificiale, ecc.

Il risultato finale è che la linea tra modello e vista in un gioco sarebbe arbitraria e non utile: finiresti per duplicare molto stato tra di loro.

Invece, i giochi tendono a disaccoppiare le cose lungo i confini del dominio: AI, fisica, audio, rendering, ecc. Saranno mantenuti il ​​più separati possibile.

Perché MVC non si adatta all'architettura di un gioco. Il flusso di dati per un gioco è completamente diverso da quello di un'applicazione enterprice, perché non è un evento guidato e spesso c'è un budget (molto) millisecondo in cui eseguire queste operazioni. Ci sono molte cose che devono accadere in 16.6 millisecondi, quindi è più vantaggioso disporre di una pipeline di dati "fissa" e rigida che elabora i dati necessari sullo schermo esattamente in quel momento.

Inoltre, la separazione è lì; la maggior parte delle volte non è cablata allo stesso modo del modello MVC. C'è un motore di rendering (Visualizza), la gestione dell'input dell'utente (Controller) e il resto come logica di gioco, ai e fisica (Modello). Pensaci; se stai recuperando l'input dell'utente, eseguendo l'IA e renderizzando l'immagine 60 volte al secondo, perché dovresti avere bisogno di un osservatore tra il modello e la vista per dirti cosa è cambiato? Non interpretarlo come se dicessi che non hai bisogno del modello Observer nei giochi, ma in questo caso non lo fai davvero. Stai comunque facendo tutto quel lavoro, ogni fotogramma.

Sebbene TDD non sia quasi mai utilizzato negli studi di sviluppo, utilizziamo le pratiche Agile per lo sviluppo del software e SCRUM sembra essere la scelta popolare almeno qui in Europa. Il motivo è semplice, i cambiamenti provengono da ogni parte. Gli artisti potrebbero desiderare più budget per le texture, mondi più grandi, più alberi mentre i designer vogliono una storia più ricca (più contenuti su disco), un mondo in streaming e gli editori vogliono che tu finisca in tempo, e in budget e così anche il dipartimento marketing. E a parte questo, lo "stato dell'arte" continua a cambiare rapidamente.

Ciò non significa che non eseguiamo neanche i test, la maggior parte degli studi ha dipartimenti di domande e risposte di grandi dimensioni, esegue un sacco di test di regressione ed esegue test unitari su base regolare. Tuttavia, non ha praticamente senso fare unit test in anticipo perché gran parte dei bug sono legati all'arte / alla grafica (buchi nelle maglie di collisione, trame errate, glitch nella profondità del campo shader) che i test unitari non possono coprire. E oltre al codice di lavoro, il fattore più importante di qualsiasi gioco è che è divertente e non esiste alcuna unità che lo collauda.

Ricorda anche che nel mondo della console è ancora diverso, perché stai programmando di più per l'hardware che per qualsiasi altra cosa. Questo generalmente (PS2 / PS3) significa che il flusso dei dati è molto più importante del flusso del codice in quasi tutti i casi; a causa di considerazioni sulle prestazioni. Il che annulla l'uso del TDD come strumento architettonico nella maggior parte dei casi. Un buon codice OOP generalmente ha un flusso di dati negativo, il che rende difficile vettorializzare e parallelizzare.

Perché MVC e TDD non sono più impiegati nell'architettura di gioco?

Attenzione: opinione in anticipo.

MVC non è usato (molto) perché:

1. MVC è un approccio relativamente nuovo e i giochi sono in genere basati sul vecchio codice. La maggior parte delle persone che creano app MVC le costruiscono dal nulla ogni volta. (So ​​che MVC stesso ha in realtà decenni; la novità è l'interesse diffuso in esso, che essenzialmente proviene da app Web come RoR). Nel software aziendale su cui ho lavorato che si basava su un codice legacy, non c'era nemmeno alcun vantaggio per MVC. È una cosa culturale, ma non è specifica per il gioco.
2. MVC è essenzialmente un modello di GUI per programmi guidati da eventi. I giochi non sono né dominati dalla GUI né guidati da eventi, quindi l'applicabilità non è eccezionale quanto lo è per le app Web o altre applicazioni basate su moduli. MVC è in genere il modello Observer con alcuni ruoli ben noti, e i giochi spesso non hanno il lusso di aspettare di osservare qualcosa di interessante - devono aggiornare tutto ogni fotogramma (o qualche variazione su quello) indipendentemente dal fatto che qualcuno abbia fatto clic o meno .

Questo non vuol dire che i giochi non possano imparare molto da MVC. Cerco sempre di separare il modello dalla vista nei giochi che realizzo. L'idea tradizionale della vista e del controller essendo 2 parti dello stesso oggetto (widget) non funziona davvero, quindi devi essere un po 'più astratto al riguardo. Sono d'accordo con te sul fatto che è improbabile che le prestazioni siano un vero problema qui. Semmai le prestazioni possono trarre vantaggio dal mantenere separati gli elementi visivi e quelli logici in quanto ciò è più suscettibile di cache coerenza, parallelismo, ecc.

TDD non è usato (molto) perché:

1. È davvero strano da usare nei giochi. Ancora una volta, va bene per il software event driven in cui entrano e escono gli input e puoi confrontare ciò che hai visto con quello che ti aspettavi e spuntarlo come corretto. Per le simulazioni con grandi quantità di stato condiviso è significativamente più imbarazzante.
2. Non ci sono prove indiscutibili che aiuti nulla. Solo un sacco di affermazioni e alcune cifre spesso basate sull'auto-segnalazione e ricorsi all'autorità. Forse aiuta i programmatori poveri a diventare mediocri, ma trattiene i buoni programmatori. Forse il tempo speso per scrivere i test potrebbe essere speso meglio imparando i principi SOLID o progettando l'interfaccia corretta in primo luogo. Forse dà un falso senso di sicurezza avere test che passano senza alcuna prova reale che tu abbia abbastanza test per garantire che il tuo oggetto faccia la cosa giusta.

Ancora una volta, come avvertimento, penso che i test unitari siano fantastici, ma non credo che il "test prima" sia utile o sensato. Inoltre, non credo sia pratico testare la simulazione principale quando c'è così tanto stato condiviso che cambia molte volte al secondo. Limito i miei test al mio livello basso e al mio codice di biblioteca, in generale.

Tuttavia, come probabilmente intuirai, sono in gran parte contraria alle "pratiche di codifica" delle imprese "in quanto le imprese sono ben note per il superamento di tempistiche e budget. "Anche gli sviluppatori di giochi!" Ti sento dire - beh, sì. Non penso che nessuno conosca davvero il modo migliore per sviluppare software in questo momento e non sono convinto che l'adozione di pratiche rigonfiate nel software tradizionale sia affatto un passo avanti rispetto alle pratiche più libere nel software di intrattenimento. In effetti sospetto che sia principalmente di beneficio per coloro che si affidano ai programmatori Java di materie prime in cui questi approcci non sono una scala per salire a livelli più alti, ma una rete di sicurezza per impedire che cadano troppo in basso.

Come osserva Kylotan, "Nei giochi non puoi considerare l'aspetto della presentazione come un concetto staccabile e sostituibile come HTML e CSS è per le app web". Avendo creato un paio di giochi usando un semplice schema MVC (non un enorme framework) ho scoperto che il problema principale è che il tuo modello deve conoscere la tua vista. È molto probabile che sia necessario utilizzare i dati bitmap, i dati hitbox o i dati della geometria 3D delle risorse artistiche per aiutare a elaborare il rilevamento delle collisioni (o un'altra attività simile). Ciò significa che ogni modello ha bisogno di un riferimento alla sua vista, che interrompe il modello MVC classico, ad esempio non è più possibile creare una nuova vista per un modello esistente ecc.

Il modello di componente che vedi, ad esempio, Unity3D è il modo migliore per organizzare il codice di gioco.

MVC, ad alcuni livelli, è già utilizzato nello sviluppo del gioco. È forzato dal sistema operativo, che ha diverse interfacce per input e grafica. La maggior parte dei giochi contiene anche alcune istanze di MVC, ad esempio separando i thread di fisica e rendering e input. Funziona benissimo. L'idea moderna di MVC sembra essere che dovrebbe essere ripetuta, frattalmente, fino a quando nessuno può più capire il codice. I giochi non lo fanno, per fortuna.

TDD non viene utilizzato perché raramente si sa che un gioco deve "fare" prima di ripetere più volte un prototipo. Le pratiche del TDD, come i test continui o i test di integrazione, sono spesso utilizzate nello sviluppo del gioco.

I sistemi di gioco si stanno lentamente spostando verso pratiche migliori. Framework come XNA forniscono una panoramica su come rendere il codice più generalizzato / pulito senza aggiungere troppi costi generali in fase di progettazione o di esecuzione. Ma in generale direi che i sistemi di gioco riguardano l'ottimizzazione della complessità rispetto alla velocità di esecuzione, il tutto mantenendo uno stretto programma di sviluppo e rimanendo motivati. L'applicazione di concetti di ingegneria del software e progettazione del sistema non è la priorità n. 1 in un ambiente simile.

Nei miei progetti di gioco personali, provo a commentare il codice o almeno a renderlo leggibile, e metto insieme sistemi che consentiranno un po 'più di flessibilità in seguito (cioè generalità) il più possibile, ma alla fine, se non hai spostato il gioco in avanti, semplicemente non è molto bello.

Inoltre, in genere quando hai finito il gioco, hai almeno 1000 idee su come migliorare la meccanica di base, i sistemi di base, ecc., In modo tale che molto poco di quel codice "riutilizzabile" essere davvero utilizzabile. Di giorno faccio un normale lavoro SE, e mentre i sistemi su cui lavoriamo possono essere enormi, in tutta onestà penso che impallidiscano rispetto alla complessità dei giochi.

Non ho un'opinione particolare di MVC al di fuori del fatto che la vista è spesso separata dalla logica dal semplice fatto che il ciclo di rendering sta impacchettando un sacco di roba per l'elaborazione di un po 'di hardware e non è il luogo in cui si desidera "gioco logica "accadendo contemporaneamente. Anche il "controller" è separato dall'hardware, ma sfortunatamente molti, se non la maggior parte degli sviluppatori di giochi, svolgono un lavoro "interessante" nel gestore del controller. (IMO il gestore del controller dovrebbe leggere i pulsanti e le levette e creare una "presentazione" che il gioco possa visualizzare, ma la mia soapbox non è così forte.)

TDD d'altra parte è qualcosa di cui ho opinioni molto forti. Cambia semplicemente lo sviluppo in modo da produrre software su cui è più facile basarsi. È più difficile da fare, non c'è dubbio. Certo, dal momento che è più difficile da fare, non è fatto. Alcune persone si lamentano del TDD (o più generalmente dei test unitari) senza valore perché "il gioco è il test", ma il fatto è che in TDD il test è quasi irrilevante. Il punto centrale di TDD è la progettazione e l'architettura del software che escono dal processo.

Abbracciare TDD cambia davvero il proprio approccio alla programmazione. Avevo delle sensazioni su ciò che era giusto e ciò che era sbagliato prima di iniziare il percorso TDD, ma una volta che sono entrato con entrambi i piedi sono arrivato a capire molto di più su come le cose che stavo facendo erano aiutando o ostacolando lo sviluppo futuro . In effetti, questo è una specie di punto dietro il post del coderoom, TDD senza la t .

Tornando al motivo per cui non viene più utilizzato nei giochi, oltre ad essere duro, fa capire alle persone che il modo in cui lo hanno sempre fatto in passato ha inutilmente reso più difficile il loro lavoro, e soprattutto per i programmatori è una pillola amara da guardare, molto meno deglutire.

Sono convinto che le persone che rifiutano di accettare TDD semplicemente non vogliono essere programmatori migliori. Pensano già di essere "eccellenti" nella programmazione, nel design o nell'architettura, quando in realtà il loro codice dice qualcosa di completamente diverso.