În momentul în care am început să lucrăm la primul nostru joc în cadrul King România, știam că proiectul urma să fie distractiv, pe de o parte pentru că, deși toţi membrii echipei dezvoltaseră până atunci jocuri, era prima dată când lucram la un joc casual-social și, pe de altă parte pentru că urma să fie primul joc "serios" de la King care ajungea pe mobile. King mai lansase înainte un joc, atât pe App Store, cât și pe Google Play (pe atunci App Market), dar nu era un joc high-profile lansat pe Facebook, așa cum era în cazul lui Bubble Witch Saga. În momentul selecţiei jocurilor pentru portarea pe mobile, Bubble Witch Saga a fost o alegere foarte naturală. Era cel mai popular titlu din portofoliul companiei în perioada respectivă, iar King își dorea o intrare "în forță" pe piața de mobile.
Inițial am crezut că o să fie o muncă ușoară și, într-un fel, ne şi doream acest lucru deoarece abia pusesem bazele studioului şi eram conştienţi că urmau să intervină probleme legate de administrarea sa. A trebuit să cumpărăm hardware, să setăm servere, servicii şi canalele de comunicație cu birourile din Suedia și Londra etc. Pe lângă toate aspectele logistice, au intervenit şi alte aspecte care trebuiau definite pentru o funcţionare cât mai eficientă: viziunea studioului, profilul oamenilor pe care doream să-i angajăm, modul în care ne organizăm în echipă. Apoi a urmat o discuție cu managerii de proiect de la Bubble Witch Saga, varianta de Facebook, în care am fost informaţi că urma să realizăm un lucru pe care nimeni nu-l mai încercase până atunci: să sincronizăm versiunea de Facebook cu cea de mobile. În momentul acela ne-am dat seama că dezvoltarea va fi mai complicată, dar în același timp mult mai interesantă.
Jocul de Facebook ține datele pe un server, într-o bază de date distribuită. Din acest punct de vedere, teoretic, este simplu: clientul de mobile ar trebui doar să acceseze aceleași date. Însă în practică nu este chiar atât de uşor deoarece utilizatorii care se joacă pe telefoane nu sunt tot timpul online, în comparaţie cu cei de pe Facebook care sunt forţaţi să rămână online pentru a accesa jocul. Pe telefoane, odată ce aplicaţia a fost instalată, aceasta poate fi accesată în orice moment. Am fi putut opta pentru varianta în care să le impunem utilizatorilor să fie online pentru a accesa jocul, dar în felul acesta am fi pierdut foarte mulți jucători și, chiar dacă acesta n-ar fi fost un impediment, experiența de joc ar fi fost în mod cert una inferioară (de exemplu, jocul s-ar fi întrerupt de fiecare dată când se pierdea conexiunea la Internet). Toate aceste date indicau către o decizie clară: trebuia să le permitem utilizatorilor să se joace când doresc, iar în momentul în care exista o conexiune la Internet disponibilă, sincronizam progresul jucătorului cu serverul.
Așadar, găsisem o soluţie, însă nu rezolva neapărat toate problemele. Am avut destul de multe dezbateri până am ajuns la soluția finală, dar știam că aceasta aduce cu ea alte probleme. Ce se întâmpla când un utilizator se juca pe telefonul care era offline, după care se juca online pe Facebook ? Pentru că telefonul era offline, versiunea de Facebook nu înregistra sesiunile de joc completate pe telefon. Erau destul de multe cazuri speciale la care trebuia să ne gândim cu atenție, astfel încât jucătorul să nu observe, pe cât posibil, că accesează jocul pe platforme diferite. De exemplu, există utilizatori care accesează jocul de pe o tabletă Android, un telefon mobil iPhone și îl joacă și pe Facebook. Aceștia trebuie să simtă mereu că joacă același joc. Trecerea de la o platformă la alta trebuie să fie complet transparentă. Numai acest aspect al jocului a consumat în timp (investit în dezvoltare și depanare) aproximativ 35% din durata totală a proiectului.
Când ne-am impus să facem ca jocul de pe mobile să fie la fel ca cel de pe Facebook, inițial am mers prea departe și am copiat jocul de pe Facebook în toate aspectele lui. În cazul anumitor aspecte ale jocului, abordarea aceasta este foarte bună. De exemplu, fizica de joc este o portare aproape directă în C++ a codului de Action Script și jocul se comportă foarte apropiat de jocul de Facebook, neexistând diferențe foarte mari în scoruri. Scorurile sunt sincronizate între versiuni și atunci nu ai dori ca toţi utilizatorii să joace pe Facebook pentru că acolo înregistrează scoruri mai mari sau invers. Pentru alte aspecte însă, copierea nu este la fel de eficientă și în acele situații a trebuit să adaptăm jocul. Am făcut butoanele mai mari, pentru că utilizatorii interacționează cu jocul folosind degetele și nu mouse-ul, care este mult mai precis și fin. Am eliminat pe cât posibil textele pe care utilizatorii de telefoane nu sunt obișnuiți să le citească; aceștia se ghidează mai mult după icoane, animații sau feedback vizual contextual. Am adaptat jocul astfel încât să răspundă la diverse întreruperi: recepţionarea de apeluri, mesaje, apăsarea butonului de home (pe iOS) sau back (pe Android) etc. Toate aceste elemente nu există pe Facebook.
Până acum, am abordat aspectele oarecum evidente în procesul de portare a unui joc de pe Facebook pe mobile, pentru că acestea țin de interacțiuni vizibile sau de interfață. Însă foarte mult timp este investit în aspectele care nu sunt imediat aparente. Jocul de Facebook rulează pe un calculator foarte puternic. Asta înseamnă că jocul de Facebook are acces la o putere de procesare virtual nelimitată. În schimb, este limitat de viteza rețelei și a conexiunii la Internet. Utilizatorul nu doreşte să fie ţinut prea mult în fața unui ecran de loading și atunci apare problema limitării cantităţii de date care poate fi trimisă pe rețea, fără ca utilizatorul să aștepte prea mult.
Toate aceste limitări sunt cel puțin de două ori mai mari pe mobile. În primul rând, procesoarele ARM cu care sunt echipate telefoanele mobile, în general, sunt mult mai slabe decât un procesor Intel care se găsește de obicei pe PC sau Mac. În al doilea rând, memoria RAM pe telefoane este de 4 - 6 ori mai mică decât pe PC. În același timp, telefoanele au cerințe speciale de consum al energiei. De exemplu, dacă jocul nu este activ, atunci nu trebuie să consume, pe cât posibil, resurse. Fiind un joc casual-social, ne doream ca acesta să fie descărcat atât prin rețea WIFI, cât și prin 3G. Pentru a fi eligibilă pentru descărcare prin rețea 3G, aplicația trebuia să aibă sub 50 MB. Aceasta este o altă limitare pe care jocul de pe Facebook nu o are.
Ce au însemnat pentru noi toate aceste limitări? În primul rând, a trebuit să găsim metode mai bune de împachetare și de compresie a datelor. Când vorbim despre compresie, vorbim tot timpul despre un compromis care se face între memoria ocupată și ciclurile de procesor consumate pentru decompresie. A trebuit să ne gândim foarte atent la aceste compromisuri, deoarece nici cea de a doua resursă (procesorul) nu ne oferea foarte multe. Compromisurile sunt și mai importante când este vorba despre lansarea unui joc universal pe App Store, adică un singur pachet/aplicație care rulează pe toate modelele de iPhone, iPod sau iPad. Acest lucru înseamnă că, în anumite cazuri, în același pachet o să existe aceeași resursă (imagine, sunet, text) multiplicată pentru fiecare device. În alte cazuri, soluţia a constat în găsirea unor hack-uri istețe prin care reușeam să refolosim aceeași resursă pe toate device-urile. Deși poate părea excelentă, soluția rămâne totuși un compromis, pentru că la fiecare modificare a unei resurse comune trebuia să ne asigurăm că jocul se comporta consistent pe toate device-urile. Acest lucru se traduce printr-un timp de QA crescut.
Până acum am vorbit despre jocul pe mobile versus jocul pe Facebook. Dar mobile nu este o platformă mare, unitară și uniformă. Din contră! Este o platformă mare, neunitară, neuniformă și fragmentată. Am început să portăm Bubble Witch Saga pe iOS (iPhone, iPod, iPad) în ianuarie 2012 și l-am lansat (doar în câteva țări pentru început) în luna mai a aceluiași an. Apoi, ne-am concentrat pe versiunea de Android, care a plecat de la aceeași bază de cod și a fost lansată aproximativ cinci luni mai târziu. O echipă împărțită în două - o parte (trei programatori) concentrată în continuare pe lansarea versiuni de iOS și ulterior a update-urilor, iar cealaltă parte (tot trei programatori) concentrată pe versiunea de Android. În total, a durat aproximativ 10 luni să lansăm un joc pe toate platformele mari (iOS, Android). Cel mai important factor, care conduce la mărirea timpului de dezvoltare, este reprezentat de fragmentarea platformelor. Deși jocul rula atât pe iOS, cât și pe Android încă din ianuarie (pentru că aproximativ 90% din totalul codului era comun), ne-au mai trebuit încă cinci luni ca să lansăm un joc "polished" pentru Android. Am vrut ca jocul să fie compatibil cu cât mai multe modele de telefoane și ne-am confruntat cu tot felul de diferențe subtile între aceste modele, între versiunile de sistem de operare și între rezoluțiile telefoanelor, uneori foarte atipice.
Pentru că o mare parte din grafică era deja realizată pentru varianta de Facebook, am avut un singur grafician în echipă care s-a ocupat de elementele noi specifice versiunii de mobile și de adaptarea graficii existente.
Din punct de vedere al QA-ului, proiectul rămâne unul foarte dificil. Are câteva sute de niveluri, avea peste zece charm-uri permanente care influențau și modificau jocul (în varianta curentă s-a renunțat la acestea în favoarea wish-urilor), o serie de elemente speciale in-game (Doom Skull Bubble, Infected Bubble, Bomb Bubble etc) și booster-e temporare. Multitudinea de elemente creează foarte multe situații posibile care trebuie testate. Pentru acest proiect am avut șase analiști care testau jocul în cele mai mici detalii. Un ciclu de testare tipic, spre finalul proiectului, dura între trei și șapte zile, în funcție de ce se testa. Ciclul de testare pre-release era mai lung, pentru că se testau elemente adiționale specifice lansării. Asigurarea calității este foarte importantă pentru noi, pentru că după trimiterea versiunii de joc la Apple, durează în medie două săptămâni până ca aceasta să fie aprobată și lansată pe store. Dacă detectăm vreo greşeală după lansare, trebuie să o luăm de la început şi s-ar pierde nepermis de mult timp! De aceea, ne concentrăm foarte mult pe QA și încercăm să fim cât mai proactivi când vine vorba de calitatea produsului.
Multă muncă, foarte multă atenție și concentrare la detaliile care contează, o mică armată de oameni implicați direct în dezvoltarea produsului și o altă mică armată implicată în activități adiacente produsului (marketing, finance, accounting etc) și la final un scor de cinci stele ne face pe toți să decretăm: "da, e distractiv să faci jocuri!"
de Dan Suciu
