Programmare bene

Da quando è uscito Crysis (ma anche da prima) continuo a leggere questa frase:

Crysis è programmato male perchè sul mio uber-pc scatta con tutto al massimo“.

Cosa possiamo dire di Crysis? Probabilmente che le stime di crescita della potenza dei PC sono state troppo ottimistiche.

Possiamo dire che sia stato programmato male? No. Perchè no? Perchè programmare bene non vuol dire programmare in modo che il gioco sia veloce. Quello è solo un punto, probabilmente nemmeno il più importante.

Vediamo cos’altro è importante. Un gioco è ben programmato se segue le regole della buona programmazione che valgono per ogni software:

Codice documentato;

– Accoppiamento tra i moduli al minimo possibile;

Sviluppo il più possibile Data-Driven;

Chiarezza;

Solidità;

Ottimizzazione.

Prima si affronta il design, poi si scrive il codice nella maniera migliore possibile in modo che rispetti le richieste e infine, se il collo di bottiglia si trova nei nostri listati, si procede con l’ottimizzazione.

Consideriamo in dettaglio tutti i punti.

CODICE COMMENTATO

Se il codice non è commentato e la documentazione non viene scritta, qualora il suo autore dovesse abbandonare l’azienda, con lui andrà perso anche il suo know-how. Questo non deve succedere, perché una qualunque modifica al software nella parte di sua competenza sarebbe estremamente complessa e di certo genererebbe grossi bug di arduo tracciamento. Il codice va dunque commentato e la documentazione redatta. Crysis soddisfa questo punto? Siccome l’engine viene venduto, possiamo desumere che venga venduto con documentazione annessa. In passato ho lavorato con Renderware e tutto era documentato, sia nel codice sia nella documentazione allegata. Non vedo perchè Crysis avrebbe dovuto toppare su questo punto, ma siccome non possiamo saperlo, lasciamolo lì dov’è.

ACCOPPIAMENTO TRA I MODULI AL MINIMO POSSIBILE

Supponiamo che la sezione dell’input ad un certo punto voglia usare un pezzo del gioco, che gestisce magari il suono delle collisioni tra due oggetti.

E’ così creato un accoppiamento tra due moduli. Ciò può portare a mille problemi: ad esempio se modifico la collisione, di colpo l’input potrebbe non funzionare più. Per tale ragione si cerca di tenere gli accoppiamenti al minimo, limitandoli a ciò che è logicamente collegato ed ai tipi base.

Un esempio estremo: se ho un dato condiviso da più moduli e uno di questi lo modifica, magari il programmatore nemmeno immagina che questo viene utilizzato da qualcos’altro, quindi questo qualcos’altro non funzionerà più. Errori del genere portano via giorni. Crysis è a posto o ha tanti accoppiamenti? Se leggiamo le feature, notiamo che non può essere che con pochi accoppiamenti: una tale struttura permette un fortissimo riutilizzo dei componenti (giacché vivono in maniera autonoma). Già la sola integrazione perfetta con un ambiente di authoring ci fa capire che i moduli sono distinti.

SVILUPPO IL PIU’ POSSIBILE DATA-DRIVEN

Ed è qui che i fanatici dell’ottimizzazione gridano: una gestione data driven è più lenta di una gestione code-driven. Questo perché il dato va letto, interpretato e gestito, mentre se piazzato direttamente nel codice, questo è già pronto quando il gioco si compila.

Ad esempio: di che colore vogliamo le scritte sullo schermo? Se mettiamo il colore nel codice, questo sarà nell’eseguibile, pronto ad essere assegnato quando richiesto. Se lo mettiamo in un XML, questo andrà letto e interpretato, per poi prendere il dato e metterlo nella variabile dopo, magari, una conversione di tipo.

Quindi, perchè si fa? In primo luogo perché se la lettura del file si realizza in maniera oculata (ad esempio con un parser SAX invece che DOM per l’XML, oppure con un parsing in memoria per un binario), allora allungherà i tempi di startup di un tempo risibile, e inoltre in secondo luogo renderà il gioco immensamente più modificabile e tunabile per i designer ed i grafici (oltre che per l’utente). Pensiamo solo alle mesh: cosa succederebbe se il programmatore mettesse tutte le posizioni dei vertici nei sorgenti? Succederebbe che se al grafico una mesh non piace, bisognerebbe cambiare il dato a mano e ricompilare; ovviamente non ha senso: ha molto più senso che il grafico modifichi la mesh incriminata in 3dStudio Max, la riesporti e la ricarichi in gioco. Oppure pensiamo ad un designer che voglia inserire i nomi dei giocatori in un titolo calcistico, o ad un programmatore che intenda scrivere un nuovo shader.

Insomma, i benefici nei tempi di sviluppo sono talmente grandi che le perdite in fase di inizializzazione vengono del tutto riassorbite. Se consideriamo che il concetto di gioco data-driven risultava già ben presente ai tempi del C64, possiamo facilmente notare quanto sia importante.

Crysis è provvisto di tale approccio? In maniera massiccia: abbiamo editor per gli effetti, editor per gli stati, editor per i menù, editor per il gioco, editor per l’AI, editor per l’audio, editor per tutto 😀 Non c’è niente di hardcodato, tutto è data driven, per la massima modificabilità senza dover ricompilare alcunché. Questo ne conferma anche la modularità: il fatto che possiamo mettere vari moduli per creare degli effetti ci fa intuire che essi siano ben distinti e non connessi tra loro.

CHIAREZZA

Quando si scrive un programma, lo si deve fare pensando che saranno degli occhi umani a leggerlo. Il compilatore non ha molto interesse nella chiarezza: lui prende tutto quello che la grammatica del linguaggio accetta.

Se iniziamo a indentare il codice a caso e a dare alle variabili nomi inconsistenti (come ad esempio “deltaT” a variabili che indicano il tempo assoluto), allora andremo incontro a sessioni di debug molto faticose. Parimenti, se abusiamo del preprocessore dovremo affrontare simili avversità.

Crysis soddisfa questo requisito? Boh, spero che i lead controllino il codice, ma immagino di sì 😀

SOLIDITA’

Un software è solido quando, di fronte a tutti gli usi previsti dall’interfaccia d’uso, dagli input e dagli output, rimane funzionante e operativo nei tempi richiesti. Se di fronte ad una sequenza di input considerata corretta, il software entra in deadlock o crasha, allora non può essere ritenuto solido.

La solidità viene valutata con test mirati a stressare il sistema, come ad esempio saturare l’input, oppure lasciare il gioco a girare per giorni e giorni.

Come si ottiene la stabilità? In primo luogo con la disciplina: tutte le variabili allocate vanno prima o poi (quando serve) disallocate. Tutte le risorse hardware vanno rilasciate quando non servono più e tutto il sistema deve pensare di avere una serie di check per valutare che queste condizioni siano rispettate. In genere un gioco stabile è un gioco programmato con attenzione, come tutti i software e comunque per qualunque opera di ingegneria. Un ponte non crolla se è stato progettato con attenzione, giusto?

Quando, d’altro canto un software è instabile? Quando di fronte ad una precisa sequenza di operazioni considerate “safe” il programma inaspettatamente si blocca (nel caso in cui un software funzioni in multithreading, questa sequenza potrebbe non essere sempre riproducibile con facilità, rendendo il debug un autentico bagno di sangue).

Per evitare tali eventualità, si cerca di tenere il codice il più semplice possibile, tralasciando voli pindarici o ottimizzazioni spinte sulla macchina (tanto quelle ottimizzazioni il compilatore le sa fare meglio di noi, quindi perché preoccuparci?).

In Crysis è così? Non possiamo saperlo. Ma il gioco è stabile? Per quanto ho visto, funziona su una pletora di configurazioni senza crashare per molte ore di fila. Un miracolo, su PC.

OTTIMIZZAZIONE

Quando si trova un collo di bottiglia, si cerca di eliminarlo ottimizzando. Già in passato abbiamo visto che l’ottimizzazione sull’assembly senza cambiare algoritmo porta a guadagni tanto risibili da non avere senso.

Sì, amighisti, sì, lo so che sul vostro Amiga girava Lionhead: anche lì non pensiate che l’ottimizzazione sia stata fondamentalmente sulla macchina, bensì è stata effettuata su algoritmi custom e appositamente sviluppati per l’uso richiesto. Sono quelle le cose che consentono di ottimizzare tanto e davvero.

Vediamo: se c’è un collo di bottiglia sul processing dei pixel shader che si fa? Dove si controlla: nei conti degli shader o nei campionamenti delle texture? Se nei campionamenti, la scelta giusta consiste nell’ottimizzare le dimensioni delle texture: texture piccole per la roba lontana o piccola. Se è nei vertex shader, stessa cosa: sono i conti o il fatto che le mesh hanno una barca di vertici? E così via, per tutti i reparti del gioco.

Per Crysis, proviamo a pensarci: dov’è il collo di bottiglia? Ovviamente sui dati: si vuole mostrare sullo schermo TROPPO. Se vi fosse stata la necessità di andare più veloci, al fine di rendere l’insieme più gestibile, allora si sarebbe proceduto ad una scrematura, adoperando mesh meno dense e così via. Non può essere altro: il solo fatto che tutta quella roba SI MUOVA e sia giocabile in tempo reale ci fa capire che è stato fatto tutto nel modo migliore.

E la faccenda dei multicore? Beh, la solita fregnaccia da redattore (anche se in questo caso è peggio: da redattore esperto di hardware). Ne parliamo prossimamente, ok?

CONCLUSIONI

In definitiva che possiamo dire? Possiamo sostenere che Crysis sia programmato male? No, perché quello che si vede è fatto in maniera eccezionale, mentre quello che non si vede non lo possiamo sapere.

E ora via col flame!

27 comments on “Programmare bene

  1. eh ai bei tempi del c64 tutto era veloce e ottimizzatooo coi programmatori che stavano settimane per trovare la maniera di risparmiare un byte o un ciclo della cpuuuuu

  2. Personalmente non ce l’ho molto presente Crysis come non ho troppo presente FarCry.
    So che gira bene solo su pc dell’ultimo grido e dai benchmark che ho visto arrivano giusto al limite per averlo giocabile.
    Poi si potrà anche abbassare i dettagli, ma credo che quel genere di prodotto sia fatto per far sfoggio di grafica e quindi perderebbe molto dell’appeal che può avere.
    Mi ha dato molto più fastidio che si siano “lamentati” di non aver venduto, dando poi stupide motivazioni invece di realizzare che forse hanno sbagliato tempi e target.

    Per il resto io in genere vedo nei giochi considerati “mal realizzati” alcuni problemi fondamentali che possono inficiare anche la qualità programmativa: uscita prematura, scelte sbagliate a livello di design. Un controllo qualità dovrebbe impedire l’uscita di un prodotto non pronto, con ancora una lista di bug conosciuti o modifiche da fare. Inoltre per come la vedo io, alcuni giochi (non so Crysis) richiede troppo per quello che viene mostrato a video. Ora questa affermazione va spiegata: non so se effettivamente richiede tot calcoli o no, ma mi riferisco a quello che viene reso a video e percepito dall’utente. Se va lento ed è brutto da vedere (e sei nei requisiti), qualcosa non va senza guardare il lato tecnico. Se sei costretto ad abbassare i dettagli, vorresti che ci fosse qualche compromesso, qualcosa che cmq ammalgami ciò che vedi senza dargli quell’effetto di mozzato o addirittura eliminare effetti che creano l’ambientazione e possono inficiare il gameplay. Penso ad esempio a Hellgate London che se tocchi qualcosa, nelle zone buie non c’è praticamente illuminazione… avrò risparmiato ma li non gioco (sembra che mi accanisco sempre su HGL, però è il primo esempio che mi è uscito e cmq non si può dare mai addosso abbastanza a quel gioco, che soffre dei difetti che ho elencato).
    Inoltre i difetti nei giochi in genere li vedo dal punto di vista concettuale e di design, dove effettivamente vengono fatte delle scelte che possono essere anche implementate giuste ma portare a mille problemi o abusi proprio per l’idea iniziale.

  3. In realtà, come ho scritto, è un MIRACOLO che Crysis si muova, considerando quello che muove.

    Poi: quando un gioco esce, è molto difficile che sia Bug Free. E’ facile che abbia una serie di bug minor. In genere si cerca di chiudere tutti i bug dal major in su per l’uscita. I bug sono sempre noti: bisogna vedere se c’è il tempo di risolverli o no.

    Discorsi come “Ma non potevano sistemare tutto e farlo uscire dopo?” non hanno senso, se pensiamo al discorso commerciale: i giochi devono uscire in precisi momenti dell’anno, considerando le concorrenze e le feste.

  4. Sarà anche programmato bene per quei tali requisiti, ma era proprio necessario rendere ogni fogliolina di ogni cespuglio giocabile? Per quanto lo programmi bene un gioco così richiederà comunque un PC da miliardi.

    Programmato bene. Progettato (o ideato) male.

  5. Articolo molto interessante che mi trova d’accordo su parecchi punti.

    Sul codice commentato ricordo poi di aver avuto in passato una discussione con uno dei programmatori di Lionhead, il quale sosteneva che secondo lui ogni forma di documentazione/commento fosse solo una perdita di tempo, e che dunque tale pratica fosse per lui assolutamente negativa… da bocciare totalmente. Un punto di vista certamente interessante che però considero poco realistico perché per quanto il codice può essere ben scritto e “leggibile”, quando si parla di programmazione di qualcosa che sia un pelo più complesso del Notepad di Windows tenere traccia del proprio operato diventa non solo consigliato, ma una necessità qualora ci dovesse essere un passaggio di consegne… o anche solo per mantenere il know-how acquisito con un po’ di ordine.

    A riguardo invece della valutazione dell’operato di Crytek e sulla buona programmazione di Crysis, non posso che dirmi semplicemente concorde con quanto sopra riportato.

  6. Dalle tue chiare e semplici spiegazioni capisco quanto lavoro ci sia dietro un gioco. Persino una merda come kasumi ninja è quasi da rivalutare.

    Il vero problema di Crysis è stata la promozione che l’ha venduto come il gioco che necessita di un pc da almeno 2000€ per essere dignitoso da vedere. Questo comporterebbe una seria discussione sul fatto che qualunque filmato io vedo di MGS4 E’ il gioco, mentre qualunque filmato io vedo di un titolo pc è una configurazione al massimo, quindi non è e non sarà mai quello che vedrò giocando su un pc da 600€
    Poi Crysis è diventato il capro espiatorio delle richieste hardware esagerate, indipendentemente dai sui meriti.

  7. Io in uno dei notevoli post scritti su un 3d flammoso ho detto che a parità di fps la grafica di crysis solitamente è migliore.

    Ovvero se imposto due giochi per darmi sempre 30 frame al secondo la grafica di Crysis è migliore…poi magari magari lo stile dei livelli ci piace di più in un altro gioco, ma a livello di qualità visiva mi sembra non ce ne sia per nessuno….

  8. appena il forum di tgm crossposto l’articolo di Monopoli sul 3d incriminato….

    tanto per aggiungere benzina al flame…..è un dovere morale!!!

  9. Mi viene solo da obiettare che nella tua stima qualitativa non è stata trattata la scalabilità in funzione del livello di dettaglio (mi trovo d’accordo con te sul fatto che Crysis muove troppo) e degli standard tecnologici adottati dall’hardware su cui gira.

    Il problema è che sembra proprio non esserci un controllo possibile (o adeguatamente esposto, come dici tu possiamo basarci su quello che vediamo ed intuiamo) per intervenire sul livello qualitativo delle informazioni visualizzate (e questo un po’ impatta anche sul design data-driven, visto che parliamo di modelli dati estremamente dinamici e manipolabili).

    Farcry, secondo me permetteva un controllo più fine su questi aspetti, utilizzando e calibrando l’intensità dei soliti trucchi del mestiere di cui tu hai già profusamente parlato in un precedente articolo, uniti forse ad una pipeline di rendering più aperta ai fallback tecnologici.

    Magari è stata solo mancanza di tempo o di budget, però è chiaro che rispetto ad un Unreal o ad un Quake qualsiasi, si può intervenire molto meno su quel frangente. Forse è stata anche la scelta un po’ prematura di un motore DX10-based ad aver costretto a fare scelte molto meno scalabili riguardo le estensioni hardware.


  10. Poi: quando un gioco esce, è molto difficile che sia Bug Free. E’ facile che abbia una serie di bug minor. In genere si cerca di chiudere tutti i bug dal major in su per l’uscita. I bug sono sempre noti: bisogna vedere se c’è il tempo di risolverli o no.

    Discorsi come “Ma non potevano sistemare tutto e farlo uscire dopo?” non hanno senso, se pensiamo al discorso commerciale: i giochi devono uscire in precisi momenti dell’anno, considerando le concorrenze e le feste.

    Ammetterai però che non è molto corretto verso chi comprerà il tuo prodotto, farlo uscire non come è stato concepito, ma con problemi noti o con qualcosa in meno.
    E conosco molti casi (potrei citare il solito HGL) dove questo rasenta molto la truffa a fronte delle comunicazioni sbandierate prima e tuttora dagli sviluppatori.
    Che poi il bug ci scappi sempre mi sta bene, che ce lo fai scappare no.

    Inoltre come è stato detto, magari il motore di Crysis muove effettivamente bene quello che viene mostrato a video però se a me la resa video non soddisfa forse qualcosa non va. Mi spiego. Molti titoli odierni a pieno dettaglio si vedono bene, ma spesso togliendo qualcosa si vedono peggio di giochi di anni prima semplicemente perchè non si è tenuta da conto la scalabilità e l’effetto visivo complessivo man mano che le richieste hardware scendono. Magari non sarà un difetto di programmazione ma di sicuro di progettazione.

  11. Prima di tutto gli SVILUPPATORI non comunicano niente: quelli che comunicano sono i responsabili della comunicazione.

    Detto questo, non ci si può fare niente: le date vanno rispettate, quindi un gioco con bug minor non è per niente strano. Un bug MINOR non è un crash, eh, un crash è un bug CRASH che sta sopra il MAJOR.

    MINOR significa che non compromette la giocabilità, non è crashante e non è molto visibile.

    Il resto purtroppo non lo capisco: è ovvio che quando abbassi la resa estetica in un gioco, allora scenda la qualità ed il gioco assomigli ad un gioco vecchio 😀
    Anche questa frase:
    “Ammetterai però che non è molto corretto verso chi comprerà il tuo prodotto, farlo uscire non come è stato concepito, ma con problemi noti o con qualcosa in meno.”

    Il gioco esce nello stato migliore possibile, non è che si rilascia un gioco con i bug mentre noi abbiamo la versione buona 😀
    E’ molto difficile che i bug scappino: i bug in genere vengono sempre scoperti. Poi bisogna dargli una classificazione e decidere se vanno fixati. In genere si cerca di fixare tutti i bug crash, block e major. I minor ed i glitch si fixano solo se c’è tempo ed in genere non c’è mai tempo.

  12. Prima di tutto gli SVILUPPATORI non comunicano niente: quelli che comunicano sono i responsabili della comunicazione.
    Scusa hai ragione, intendevo le ditte che sviluppano, non gli sviluppatori. In ogni caso il senso è chiaro: se chi ti vende il gioco comunica qualcosa, quello ti aspetti. Se poi per varie ragioni non è così di qualcuno è la colpa, magari non del programmatore che con più tempo avrebbe fatto meglio, ma di qualcuno sarà.

    Detto questo, non ci si può fare niente: le date vanno rispettate, quindi un gioco con bug minor non è per niente strano. Un bug MINOR non è un crash, eh, un crash è un bug CRASH che sta sopra il MAJOR.

    MINOR significa che non compromette la giocabilità, non è crashante e non è molto visibile

    Non è però un prodotto finito perchè se un bug non è conosciuto mi può star bene, ma se si sa che esiste vuol dire che non è stato fatto qualcosa prima per prevenirlo, insomma il tempo necessario a realizzare il prodotto è più di quello che si è impiegato.
    Ed escono prodotti con Major Bug.

    Il resto purtroppo non lo capisco: è ovvio che quando abbassi la resa estetica in un gioco, allora scenda la qualità ed il gioco assomigli ad un gioco vecchio
    Non è ovvio invece. Se abbassi la resa grafica non è necessariamente vero che l’impatto visivo debba risentirne in maniera così evidente, o meglio si vedrà meno definito o con meno dettagli, ma da li a vedersi male dovrebbe passarne. Nella frase che citi mi riferivo al fatto che spesso prodotti nuovi a pieni dettagli si vedono bene, togliendo qualcosa si vedono PEGGIO di prodotti vecchi.

    “Ammetterai però che non è molto corretto verso chi comprerà il tuo prodotto, farlo uscire non come è stato concepito, ma con problemi noti o con qualcosa in meno.”

    Il gioco esce nello stato migliore possibile, non è che si rilascia un gioco con i bug mentre noi abbiamo la versione buona

    Beh, il gioco esce e vende, chi ci ha lavorato prende lo stipendio, ma chi l’ha comprato prende un prodotto non finito, sia che siano problemi minori che problemi maggiori. Si suppone che fino a che i problemi non sono risolti ci si lavori.
    Se poi i tempi sono stretti è un problema di chi i tempi li calcola e alla peggio di chi ci ha lavorato male (di norma è la prima penso).
    Già assumere di non risolvere qualche problema è cmq ammettere che si preferisce lasciare un lavoro incompiuto ma avere i vantaggi di un ritorno come se fosse tale.

  13. un esempio penso possa essere stalker dove togliendo l’illuminazione dinamica il gioco diventava dx8……ovvero a togliere un’opzione la grafica ne risentiva pesantemente.

  14. e va bene, mi tocca … io mi chiedo: è proprio necessario sorbirsi ogni volta ‘sta valanga di informazioni ben documentate e tuttavia inutili? coloro che rispondono strabiliati della competenza del redattore, lo fanno solamente perchè non sanno molte delle cose che vengono spiegate. E fin qui va bene: è un buon articolo divulgativo su un sacco di cose inutili per chi non fa il mestiere dello sviluppatore di videogiochi. In realtà l’articolo quà e là vuole far “passare” qualche altro parere, inchiavardandolo dietro a tutta questa sottigliezza tecnica. In pratica: se non sei d’accordo, allora significa che non ne sai abbastanza, oppure non hai capito.
    In questo “collettivo” di cervelli parlate di videogiochi “giocati”, di design “provato sul campo”. Vi prego: continuate a parlare di questo, lo fate benissimo sia quando mi trovo d’accordo con quanto leggo sia quando sono in disaccordo. Questi articoli invece non servono a niente, non c’è niente da imparare perchè queste informazioni qui sono fuori posto, per quanto documentate, e non c’è da essere d’accordo o in disaccordo semplicemente perchè i pareri non sono quasi mai giustificati se non attraverso la presunzione di una superiore capacità in ambito tecnico.
    Jerome diceva: ci sono due tipi di ciclisti, quelli che usano la bicicletta, e quelli che l’aggiustano. Questo per dire che per quanto il redattore sia preparato nel suo campo (di cui anch’io conosco qualcosa, senza mostrare le stellette…), sta solo apparentemente parlando di quello che vi interessa, oppure – quando lo fa – tira su un inutile paravento per non dover mai ammettere di avere torto o di aver cambiato idea: è sempre e solo un fatto tecnico, e chi non conosce i fatti può solo tacere e imparare.
    Inoltre c’è un atteggiamento conservatore dietro alle opinioni di Monopoli che è irritante: tutto ciò che è reale è razionale, si sarebbe detto altrove. Se l’hanno fatto è perchè andava fatto così, se l’hanno fatto così vuol dire che non si poteva fare di più, e via così… ma che palle. Tutte queste informazioni, per sapere che il mondo va bene così com’è?
    Ad ogni modo non capisco quale utilità abbia, ai fini della vostra ricerca verso una nuova consapevolezza videoludica, sapere come ragionano alla Ubisoft: non è una cosa che potete cambiare. Ed eventualmente, queste informazioni non cambieranno di una virgola il fatto che Crysis ve lo comprerete lo stesso (o peggio, la scheda video per giocarci).

    Quindi…

    …a me piace lo stile grafico, i controlli, la storia, le trovate, ed i controlli di Psychonauts. Che me ne faccio di questo articolo?

    …sono uno sviluppatore indie, voglio fare un piccolo gioco indipendente. Che me ne faccio di questo articolo?

    …sono un videogiocatore accanito ma “attento”. Cerco di capire quali prodotti siano più conformi al mio gusto. Che me ne faccio di questo articolo?

    …sono un giocatore saltuario, solitamente ripugnato dalla bassezza dei temi dei videogiochi (ammazza ammazza ammazza), che cerca qualcosa di nuovo. Che me ne faccio di questo articolo?

    e così via…

    molto meglio discutere di finali, di profeti inutili, di confini incerti, etc.. ma ‘sto strazio periodico, invece, finirà mai?

  15. Federico…
    Fermo restando che quanto dici sia grossomodo corretto e penso conosciuto ai più (l’apparente utilità di alcuni articoli, il modo di scrivere e di porsi di Monopoli, l’impossibilità di controbattere).
    Il perchè di questo articolo? Si sa che Monopoli è infastidito quando vengono dette alcune cose, a volte campate in aria o per sentito dire, altre volte no, su qualcosa che in teoria può competergli che lui ritiene non veritiere. E quindi mostra un’altra versione dei fatti. Fin qui non ci vedo niente di male, anzi è un bene che ogni tanto ci sia qualcosa che faccia riflettere.
    Che poi molte cose la gente le sappia va bene, che il modo in cui lui le porti avanti è come tu hai descritto e fuor di ogni dubbio, però non mi sento di buttare tutto quello che dice così. Si sa cmq che se non si è daccordo prevale la parola di chi “ne sa di più”. Quindi che si prenda come spunto quel che di buono c’è e si lasci stare il resto. Non esiste che al mondo uno abbia torto solo perchè non sa e non è possibile ne obbligatorio sapere tutto.
    Io dalla discussione ho preso spunto per dire la mia, ovvero che non importa quanto possa essere difficile il lavoro del programmatore (che ormai passa per vittima di tutti i commenti negativi anche se non è vero), semplicemente a prescindere il prodotto che fai deve essere fatto bene e curato e venduto per tale, se lo fai male cmq non ci sono scuse. E questo si vede dal risultato, non da quello che viene prima. Poi diventa un discorso sulle colpe casomai.

    A me va bene che ci sia qualche articolo “più tecnico” se così si può dire, giusto per spezzare un po’. Il sito è scritto per lo più da umanisti o giù di li e da come l’esperienza mi insegna, di quel che un umanista dice (e della sua intrinseca artefatta complicatezza) devi buttare il 90% ma quel 10% che rimane lo può dire solo lui ed è un bene che ci sia perchè integra quello che c’è già. Da quel 10% si tirano fuori un sacco di cose interessanti.

  16. E perché non “sono un ragazzotto disoccupato che caga il cazzo scrivendo nei forum che Gioco X è programmato male e io saprei fare cento volte meglio”?

    E perché non “sono un programmatore alle prime armi e non vedo perché non stia bene programmare un gioco come un .cpp unico che contiene codice, librerie, dati, e pure mia nonna”.

    Federico, per me quanto ha scritto Monopoli stavolta è un semplice rinfresco di ciò che so già per quel che riguarda la programmazione, ma trovo interessante leggere esempi applicati al mondo dei videogiochi, che come sviluppatore non frequento. Mi duole (vabbe’, non è vero) che a te non interessi questo articolo, ma se tanto mi dà tanto dovrai (e, se te lo permetterai, potrai) fare sempre di più uso del Diritto Inalienabile del Lettore di Non Leggere, perché qui su Ars Ludica ci piacerebbe che i videogiochi fossero trattati da più punti di vista possibile (e questa dev’essere la seconda volta che lo scrivo).

    Non è però un prodotto finito perchè se un bug non è conosciuto mi può star bene, ma se si sa che esiste vuol dire che non è stato fatto qualcosa prima per prevenirlo, insomma il tempo necessario a realizzare il prodotto è più di quello che si è impiegato.
    Ed escono prodotti con Major Bug.

    MIK0, per “prevenire” i bug l’unica cosa è lo sviluppo test-driven – cioè PRIMA crei i test che il tuo codice dovrà soddisfare, poi sviluppi il codice. Questo riduce il tempo di debug, ma allunga il tempo necessario ad avere qualcosa di funzionante, ed è scarsamente praticabile per software che superino una certa complessità (in genere lo si applica per applicazioni veramente critiche… il software che muove un braccio meccanico che fruga nelle interiora di un tizio lo è, un videogioco no).

    Quello che auspichi è ovviamente il bel mondo ideale in cui tutti hanno tutto il tempo e le risorse necessarie per lavorare bene… questo mondo ideale non esiste. Perché dovrebbe esistere nell’informatica, quando ci sono architetti, ingegneri, medici, che fanno stronzate clamorose in qualcosa che al contrario di un software NON è PATCHABILE?

    Un “minor bug” non è necessariamente “minor” come complessità di risoluzione… è solo “minor” come impatto. In alcuni miei programmi, magari dopo mesi che sono in produzione, mi capita di accorgermi di un potenziale bug che non tiene conto di un caso particolare (e se si tratta di programmazione con segnali, thread, eventi, semafori tanti auguri – ho visto bug risolti dopo mesi) e che causa un disservizio trascurabile; magari però per risolvere quel bug mi dovrei sbattere per due giorni perché il programma deve affrontare un problema di un ordine superiore a quello che ha affrontato fino a quel momento, per non parlare del fatto che tutto va (andrebbe…) TESTATO di nuovo da capo, mentre quegli stessi giorni magari farei meglio a impiegarli per finire un lavoro che eviterà all’azienda di finire sotto processo; perché sarebbe bello stare a grattarsi una volta finito un lavoro, ma STRANAMENTE non capita quasi mai (anzi mi capitano i giorni in cui passo il tempo solo a ricevere cose da fare).

  17. Mi spiace che non ti sia piaciuto l’articolo, Federico, sul serio. In genere cerco sempre di essere molto chiaro, spiegando tutto quello che scrivo ed usando terminologia non tecnica, anche a rischio di essere attaccabile da esperti.

    Rileggendo questo articolo mi sono accorto che ho dato per scontate molte cose, dando l’idea che io dica sempre e solo il vero. In realtà quella che leggi è la mia opinione sulla faccenda, tutto qui: la mia opinione da programmatore con un po’ di anni d’esperienza.

    L’idea di aver ragione deriva dal fatto che molto spesso parlo di cose difficilmente attaccabili, molto ovvie per i programmatori ma meno ovvie per i profani.
    Diciamo che quando parlo di “High Cohesion Low Coupling”, i programmatori ed i progettisti sanno di che parlo e potrei non dire altro.
    Questo concetto non banale però non può essere chiaro in assoluto, quindi lo spiego non trattandolo come una possibilità per programmare, ma come una proprietà che se c’è, allora il programma è ben fatto. Se manca, allora è brutto 😀
    C’è poco da fare, ci sono molti libri che spiegano questi concetti (sono i libri dei pattern di design), però non posso metterlo giù come un concetto che “potrebbe essere vero, chi lo sa, per me sì” perchè farei un grave errore nel tentativo di divulgare.

    In futuro io continuerò a scrivere articoli per Arsludica (fintanto che i miei colleghi sopporteranno i miei improperi :D) e ti chiedo di essere sempre critico: la tua critica mi ha aiutato a capire come migliorare i miei prossimi articoli. Cercherò di essere meno perentorio, di spiegare con più attenzione e usare solo i termini spiegati nell’articolo, per non dare l’idea di voler parlare di qualcosa “che solo gli esperti possono capire e gli altri si attacchino e ci credano”.

  18. tutto il rispetto a monopoli, ma capisco anche la posizione di federico… cioé, questo post parla di programmazione in generale, le cose scritte qui si potrebbero applicare benissimo alla programmazione di un sistema operativo o di un pacchetto office.
    la programmazione di videogiochi dovrebbe essere diversa? forse no, però leggendo il post, dal tono “professional” mi viene da fare il collegamento con l’atmosfera che si respira in molti vg odierni, da “construction kit”…
    è un discorso cioé che va al di là del “sul mio pc scatta”, perché oltre all’ottimizzazione, con questo approccio “aziendale”, se vogliamo chiamarlo così, alla programmazione dei vg, si perde un (bel) po’ in creatività, o meglio in libertà creativa…
    mi rivolgo a monopoli, e agli altri programmatori in linea… mettendovi una mano sul cuore, quante volte v’è venuta l’idea di aggiungere una cazzatina, un tocco fuori dalle righe, e l’avete abbandonata perché sennò s’incasinava il “prodotto”? o perché il programma diventava meno elegante?
    penso ai vg giapponesi e al loro essere (mediamente) molto più pieni di stronzate e di easter egg rispetto a quelli occidentali… e infatti in non ricordo quale intervista (citata pure qui su ars ludica, mi pare fosse a un tizio della konami) si diceva che in giappone sono disorganizzati… forse tra le due cose c’è un nesso?
    per concludere: scrivere un programma in maniera elegante è un vantaggio soprattutto in quegli ambiti dove il programma deve venire aggiornato e rifinito continuamente (leggi: SO e applicativi).
    capisco che al giorno d’oggi bisogna avere un occhio di riguardo ai $$$ dato che se ne spendono tanti tanti, per cui da un punto di vista AZIENDALE conviene avere del codice pulito e riutilizzabile. ma se si esagera… construction kit… fifa construction kit, pes construction kit, call of duty construction kit, prince of persia construction kit, e via così…

  19. è un discorso cioé che va al di là del “sul mio pc scatta”, perché oltre all’ottimizzazione, con questo approccio “aziendale”, se vogliamo chiamarlo così, alla programmazione dei vg, si perde un (bel) po’ in creatività, o meglio in libertà creativa…

    Te lo può dire qualsiasi artista: puoi essere un genio, ma il genio non basta; se non studi e migliori la tecnica nella tua arte andrai meno lontano di chi genio non è ma ci si mette d’impegno. Lo dicono tutti gli insegnanti: PRIMA impara la teoria e la tecnica, POI dai sfogo alla tua creatività.

    Michelangelo ha messo il suo estro nell’affrescare la Cappella Sistina, ma NON nel preparare i pigmenti e la base: queste cose andavano fatte nel modo MENO creativo, e più conosciuto e sicuro possibile; sennò hai fatto un bellissimo dipinto, e dopo un anno casca a terra perché hai preso strane iniziative.

    Se hai del codice fatto bene puoi riutilizzarlo quanto vuoi, e concentrare i tuoi sforzi sulle “cose in più” che auspichi; se scrivi il codice “creativamente”, i tuoi sforzi finiranno inghiottiti da un debug infinito (e MIK0 non sarà contento).

  20. Beh, considera che in genere gli easter egg sono molto spesso dei bug divertenti 😀
    Ad esempio in SB riding Challenge c’era un cheat che faceva diventare gigantesche le teste dei piloti, a seconda di quanto si andava veloce.

    Il videogioco, però, non può allontanarsi in alcun modo dallo sviluppo standard, perchè allontanarsi non significa essere originali e fori dagli schemi (e cool :D).
    Significa introdurre delle problematiche che di certo, successivamente, si rivolteranno contro l’intero sistema, causando piano piano in trend negativo in cui si dice “vabbè se lui l’ha fatto lo faccio pure io”.
    Tutto questo fino a che si raggiunge il parossismo: un sistema inutilmente complesso, che porta a cose tipo “per aggiungere un bottone nella UI sevono 3 giorni uomo” o “per capire chi fa quell’effetto ci ho messo tre giorni e l’ho trovato nell’input” 😀

    La creatività non è nemica delle regole nel caso della programmazione. Posso capire che lo sia in un campo artistico, come la musica e la pittura. Per la musica lo capisco in maniera più profonda, giacchè suono.
    Ma la programmazione in sè, se dobbiamo per forza dire che è un’arte, allora è un’arte la cui bellezza è direttamente proporzionale al suo ordine, perchè nel momento in cui si fa del disordine, ne pagano le coseguenze tutti i programmatori in azienda 😀

    Te lo dico con congnizione, fidati 😀

  21. Aggiungo una cosettina: sono praticamente certo che i vari fifa e pes cambiano così poco di anno in anno perchè il loro codice è un casino mostruoso e cambiare qualcosa è un massacro 😀
    Se ci fosse un codice più pulito, le modifiche non sarebbero un problema 🙂

    C’era la leggenda che nel codice di FIFA ci fossero delle parti delle versioni per Sega Megadrive e che ogni anno cercassero di toglierle, ma ogni volta si andava incontro a dei crash casuali ed irriproducibili in maniera certa 😀
    Questa leggenda, purtroppo, pare avere un fondo di verità 😀

  22. Chiarisco, non si sa mai.
    Mai detto che il software possa non avere bug.
    Mai detto che si debba sviluppare partendo dal test.
    Certo, se si pensa un po’ più in la a quello che si fa si può già progettare pensando alle varie problematiche ma presumo che questa sia la norma. Senza esagerare.

    Quel che dico è: se ti dai un tempo per fare qualcosa e in quel tempo non ce la fai, la responsabilità di non avercela fatta rimane nell’ambito di chi sta creando quella cosa. Non si può scaricarla su chi compra ciò che tu hai fatto e per il quale vieni pagato. Se tu cmq vieni pagato uguale ma ci metti di più dovrebbe essere un problema tuo o dell’azienda. Poi la responsabilità andrà ricercata o nel programmatore o nel progettista, o in una delle altre componenti dello sviluppo.

    Per come l’hai messa giù sembra che sia considerato accettabile (e ho visto che spesso per i videogiochi è così) che un prodotto esca alla data di scadenza prefissata nello stato in cui è. Con questo concetto per assurdo uno potrebbe impacchettare un pdf con il documento di design e dire a chi acquista che il gioco poi arriverà.
    Il supporto ad un prodotto dovrebbe essere risolvere problematiche irrisolte e NON conosciute e difficilmente rilevabili dai test e aggiungere qualcosa di nuovo, NON aggiungere qualcosa che doveva già esserci.

    Mi dici che auspico un mondo ideale e forse è vero, ma se l’alternativa è farsi andare bene un mondo che così non va e che si è accettato anche se sbagliato mi tengo il mio punto di vista. Un lavoro richiede troppo tempo, ci vogliono più persone. Si ricevono troppe richieste e si ha poco tempo ma va fatto tutto? Beh probabilmente i mezzi sono sottodimensionati rispetto a ciò che viene chiesto e l’unica conseguenza è fare il lavoro male. Oggi semplicemente funziona perchè si ammette lo sfruttamento del lavoratore, ovvero si pretende che venga fatto di più nello stesso tempo, è qui l’errore.
    L’alternativa è prendere qualcosa di già fatto e aggiungerci qualcosa, ma le licenze costano. Sarà per quello che chi sviluppa per esempio un motore grafico ci impiega di più e forse rientra nei costi al titolo successivo in sviluppo e non al primo, oppure concedendo le licenze.

    L’esempio degli architetti te lo volevo citare io, appunto per esempi di gente che ha progettato partendo da tutti gli assunti appresi studiando per poi scazzare arrivati a contatto con la realtà. Perchè è quello che succede anche nell’informatica, spesso si perde questo contatto e si riempie tutto di layer di fregnacce non sempre necessari (e non auspico il “programmatore astuto” come diceva uno dei miei prof). Certe cose vanno imparate con ordine.
    Detto questo non vedo perchè chi fa un software non ci debba mettere la stessa attenzione di un architetto (quello che non scazza però). Non si può accettare a priori che qualcosa, anche di importante, non andrà come deve. Quello si spera debba essere sempre un imprevisto.

    Riguardo all’ordine nella programmazione non ho nulla da obiettare. Mi sta bene che ci sia disordine nel contempo in cui si prende dimestichezza con il mezzo perchè penso che sia cmq qualcosa che non puoi studiare ma va appreso con l’esperienza. Infatti ci sono più linee di pensiero riguardo all’ordine e a come il codice va scritto. Quindi l’ordine serve per i motivi citati e non penso che questo debba per forza ledere la creatività. Tant’è che ogni tanto si sente parlare di riscrittura del codice di una certa parte, probabilmente perchè dopo tentativi, aggiunte ed esperienza l’ordine tende ad oscillare ma si può “riordinare” con ciò che si ha imparato. Ovviamente ad averne il tempo.

    A parte tutto questo discorso sulla prammazione o sulla sua etica o quello che è, in un videogioco rientrano anche altre figure che curano prettamente il lato creativo (non che il programmatore ne sia escluso a priori, non si può dividere le persone a scomparti). E anche loro sbagliano e anche per quello che loro creano che vanno fatti dei test. Un design sbagliato porta a risultati sbagliati a prescindere da come verranno realizzati. Ed in molti giochi è questo il problema.

  23. Non capisco quale sia il fulcro del messaggio di Federico… parlare di videogiochi sì, ma senza mai cercare di capirne davvero perché tanto non serve, quindi limitiamoci sempre ai soliti 3, 4 discorsi triti e ritriti, che tanto va bene così? Per carità, si può fare anche così, ma poi quella tanto declamata maturità del media videoludico dove la mettiamo, se tanto ciò di cui discutiamo si limita alle solite cose alla “console war” (io ho la console più figa, quel gioco è più figo)?

    Ad ogni modo non capisco quale utilità abbia, ai fini della vostra ricerca verso una nuova consapevolezza videoludica, sapere come ragionano alla Ubisoft: non è una cosa che potete cambiare. Ed eventualmente, queste informazioni non cambieranno di una virgola il fatto che Crysis ve lo comprerete lo stesso (o peggio, la scheda video per giocarci).

    Personalmente credo che la consapevolezza passi attraverso molte cose. Per capire meglio la pittura approfondire le conoscenze sull’uso del mezzo pittorico che ne facevano gli artisti aiuta a capirne meglio le opere, tanto per fare un esempio.
    Non cambierà il fatto che si preferisca Van Gogh a Gauguin? Beh, ma quello è tutt’altro discorso.

  24. A me avere informazioni così dettagliate da un insider del mondo dei videogiochi aiuta a comprendere meglio i videogiochi… come aiuta sapere il lavoro che fa un montatore in fase di montaggio di un film o quello di un pittore che sceglie alcuni colori e materiali piuttosto di altri per realizzare la sua opera.

Leave a Reply