Commenti a: Programmare bene

Di: Simone "Karat45" Tagliaferri

Simone "Karat45" Tagliaferri — Sat, 28 Jun 2008 12:29:43 +0000

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.

Di: Marco/Cav

Marco/Cav — Sat, 28 Jun 2008 11:29:25 +0000

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.

Di: MIK0

MIK0 — Sat, 28 Jun 2008 10:15:14 +0000

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.

Di: Alex Monops

Alex Monops — Sat, 28 Jun 2008 09:39:56 +0000

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à 😀

Di: Alex Monops

Alex Monops — Sat, 28 Jun 2008 09:36:01 +0000

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 😀

Di: StM

StM — Sat, 28 Jun 2008 09:27:58 +0000

è 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).

Di: Bruno

Bruno — Sat, 28 Jun 2008 00:01:24 +0000

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ì…

Di: Alex Monops

Alex Monops — Fri, 27 Jun 2008 23:49:20 +0000

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”.

Di: StM

StM — Fri, 27 Jun 2008 22:29:24 +0000

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).

Di: MIK0

MIK0 — Fri, 27 Jun 2008 21:50:45 +0000

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.

Di: Federico

Federico — Fri, 27 Jun 2008 20:46:28 +0000

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?

Di: Alessandro Monopoli

Alessandro Monopoli — Fri, 27 Jun 2008 05:45:50 +0000

Dannazione, ci puntavo tanto 😀 E’ perchè è mancata la gente giusta 😀

Di: Emanuele "Emack" Colucci

Emanuele "Emack" Colucci — Thu, 26 Jun 2008 21:49:25 +0000

non c’è stato flame… stai perdendo colpi, alessà 😀

Di: Ray

Ray — Thu, 26 Jun 2008 19:14:17 +0000

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.

Di: MIK0

MIK0 — Thu, 26 Jun 2008 14:47:16 +0000

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.

Di: Alessandro Monopoli

Alessandro Monopoli — Thu, 26 Jun 2008 14:12:18 +0000

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

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.

Di: MIK0

MIK0 — Thu, 26 Jun 2008 14:03:55 +0000

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.

Di: Matteo Anelli

Matteo Anelli — Thu, 26 Jun 2008 13:32:28 +0000

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.

Di: Ray

Ray — Thu, 26 Jun 2008 12:46:20 +0000

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

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

Di: Nevade

Nevade — Thu, 26 Jun 2008 12:41:32 +0000

Sempredettoio che Crysis era programmato bene :asd:

Di: Ray

Ray — Thu, 26 Jun 2008 12:40:24 +0000

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….

Di: Fleym

Fleym — Thu, 26 Jun 2008 12:37:34 +0000

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.

Di: MarcoCav

MarcoCav — Thu, 26 Jun 2008 12:27:38 +0000

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.

Di: angelword

angelword — Thu, 26 Jun 2008 12:19:30 +0000

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.

Di: Alex Monops

Alex Monops — Thu, 26 Jun 2008 10:52:46 +0000

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

Di: MIK0

MIK0 — Thu, 26 Jun 2008 10:37:22 +0000

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.

Di: Bruno

Bruno — Thu, 26 Jun 2008 06:28:30 +0000

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