Forza Motorsport 2

Sviluppato da Turn 10 Studios | Pubblicato da Microsoft Game Studios | Piattaforma Xbox 360 | Rilasciato l’8 giugno 2007 (EUR)

Ritengo i titoli automobilistici provvisti di velleità simulative la miglior implementazione ludica del meccanismo della perseveranza: sfruttando lo spirito agonale del giocatore, lo si invoglia ad un costante labor limae per realizzare prestazioni sempre migliori e soverchiare gli avversari. L’abnegazione da parte dell’utente è fondamentale, così come lo è la facoltà di padronanza delle variabili razionali che caratterizzano il setup di un veicolo da corsa. Il determinismo con cui si prepara la vettura toglie aleatorietà all’esito della gara: l’intera responsabilità è lasciata al lavoro di preparazione svolto dal pilota virtuale, mentre i colpi di fortuna sono spinti ai margini dell’esperienza corsaiola. Si potrebbe obiettare che anche un Pac-Man o un Tetris soddisfino molti dei requisiti appena elencati, ma va comunque considerato che sono privi della necessaria sovrastruttura atta a rendere le sessioni di gioco ancora più addictive e maggiormente bilanciate verso la razionalità piuttosto che verso i riflessi. La pista, insomma, è il palco dove inscenare la migliore interpretazione motoristica di cui si è capaci.

Forza Motorsport 2 è stato il primo videogioco rilasciato per Xbox 360 a proporre un plausibile modello simulativo pur essendo provvisto, comunque, di una curva d’apprendimento decisamente dolce. L’offerta non esula dalla classica formula che prevede una vagonata di auto (oltre 300 – dalle lente berline agli audaci prototipi) naturalmente potenziabili in varie parti (motore, freni, telaio, trasmissione, appendici aerodinamiche, pneumatici e via discorrendo), una serie di tracciati (14, molti ispirati da piste reali come quella del Mugello e alcuni inventati di sana pianta, come quello di New York) proposti in varie configurazioni, e l’uso di uno schema “a livelli” attestante il grado di esperienza e di carriera maturati. Anche le modalità di gioco non si discostano dai canoni (le solite coppe a tema, le gare singole di durata, esibizioni veloci, multiplayer online e locale in split-screen).

Sulla pista il comportamento dei bolidi appare direttamente proporzionale alle abilità di guida (questo è ovvio) e all’assetto elaborato (questo invece è un po’ meno ovvio), senza però imporre la ricerca di tecnicismi spinti per realizzare una buona prestazione. La bravura dei designer è consistita proprio nel fornire, all’interno di uno stesso contesto videoludico, approcci multilivello: se per marcare un tempo decoroso è sufficiente modificare appena parametri di facile approccio (quali la pressione delle gomme, la lunghezza delle marce e il carico aerodinamico), per limare altri decimi preziosi alla ricerca del giro perfetto bisogna manipolare con criterio financo il più piccolo particolare. Gli errori, quali gite non programmate sui prati e collisioni assortite, si pagano sotto forma di penalità sui tempi (secondi sommati al tempo effettivo del giro incriminato) e sul portafoglio (più si sfascia la macchina meno crediti formeranno la ricompensa).

Il modello dei danni contempla tutte le aree sensibili (carrozzeria, braccetti, motore, cambio, gomme) e, se impostato su “simulazione”, inficia notevolmente le potenzialità del mezzo, fino ad annullarle del tutto mediante un mesto motore spento e ritiro obbligatorio. Nelle gare di durata occorre tener d’occhio anche usura delle gomme e consumo di benzina, fattori che rendono necessario almeno un pit stop (per niente spettacolare, e dire che già in Grand Prix 4, uscito nel 2002, era stato fatto un lavoro migliore in tal senso) dopo una quindicina di giri. A tal proposito si percepisce una grande lacuna anche nell’impostazione di una strategia nel long-run: semplicemente non v’è modo di effettuare una efficace programmazione giocando proprio sulla qualità degli pneumatici e sulla quantità di carburante imbarcato. Un gran peccato, per un titolo del genere.

La vastità del pantheon di auto lascia decisamente soddisfatti, come pure il processo, virtualmente infinito, di customizzazione delle stesse; oltre al già citato schema di potenziamento è possibile editare graficamente il mezzo mediante un tool apposito. Non è raro, pertanto, affezionarsi a un particolare veicolo (tra l’altro, l’affetto è premiato nel gioco con l’incremento della reputazione e con la conseguente possibilità di usufruire di sconti e vantaggi da parte delle rispettive case madre). Non è però possibile esprimere analogo giudizio nei confronti dei tracciati presenti, decisamente troppo pochi e troppo uniformi tra di loro. Manca una certa eterogeneità di genere, che permette una diversificazione realmente spinta degli stili di guida. Sul versante tecnico, ad ogni modo, il lavoro compiuto in questo ambito è senza ombra di dubbio perfetto; ciò che latita è il carattere, insomma (sebbene la presenza della leggendaria Nordschleife valga da solo il prezzo del biglietto).

La ragione per cui Forza Motorsport 2 non verrà ricordato a lungo è la sua mancanza di personalità. Mi spiace constatare come il titolo dei Turn 10 sia tanto solido e compatto quanto povero di innovazioni in termini di emozioni e di strategie. Gradito sarebbe stato anche un sistema di condizioni meteorologiche variabili, che sicuramente avrebbero innalzato il coefficiente di difficoltà e contestualmente “costretto” il videogiocatore ad una maggiore versatilità. L’esperienza ludica è notevolmente polarizzata verso la prestazione secca del giro singolo, premiando dunque la fatuità piuttosto che la costanza (problema questo che viene mitigato se gli avversari sono esseri umani sufficientemente agguerriti). Non resta che sperare in un terzo capitolo della serie, peraltro già in lavorazione, per assistere ad un vero capolavoro.

(Dis)informazione videoludica: la parola a Marco Accordi Rickards

Marco Accordi Rickards, giornalista ed editor di Game Pro, è uno dei principali attivisti e sostenitori della cultura videoludica in Italia. Il suo impegno lo ha portato ad essere il direttore culturale di GameCon, unica fiera-convention italiana interamente dedicata ai videogiochi e al loro sviluppo, nonché a tenere conferenze sul territorio nazionale in diversi eventi tematici.
Abbiamo deciso di intervistarlo, per capire meglio quali possono essere i principali elementi di ostacolo a una corretta informazione videoludica.

read more

MMO in breve, free edition

Adventure Quest: Massivo in differita.

Crossfire: Se fosse il 1982, sarebbe la prova vivente che basta un’iniziativa Open Source per creare un MMOG decente.

Dungeon Runners: Non tutti i lanci rimandati di mesi si confermano come sonori fallimenti.

Exteel: Gundam giganti. Customizzabili.

Maple Story: Konami! Svegliaaa! Voglio Castlevania Online!

MegamekNET/MekWars: Non è mica detto che un MMO non possa essere a turni e basato su un gioco da tavolo.

Mythos: Ah! Allora qualcuno che in Blizzard aveva esperienza di videogiochi lo hanno assunto!

Ogame: Sì. Si possono creare giochi massivi interamente basati su bug, regressioni e svarioni di design.

Rubies of Eventide: Che ci crediate o no anni fa c’era la pubblicità su Dragon Magazine di questo MMOG dalle idee mooolto confuse.

Runescape: Do more with less.

Silkroad Online: Perché pagare un abbonamento per essere gankati?

The Crims: GTA in versione Naif. Funziona quasi meglio dell’originale.

Tibia: Pixel art con gli steroidi.

Travian: Non che abbia inventato il genere dei MMOBG ma è sicuramente il più professionale e ben gestito che c’è in giro.

Wyvern: Perché non tutti si vergognano a farsi chiamare ancora MUD.

Esaminando Muslim Massacre

Ogni guerra santa è prima di tutto una guerra culturale in cui, più che uno scontro di civiltà contrapposte, scendono in campo le rispettive ottusità dandosi battaglia in nome di principi astratti e distanti. I periodi di crisi economica e culturale sono fertilissimi per l’affermarsi degli assolutismi e il nostro non fa certamente eccezione. Senza addentrarci troppo in questioni che esulano dall’ambito di Ars Ludica in quanto tale e che meritano sicuramente un approfondimento maggiore in altre sedi (e con altre persone), esaminiamo uno dei frutti del clima di odio culturale degli ultimi anni: Muslim Massacre.

Si tratta di un’arena shooter con la grafica che sembra rippata da Cannon Fodder in cui lo scopo del giocatore è quello di massacrare terroristi islamici. Fin qui niente di originale, verrebbe da dire, il solito gioco di propaganda filo USA. A renderlo interessante sono alcuni elementi che meritano di essere esaminati.

Il primo è il suo essere un gioco freeware, un progetto amatoriale quindi, ovvero di essere stato “pensato” in assoluta libertà rispetto a logiche commerciali. In questo senso stupisce la realizzazione di un prodotto “così” convenzionale e conservatore, privo di qualsiasi slancio anarchico sia a livello di gameplay che a livello tematico. Ma questa è una caratteristica comune a molti titoli freeware che, spesso, non vanno oltre l’esercizio di programmazione e il tentativo di copia della fonte di ispirazione degli sviluppatori, qualsiasi essa sia (non è una critica, sia chiaro, è una constatazione).

Il secondo elemento interessante è il background culturale che lo ha prodotto e che è intuibile sin dal titolo. Senza nessuna mediazione lo sviluppatore ha scelto di essere il più esplicito possibile: “Muslim Massacre”. Bando a qualsiasi generalizzazione, quindi. Non bisogna massacrare dei terroristi e nemmeno un esercito nemico, bisogna semplicemente massacrare dei musulmani. Certo, avviando l’eseguibile uno slide show di prime pagine di giornali fasulli lascia intendere che il massacro nasce come risposta ad una bomba messa a Chicago da Al Qaeda, ma la sostanza non cambia granché, visto che il titolo è incontrovertibile e non lascia spazio alle interpretazioni: quelli che uccidiamo sono prima musulmani e poi, magari, terroristi… sempre che nella testa dell’autore le due cose siano scindibili (magari è solo un adolescente confuso che per pensare segue la sudorazione delle sue palle più che la ragione).
Esaminando le scelte stilistiche fatte per confezionare il gameplay (per un approfondimento CLICCA QUI), notiamo (seguendo l’ordine delle schermate come appaiono all’avvio):

il logo vagamente nazisteggiante dello sviluppatore;

la scelta, per i titoli dei giornali, di frasi che sembrano uscite dalla più squallida propaganda militarista;

la prima “M” della parola Muslim decorata con la bandiera americana, i colori scelti per le voci del menù (che riprendono quelli della bandiera) e il cursore a forma di missile;

la caratterizzazione estremamente gore dei nemici morti, che sembra più legata ad un particolare immaginario che ad un esame attento della realtà di un campo di battaglia reale; i vari nemici, che sembrano usciti da un manule di propaganda del perfetto terrorista (dal terzo schema in poi arriveranno anche i kamikaze); la presenza, in basso a destra, di una raffigurazione del soldato americano incredibilmente stereotipata, con tanto di canotta verde, con capelli biondi e occhi azzurri, con la sigaretta in bocca, con un tatuaggio raffigurante la bandiera americana sul braccio sinistro e con il braccio destro messo nella tipica posizione di chi sta mostrando i muscoli… manca solo la classica frase ad effetto (meglio non dare suggerimenti, comunque); la presenza di un contatore delle nostre vittime sopra l’immagine del soldato; e, infine, lo scenario estremamente stereotipato (la classica strada nel deserto… anche gli scenari successivi non sono da meno).

Pensandoci bene, però, c’è un solo dettaglio che rende questo gioco così sgradevole: la totale mancanza di ironia. Non c’è un momento dissacrante, o un qualcosa che faccia intuire un minimo di sarcasmo…

Oppure proprio questa ostentazione di tutti i luoghi comuni possibili e immaginabili è l’ironia che vado cercando?

E, ancora, se l’ironia fosse implicita nel fatto che qualcuno è riuscito a concepire un gioco del genere?

MUSLIM MASSACRE

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!

MMO in breve, reprise

Battlefield *: Che vi piaccia o no, una partita qui ha più giocatori dell’endgame-tipo di WoW. E i PG sono persistenti.

Dark Age Of Camelot: Massivo.

Dark Age of Camelot ITA: L’ignoranza è una brutta besta. Fa persino giocare un pugno di persone ad un titolo che ne richiedeva almeno 100 volte tante pur di non imparare l’inglese.

EVE Online: La schiavitù debellata? Migliaia di persone ogni sera pagano per fare i turni e la carne da cannone.

EverQuest: Uno degli elementi chiave del boom di Internet. In proporzione, oggi avrebbe avuto 50 Milioni di utenti solo in USA ed EU. Praticamente Matrix.

EverQuest 2: Mai mettere in discussione le scelte suicide di Sony, basta iniziare a giocare un annetto dopo.

Lineage: Diablo con gli steroidi.

Lineage II: Amore/odio. E farmer.

Marvel Universe Online: La dimostrazione che, se non hai un sacco di soldi, puoi fare delle scelte idiote senza pentirtene.

Pirates of the Burning Sea: RvR orientato alla conquista territoriale/commerciale come nessun altro. E con le condizioni di vittoria!

Planetside: Tribes. A pagamento!?

Star Wars Galaxies: Una community può uccidere un gioco. E portare rancore per anni senza averlo nemmeno più giocato, nonostante i developer siano riusciti a salvarlo.

Tabula Rasa: Basta solo capire che per fare un MMO di nicchia non è necessario sprecare milioni di euro per spiattellarci il nome di Garriot.

Vanguard: EverQuest 2, cinque anni fa (sì lo so che nemmeno esisteva, questo dovrebbe rendere l’idea).

Il combattimento in Age of Conan

AOC Logo

Molto spesso non basta avere delle ottime idee per produrre un ottimo design, anzi. Spesso troppe idee innovative possono avere l’effetto opposto di una modifica marginale su un modello di gioco più rodato e stabile. Age of Conan si trova in una situazione simile dal punto di vista del game design, in particolare per quanto riguarda il suo sistema di combattimento: i designer hanno voluto introdurre una serie di elementi rivoluzionari, il cui amalgama avrebbe dovuto produrre il sistema di combattimento definitivo.

Come vedremo, queste idee una volta introdotte nelle dinamiche di combattimento si sono influenzate a vicenda, ottenendo l’effetto di esaltare reciprocamente i rispettivi limiti, concependo un sistema di gioco tutt’altro che ottimale.

read more