Ars Ludica | Forum | Archivio | About

Oscurità proiettate

        Monday, 12 May 2008, 8:48 - Monopoli

Le ombre sono una cosa divertente: se non ci fossero, i progettisti di sistemi per il rendering sarebbero felici e contenti.

Purtroppo ci sono, quindi quando un giocatore guarda lo schermo e non le vede, grida “Non ci sono le ombre! Questo gioco è becero sterco!”.

Perchè ogni tanto i giochi non presentano le ombre dei personaggi (o degli edifici) oppure, quando lo fanno, non sono poi bellissime?

Il motivo è semplice: fare le ombre è molto complesso.

Vediamo un’ombra vera:

In questa immagine possiamo notare varie peculiarità: in primo luogo l’ombra non è completamente nera, perché la luce, nell’aria, non viaggia bella tranquilla ma incontra continuamente pulviscolo ed altre belle cose che la riflettono di qua e di là, quindi anche dentro l’ombra.

In più notiamo che l’ombra dell’uomo è molto netta, mentre quelle delle… ehmmm… vabbè, quel che è, sono molto meno nette.

Perchè? Per lo stesso motivo visto prima: la precisione dell’ombra cambia a seconda della distanza del soggetto dall’oggetto su cui viene proiettata: più è distante più i raggi saranno deviati. Da ciò deduciamo che in un luogo senz’aria, le ombre saranno perfette. Così è, infatti, se guardiamo le foto dalle missioni lunari.

Come possiamo fare a simulare tutto questo? Il proiettare raggi che intersecano cose è fuori discussione: si chiama ray-tracing e in tempo reale, al momento non è una cosa semplice. Anzi, diciamo che al momento ce lo scordiamo (anche se Carmack dice di avere qualcosa in mano a riguardo). Esiste un engine di rendering per Quake 3 in raytracing fatto da appassionati, ma purtroppo va un po’ pianino :D . Tipo 1 frame ogni 30/40 secondi.

Quindi, siccome il proiettare i raggi è fuori discussione, come facciamo? Dobbiamo inventarci qualcosa che ci risolva il problema.

In più, facendo così, avremmo ombre nettissime ad ogni distanza, a meno di calcolare la deviazione della luce a causa del pulviscolo (si chiama “scattering”). A questo punto però ci sarebbero tanti bei problemi di precisione. Al momento il real time è fuori discussione.

Possiamo, per ora, utilizzare tre differenti soluzioni:

Proiezione Planare

Purtroppo non so se si chiama così, questa tecnica, poiché non è tanto efficace da esser degna un nome. Diciamo che consiste nel proiettare tutti i punti di un modello 3D su un piano, lungo la linea della direzione della luce:

Questo sistema mostra subito il fianco all’hard core gamer: in pratica se c’è un oggetto sul piano, la tecnica non lo vedrà e andrà semplicemente sul piano.

Certo, il piano può essere inclinato, però comunque se c’è un muro su quel piano, l’ombra non ci andrà sopra. Questo sistema può andare bene per i giochi di calcio, dove le ombre dei nostri miliardari preferiti sono proiettate praticamente sempre e solo sul piano di gioco.

Shadow Volumes

Carmack le ha amate. Non è il solo, c’è anche Starbreeze che ama questa tecnica: sia Chronicles of Riddick che The Darkness usano questo sistema.

Vediamo come funziona: per prima cosa supponiamo di avere il nostro modello 3d (tipo un pallone) ed un piano comunque modellato (cioè non una formula matematica, ma proprio un modello 3d a forma di piano). Ci mettiamo su anche un muro. Ora mettiamo una luce in modo che l’ombra cada sia sul piano che sul muro.

Fatto questo, ci sono da fare tre passaggi:

1) Si disegna la mesh, tirando tutti suoi vertici che “non guardano” la luce molto in là. Questo creerà un volume (da qui il nome della tecnica) che noi speriamo intersechi tutti gli oggetti della scena. In questo passaggio diremo all’hardware di disegnare solo i triangoli che guardano in camera (diciamo quelli “davanti” e non quelli “dietro” alla nostra palla)

2) Si fa un’altra bella passata, disegnando quelli “dietro”. Queste passate non vengono fatte sullo schermo, ma su una struttura chiamata “Stencil buffer”. In pratica lo stencil non si becca il colore, ma se qualcuno scrive su un dato pixel, lui somma “1″ al valore di quel pixel. Così sappiamo se qualcuno ha scritto lì.

In seguito “aggiungiamo” la prima “passata” allo stencil, mentre “sottraiamo” la seconda; ci rimarrà così nello stencil una pletora di numerelli che rappresentano proprio l’ombra.

Fatto questo, disegnamo un bel quadratone scuro su tutto lo schermo, premurandoci di dire all’hardware di disegnare solo dove lo stencil è diverso da 0. Così facendo disegneremo la nostra ombra perfetta.

Problemi: in primo luogo dobbiamo disegnare l’oggetto tre volte: una volta per farlo vedere normalmente ed altre due per lo stencil. Fortunatamente qui l’hardware ci viene in soccorso: le moderne schede fanno le due passate in un colpo solo.

Però se vogliamo farlo su tutti gli oggetti della scena, dobbiamo farlo con tutti gli oggetti. Se lo facciamo anche al mondo, siamo fritti. Ma non è finita qui: se inizio a proiettare questi volumi in maniera massiccia, rischio di saturare tutta la sezione finale della pipeline, quella che disegna i pixel, perché in pratica devo disegnare una quantità esagerata di pixel (nello stencil) a causa di questi volumi. Quindi abbiamo due colli di bottiglia.

In più ci sono problemi con modelli molto poco densi poligonalmente, oppure con forme allungate (come un parallelepipedo bello allungato).

Questa tecnica è stata usata fondamentalmente solo da Doom3 (e da chi usa il suo motore) e dai giochi Starbreeze, poiché presto si è rivelata inadeguata: oltre ai due colli di bottiglia, presenta enormi difficoltà a fare ombre sfumate sui bordi (la cosa richiederebbe ulteriori passate. C’è una demo ATI che lo fa in 16 passate :D ).

Shadow Map

Questa tecnologia è quella che al momento risulta più studiata in assoluto: in genere in tutti i seminari sulla computer grafica sono presenti delle dimostrazioni dei passi avanti compiuti utilizzando questa procedura.

Come mai? In primo luogo la tecnica dello shadow mapping è di base più leggera: richiede solo un rendering in più oltre a quello standard. Richiede però un hardware capace di fare conti per vertice e per pixel. I pixel shader, per intenderci. Qualche anno fa (diciamo il 2000, la prima volta in cui lessi di questa tecnica) questo poteva essere un limite, ma oggi non più.

Il sistema basilare funziona così:

1) Facciamo il rendering della nostra scena.

2) Facciamo il rendering della scena, mettendo la camera dove sta la luce ed angolata nella stessa direzione di questa.

A questo punto confrontiamo gli Z-Buffer dei due rendering: se lo Z-Buffer della luce in un dato punto è minore (o maggiore, a seconda della piattaforma) dello Z del rendering normale, allora quel punto è in ombra.

Spiego velocemente cos’è lo Z-Buffer: è una superficie grande come lo schermo (se lo schermo è 1.024 x 768, allora anche lo Z-Buffer è 1.024 x 768). In questa superficie viene salvato il valore della coordinata Z di uno punto sullo schermo. La coordinata Z è la profondità. Questa superficie serve per fare lo Z-Test: quando disegnamo qualcosa sullo schermo, prima di farlo, controlliamo lo Z-Buffer. Se lo Z che vogliamo scrivere è minore (o maggiore; comunque più “vicino” alla camera) di quello che c’è già scritto, allora vuol dire che il punto che vogliamo scrivere è visibile perchè non c’è niente davanti. Se no, no. Questo ci consente di disegnare gli oggetti nell’ordine che vogliamo, senza che quelli disegnati dopo coprano quelli disegnati prima.

Dicevamo che la tecnica dello shadow mapping consiste fondamentalmente, quindi, nel disegnare dei punti derivati da una elaborazione dello Z-buffer.

Per fare questo, però, dobbiamo disegnare il mondo anche dal punto di vista della luce: operazione che si effettua su di una texture. Ovviamente, più questa texture è grande peggio è. Fortunatamente a noi interessa lo Z-Buffer di quel rendering, quindi possiamo anche disegnare tutti gli oggetti bianchi, senza pixel shader. Quando si fa così, gli hardware moderni fanno fare al rendering una specie di “corsia preferenziale”, saltando un bel po’ di stage nella pipeline, andando velocissimo.

Quali sono i problemi? Ci sono delle angolazioni sfortunate, che danno un sacco di problemi (li notate bene bene in Devil May Cry 4). In più ci sono sempre delle angolazioni cha fanno vedere i pixelloni giganti (lo notate bene sempre in Devil May Cry 4 :D). Nonostante questo, la ricerca continua perchè mediante questa tecnica è possibile fare delle buone ombre sfumate sui bordi (ne vediamo degli esempi in Crysis e GTA4), oltre che, mediante modifiche e moglioramenti, di fare delle buone ombre su tutti gli oggetti in scena.

Ma perchè ancora ad oggi le ombre non sono bellissime come quelle vere? O almeno come quelle nei film di animazione in CG?

Perchè ovviamente anche fare i conti di cui sopra costa. Quando fare le ombre inizia a costare, diciamo 5 millisecondi, allora può darsi che inizi a costare troppo. I rendering per quei film prendono bel più di 5 millisecondi :D

Al momento il top della tecnologia è Crysis e ci mostra ombre di certo belle, ma con questi difetti:

  • Non è molto diversa la sfumatura tra oggetti lontani ed oggetti vicini
  • Qualche problema di aliasing sugli oggetti lontani
  • Puntini e dithering piuttosto evidenti da vicino
Perchè tutto questo? Perchè altrimenti non ci starebbe dentro con i tempi.
La ricerca prosegue sempre, e se solo confrontiamo le ombre di GTA4 con quelle di Assassin’s Creed notiamo un enorme incremento.
Quanto dovremo aspettare per non vedere più i puntini ed avere delle ombre perfette, magari da più sorgenti di luce e con un diverso grado di sfumatura? Non molto: le ombre sono uno dei campi più studiati della grafica real-time, quindi stimo che entro tre anni il problema dei puntini sarà sparito: credo che un aumento dinamico dei conti che si fanno per farlo possa ridurlo moltissimo, ma per eliminarlo bisognerà pensare in un altro modo, ad esempio un post processing dell’ombra stessa. Tutto questo richiede altro tempo, che al momento non c’è.
Non esiste niente di definitivo, quindi, per quanto riguarda questo argomento. Ma siate fiduciosi :)

Everyday Shooter

        Saturday, 10 May 2008, 7:00 - Simone "Karat45" Tagliaferri

Prodotto e sviluppato da Queasygames | Piattaforme PC | Rilasciato nel 2008

La sensazione è di scuotimento e di distanza.

All’inizio vieni pervaso da un leggero fastidio, poi comincia l’ipnosi e lo schermo vibra ripetutamente.

Non sai perché sei qui. Anzi, non sai e basta.

L’idea è quella dell’informe, ma le forme sono ben visibili e la musica ha un senso nella sua melodiosa, stonata e piacevolissima casualità.

Sei tu che suoni. È un simulatore di chitarra?

Sei tu che deformi lo scenario? È un clone di Photoshop?

Viene subito in mente Galaxy Wars. Ma qui c’è molta più radicalità e consapevolezza. Non ci sono galassie, solo quadri in movimento che si attorcigliano e rimandano vibrazioni auditive.

Mondrian sotto acido?

Vedi quella linea sullo schermo? Sembra un elastico. Tiralo e il mondo apparirà pulsante in un perpetuo raschiare dalla visibilità infetta.

Visione visiva e sonora, piena di VISUONI e viste inattese.

Si può rimanere abbagliati e per questo ci si lascia andare al suono. Forse l’approccio giusto per comprenderlo è quello di Artaud davanti a Van Gogh.

Eh sì che lo guardi fisso ma devi immaginarlo nella sua scomposizione matematica degli eventi.

Cos’è che guido con il joypad? Un quadrato? Un rettangolo? Un rombo? Un quadrilatero qualsiasi?

Everyday Shooter può essere descritto solo al participio. Anzi, non può proprio essere descritto perché se ti metti lì a ridurlo lo ammazzi, gli dai una coltellata nel codice che schizza via in ogni angolo dello schermo e poi della rete.

Descriverlo lo farebbe diventare un errore di sistema, degno soltanto di una segnalazione a Microsoft. Cosa è successo?

SITO UFFICIALE

PAGINA DEL GIOCO SU STEAM

Link per questo post: OKNOtizie

Orizzonti Lontani

        Tuesday, 6 May 2008, 7:00 - Monopoli

Oggi mi piacerebbe discutere con voi di una tematica piuttosto complicata: quella dei famosi “spazi aperti”.

Sulle riviste e sui forum si discute di quale sia il gioco con gli spazi più ampi o di quale engine sia più capace di fare cosa.

Ma come facciamo a capire quando uno “spazio” è ampio?

In primo luogo cerchiamo di capire la problematica: perchè disegnare uno spazio ampio è un problema?

Per due motivi:

  • Grande quantità di poligoni
  • Grande quantità di materiali
Perchè ho scritto “materiali” e non “texture”? Perchè la texture non è l’unica cosa che appesantisce la pipeline di rendering: anche un semplice cambio di stato la appesantisce.
Possiamo quindi definire un gigantesco quadrato con sopra una texture uno “spazio ampio”?
Dal punto di vista letterale, sì, ovviamente: il quadrato è enorme. Per questo è più corretto utilizzare il termine inglese “Large Environment”, che in sè condensa la grande dimensione dal punto di vista del dato, rispetto al punto di vista visivo.
Purtroppo questo punto è molto difficile da capire, quindi insisterò maggiormente per far capire cosa intendo.
Prendiamo una cartolina qualunque:Champoluc
Questa è una foto della mia amatissima Champoluc vista dall’alto. Proviamo ad immaginare di dover fare il rendering in tempo reale di questa immagine.
Facciamo finta che ogni casa sia modellata in maniera realistica, con circa 25000 poligoni e 3MB di texture.
Possiamo facilmente intuire che questa scena (solo con le case) prevede circa 1.000.000 poligoni e 120 MB di texture.
Se solo ci fossero le case, la scena sarebbe già abbastanza pesantina. Aggiungiamoci gli alberi (saranno almeno trecento), aggiungiamoci l’illuminazione e il terreno ed ecco che abbiamo una scena che non può essere in alcun modo presentata così com’è alla scheda grafica.
In più consideriamo che, se fosse un gioco, non potrebbe esserci solo questo: appena giriamo la testa dovrà esserci tutto il resto del mondo.
Possiamo quindi già tirare una conclusione: qualunque engine potrebbe mostrare ambienti ricchissimi, se avesse a disposizione un hardware potentissimo.
Quindi: come facciamo a mostrare una scena come quella sopra ad un framerate di (diciamo) 30 fps?
In primo luogo dobbiamo capire cosa significa “30fps”: significa avere circa 32 millisecondi ad ogni frame.
Non molto.
30 fps x 1.000.000 = 30.000.000 di poligoni
Un po’ tanti.
Consideriamo che non abbiamo tutti i millisecondi per noi: c’è anche il gioco in sè che vuole la sua parte.
Ok, possiamo partire a valutare i problemi:

TEXTURES e MATERIALI

Il problema è talmente noto che la soluzione è già stata trovata da quando si fa grafica in tempo reale.
La prima scrematura si fa sulla distanza: perchè usare le texture 2048×2048 quando le case sono così lontante? Basta usare texture 256×256. Facendo così, si riduce drasticamente il tempo di campionamento delle texture.
Questo si chiama “Mipmapping” e non funziona solo sulla lontananza dall’oggetto, ma anche dalla sua posizione rispetto alla camera: più l’oggetto è “di sbieco” più la texture utilizzabile è piccola.
Perfetto, ma questo non basta: una singola casa ha un bel po’ di materiali (il tetto innevato, le finestre, il legno, il muro). Ognuno di questi materiali avrà dei parametri, delle texture e degli stati hardware da settare.
Per ridurre il cambio di stati, possiamo raccogliere per bene tutti gli oggetti col medesimo materiale e disegnarli tutti assieme.
Alcune architetture sono terribilmente più veloci se si riduce il numero di chiamate alla funzione di render, ma passando tanti triangoli: potremmo fare anche così. Questo non è banale per nulla, quindi se decidiamo di farlo, dovremo essere certi che l’architettura sulla quale lavoriamo ci fornisca un boost molto ampio.
Il PC in generale è una di queste architetture, per esempio.

Numero di Primitive

Parlando terra terra, una primitiva è un triangolo. Non è sempre così (OpenGl ad esempio prevede triangoli, punti, linee, quadrati e poligoni), ma possiamo facilmente dire che è così nel 99% dei casi.
La regola principale nel campo della computer grafica è: il modo più veloce per fare una cosa è non farla.
Quindi: qual’è il modo più veloce per disegnare un sacco di triangoli? Risposta: disegnarne pochi.
Ma come possiamo fare? Nella storia ci sono state mille e mille soluzioni. Vediamone qualcuna:
- Riduzione del livello di dettaglio: se un oggetto è lontano, possono bastare pochi poligoni per descrivere la sua forma, rispetto a quando è vicino. Ci sono algoritmi che riducono il numero di poligoni in tempo reale (algoritmi “continui”) oppure è possibile utilizzare N modelli 3D prefabbricati, con sempre meno triangoli (algoritmi “discreti”).
- Eliminazione degli oggetti fuori dal campo visivo: se un oggetto non è nel campo visivo (frustum) si può evitare di mandarlo in rendering. il controllo si chiama “frustum test” ed in genere si fa per oggetto.
- Eliminazione dei triangoli fuori dal campo visivo: questo punto si differenzia dal precedente perchè la precisione scende al triangolo. Tal sorta di test si fa in genere su modelli 3d di grandi dimensioni (come i terreni o gli ambienti), che altrimenti sarebbero sempre in camera e sarebbero sempre disegnati per intero, poiché ben più grandi di quello che la camera può vedere. Per risolvere questo problema ci sono varie soluzioni, come gli OctTree, una struttura dati che consente di partizionare lo spazio e di fare velocemente i conti per decidere “chi è dentro e chi è fuori”, oppure il “Potential Visible Set“, un sistema che divide (in preprocessing) tutto il mondo in blocconi e decide quali oggetti siano visibili nei vari settori. Se un triangolo non è mai visibile, potrebbe essere semplicemente eliminato dalla scena.
- Eliminazione dei triangoli coperti da altri triangoli: Il test che si compie, in questo caso si chiama “Occlusion Test” o “Visibility Test”. Un sistema per eseguirlo è utilizzando i “Binary Space Partition Trees”, amati da sempre da Id Software.
Ognuno di questi sistemi (più i mille altri che non ho citato) servono ad evitare di disegnare tutto ciò che non serve, in modo da mandare alla scheda grafica la quantità minore di triangoli (od oggetti) possibile.

Oggetti Ripetuti

Se guardiamo la scena, notiamo che ci sono una quantità troppo elevata di alberi. Da soli, questi alberi, rischiano di prendere interamente tutto il tempo che abbiamo per fare il nostro rendering. Come fare?
Qui abbiamo fondamentalmente due soluzioni, a seconda dell’hardware che abbiamo a disposizione: se l’hardware supporta l’instancing, possiamo mandare un singolo modello 3d di albero, seguito dalle informazioni necessarie per il rendering per ogni albero che vogliamo. Ad esempio, possiamo mandare l’albero e poi cento posizioni diverse, così l’hardware disegnerà questo albero cento volte in queste cento posizioni.

Conclusione

Dopo tutto questo articolo, cosa possiamo dire? Possiamo dire che se un engine non supporta tutte queste feature, allora non supporta gli spazi aperti? No, non possiamo dirlo.
Perchè? Perchè se abbiamo un megaPC pazzesco, con tantissima RAM ed una scheda grafica pazzesca ed immensa, possiamo completamente ignorare tutti i problemi di cui sopra e mandare alla scheda quei 30 milioni di triangoli al secondo, oppure quei gigabyte di texture, tanto il sistema è potente e reggerà il colpo.
Il problema, per i progettisti, è pensare a dei sistemi per far girare questi ambienti su computer esistenti.
Proviamo a pensare a “Grand Theft Auto San Andreas”: non voglio nemmeno immaginare da quanti poligoni e texture sia composto il mondo. Nonostante questo, gira su una PS2 a 30 fps (o 60?). Se tutte queste tecnologie non fossero implementate, non girerebbe mai su una PS2.
Quindi, ora, sapendo questo, poniamoci questo quesito: ha senso chiedere se un engine supporta gli spazi aperti? Viste le migliaia di possibilità dietro questa domanda, io dico di no.
Ha senso, allora, chiedere quanti poligoni e che mole di texture può disegnare un dato engine con un dato PC garantendo i 30 (o 60) fps? Questa domanda ha molto senso, ma capirete bene che non è un equivalente della precedente: se dieci anni fa 500.000 triangoli e 100MB di texture per tutto il mondo potevano essere un “Large Environment”, oggi come oggi questi numeri sono decisamente cambiati.
Quindi, quando vi trovate in una discussione sulla capacità o meno di un engine di disegnare i dannatissimi spazi aperti, cercate sempre di capire con chi state parlando: se è un giornalista o un videogiocatore fanatico del PC, allora molto probabilmente sarà meglio non entrare nemmeno nel discorso :)

Link per questo post: OKNOtizie

Dissonanze

        Saturday, 3 May 2008, 12:21 - Simone "Karat45" Tagliaferri

L’ultima volta che sono sobbalzato ascoltando una “colonna sonora” (da intendersi riferita a tutti i suoni presenti all’interno di un videogioco) videoludica è stato con Thief: The Dark Project. Non si trattò di tensione o di bellezza delle musiche. Fu un sobbalzo dovuto alla novità, alla sperimentazione di una nuova forma di gameplay, e al convincermi che la tecnologia abbia un senso se usata in modo intelligente e innovativo.

Da allora non credo che di aver più udito niente di così “fresco” (forse giusto Electroplankton
per Nintendo DS).

Intendiamoci: di videogiochi con colonne sonore belle è pieno il mondo. Gli effetti sonori si sono fatti sempre più raffinati e ormai il rombo di un’auto virtuale o il rumore prodotto da una mitragliatrice sono simili alla controparte reale. Talmente simili che sentendo il rumore di un mitra nella realtà ci si potrebbe chiedere perché non emetta lo stesso identico suono di quello adoperato nel’ultimo titolo guerrafondaio appena finito.

Da profano immagino che anche le tecnologie audio vadano sviluppandosi di pari passo con quelle grafiche e con tutte le altre presenti all’interno di una macchina da gioco qualsiasi. Il problema è che se ne parla poco e, soprattutto, è difficile sentirle “in gioco”. In effetti tanto è vero che siamo pieni di “parole marketing” attinenti alla grafica, che non capiamo ma che amiamo leggere sulle confezioni o nelle anteprime, tanto mancano parole comuni per descrivere le tecnologie sonore, tranne che per la presenza di alcune espressioni generiche che si adattano più o meno ad ogni contesto (il sonoro è avvolgente, non è avvolgente, crea una buona atmosfera, rovina l’atmosfera e via di questo passo).

Ma non è questo il punto. Il punto è che si procede per privazioni. Il sonoro, con la decadenza del genere stealth, sembra “uscito fuori dal gameplay” e spesso, troppo spesso, la colonna sonora di un videogioco si limita ad essere un piacevole accompagnamento che non prova ad aggiungere altro all’esperienza ludica.

Parlo da profano, ma credo che bisognerebbe sperimentare di più dal punto di vista sonoro (genere permettendo), lavorando sui suoni e sui rumori ed evitando gli accompagnamenti standard (per fare un esempio la musica epica nei combattimenti dei videogiochi fantasy… sarà anche coinvolgente, ma ci sono molti modi per descrivere l’audio di una battaglia e le tecnologie permetterebbero di sperimentarli senza perdere appeal commerciale).

Ovviamente sarei felicissimo di ricevere indicazioni su colonne sonore interessanti che avete sentito all’interno di qualche videogioco e che mi sono perso. Anzi, magari potremmo compilare una lista con le migliori colonne sonore, bellezza delle musiche prescindendo, da tenere in archivio da qualche parte.

Link per questo post: OKNOtizie

Perfect Score

        Friday, 2 May 2008, 16:20 - Simone "Karat45" Tagliaferri

Amico fanatico dell’Xbox 360 (chissà se si degnerà mai di leggere questo blog): “GTA IV è un cazzo di capolavoro, è molto meglio di Halo 3.”
Io: “Ma Halo 3 non era il meglio del meglio che meritava il suo 10 a mani basse?”
Lui: “GTA IV è meglio. È da 10. Anzi è da oltre 10.

Questa battuta mi ha fatto sorridere. Sostanzialmente mette fine a tutte le polemiche sull’utilità dei voti numerici e sul loro valore effettivo. Soprattutto rende evidente l’assurdità dei perfect score (in questo caso intesi come i voti più alti assegnabili con un dato sistema di valutazione, ad esempio 10/10 o 100%) che, a parte sottolineare l’eccellenza di un tal prodotto, confondono e fanno partire un gioco al rialzo senza fine.

Se un gioco da 10 è migliore/diverso di un altro gioco da 10 come si fa ad accettare logicamente che entrambi abbiano un 10 a rappresentarli?

Un altro paradosso è che la valutazione massima ottiene l’effetto di sottolineare più i difetti dei pregi, come avvenuto nel caso di Halo 3 e come sta avvenendo con GTA IV (che non giudico in mancanza di una prova su strada) che porta molti a chiedersi come faccia a prendere 10 (100, ABC, cinque Emack d’oro e così via) un gioco con anche un solo difetto. Ad esempio molti hanno sottolineato come l’ultima fatica della Rockstar sia strutturalmente identica ai precedenti capitoli, cosa a cui non fatico a credere.

È paranoia, certo, ma è una paranoia che nessuno s’impegna a mitigare e che, anzi, non si fa altro che alimentare con l’abuso di perfect score e recensioni sperticate negli elogi, che sembrano scritte più da un addetto del marketing che da “critici” (sull’esaltazione infantile del redattore-tipo esperto di videogiochi andrebbe scritto qualcosa a parte) formati e capaci di discernere ed indirizzare il lettore.

Link per questo post: OKNOtizie

Dubbi paranoici di un giocatore davanti ad una porta

        Monday, 28 April 2008, 17:53 - Simone "Karat45" Tagliaferri

E se passando quella porta morissi per colpa di una trappola?

E se passando quella porta venissi attaccato da un mostro troppo forte per il mio personaggio?

E se passando quella porta rimanessi incastrato?

E se passando quella porta mi venisse sottratto tutto l’equipaggiamento?

E se passando quella porta scoprissi un altro tassello della trama rovinandola completamente?

E se passando quella porta venissi disintegrato da un incantesimo?

E se passando quella porta s’impallasse tutto?

E se passando quella porta finissi in un baratro senza fondo?

E se passando quella porta perdessi i salvataggi?

E se passando quella porta fossi costretto a tornare indietro?

E se passando quella porta…

Ma sì, meglio caricare un altro gioco.

Perché dietro una porta, qualcosa c’è sempre.

La foto è di: gi varga

Link per questo post: OKNOtizie

Wii Fit ci salverà

        Thursday, 24 April 2008, 18:52 - Simone "Karat45" Tagliaferri

Avanti obesi onanisti dal culo a chiatta piena di mondezza! E’ arrivato il vostro momento! Alzate le budella appesantite dagli anni in cui siete rimasti inerti davanti allo schermo.

Fino ad oggi avete creduto di potervi infilare in qualche mondo fatto di vettori e pixel per salvare regni, principesse, voi stessi e il vostro cane. Tutto quello che avete ottenuto è una panza da fare schifo ai cammelli orbi della Tunisia.

Alzatevi dalle vostre sedie sudaticce come le vostre natiche e iniziate ad agitarvi come salcicce sul girarrosto. E’ l’ora della riscossa! Dimostrate che non vi piace soltanto guardare film porno masturbandovi mentre mangiate patatine al formaggio!

Oggi anche voi entrate a far parte della società, perché la società è entrata a far parte di voi decidendo di farvi dimagrire!

E un, due, tre
e un, due, tre.

Non lo avete capito che fate schifo e che la vostra vita non ha avuto senso? Avete amato i videogiochi per arrivare alla rivelazione: siete degli esseri inutili che hanno sempre puntato sul cavallo sbagliato.

Tu che mi guardi basito con in mano Wii Diet, la dietà interattiva che picchia i carboidrati usando i Mii. Tu che hai in mano un joypad, residuato di un modo di concepire i videogiochi da sfigati cronici capaci soltanto di scaccolarsi combattendo contro qualche boss di forma fallica… sì, proprio tu.

Guardami e pensa alla tua nuova vita. Pensa a quello che sei e a quello che potresti diventare e gioisci! Wii Fit è qui!

Link per questo post: OKNOtizie