FEROCIOUS °,..,°

Al Penny Arcade Expo, la fiera per il giocatore voluta da Jerry Holkins e Mike Krahulik, c’era anche un breve filmato del secondo episodio di Rain-Slick. Molti italiani, tedeschi, francesi e spagnoli vorrebbero seguire la storia dei loro eroi con i dialoghi tradotti in madrelingua. Secondo me il successo che ha riscontrato il gioco, con le vendite di giugno e luglio, avrebbe dovuto incoraggiare gli autori ad assumere esperti traduttori per internazionalizzare tutta la successiva serie di esilaranti gag dei protagonisti di questa caccia al gigantesco robot di New Arcadia. Ammetto che anch’io ho incontrato qualche problema a capire lo slang in certe situazioni, ma con un buon vocabolario di inglese potevo lo stesso farmi due risate. Ron Gilbert è tra i principali produttori di giochi di avventura per computer. Agli inizi di quest’anno ha assunto l’importante incarico di direttore creativo negli studi di Hothead Games a Vancouver, in Canada. L’apice della carriera l’aveva già raggiunto quando lavorava con LucasArts. Ora Ron sta lavorando su un altro gioco a episodi, intitolato DeathSpank che poi è il nome del personaggio principale apparso anche sul suo blog; sta tentando di far incontrare il suo vecchio capolavoro Monkey Island con il celebre Diablo, ovvero l’avventura e il gioco di ruolo. A me sembra una buona idea, perché questi generi sono trascurati su Linux, soprattutto i giochi di un certo spessore artistico vengono a mancarci.

• Multiplatform support for DeathSpank

L’evento tessano si è concluso domenica con pochi annunci clamorosi rispetto all’edizione del 2007 e l’assenza di Crusader tra i giornalisti inviati a documentare le quattro giornate non ha permesso di focalizzare chiaramente la situazione dello sviluppo dei nuovi giochi di id Software su Linux. Leggendo attentamente le interviste rilasciate ai più importanti network da chi curava i rapporti con la stampa, non si trovano né conferme né smentite ai propositi, esposti negli ultimi due anni, di fare i ports. Pertanto si devono supporre ancora valide le vecchie ipotesi: Rage si può fare, Wolfenstein è pur sempre basato su id Tech 4, il motore grafico che spingeva Doom 3, Quake 4 ed Enemy Territory: Quake Wars. Sono tutti titoli portati a Linux dallo straordinario Timothee Besset, nel frattempo impegnato su Quake Live, altro imperdibile videogioco. Doom IV, a cui intendono dare un nome più evocativo con l’aggiunta di un sottotitolo al posto del numero di serie, probabilmente romperà i ponti con Doom 3 e riprenderà invece a raccontare la storia da Doom II (vd. Doom IV won’t actually be called Doom IV); forse sarà sviluppato con i caratteri del multiplayer di Quake Live, se quest’ultimo avrà successo, vale a dire: statistiche, buddy list, chat, replay delle partite, et cetera (vd. Doom 4 may leverage Quake Live system). Sia Doom IV che Rage gireranno su id Tech 5, engine dalle spiccate capacità di creare perfettamente vasti spazi esterni (outdoor) e che tradisce la passata attitudine dei programmatori a specializzare il sottosistema grafico con gli indoor. Inoltre c’è una differenza sostanziale: Doom sarà un gioco a 30 Hz, Rage a 60 Hz. Significa, secondo Carmack, che il primo avrà una maggior potenza a disposizione per presentare su ogni singolo fotogramma un livello di dettagli elevato rispetto al secondo. All’apparenza sembreranno due videogiochi progettati con engine completamente distinti. Per il momento esiste un prototipo, e dalla fine di agosto vi lavoreranno quindici persone.

Doom III aveva deluso, con le sue ambientazioni fosche e lo scripting ripetitivo della IA, persino molti ‘fidelizzati’ alla saga. Ma questa volta, per non frustrare le aspettative, il racconto, l’intelligenza artificiale e l’aspetto grafico di Doom IV verranno attentamente pianificati ed equilibrati per allontanare il minor numero di giocatori possibile. Intanto Rage è giunto a uno stadio avanzato di sviluppo, a giudicare dal video mostrato all’apertura della conferenza venerdì scorso, dai chiarimenti di Tim Willits, il direttore creativo del progetto, e dal discorso di Carmack che lo ha presentato. La sua storia è imperniata su una guerra post apocalittica del futuro, cinica e sinistra allo stesso tempo: gli abitanti del pianeta Terra sopravvissuti all’impatto di un meteorite, devono combattere contro pirati senza scrupoli, la fame e la carenza di carburante. Sono nemici molto diversi, ma ugualmente spietati. C’era un piano preparato dai governi per fronteggiare l’emergenza della catastrofe. Avrebbe riportato lentamente alla normalità la vita sociale e politica dei popoli, ma andò perduto, non si sa come. Il giocatore ha il dovere di aiutare i coloni a superare le avversità che di giorno in giorno si presentano. Le missioni possono prevedere un viaggio da un capo all’altro del deserto: in tal caso è libero di scegliere come spostarsi, a piedi o alla guida di un autoveicolo. Se incrocia dei banditi può affrontarli o scappare. Massima autonomia insomma (vd. id Software’s Tim Willits Talks Rage (PC)).

Mentre leggo la notizia di Phoronix, già fantastico sulle prestazioni del portatile che acquisterò alla fine di questo mese (devo scegliere fra MSI GX 700 o Toshiba X200). Non aggiungerò oggi nulla a quanto è stato già scritto altrove, a parte naturalmente parlarvi di alcune prove effettuate per conto mio con il nuovo Phoronix Test Suite (PTS) sull’attuale computer. Ammetto che l’argomento benchmark è piuttosto ostico, ma i software di questo tipo vengono in aiuto ai principianti perché permettono facilmente di svolgere comparazioni, confronti con altri dati statistici pubblicati sul web oppure semplicemente esaminare a fondo il PC alla ricerca dei punti deboli che compromettono il rendimento complessivo (valore importante per giocare bene). PTS è dunque una collezione di programmi per il Benchmark sotto Linux; non solo Phoronix li usa per i suoi test “interni”, ciò basterebbe come garanzia sui risultati, ma sono stati sviluppati seguendo anche i suggerimenti dei venditori di componenti hardware. Non voglio sminuire i progetti analoghi, anzi colgo l’occasione per ringraziare Encelo per avermi segnalato GL O.B.S. Mi occuperò anche del suo GL Open Benchmark Suite così come di SPECviewperf, questione di giorni perché devo prima conoscere a fondo una cosa per poterla trattare in maniera obiettiva e completa. Ma il mio contributo resterà pur sempre modesto, dovendomi limitare a riportare link ed opinioni da un blog così poco conosciuto. Mi dispiace soprattutto per gli addetti ai lavori, che non riceveranno una eco pari allo sforzo da loro compiuto.
Inizialmente ho avuto dei problemi di installazione ed esecuzione. La procedura non era chiara, speravo di trovare istruzioni precise nella directory per lanciarmi subito con i benchmark, invece conteneva solo informazioni essenziali: un README con i collegamenti al sito web, un TODO con la lista delle cose ancora da fare: scrivere la documentazione per esempio! Poi mi ha sorpreso il linguaggio di scripting php usato per l’esecuzione batch dei comandi. PHP rappresenta un emblema della portabilità dei programmi fra sistemi operativi, ma questa portabilità è veramente necessaria per i nostri scopi? Sì, se il confronto si deve fare fra Linux con Windows, Linux e FreeBSD o Solaris, ecc. Però siamo abituati a eseguire php sui server per creare e serverire pagine web anziché da linea di comando per mandare in esecuzione le applicazioni. L’impatto del software di benchmark sulla memoria di sistema e sull’elaborazione è cruciale. Forse anche sotto questo punto di vista l’interprete php si rivela una scelta azzeccata per non falsare i risultati, avendo poche dipendenze e consumando risorse minime. Gli intoppi che accennavo in precedenza, non si sarebbero manifestati su una distribuzione Linux, io invece usavo Linux From Scratch e tra una dipendenza e l’altra (PHP 5, Php-GTK) non sono riuscito a venirne a capo immediatamente, ma solo dopo aver chiesto lumi a Michael sul forum.