Desenvolupament d'aplicacions multidispositiu

Al mercat hi ha una gran varietat de dispositius de diferents models, cadascun dels quals té uns components de diferent tipus i capacitats. Per tal de poder desenvolupar aplicacions per a ells, el primer pas és agrupar-los en famílies. Els dispositius de cada família compartiran una sèrie de característiques comunes, com mida, capacitat de procés o presència d’alguns perifèrics, i això ens permet dissenyar aplicacions amb la seguretat que el dispositiu admet aquestes característiques. Vegem-los detingudament (vegeu la figura):

• Ordinadors personals. Els ordinadors personals són equips relativament voluminosos que l’usuari fa servir típicament assegut a un escriptori i que compten amb una pantalla, un teclat i un ratolí. Entre totes les famílies de dispositius, sempre que comparem dispositius de preus similars, és la que presenta unes prestacions més altes, tant en l’àmbit de capacitat d’emmagatzematge de dades com de procés i presència de perifèrics, amb l’excepció dels perifèrics de posicionament i orientació que, en ser equips que no es desplacen durant el seu ús, normalment no són necessaris.
• Consoles. Les consoles són una família de dispositius amb unes prestacions similars a un ordinador personal però orientades a videojocs, i compten amb un conjunt de perifèrics adaptats a aquesta finalitat específica. En concret, disposen de palanques de control (joysticks) i comandaments de joc (gamepads) i, en comparació a un ordinador personal amb un preu similar, tenen una capacitat de memòria i de procés més baixa, que compensen amb una targeta gràfica amb una capacitat de procés i de memòria més alta, almenys en el moment de la seva sortida al mercat.
• Mòbils. Els mòbils són una família de dispositius que es caracteritza perquè l’usuari els transporta amb ell i els fa servir principalment per comunicar-se i consultar informació, fent servir com a perifèric d’entrada una pantalla tàctil. En ser dispositius que no romanen a un mateix lloc, compten amb tot un seguit de dispositius de posicionament i orientació com acceleròmetres i GPS. Com que la seva mida ha de ser reduïda i han de limitar el consum d’energia per tal que la bateria no s’esgoti ràpidament, les prestacions dels seus components són més baixes en comparació amb un ordinador personal.
• Consoles portàtils. Les consoles portàtils són una família de dispositius amb unes prestacions similars als mòbils, però amb una finalitat específica, que és executar videojocs. Compten, per tant, amb gamepads i joysticks integrats i sovint també altres perifèrics d’entrada com pantalles tàctils i càmeres. En comparació amb els mòbils, les seves capacitats solen ser més altes, almenys en el moment de la seva sortida al mercat, i destaquen especialment en l’aspecte gràfic.
• Sistemes de realitat virtual. En aquesta família de dispositius trobem els dispositius que depenen dels ordinadors i els dispositius sense fils, basats en tecnologia mòbil. Aquests darrers són els que dominen el mercat, ja que tenen una barrera d’entrada més baixa perquè no requereix un PC de gamma alta. A més tenen l’avantatge de què poden connectar-se a un PC per gaudir de jocs amb una resolució més gran, perquè la seva tecnologia és compatible amb la dels dispositius que depenen dels ordinadors. Aquests dispositius compten amb unes ulleres situar al jugador en el món virtual i dos controladors que li permeten interactuar, encara que alguns dispositius tenen seguiment de mans i es pot prescindir d’aquests controladors.

Les aplicacions no s’executen directament sobre un dispositiu, sinó sobre una plataforma. Aquesta està formada pel dispositiu més un sistema operatiu que proveeix de tot el programari necessari perquè l’aplicació pugui interactuar amb ell (vegeu la figura).

La importància de les plataformes està en el fet que permeten desenvolupar una aplicació per a tota una família de dispositius sense haver de tenir en compte les diferències en la forma de comunicació amb els perifèrics i els components centrals de cada model, ja que el sistema operatiu ofereix a l’aplicació una interfície comuna independent del dispositiu concret en què s’estigui executant.

D’altra banda, per desenvolupar una aplicació per a una plataforma concreta necessitarem un conjunt d’eines anomenat kit de desenvolupament (vegeu la figura). En el cas que hi hagi una organització responsable de la plataforma, aquesta proveirà els desenvolupadors d’un conjunt d’eines “estàndard” anomenat kit de desenvolupament estàndard o SDK (standard development kit), que consistirà en eines de programari i, en algunes ocasions, maquinari específic.

Si la plataforma és tancada, aquest responsable serà l’empresa propietària i només farà arribar el kit als desenvolupadors que hagi autoritzat; en cas contrari, serà de lliure accés.

Una plataforma pot fer servir un dispositiu físic, per exemple un mòbil, però també una màquina virtual, és a dir, un dispositiu idealitzat que no té una existència física. En el primer cas parlem de plataformes hardware, i en el segon de plataformes software (vegeu la figura).

Dintre de les plataformes hardware, distingirem dos casos: aquelles en què la família de dispositius sobre els quals s’executa el sistema operatiu és força uniforme quant a les capacitats, o homogènies, i aquelles que presenten molta variabilitat, heterogènies.

Tot i que el sistema operatiu “oculta” les complexitats de tractar amb el dispositiu, l’aplicació pot consultar informació sobre aquest, com la presència de certs perifèrics o la seva capacitat, i adaptar el seu comportament. En conseqüència, el desenvolupament d’aplicacions per a plataformes heterogènies sol ser més complex, ja que cal preveure alternatives en funció de les característiques del dispositiu.

Distingirem també entre plataformes obertes o tancades, en funció de si existeix un propietari que posa restriccions al desenvolupament d’aplicacions per a la plataforma o no. Sovint aquest propietari proporciona també una botiga virtual on els desenvolupadors poden publicar les seves aplicacions. Si la plataforma és tancada, hi haurà un procés de revisió i aprovació de les aplicacions que s’hi publiquen.

Les plataformes hardware estan compostes per un sistema operatiu que pot executar-se sobre una família de dispositius físics o bé sobre un conjunt concret de dispositius dins una mateixa família. Aquestes són les més destacades:

1. PC/Windows. La plataforma PC/Windows és una plataforma propietària de l’empresa Microsoft que s’executa a la família dels ordinadors personals. És una plataforma heterogènia, és a dir, els dispositius sobre els quals s’executa el sistema operatiu, tot i pertànyer a la mateixa família, poden tenir capacitats molt diferents. Des del punt de vista de l’accessibilitat per als desenvolupadors, la plataforma és oberta i el kit de desenvolupament estàndard és públic i gratuït, tot i que per publicar al marketplace cal pagar una taxa i passar per un procés de revisió.
2. PC/Linux. La plataforma PC/Linux és una plataforma lliure que s’executa a la família dels ordinadors personals. És extremadament heterogènia, ja que s’executa sobre dispositius amb diferents capacitats sense cap mena de restricció. Caldrà tenir en compte que:
   • No existeix un únic sistema operatiu en aquesta plataforma, sinó molts que comparteixen un nucli comú que proporciona les funcionalitats principals.
   • Des del punt de vista del desenvolupament d’aplicacions, la plataforma és completament oberta, però no existeix un kit de desenvolupament oficial, sinó que cada desenvolupador és lliure de triar les seves eines. Això fa que sigui un entorn ideal per aprendre a desenvolupar aplicacions, tot i que no sigui una plataforma creada amb un objectiu comercial.
3. Mac. La plataforma Mac és una plataforma propietària de l’empresa Apple que s’executa a la família dels ordinadors personals. És una plataforma homogènia, ja que la mateixa companyia selecciona el hardware que s’integra als dispositius i limita aquests a uns pocs models. Tècnicament, es tracta d’una plataforma oberta, ja que qualsevol desenvolupador pot accedir al kit de desenvolupament estàndard i distribuir aplicacions, però a la pràctica funciona com una plataforma tancada, perquè la seva base d’usuaris està més habituada a fer servir el marketplace, i les aplicacions han de passar per un procés de revisió i aprovació per accedir-hi.
4. Mòbil/Android. La plataforma Android és una plataforma propietària de l’empresa Google que s’executa a la família dels mòbils. És una plataforma heterogènia, ja que els dispositius sobre els quals s’executa el sistema operatiu presenten una gran variabilitat quant a capacitats. Caldrà tenir en compte que:
   • Es tracta d’una plataforma oberta, ja que l’empresa no limita el desenvolupament d’aplicacions i el kit de desenvolupament estàndard és públic. Això no obstant, hi ha un marketplace, Google Play, on els desenvolupadors han de pagar una petita taxa i passar per un procés de revisió, però no és gaire exigent.
   • En sentit estricte, hauríem de dir que es tracta d’una plataforma híbrida hardware/software, ja que el sistema operatiu d’Android internament fa servir una màquina virtual derivada de la Java Virtual Machine.
5. Mòbil/iOS. La plataforma iOS és una plataforma propietària de l’empresa Apple que s’executa a la família dels mòbils. És una plataforma homogènia, ja que Apple és responsable també de la fabricació els dispositius, i els limita a uns pocs models que compten cadascun amb uns perifèrics i unes capacitats concretes. Caldrà tenir en compte que:
   • La plataforma és tancada i, tot i que el kit de desenvolupament estàndard és públic, cal que els desenvolupadors passin per un procés de registre i validació per tal de poder publicar les seves aplicacions al marketplace, l’App Store, que és a més l’únic lloc on els usuaris poden obtenir les aplicacions. El desenvolupament de les aplicacions, a més, s’ha de fer des d’una plataforma PC/Mac.
   • Un altre aspecte diferencial és que el procés de validació de les aplicacions és relativament exigent, i la mateixa empresa publica unes guies amb tota una sèrie de requisits que han de complir les aplicacions per obtenir l’aprovació.
6. Consola/Playstation. La plataforma Playstation és una plataforma propietària de l’empresa Sony que s’executa a la família de les consoles. És una plataforma extremadament homogènia, ja que només existeixen un pocs models de dispositiu amb un hardware pràcticament idèntic. Caldrà tenir en compte que:
   • La plataforma és completament tancada i només els desenvolupadors autoritzats per Sony poden rebre el kit de desenvolupament estàndard i publicar aplicacions. Com que els mateixos dispositius no admeten la instal·lació d’aplicacions durant el desenvolupament, cal també que el kit inclogui una versió de desenvolupament de la consola, cosa que encareix el preu que paga el desenvolupador.
   • El procés de revisió i aprovació de les aplicacions, en aquest cas jocs, és força extens i complex. La mateixa empresa fa arribar als desenvolupadors unes guies amb els punts mínims que ha de complir l’aplicació per poder publicar-se.
7. Consola portàtil/Nintendo Switch. Aquesta és una plataforma propietària de l’empresa Nintendo. Com en el cas de les consoles PlayStation es tracta d’una plataforma extremadament homogènia i tancada. Per poder desenvolupar per a aquesta consola, cal obtenir permís de Nintendo per poder adquirir el kit de desenvolupament.
8. Realitat virtual. Els sistemes de realitat virtual són plataformes emergents, en el sentit que encara s’estan donant les passes per establir uns estàndards que han de complir tots els dispositius. Així i tot, algunes companyies han fet alguns avenços, com la plataforma Meta, propietat de Meta (anteriorment coneguda com a Facebook); i SteamVR propietat de Valve. Aquestes plataformes permeten el desenvolupament d’aplicacions per a dispositius de realitat virtual fent servir els dispositius comercials i un kit de desenvolupament de programari. Totes dues plataformes es poden integrar amb els motors de videojocs Unity i Unreal Engine.

Les plataformes software són aquelles que ofereixen a l’aplicació accés no a un dispositiu físic, sinó a una màquina virtual, és a dir, un dispositiu que no existeix al món real, però que es pot simular fent servir un programa.

En molts aspectes, el desenvolupament d’una aplicació per a una plataforma software és similar al d’una aplicació per a una plataforma hardware, ja que la plataforma ofereix uns serveis comuns a l’aplicació i també és necessari obtenir un kit de desenvolupament del fabricant (vegeu la figura). Es diferencia en què com que el dispositiu no existeix realment, per a una aplicació a una plataforma software cal la presència d’un programari que simuli la màquina virtual.

Aquest programari, que s’anomena l’entorn d’execució o Runtime Environment, al seu torn és també una aplicació i, per tant, necessita una plataforma hardware per executar-se (vegeu la figura).

El benefici de les plataformes software és que si el propietari proveeix d’entorns d’execució per a diverses plataformes hardware, qualsevol aplicació desenvolupada per la plataforma software podrà executar-se a aquestes plataformes (veure la figura).

Actualment, les plataformes software principals són Java, .Net i web:

• Java és una plataforma software que defineix una màquina virtual anomenada Java Virtual Machine. Es tracta d’una plataforma oberta i el seu SDK és públic i gratuït. Com que és una màquina virtual, pot executar-se sobre molts dispositius físics diferents.
• .Net és una plataforma software propietat de Microsoft. Defineix una màquina virtual anomenada Common Language Runtime. Podem trobar-la a ordinadors personals i compta amb una versió de codi obert anomenada Mono.
• Tot i que la web no és exactament una plataforma, l’hem de tractar com a tal, ja que el llenguatge en què s’executen els jocs per a web s’executa en una màquina virtual dins dels navegadors. El llenguatge en el qual es programen els jocs per a web és HTML5, el que inclou JavaScript i diverses API (Application Program Interface) com WebGL que permet crear jocs 3D.

El rendiment de les aplicacions que s’executen a una màquina virtual es veu afectat pel fet que les instruccions de l’aplicació s’han de traduir del joc d’instruccions de la màquina virtual al del dispositiu físic. Així, podem trobar dues situacions:

Si aquesta traducció es fa progressivament durant l’execució de l’aplicació (vegeu la figura), l’execució de l’aplicació a la màquina virtual serà força més lenta que si la mateixa aplicació s’executés directament al dispositiu físic.

Si es tradueixen totes les instruccions abans de començar l’execució (vegeu la figura), l’aplicació trigarà més a iniciar-se, però una vegada ho faci el seu rendiment serà pràcticament igual al que tindria si s’executés directament al dispositiu físic.

Els perifèrics d’entrada serveixen per comunicar dades al processador i memòria principal; per exemple, el codi de l’última tecla premuda en el cas d’un teclat (vegeu la figura). Hi ha dues formes principals en què aquesta comunicació pot tenir lloc:

• Si hi ha una necessitat contínua per part de l’aplicació de conèixer l’estat del perifèric, l’accés es fa per enquesta (vegeu la figura); és a dir, l’aplicació consulta cada cert temps el perifèric i li demana les dades que tingui, per exemple un videojoc pot consultar el teclat cada cinquanta mil·lisegons per saber on cal dirigir un personatge.

• Si l’aplicació té altres tasques a fer o pot esperar i només necessita saber quan hi ha noves dades disponibles al perifèric, l’accés es fa per interrupció (vegeu la figura); és a dir, el perifèric avisa el programa principal mitjançant un esdeveniment i l’aplicació deixa el que estigui fent per atendre’l. Aquest tipus d’accés és típic d’aplicacions interactives basades en finestres, on per exemple un programa no fa res fins que l’usuari fa un clic amb el ratolí sobre algun element.

En cas que el perifèric hagi de comunicar una gran quantitat de dades a l’aplicació, o bé si no hi ha una mida preestablerta sinó que la comunicació de dades és contínua, es fa servir la tècnica del buffering o streaming, que consisteix a reservar una àrea de memòria o buffer per tal que el perifèric desi allà les dades a mesura que les vagi generant (vegeu la figura).

L’aplicació pot llavors interrogar el perifèric per saber si hi ha noves dades disponibles o bé esperar i rebre un esdeveniment quan això succeeixi. Com que la mida del buffer és limitada, pot donar-se la situació que s’ompli, de manera que és important que l’aplicació llegeixi com més aviat millor les dades per poder treure-les i desar espai per a altres de noves.

El teclat és un perifèric d’entrada bàsic present a molts dispositius. Això fa que normalment tinguem disponibles funcions per accedir-hi en qualsevol llenguatge i entorn de programació. Quan hi accedim per interrupció, l’aplicació rep els esdeveniments següents:

• Tecla premuda o key press, quan l’usuari prem la tecla.
• Tecla amunt o key up, quan l’usuari la deixa anar.

Juntament amb l’esdeveniment, l’aplicació rep un codi numèric que correspon al codi de la tecla que s’ha premut o s’ha deixat anar. Hem de tenir en compte, però, que aquest codi pot correspondre a diferents caràcters en funció de les preferències d’idioma de l’usuari.

Una altra manera d’accedir a les dades del teclat és per la tècnica de buffering. En aquest cas, es reserva un espai de memòria on s’emmagatzemen les últimes tecles premudes i l’aplicació les llegeix “consumint” una porció de les dades cada cop, per exemple una línia. Si el buffer s’omple sense que l’aplicació llegeixi les dades, les tecles premudes a partir d’aquell moment no queden registrades i el dispositiu pot emetre un avís a l’usuari per indicar-l’hi.

Cada teclat té unes limitacions quant a les combinacions de tecles que es poden prémer a la vegada i quan l’usuari arriba al límit de tecles simultànies que li permet la combinació que està prement, prémer una tecla addicional no genera cap esdeveniment.

El ratolí és un perifèric de posicionament bàsic present als dispositius d’escriptori com els PC. Consta de com a mínim un botó i és força habitual que també tingui una rodeta o altres botons auxiliars. Com a perifèric de posicionament, el ratolí no té una referència absoluta de la seva posició, sinó que cada cert temps prem una mesura de quant s’ha desplaçat i transmet aquesta informació a l’aplicació. És, per tant, un perifèric de posicionament relatiu.

Un altre element vinculat habitualment al ratolí és el cursor. És una fletxa o icona que es representa a la pantalla i que l’usuari pot fer servir per interaccionar amb una aplicació. Cal dir, però, que podem trobar aplicacions, per exemple un simulador de vol, que facin servir el ratolí sense mostrar un cursor. La comunicació amb el ratolí es pot fer per interrupció, i en aquest cas l’aplicació rep els següents esdeveniments:

• Mouse Up, quan es prem algun botó.
• Mouse Down, quan es deixa anar un botó.
• Mouse Move, quan es mou el ratolí.

En el cas dels dos primers esdeveniments, porten com a dada el botó que s’ha premut o deixat anar; en el cas de l’últim, el desplaçament mesurat en els eixos x i y.

Les palanques de control (joysticks) i els comandaments de joc (gamepads) són dispositius dissenyats específicament per controlar aplicacions interactives, típicament videojocs. Consten d’una certa quantitat de botons i palanques que podem desplaçar en un o més eixos (vegeu la figura) i també altres components complementaris com acceleròmetres o giroscopis.

L’accés als botons es fa típicament per interrupció, i de manera similar a un teclat, l’aplicació rebrà els esdeveniments:

• Joystick Button Up.
• Joystick Button Down.

Cadascun d’aquests esdeveniments vindrà acompanyat de l’identificador del botó que s’ha premut o deixat anar. Pel que fa a les palanques, l’accés se sol fer per enquesta i, en aquest cas, l’aplicació demana cada cert temps l’estat de la palanca i rep aquestes dades:

• En el cas de les palanques digitals, la dada que es rep és, per cada eix, un codi que indica si la palanca està centrada o inclinada en un sentit o l’altre, per exemple 0, -1 i 1.
• En el cas de les palanques analògiques, es rep un nombre real que indica el grau d’inclinació de la palanca en cada eix, per exemple un nombre real entre -1 i 1, per exemple 0,7.

En el cas de les palanques analògiques, hi ha una limitació, i és que encara que l’usuari la deixi anar completament, l’aplicació usualment no rep el valor zero, sinó un nombre proper, i pot interpretar erròniament que l’usuari vol fer un desplaçament (vegeu la figura). Per adreçar això les aplicacions han de fer servir el concepte de zona morta, que és un valor mínim d’inclinació per sota del qual consideren que l’usuari no està fent cap desplaçament (vegeu la figura).

La pantalla tàctil és un perifèric de posicionament format per una pel·lícula que detecta el contacte dels dits mitjançant les variacions que això provoca en certes propietats elèctriques, per exemple la seva capacitància. A diferència d’altres perifèrics de posicionament, la pantalla tàctil pot donar una posició absoluta per cada dit amb què es prem, ja que el contacte es fa sobre una superfície amb unes dimensions concretes. La comunicació de l’aplicació amb una pantalla tàctil se sol fer per interrupció, i els esdeveniments que es reben són (vegeu la figura):

• Touch Down, quan l’usuari toca la pantalla amb un dit.
• Touch Move, quan l’usuari mou el dit sense aixecar-lo.
• Touch Up, quan l’usuari aixeca el dit de la pantalla.

Amb cadascun d’aquests esdeveniments, l’aplicació rep un identificador numèric que indica el dit amb què s’ha fet el touch i la posició a la pantalla d’aquest. Segons les característiques del maquinari podem trobar que hi ha una limitació en el nombre màxim de dits que pot detectar una pantalla tàctil simultàniament.

La càmera és un perifèric que podem trobar en equips com PC i mòbils i que proporciona imatges de l’entorn del dispositiu. Aquestes imatges poden tenir una mida considerable, en funció de la resolució a què treballi el perifèric, i per aquest motiu es fan servir buffers per comunicar-la amb els components centrals. Quan l’aplicació vol capturar una imatge, ho comunica a la càmera i aquesta l’avisa per interrupció quan la captura ha tingut lloc, donant-li accés a l’àrea de memòria o buffer on ha emmagatzemat la imatge.

En cas que vulgui capturar vídeo, se sol fer servir la tècnica de buffering, és a dir, l’aplicació envia una comanda a la càmera per iniciar la gravació i aquesta va deixant les dades a un buffer que l’aplicació pot consultar (vegeu la figura). A partir d’aquell moment, la càmera pot avisar per interrupció quan hi hagi noves dades disponibles o bé l’aplicació pot gestionar el procés per enquesta. En cas que el buffer s’ompli, normalment les dades antigues es descarten, ja que en el cas d’un vídeo l’assumpció comuna és que les imatges més recents són més importants.

Per la seva banda, el micròfon és un perifèric d’entrada que tenim disponible a diferents famílies de dispositius, com els mòbils o les consoles portàtils. L’accés al micròfon és similar a l’accés a una càmera i també es fa servir la tècnica del buffering, ja que el perifèric produeix dades contínuament. La diferència més significativa és que el format de les dades de so és diferent del d’una imatge i la seva mida és molt més petita, de manera que el seu procés no és tan costós.

Els perifèrics de posicionament i orientació, com el teclat o el ratolí, són perifèrics d’entrada (és a dir, la transmissió de dades es fa en la direcció del perifèric al processador i memòria principal). La seva funció és donar una referència de la posició local, l’orientació i la posició global del dispositiu (vegeu la figura).

Aquestes mesures la poden donar en termes relatius, és a dir, com un desplaçament respecte a l’última posició i orientació mesurades, o en termes absoluts, respecte a un marc de referència immòbil, com per exemple el pol nord terrestre. Segons la seva qualitat i les condicions de l’entorn, aquesta mesura pot tenir una precisió variable, és a dir, pot correspondre’s amb la mesura real en major o menor grau.

També és força comú la presència d’una gran quantitat d’oscil·lacions d’alta freqüència a la mesura, és a dir que, a un cert instant, el perifèric pot donar una mesura molt alta, a l’instant següent una de molt baixa i una de molt alta a continuació. Això fa que sigui necessari fer algun tipus de filtratge que doni un valor més estable, per exemple fent una mitjana de les deu últimes mesures.

La major part de dispositius compta amb almenys un d’aquests perifèrics, i en el cas dels mòbils i altres dispositius de mida similar, amb més d’un. També podem trobar-los integrats com a components a altres perifèrics, per exemple als comandaments de joc (gamepads).

Els perifèrics de posicionament i orientació són els acceleròmetres, les brúixoles, els giroscopis i els GPS. Considerats per separat, cap d’ells determina completament la posició i orientació del dispositiu sinó que cadascun aporta informació d’un aspecte concret. Per tant, és necessari combinar la informació que aporten per tal d’obtenir una imatge de conjunt.

Els acceleròmetres mesuren l’acceleració que està patint un dispositiu en un moment donat. En el cas dels acceleròmetres integrats als mòbils, aquests fan servir materials que canvien les seves propietats de conductivitat quan estan sotmesos a forces. Quan l’aplicació vol consultar aquesta acceleració, l’acceleròmetre li retorna els valors que corresponen a les acceleracions als eixos x, y i z d’un sistema de referència vinculat al dispositiu (vegeu la figura).

Amb aquesta informació, l’aplicació pot calcular el desplaçament que ha patit el dispositiu en termes relatius, és a dir, respecte a l’última posició mesurada, tot multiplicant el temps transcorregut per l’acceleració aplicada, sempre que també conegui la velocitat que tenia el dispositiu anteriorment.

Si l’aplicació vol obtenir la mesura de la posició en valors absoluts, primer de tot cal fer que l’usuari prengui una referència, és a dir, parteixi d’una posició coneguda amb el dispositiu en repòs. Una vegada s’ha pres la referència, l’aplicació pot calcular els desplaçaments en termes relatius i sumar-los a aquesta posició i orientació inicials.

Una limitació que té aquest procés és que la mesura d’un acceleròmetre no és completament precisa, de manera que en cada pas s’acumula un error que fa que, amb el temps, la posició calculada esdevingui molt diferent de la real (vegeu la figura). Una forma d’evitar aquesta situació és fer que l’usuari prengui una nova referència periòdicament.

Cal tenir en compte també que l’acceleròmetre també mesura l’acceleració produïda per la força de la gravetat, de manera que, en repòs, sempre donarà un valor de -9,8 m/s² en la direcció de terra, i amb aquesta dada l’aplicació pot deduir l’orientació del dispositiu respecte al pla de terra. Un altre ús que pot fer l’aplicació de l’acceleròmetre és detectar quan l’usuari està agitant el dispositiu.

La brúixola fa una mesura del camp magnètic i dona a l’aplicació la direcció en què està el pol Nord. Aquesta mesura es dona com un angle amb relació a un sistema de referència solidari al dispositiu (vegeu la figura).

Hem de tenir en compte que la mesura que dona la brúixola fa referència al pol Nord magnètic, que no coincideix amb el pol Nord geogràfic, que és un punt fix a la superfície de la terra. Per obtenir la direcció Nord geogràfica, l’aplicació ha de combinar la lectura que li dona la brúixola amb algun tipus d’informació cartogràfica addicional.

El giroscopi es fa servir per mesurar l’orientació del dispositiu. Podem concebre’l com un conjunt de petits discs que contenen un element que detecta la rotació del dispositiu i la transforma en un senyal elèctric. El giroscopi dona una mesura de l’orientació absoluta (vegeu la figura) amb relació a una certa orientació inicial, per exemple la que tingués en el moment d’iniciar-se l’aplicació i, a diferència de l’acceleròmetre, no té un error acumulat, ja que fa servir la gravetat de la Terra com a referència.

El GPS dona una mesura absoluta de la posició del dispositiu al planeta, en forma de latitud i longitud. Aquesta mesura té una precisió variable que en el millor dels casos pot suposar un error de només uns pocs metres. Cal notar que el perifèric és un receptor, és a dir, només capta els senyals que envien els satèl·lits GPS.

Per poder fer la mesura, el GPS necessita que li arribin els senyals d’un mínim de satèl·lits. Una vegada arriba a aquest mínim, tots els satèl·lits addicionals que s’hi rebin incrementen la precisió de la mesura, reduint el marge d’error. Altres fenòmens que afecten el camp electromagnètic de la Terra, com les tempestes solars, també poden interferir en el seu funcionament.

Els perifèrics de sortida reben dades des del processador i la memòria principal, i les transmeten a l’usuari o a un altre equip. Aquestes dades poden ser imatges, so i qualsevol altre tipus d’informació que aquest pugui captar. En alguns casos, es pot donar permís al perifèric perquè llegeixi les dades de memòria mentre l’aplicació fa altres tasques. Aquest mecanisme es diu accés directe a memòria, Direct Memory Access o DMA.

En cas que la mida de les dades que s’hagin d’enviar al perifèric sigui petita, l’aplicació les pot enviar com a paràmetres, juntament amb les comandes, de manera similar a com es fa l’accés per enquesta a un dispositiu d’entrada. En canvi, si la mida de les dades és molt gran, es reservarà una àrea de memòria o buffer on l’aplicació escriurà les dades per tal que el perifèric les llegeixi (vegeu la figura).

La pantalla és el dispositiu de sortida més important a una aplicació interactiva. Físicament, està composta per una gran quantitat de cel·les distribuïdes en forma de matriu que es poden il·luminar individualment amb diferents tècniques per tal de formar imatges.

L’aplicació es comunica amb la pantalla a través d’una àrea de memòria anomenada framebuffer. Aquesta àrea pot residir a memòria principal o a memòria de vídeo i conté una matriu de píxels ordenada per files que es correspon amb les cel·les luminescents de la pantalla. Si l’aplicació vol mostrar una imatge a pantalla, només ha d’escriure a les posicions corresponents d’aquesta matriu de memòria els valors de vermell, verd i blau que vol que mostrin els píxels (vegeu la figura).

Les dimensions del framebuffer determinen la resolució que pot mostrar la pantalla en un moment donat, i la quantitat de bits que es facin servir per codificar els colors determinen el nombre de colors diferents que es poden mostrar. La combinació d’unes dimensions concretes amb una quantitat determinada de bits es coneix com un mode de vídeo, i cada pantalla suporta un grup concret d’entre tots els possibles.

Moltes aplicacions, especialment les aplicacions en 3D, no accedeixen directament al framebuffer sinó que transmeten les imatges, els models i les textures a la targeta gràfica, i és aquesta qui s’encarrega de produir la imatge corresponent. D’altra banda, en les aplicacions de realitat virtual l’usuari fa servir dues pantalles, una per cada ull i, per tant, es fan servir dos framebuffers.

La targeta d’àudio és el perifèric encarregat d’interpretar una ona sonora per tal que la puguin reproduir els altaveus. Aquesta ona s’emmagatzema a una àrea de memòria especial, el buffer de so, i s’interpreta mitjançant un component anomenat convertidor d’analògic a digital o ADC. L’ona sonora es codifica fent servir samples, que són mesures de la intensitat de l’ona en un punt concret. Com més samples per segon es facin servir i més bits es dediquin a codificar cada sample, l’ona reconstruïda serà més semblant a l’original i, per tant, el so serà més fidel (vegeu la figura).

Les aplicacions usualment no escriuen directament al buffer de so, sinó que creen petits fragments de so anomenats clips i demanen a la targeta que els reprodueixi. Aquests clips resideixen a la memòria principal, i cada vegada que l’aplicació demana que se’n reprodueixi un, la targeta de so ho fa mesclant-lo amb la resta de clips que s’estiguin reproduint en aquell moment. Algunes targetes compten també amb xips que poden afegir efectes als clips, els Digital Signal Processors o DSP, i alliberen d’aquesta tasca el processador principal.

Quan es demana reproduir un clip, aquest s’assigna a un canal, i en funció de cada targeta hi ha un límit de canals disponibles que es fan servir per fer la mescla final que es deixa al buffer de so. Això vol dir que, encara que els canals s’alliberin quan acaba la reproducció del clip, no podem reproduir un nombre il·limitat de clips al mateix temps, i una vegada s’arriba al límit els nous clips que li demani l’aplicació no sonaran.

Els perifèrics hàptics permeten transmetre a l’usuari una sensació física o una força de resistència. L’habitual és trobar-los integrats a dispositius com mòbils, comandaments de joc (gamepads) i palanques de control (joysticks). Per activar-los, l’aplicació només ha de donar una comanda al perifèric amb la intensitat amb què vol que es faci l’efecte.

En el cas dels perifèrics de feedback de força, aquests introdueixen una resistència al moviment que una aplicació pot fer servir per simular els efectes d’un fenomen físic, per exemple la duresa del volant de direcció d’un cotxe. En el cas dels perifèrics de vibració o rumble, aquests fan que el perifèric vibri amb una certa intensitat, recurs que pot aprofitar una aplicació per, per exemple, avisar l’usuari d’un perill o transmetre-li la sensació que està travessant un terreny accidentat.

En el següent vídeo trobareu una explicació amb exemples d’aplicació d’aquesta tecnologia:

Els perifèrics d’entrada sortida es fan servir per transmetre dades tant del processador i la memòria principal cap al perifèric com en sentit invers. Com que pot donar-se el cas que aquestes dades siguin voluminoses, es reserven buffers separats pels dos sentits.

Cal aclarir que sempre hi ha una comunicació de dades en ambdós sentits en qualsevol perifèric, però quan parlem de dispositius d’entrada i sortida la quantitat de dades que circula en un sentit i el contrari estan equilibrades i, en el cas d’un dispositiu que només sigui d’entrada o de sortida, les dades que circulen en sentit contrari al flux principal de dades només són senyals de control o avisos que serveixen per coordinar les diferents operacions.

Els perifèrics d’emmagatzematge massiu són perifèrics que tenen la capacitat d’emmagatzemar una gran quantitat de dades. L’aplicació es comunica amb ells mitjançant buffers a memòria principal que el perifèric llegeix o escriu en funció de l’operació que se li demani (vegeu la figura). Hi ha diferents tipus segons el medi d’emmagatzemament que es faci servir, cadascun amb una capacitat i un temps d’accés o latència diferents:

• Els discs durs magnètics, que fan servir discos magnètics, tenen una latència alta i una gran capacitat d’emmagatzematge.
• Els discs durs d’estat sòlid, que fan servir transistors, tenen una latència petita i una capacitat d’emmagatzematge moderada.
• Les targetes de memòria, que fan servir transistors, tenen una latència petita i una capacitat d’emmagatzematge petita.
• Les unitats òptiques, que fan servir medis com un DVD o un Blu-ray, tenen una latència alta i una capacitat d’emmagatzematge petita.
• Les unitats magnètiques, que fan servir cintes magnètiques, tenen una latència alta i una gran capacitat d’emmagatzematge.

La targeta de xarxa és un perifèric que permet enviar i rebre dades a o des d’altres equips. Aquesta comunicació es porta a terme emprant un model de quatre capes conegut com el model de capes d’Internet o model TCP/IP enviant paquets de dades a través de la xarxa local o d’Internet amb uns formats específics anomenats protocols.

La comunicació a través d’Internet es fa utilitzant un model de quatre capes i a cada capa s’embolcallen les dades utilitzant com a mínim un protocol. Aquestes capes són: capa d’aplicació, capa de transport, capa d’Internet i capa d’accés a la xarxa.

En el desenvolupament de videojocs només es tracta amb les dues primeres capes:

• La capa d’aplicació és la responsable d’empaquetar i desempaquetar les dades que s’envien per ser usades per l’aplicació. Aquesta és l’única capa que es pot implementar, afegint nous protocols i funcionalitats si és necessari, encara que normalment és gestionada pel motor de videojocs o per biblioteques de xarxes.
• La capa de transport indica com s’han de transmetre les dades entre els equips de la xarxa. Es fan servir dos protocols diferents: UDP i TCP, cadascun amb les seves peculiaritats. Sovint no es pot escollir entre un o l’altre, perquè ve predeterminat per les biblioteques fetes servir o el motor de videojocs. Per exemple, l’arquitectura de xarxa d’Unreal Engine empra UDP, però un joc web només pot utilitzar TCP.

El protocol UDP permet transmetre petits paquets de dades amb una latència relativament petita. El protocol UDP fa servir internament el protocol IP, de manera que cada equip s’ha d’identificar en la comunicació per l’adreça IP. Cal tenir en compte també que aquest protocol no assegura que els paquets es rebin i no crea una connexió entre els equips d’origen i destí.

Per altra banda, el protocol TCP permet crear un flux de dades bidireccional entre dos equips, segur i sense limitació en la mida de les dades, es pot fer servir el protocol TCP/IP. Aquest protocol té una latència més gran, ja que s’ha d’establir primer una connexió entre els dos equips i també fa servir internament el protocol IP. Compta amb un sistema de detecció d’errors que fa que quan un paquet de dades no es rep correctament es torni a demanar i no té un límit en la mida de les dades que es transmeten. Com que la mida de les dades no està limitada, en aquest cas es reserva un buffer de transmissió i un de recepció.

Per portar a terme el desenvolupament d’un videojoc o aplicació multimèdia caldrà determinar a quines plataformes es vol publicar, i aquesta elecció determinarà quines estratègies i tècniques es poden aplicar.

Independentment de l’opció que es faci servir, si la plataforma és heterogènia, caldrà adaptar l’aplicació a la variabilitat que presentin els dispositius; per exemple, diferents mides de pantalla, la presència o absència d’alguns perifèrics, característiques del sistema operatiu…

Una vegada feta la selecció de les plataformes en què es vol publicar l’aplicació, s’ha d’elaborar una estratègia de desenvolupament que permeti crear totes les versions amb un mínim d’esforç, és a dir, compartint el màxim de codi i recursos i, si és possible, fent servir un procés de desenvolupament comú.

Tot i que no hi ha un procediment únic per fer això, però en el cas d’estudis indie, i cada vegada més estudis grans, s’acostuma a usar motors de videojocs de tercers que permeten publicar els seus productes per a múltiples plataformes a partir d’un mateix codi.

Els dos motors de videojocs més emprats són Unity i Unreal Engine, que presenten dos clars avantatges respecte als seus competidors: permeten publicar jocs per a consoles i la majoria de fabricants proporcionen SDK ja preparats per a aquests motors.

En el cas d’encarar el desenvolupament emprant una solució pròpia, com és el cas d’algunes companyies que produeixen jocs AAA, o altres motors menys usats serà necessari recórrer a altres solucions força més complicades, com dividir el codi en diferents repositoris separant la part de codi comuna de l’específica per a cada plataforma.

En el cas de les aplicacions multimèdia es pot optar per fer servir un motor de videojocs o un framework de desenvolupament d’aplicacions multiplataforma com Xamarin o Flutter, tenint molt en compte les limitacions que presenten respecte a les plataformes suportades.

Com es gestionarà l’entrada de l’usuari en cada plataforma? S’admeten diferents tipus d’entrada?

• Per exemple, en un PC es pot interactuar amb teclat, ratolí, comandament de joc (gamepad) o altres dispositius, però en una tauleta el mètode principal seran els tocs a la pantalla.

Quina resolució de sortida tenen les plataformes?

• En un PC de sobretaula la resolució es trobarà entre 1080p i 4K, en un portàtil el més habitual és una resolució 1080p, una consola Nintendo Switch té una resolució de 1080p quan es troba connectada i 720p quan s’utilitza en mode portàtil, en un MacBook la resolució és més propera als 2K o 1440p…
• Segons aquestes resolucions caldrà optimitzar les textures perquè tinguin la mida mínima necessària, però es vegin el més nítidament possible. Si es fan servir textures de baixa resolució en els dispositius amb major qualitat, es veuran distorsionades i, en el cas contrari, es malbaratarà la memòria.

Com es gestionaran les diferents relacions d’aspecte de la pantalla?

• La majoria de monitors i pantalles de televisió tenen una relació d’aspecte 16:9, les pantalles de mòbil varien molt amb algunes al voltant de 16:9, però els iPhones usen 19,5:9, les tauletes usen 4:3 (com les pantalles antigues) i els jocs de realitat usen 1:1 per cada ull.
• Aquesta relació és molt important per determinar com es retallarà l’àrea visible pel jugador o l’usuari, quins elements quedaran fora del seu camp de visió i com cal dissenyar la interfície per ajustar-se a cada cas.
• Si el disseny de la interfície no és adequat, quedarà fora de l’àrea visible, retallada, massa gran o massa petita, o descentrada. Per aquest motiu s’acostumen a dissenyar interfícies fluides, utilitzant posicionament relatiu als costats i les cantonades de la pantalla en lloc d’un posicionament absolut.

Requereix el videojoc o aplicació permisos especials?

• Quan es desenvolupa només per a PC, no hi ha gaires limitacions pel que fa als permisos; però, si es vol distribuir en consoles o dispositius mòbils iOS o Android, caldrà tenir en compte quines limitacions imposen aquestes plataformes.
• Per exemple, per fer servir les capacitats d’ubicació dels dispositius mòbils cal demanar permís a l’usuari per emprar el GPS, si es requereix connectar a la xarxa, cal demanar el permís d’ús de la xarxa local, si es vol transmetre veu cal demanar permís per accedir al micròfon, per fer fotos caldrà el permís per accedir a la càmera…
• Fixeu-vos que a Windows l’accés a la xarxa no es controla a l’aplicació, sinó que serà bloquejat pel tallafoc de Windows i aquest serà el responsable de demanar permís a l’usuari. Per altra banda, l’accés a l’ús de la càmera o el micròfon no requereix cap permís.
• Els motors de videojocs acostumen a gestionar aquests aspectes de manera transparent als desenvolupadors, però sovint cal fer modificacions específiques per a cada plataforma. Per exemple, a Android s’afegeixen els permisos al fitxer AndroidManifest.xml mentre que a iOS cal modificar el fitxer info.plist.

Per desenvolupar aplicacions multiplataforma s’hauran de fer servir algunes tècniques i eines, com ara: la compilació condicional, la comprovació de capacitats, les biblioteques cross-platform, les eines genèriques de conversió de recursos, els fitxers de procés per lots i l’adaptació de la interfície.

Compilació condicional:

La compilació condicional consisteix en la presència al codi d’una sèrie de directives que indiquen al compilador que un fragment de codi només s’ha de compilar per a unes plataformes concretes. D’aquesta podem fer servir el mateix fitxer de codi per a totes les plataformes i, en cas que trobem alguna incompatibilitat, resoldre-ho creant un fragment de codi diferent per a cadascuna (vegeu la figura).

Els motors de videojocs com Unity també compten amb les seves directives de compilació condicional. Aquestes permeten també distingir entre l’execució a l’editor o l’execució com a plataforma independent. Això permet per afegir codi per fer proves que només sigui necessari a l’editor, com poden ser diferents assistents per crear un nivell, però que no formen part del videojoc.

A continuació podeu veure un exemple d’utilització de compilació condicional a Unity, on el component mostrarà diferents missatges segons en quina plataforma s’executi:

using UnityEngine;
using System.Collections;
 
public class PlatformDefines : MonoBehaviour {
  void Start () {
 
    #if UNITY_EDITOR
      Debug.Log("Unity Editor");
    #endif
 
    #if UNITY_IOS
      Debug.Log("iOS");
    #endif
 
    #if UNITY_STANDALONE_OSX
        Debug.Log("Standalone OSX");
    #endif
 
    #if UNITY_STANDALONE_WIN
      Debug.Log("Standalone Windows");
    #endif
 
  }          
}

Comprovació de capacitats:

La comprovació de capacitats consisteix a detectar, generalment a la fase inicial d’un programa, totes les característiques del dispositiu que siguin rellevants de cara al funcionament de l’aplicació. Per poder fer aquesta detecció, les plataformes ofereixen tota una sèrie de funcions amb informació sobre les característiques del dispositiu, per exemple quantitat de memòria disponible, nombre de nuclis que té el processador o la presència o no de perifèrics com un gamepad (vegeu la figura).

Una vegada determinades aquestes característiques, l’aplicació pot prendre decisions per adaptar-se al dispositiu, per exemple adaptar la interfície a la mida de pantalla o fer servir unes textures de menor resolució.

Cal distingir aquest cas de la compilació condicional, perquè aquí l’aplicació té el codi per fer front a totes les circumstàncies que es pot trobar, a diferència de la compilació condicional, on el codi de les situacions no admeses no està present a l’arxiu de l’aplicació.

Biblioteques cross-platform:

Sovint ens trobarem que per fer una mateixa tasca, les biblioteques de cada plataforma ofereixen una funció, procediment o classe diferent, de manera que hem de produir versions diferents del codi fent servir compilació condicional (vegeu la figura).

Per simplificar el desenvolupament en aquest cas, una opció que tenim és fer servir biblioteques cross-platform. Són biblioteques que estan disponibles a diferents plataformes i ofereixen les mateixes funcions a totes, de manera que no cal distingir casos al codi (vegeu la figura).

Com que una biblioteca no deixa de ser codi màquina compilat, hem de tenir en compte que dins d’una mateixa plataforma podem necessitar una versió diferent de la biblioteca per cada tipus de processador que admeti, i assegurar-nos que quan compilem el nostre codi per a un processador concret, enllacem una biblioteca compilada pel mateix processador.

Algunes biblioteques cross-platform estan especialitzades en una funció concreta, per exemple el so, mentre que altres ofereixen tot un ventall de funcions que intenten cobrir totes les necessitats d’un tipus concret d’aplicació.

Una de les característiques essencials dels motors de videojocs és que ja inclouen aquestes biblioteques, ja sigui com a part del motor, com a paquet o mòdul instal·lable o com a connector de tercers. Per tant, un cop instal·lades se simplifica el seu ús perquè són transparents al desenvolupador.

La utilització de Unity com a motor de desenvolupament facilita notàblement l’aplicació d’estratègies efectives de desenvolupament donat que ofereix la possibilitat de crear builds per a diverses plataformes utilitzant un únic codi font. És essencial, en aquest context, que es planifiqui una estratègia que maximitzi la compartició de codi i recursos entre les diferents versions del projecte.

D’aquesta manera, es persegueix un desenvolupament que, mentre manté un nucli comú i modular de codi, permet adaptacions específiques per a cada plataforma, creant diferents builds, optimitzant, per exemple, les entrades d’usuari i les particularitats del renderitzat en cada cas.

El motor de videojocs Unity permet crear builds del joc per a diferents plataformes, a partir del mateix codi font. Cal tenir ne compte que només estaran disponibles els diferents tipus de builds quan s’hagin instal·lat al motor els mòduls corresponents, com es mostra a la figura. En alguns casos, com el de PlayStation o Nintendo Switch, cal obtenir els permisos i el programari de les companyies propietaries.

A la llista de mòduls no es trobarà cap consola perquè es tracta de plataformes tancades. Per tant, aquests mòduls només s’instal·laran juntament amb l’SDK proporcionat per la companyia un cop s’obtinguin els permisos necessaris.

La creació d’una build per a Windows o Linux és trivial, només cal omplir els detalls de l’aplicació i prémer el botó per crear la build. Cal tenir en compte que per poder executar les builds caldrà disposar d’un equip o una màquina virtual amb el sistema operatiu adequat.

Per altra banda, crear una build per a Android és més complicat, ja que requereix un programari específic a banda d’una configuració de projecte més complexa.

Afortunadament, la instal·lació dels mòduls per crear builds d’Android simplifica la feina, ja que s’instal·len les eines d’Android, l’SDK (software development kit) i NDK (native development kit) necessaris per crear la build.

Tot i que és possible crear jocs utilitzant els llenguatges de programació JavaScript i les API de HTML5, és més habitual crear els jocs amb algun motor de jocs i exportar-lo a WebGL. D’aquesta manera el joc pot executar-se en qualsevol navegador.

Per exportar un joc a format WebGL en Unity primerament cal instal·lar el mòdul WebGL Build Support des del Unity Hub, tal com es mostra a la figura.

Un cop instal·lat aneu a File→Build Settings, seleccioneu les escenes que formen part del vostre joc i a Platform seleccioneu WebGL.

Premeu el botó Switch Platform, aquest procés pot trigar una mica. Un cop completat el canvi de plataforma veureu algunes opcions noves (vegeu la figura) i podreu veure les opcions avançades d’exportació prement el botó Player Settings.

Premeu el botó Build i indiqueu a quina carpeta voleu guardar la build del joc.

Un cop finalitzat el procés, podreu trobar la build a la carpeta seleccionada, incloent-hi un fitxer html que podreu obrir amb el vostre navegador, però donarà l’error que es mostra a la figura.

Hi han diverses opcions per provar els vostres jocs en WebGL, les més simples són utilitzar el servei de Unity (tal com s’indica a la seva guia Create and publish WebGL builds) o utilitzar una plataforma com SIMMER.io.

Per pujar un joc a simmer.io cal seguir els següents passos:

1. Crear un compte a simmer.io.
2. Prémer el botó Upload.
3. Seleccionar un pseudònim i acceptar els termes de la llicència.
4. Arrossegar la carpeta que conté la build del joc al quadre que es mostra a la figura

Un cop pujat el joc només cal indicar el nom del projecte, escollir l’URL a partir de la qual es pot accedir al joc i prémer el botó Save Upload per finalitzar la publicació (vegeu la figura).

A partir d’aquest moment podreu compartir l’enllaç per compartir el joc per internet.

A l’hora de dissenyar una aplicació multimèdia o un videojoc, cal tenir molt en compte quines són les característiques de cada dispositiu, dels perifèrics d’entrada, dels perifèrics de sortida i dels requisits exigits per cadascuna de les plataformes, per poder publicar el vostre videojoc o aplicació multimèdia.

Aquests requisits són imposats per les plataformes de distribució, que de vegades són els mateixos fabricants del dispositiu en el cas de les plataformes tancades com PlayStation i iOS, i són coneguts com a compliance checks (verificacions d’acompliment).

Atès que la distribució d’un projecte multiplataforma s’ha de realitzar mitjançant diferents plataformes de distribució (per a PC, per a dispositius Android, per a dispositius iOS…) caldrà assegurar que el producte final satisfà els requisits d’aquestes i no seran bloquejades. Per exemple, Epic Store no permet la distribució de videojocs per a adults mentre que Steam sí que permet aquest tipus de jocs, però ha prohibit els jocs que utilitzen la tecnologia Blockchain (criptomonedes i NFT, Non Fungible Tokens).

Cal tenir en compte que totes les plataformes de distribució cobren una comissió (que acostuma a ser del 30%) per cada venda de l’aplicació i per cada pagament dins d’aquesta (IAP o in app purchases en anglès).

Una estratègia de distribució que segueixen molts estudis és publicar els seus jocs en totes les plataformes possibles, per aquest motiu és habitual trobar el mateix videojoc en diferents stores perquè un cop s’ha desenvolupat el cost d’adaptar-lo als requisits de cada plataforma no acostuma a ser gaire gran.

En alguns casos, les companyies propietàries dels stores ofereixen als desenvolupadors un contracte d’exclusivitat per publicar el seu joc només al seu store, oferint-los un tracte molt avantatjós a canvi de no publicar el seu joc en cap altre store durant un temps determinat.

Un altre tipus d’oferiment que poden fer les plataformes de distribució és incloure un joc en algun servei com el Game Pass de Xbox o Humble Choice d’Humble Bundle, on s’ofereix una quantitat fixa (no lligada al nombre de vendes ni descàrregues) per incloure el joc dintre del servei durant un temps determinat.

Plataformes de distribució per a jocs per a ordinador (Linux, Windows i Mac):

• Steam: és la principal plataforma de distribució de jocs per a PC i Mac. També permet distribuir jocs de realitat virtual de PC com les ulleres dels fabricants Valve, HTC, i Oculus/Meta (en el mode de connexió a l’ordinador). No permet la distribució de jocs que utilitzen la tecnologia Blockchain.
• Epic Store: plataforma de distribució propietat d’Epic (creadors d’Unreal Engine). Cobra una comissió del 12% i elimina el pagament de llicències (un 5% si se supera un milió de dòlars) per a jocs desenvolupats amb el seu motor i distribuïts al seu store. No permet la publicació de jocs per a adults.
• GOG: aquesta plataforma no aporta cap avantatge pels desenvolupadors respecte a Steam o Epic Store. Està especialitzada en jocs clàssics encara que també són distribuïdors. A diferència de Steam i Epic Store els jocs són independents del client GOG i poden jugar-se sense connexió.
• itch.io: es tracta d’una plataforma de distribució gratuïta molt utilitzada per distribuir demostracions de jocs, jocs per a Game Jams, publicació de dev logs (articles de desenvolupament). Ofereix la possibilitat de publicar videojocs i recursos gratuïts, de pagament i fent servir un format de pagament voluntari on l’usuari paga el que vol.

Plataformes de distribució per a jocs de consola. Per publicar un joc primerament cal obtenir l’aprovació de la companyia, en cas contrari ni tan sols serà possible obtenir el SDK per desenvolupar-los:

• Nintendo Store: plataforma de distribució per a jocs per a les consoles WII-U i Nintendo Switch.
• PlayStation Store: plataforma de distribució de jocs per a consoles PlayStation. Compta amb un servei de subscripció per jugar a un catàleg de més de 400 jocs.
• Microsoft Store (Xbox): plataforma de distribució de jocs per a PC i Xbox que ofereix també un servei de subscripció (separats la versió de PC i la de Xbox) que permet jugar a més de 100 jocs.

Plataformes de distribució de jocs per a dispositius mòbils i tauletes:

• Apple Store (iTunes): la companyia Apple només permet la distribució d’aplicacions per a dispositius iOS (iPhone/iPad/watchOS/tvOS) mitjançant aquest store.
• Google Play: plataforma principal de distribució de videojocs i aplicacions per a dispositius mòbils i tauletes Android. Ofereix la possibilitat de pagar un 15% als desenvolupadors que facturin menys d’un milió de dòlars anuals.
• Amazon App Store (Android): store alternatiu per a aplicacions Android propietat d’Amazon.

Encara que els jocs de realitat virtual per a ordinador es poden adquirir com qualsevol altre joc de PC, només Steam dona un suport específic a aquest tipus de videojocs, ja que és propietat de Valve i fabriquen dispositius de realitat virtual (Valve Index i HTC Vive).

Per altra banda, cada vegada hi ha més models d’ulleres de realitat virtual sense fils i per les seves característiques requereixen que l’adquisició de noves aplicacions es faci dintre del dispositiu. En el cas de les ulleres Meta Quest, el dispositiu més popular d’aquest tipus, només hi ha una plataforma de distribució oficial.

• Oculus Store: aquesta és l’única plataforma de distribució oficial d’aplicacions per a Meta Quest. Requereix l’aprovació de la companyia abans de poder publicar l’aplicació i no és fàcil d’aconseguir, encara que ofereixen la possibilitat de publicar el joc en un store alternatiu anomenat AppLab amb algunes limitacions (la més important és que aquestes apps no surten al cercador).
• Sidequest: és una plataforma de distribució alternativa per a jocs per a Meta Quest que presenta limitacions crítiques: els usuaris han de copiar els jocs al dispositiu utilitzant la seva aplicació des d’un PC, requereix que l’usuari activi les opcions de desenvolupador a les ulleres i la plataforma no gestiona cap mena de pagament. A causa d’aquestes limitacions la visibilitat de les aplicacions en aquesta plataforma és molt baixa, però es pot usar per promocionar versions beta de les aplicacions i recollir retroalimentació dels jugadors.
• Viveport: és un servei creat per la companyia Vive per oferir les seves aplicacions per a altres dispositius de realitat virtual per a ordinador. Ofereix també un servei de subscripció anomenat Viveport Infinity on s’ofereixen més de 700 jocs.

Una de les arquitectures més utilitzades en el desenvolupament d’aplicacions és l’arquitectura de tres capes basada en el patró de disseny Model-Vista-Controlador o MVC. L’objectiu d’aquesta arquitectura és separar la lògica de negoci de les dades i de la seva visualització:

• Model (dades): representació de les dades, per exemple les classes que representen al jugador, als enemics, una arma…, formen part del model.
• Vista (visualització): inclou les interfícies d’usuari i tota mena de representació gràfica.
• Controlador (lògica de negoci): quan s’interactua amb l’aplicació, sigui prement una tecla o fent clic a un botó de la interfície d’usuari, el controlador és el responsable de processar aquesta entrada, fer els canvis necessaris (modificar la posició del jugador, carregar una nova escena, afegir una arma a l’inventari…) i comunicar els canvis necessaris a la vista per actualitzar-se.

Aplicant correctament aquesta arquitectura l’usuari interactuarà només amb el controlador, que serà el responsable d’actualitzar el model i comunicar els canvis de representació a la vista, tal com mostra la figura, la vista mai consulta al model.

Exemple de comunicació entre capes

Successió d’accions quan el jugador prem una tecla en un joc que implementa l’arquitectura de tres capes (vegeu el diagrama de seqüència a la figura):

1. El jugador prem la tecla W, aquest esdeveniment és interceptat pel controlador.
2. El controlador llegeix la posició del jugador (model) i modifica la seva posició (el desplaça).
3. El controlador comunica a la vista la nova posició on s’ha de dibuixar el jugador.

Habitualment, en una arquitectura en capes, els components relacionats amb una capa només poden relacionar-se entre els components de la mateixa capa i, excepcionalment, amb les capes adjacents. Per això el controlador pot comunicar-se amb la capa del model i la capa de la vista, però aquestes dues no poden comunicar-se entre elles.

A Unity es pot forçar aquest comportament utilitzant Assembly Definitions, organitzant els scripts per capes i creant una definició per a cadascuna. En fer-ho així, si s’intenta accedir als components d’una altra capa, es produirà un error en temps de compilació, de manera que no serà possible incomplir les regles per error, encara que dins de la configuració del Assembly Definition es poden configurar referències per permetre aquest accés explícitament.

Pel que fa al desenvolupament d’aplicacions multiplataforma mitjançant plataformes web, és freqüent trobar-se amb aquesta arquitectura, però habitualment els frameworks només implementen una part d’aquests. Per exemple, React Native implementa la vista, però implementar correctament el model i els controladors correspon als desenvolupadors.

Per altra banda, alguns frameworks com Xamarin utilitzen una arquitectura de tres capes basada en el patró MVVM (Model-Vista-VistaModel) on la VistaModel fa la funció del controlador. La diferència principal amb el model és que entre la vista i VistaModel hi ha un component addicional anomenat binder que és el responsable de sincronitzar la informació en lloc de comptar amb un controlador, això permet eliminar l’acoblament entre la vista i la VistaModel per reutilitzar-la amb altres vistes.