Note per la programmazione reale

Virtuale ma non troppo

di

thumbnail

05

ott

2016

Il sentiero che uno sviluppatore deve intraprendere per arrivare con successo alla sua prima applicazione in realtà virtuale.

La realtà virtuale, VR per gli amici, non è certo una invenzione nuova. La possiamo ricordare dai tempi degli iGlasses (no, Apple non è stata la prima a porre una “i” di fronte al nome dei propri prodotti) di Virtuality Group (ed erano gli anni ’90), del Virtual Boy Nintendo, di Stuntmaster e Cybermaxx di Victormaxx e del VFX-1 di Forte Technologies. Tutte invenzioni che hanno giocato il loro gettone per fare breccia nel mercato ma non hanno vinto la partita, lasciandoci per una decade almeno in balia di schermi piatti, poi 3D, poi densissimi e tascabili.

Oggi siamo però allo start di una nuova partita ed i concorrenti si presentano al mercato con un parco prodotti più invitante, anche (e soprattutto) per gli sviluppatori. Le applicazioni in VR possono essere distinte in grosse famiglie, ma considerando le più pronte e combattive abbiamo all’angolo blu quella per smartphone e dispositivi portatili ed all’angolo rosso quella per desktop e (molto presto) console per mezzo di sistemi headset, da indossare sul capo.

In questo articolo effettueremo un breve volo pindarico sul mondo dello sviluppo per sistemi portatili, mentre parleremo in futuro di alcuni dettagli tecnici e della VR per sistemi fissi.

Dal cartone al casco

Le applicazioni in realtà virtuale per sistemi portatili (app VR) non sono dissimili da quelle che utilizziamo abitualmente sul nostro smartphone: esse hanno solo bisogno di un sistema di lenti aggiuntivo per essere apprezzate. Questo deve essere capace di contenere il dispositivo portatile e deve essere otticamente compatibile con lo schermo del dispositivo in uso. Alla data di oggi, se vogliamo sviluppare una app VR, non abbiamo molta scelta: possiamo scegliere se andare su Google Cardboard o Samsung Gear VR. La differenza principale tra le due opzioni sta nelle versioni delle librerie per lo sviluppo, nelle diverse meccaniche di input disponibili e nelle integrazioni con gli ecosistemi di servizi proprietari.

Google Cardboard

Supereconomico e supersemplice, Google Cardboard.

Se scegliamo il mondo Cardboard, abbiamo pochi vincoli: il visore è un semplice supporto (solitamente di cartone) annesso ad un sistema di lenti (solitamente di plastica) nel quale infileremo lo smartphone iOS o Android subito dopo l’avvio di una app VR. Esistono centinaia di diversi Cardboard – possiamo anche costruirci il nostro – e il visore ha il solo scopo di inibire la vista del mondo che ci circonda, limitandola al solo schermo del dispositivo (ora bloccato davanti al nostro naso) e diviso verticalmente in due parti uguali (una per l’occhio destro e una per il sinistro) per tutta la durata dell’esecuzione dell’applicazione, che ora genera un contenuto separato per ciascuna metà dello schermo. L’app deve essere informata a monte sul sistema di lenti del visore in uso e qui Google gioca la carta del padrone: gestisce la configurazione a livello di dispositivo grazie alla sua applicazione dedicata ed al controllo sul sistema operativo.

Samsung Gear VR (prodotto in collaborazione con Oculus) è invece un casco munito di pulsantiera e touchpad, da acquistare unitamente a uno smartphone Samsung (quindi solo Android) e gode quindi di una vestibilità ed un sistema di lenti predefinito. Le app per Gear VR non si trovano sul Play Store ma solo nell’Oculus store e richiedono canoni qualitativi elevati e piena integrazione coi sottosistemi e servizi Oculus. Inserendo lo smartphone nel casco Gear VR lo si collega al visore stesso attraverso una porta USB consentendo, a differenza del Cardboard, un’esperienza plug&play e, grazie ai controller presenti sul casco, una immersività maggiore (non si esce infatti mai dal rendering VR, bensì si torna all’Oculus Home).

Samsung Gear VR

Gear VR richiede un approccio più strutturato.

Doppio standard

Per uno sviluppatore è pertanto importante considerare che una app per Gear VR dovrà essere obbligatoriamente connessa con alcune funzionalità offerte dall’SDK, rispettare le linee guida proposte ed i requisiti minimi descritti nella documentazione ufficiale per non vedere la propria app rifiutata durante il processo di pubblicazione (sarà un incaricato in carne ed ossa, dopo una prima scrematura automatica, a darci l’OK oppure il KO). Per Cardboard invece, come per il resto delle app su Play Store, non esistono vincoli a monte: per quanto sia facile pensare che alcuni vincoli dovrebbero essere il minimo di ogni app VR decente, per Google tutto fa brodo fino a prossimo avviso. Discorso diverso invece per iOS dove siamo già abituati ai dettami Apple per superare il processo di approvazione.

Se quindi progettate una prima app VR mirando al mercato col maggior numero di utenti, preferendo la strada più breve per la pubblicazione, allora concentratevi sul mondo Cardboard partendo dal versante Android. Se invece vi interessa ottenere un’app ottimizzata ad hoc per una manciata di dispositivi, esposta in una vetrina con dei canoni qualitativi minimi ad esclusivo godimento di una ristretta fetta di utenti che possono permettersi questi contenuti esclusivi, allora scegliete Gear VR.

In ogni caso assicuratevi di avere in casa un Cardboard adatto al vostro potente smartphone con più di 400 punti per pollice sullo schermo, giroscopio e magnetometro. I dettagli in un prossimo articolo.




Giacomo Cappellini (@Arkanoid) è da cinque anni analista programmatore e tool-maker di applicazioni per smartphone e tablet, da dieci anni deviato nel multidisciplinare mondo dello sviluppo di videogiochi cross-platform. Nonostante una grave e particolare forma di ossessione verso lo how-it’s-done, trova ancora tempo e modo per parlarne.

Letto 1.953 volte | Tag: , , , , , , , ,

Lascia il tuo commento