Share
Daniel Schuller și cu mine am format Bigyama în 2012, după ce am lucrat pe numeroase titluri cum ar fi Magic the Gathering: Duel of the Planeswalkers și Star Wars: Battlefront. Compania a început cu un salt prost în PlayStation Home și o mutare în Scoția, înainte de a reveni la Nottingham și o reorientare pe talentele noastre de bază: programarea și realizarea de jocuri minunate! Primul nostru pas a fost acela de a furniza cotlete tehnice pentru a ajuta jocurile Fallen Tree să aducă Quell Memento la PlayStation Vita.
Acest articol discută modul în care la Bigyama l-am trimis pe Quell Memento la Vita. Dacă doriți să aflați mai multe despre designul lui Quell, vă rugăm să verificați articolul Fallen Tree, The Making of Quell.
Memento este al treilea joc din seria Quell; jocurile anterioare s-au descurcat foarte bine pe telefonul mobil și l-am cunoscut pe Joe și pe Lewis la FTG de ceva timp, colaborând cu ei la Free Radical Design înainte de demisia sa. A fost grozav să ai ocazia să lucrezi din nou cu ei și să ai ocazia să lucrezi la o nouă platformă.
Câteva timp în urmă, m-am întâlnit cu echipa de la Honeyslug, dezvoltatorii succesului PSP Mini Kahoots care au continuat să dezvolte titlul de lansare a Vita, Frobisher Says. Ne-au pus în legătură cu echipa de relații cu dezvoltatorii de la SCEE (Sony Computer Entertainment Europe).
Am mers la studioul SCEE din Londra și am discutat opțiunile - PSP Mini, PlayStation Mobile sau PlayStation Vita - fiecare dintre ele oferind dezvoltatorilor acces la Vita cu diferite grade de funcționalitate. După câteva e-mail-uri, am decis că cea mai bună opțiune pentru Quell a fost să facă un joc nativ Vita, oferindu-ne acces complet la puterea Vita și toate caracteristicile PSN, cum ar fi clasamentele și trofeele.
Adesea, prima sarcină în crearea unui joc este să decideți ce motor să utilizați. Există o serie de motoare disponibile pe Vita, dar cele mai multe sunt complete overkill dintr-o perspectivă tehnică și doar imposibil de a avea o perspectivă financiară pentru un proiect de această dimensiune.
Există, de asemenea, PhyreEngine, deseori trecute cu vederea, dezvoltate de Sony în sine și libere de a fi folosite de dezvoltatorii înregistrați PlayStation - au fost folosiți pentru a dezvolta jocuri de la Soul Demon la Colin McRae: Dirt and Journey. Din nou, după cum probabil vă imaginați, acest lucru a fost mult mai mult decât ne-am dorit cu adevărat, cum ar fi încercarea de a sparge o piuliță cu un ciocan.
În mod convenabil, Quell Memento a folosit motorul Fallen Tree Games și motorul și codul de joc au fost scrise folosind C. C și variantele sale sunt limbajul standard folosit pentru a face jocuri și dacă dezvoltați un joc pe care să-l lansați pe multe platforme diferite într-adevăr nu ar trebui să meargă cu altceva.
Acest lucru a făcut ca decizia noastră să fie evidentă: vom porni motorul lui Fallen Tree Game la Vita. A fost gratuit, a fost construit special pentru a rula jocurile Quell și a fost un cod de bază frumos.
S-ar putea suna contrar intuitiv pentru a ignora toate motoarele care ruleaza deja pe Vita si aleg un motor care nu merge, dar deplasarea unui joc la un nou motor poate inseamna recrearea intregului joc pentru acel motor deoarece functioneaza intr-un mod foarte diferit . Portarea motorului abordează rădăcina problemei. Nu trebuie să vă faceți griji cu privire la recrearea fiecărei caracteristici individuale de joc - trebuie doar să recreați funcționalitatea pe care o au toți cei deasupra.
Dacă sunteți norocos, un port vă poate oferi o oportunitate de a vă dezvolta propria tehnologie pentru o nouă platformă, în timp ce vă plătiți pentru a face acest lucru. Bigyama are propriul motor in-house și, dacă Quell Memento a fost construit pe un motor fără acces la cod sursă, cum ar fi UDK sau Unity, ar fi meritat.
Frumusețea dezvoltării unui port este că aveți un obiectiv clar de urmărit.
Frumusețea dezvoltării unui port este că aveți un obiectiv clar de urmărit.
Acest lucru poate părea descurajant la început, dar poate fi împărțit în câteva domenii-cheie: grafică, intrare utilizator, audio, rețea și salvare jocuri.
Așa cum am menționat deja, portarea motorului a însemnat că nu a existat un cod de joc semnificativ care să fie scris sau rescris; în această situație, obținerea acestor domenii cheie ar trebui să însemne că jocul are în mare parte grijă de el însuși. Etapele timpurii de a face un joc este o bordură pentru a găsi distracția în modul de joc, dar cu un port este o bordură pentru a obține destul de sus și de funcționare pentru a afla unde este rupt.
Când faceți un port, începeți cu grafica.
Este cel mai bun loc pentru a începe - dacă nu puteți afișa nimic pe ecran, va fi foarte greu să știți dacă faceți progrese. Am inceput sa facem grafica inainte sa ne punem mainile pe Vita. Grafica API a Vita este foarte asemănătoare cu OpenGL, iar Quell Memento deja folosea OpenGL.
Quell a folosit o conductă cu funcții fixe (ceea ce înseamnă că utilizatorul poate configura numai etapele procesului de redare printr-un set fix de funcții), dar Vita a folosit o conductă programabilă (programele de shader permit etapele procesului de redare care au fost fixate anterior pentru a fi programate așa cum dorește utilizatorul).
Am avut o perioadă scurtă de timp între a deveni dezvoltatori licențiați și primind kiturile de dezvoltare, așa că în motorul propriu (care folosea Lua / C ++ / OpenGL) am simulat comportamentul stivei matrice OpenGL folosind shaders și un mic cod personalizat. Acest lucru a însemnat că întregul cod Quell existent - bazat pe conducta tradițională a funcțiilor fixe - ar putea rămâne în mare măsură neatins.
// Parte din pachetul nostru pentru a emula stivă matrice OpenGL // Puteți găsi fișierul complet aici: https://github.com/balaam/glfacade Matrix4 glfCalcProjMatrix () Matrix4 mat; mat = mat.identity (); pentru (int i = 0; i < (int)g_glFacade.projectStack.size(); i++) mat = mat * g_glFacade.projectStack[i]; return mat;
Odată ce aveam kituri, am avut rapid ceva în derulare. A fost o mică lucrare de făcut, cum ar fi convertirea formatului de culori al vârfurilor în cel așteptat de shader și reambalarea datelor de vârf din mai multe tampoane separate, fiecare conținând atribute de vârf separate - poziție, UV-uri și așa mai departe - într-o singură cu tampon intercalat, așa cum se arată în diagrama de mai jos:
Cu adăugarea unui shader foarte de bază, în curând am avut ecranul nostru de pornire și de funcționare pe kit ... fel:
Prin adăugarea unui shader simplu pentru a aplica texturi, a devenit în curând acest lucru:
Dupa cum am mentionat, Quell folosea conducta fixa si Vita a fost programabil - ceea ce inseamna ca toate randarile trebuiau transformate in shadere, mai degraba decat abordarea functiei fixe a setarii unei multitudini de stari diferite de randare pentru a obtine un efect dat.
Există câteva școli de gândire cu privire la modul de gestionare a shaderelor. Una este crearea unui shader separat pentru fiecare material sau efect; cealaltă este abordarea "uber-shader", un shader uriaș care utilizează definiții pre-procesoare pentru a produce variantele necesare la momentul compilării. Fiecare are propriile argumente pro și contra:
Shadere individuale - Pro:
Shaders individuale - Contra:
Uber-shader - Pro:
Uber-shader - Contra:
În realitate, majoritatea proiectelor vor utiliza probabil o combinație a ambelor abordări. Pentru portul Quell am ales să mergem în întregime cu abordarea individuală a shader-ului, deoarece cerințele noastre erau atât de simple și fixe.
Jocul sa bazat pe relativ puține combinații diferite de state OpenGL rendering. Pentru a da o idee cât de clar au fost cerințele noastre de shader, am adăugat cele mai complexe aici:
float4 principală (float4 vColor: COLOR0, float2 vTexCoord: TEXCOORD0, float2 vTexCoord1: TEXCOORD1, float2 vTexCoord2: TEXCOORD2, sampler uniformă2D testTex: TEXUNIT0, sampler uniformă2D testTex1: TEXUNIT1, sampler uniformă2D testTex2: TEXUNIT2) float4 texResult = tex2D (testTex, vTexCoord ); float4 texResult2 = tex2D (testTex1, vTexCoord1); float4 texResult3 = tex2D (testTex2, vTexCoord2); float4 currentCol = texResult; curentCol [0] = texResult3 [0] * vColor [0]; actualCol [1] = texResult3 [1] * vColor [1]; curentCol [2] = texResult3 [2] * vColor [2]; curentCol [3] = ((texResult2 [3]) * (texResult [3])) * vColor [3]; retur actualCol;
Codul Quell Vita avea un total de 13 shadere: opt programe de shader (un vertex și șapte shadere de fragmente), combinate cu moduri specifice de amestecare. A fost destul de ușor să înlocuiți codul în motorul Quell care a creat toate variabilele OpenGL cu apeluri pentru a seta un shader în schimb:
rlSetBlend (RL_BLEND_RGBA); rlSetMultiTexture (0, rlGetTexture (quellGame_getAtlasImage (QUELLATLAS_SURROUND, true))); rlSetMultiTexBlend (0, RL_TEXBLEND_MODULATE_PASS_INV_ALPHA_TO_NEXT); rlSetMultiTexture (1, rlGetTexture (paneDesatTexture)); rlSetMultiTexBlend (1, RL_TEXBLEND_PREVIOUS_ALPHA_WITH_TEX_ALPHA);
a devenit:
rlSetShader (RL_SHADER_BLEND_RGBA_4);
Accentsconagua
rl (render layer) sunt un set de funcții care înfășoară funcționalitatea OpenGL; 4 în RL_SHADER_BLEND_RGBA_4 pur și simplu a arătat că aceasta a fost cea de-a patra variantă a acestui shader RGBA - cu atât de puține shadere nu am cerut o convenție de numire deosebit de descriptivă. Aceste rl există deja funcții în motorul Quell, dar dacă jocul care urmează să fie portat nu folosește acest tip de abstractizare, este ceva ce vreți să adăugați din timp. Permite ca codul de redare să fie abstracționat, astfel încât modificările specifice platformei să poată fi făcute fără a afecta codul de joc.
Idealistul în mine ar fi vrut cu adevărat să fi implementat un sistem bazat pe uber-shader. Cu toate acestea, acest lucru ar fi fost suprasolicitat și ar fi trebuit să fie sprijinită de tipii FTG, lucru pe care am muncit din greu să minimalizăm. Portarea nu se deosebește de nici o altă sarcină de programare, deoarece veți întotdeauna să cântăriți "făcând treaba" împotriva viziunii dumneavoastră idealizate a modului în care aceasta ar trebui să fi realizat.
În cele din urmă, au existat foarte puține dureri de cap în a face parte din grafică a jocului în desfășurare, deși a existat un timp frustrant pierdut urmărind ceea ce am presupus că a fost o suprascriere de memorie în codul de redare. A fost un timp înainte să-mi dau seama că, spre deosebire de apeluri precum glDrawArrays în OpenGL, în cazul în care matricea dvs. este copiată atunci când efectuați apelul, apelurile de remiză ale lui Vita nu sunt - adică nu puteți reutiliza tamponul de vârf pe care îl transmiteți apelurilor de remiză Vita până când nu se face desenul. După cum puteți vedea din screenshot de mai jos, acest lucru poate face destul de mizerie.
... ocazional arăta cam mai mult, adesea doar pentru un singur cadru. Soluția pentru aceasta a fost pur și simplu de a utiliza funcționalitatea existentă în API pentru a aștepta până când a fost făcută cu tamponul, dar a fost o reamintire în timp util a pericolelor de a face presupuneri cu privire la modul în care lucrurile funcționează pe o nouă platformă poate fi, pe orice platformă).
Am fost norocoși aici, deoarece jocurile anterioare au fost deja lansate pe Sony Xperia Play, ceea ce înseamnă că nu a fost nevoie de mult de lucru pentru a face butoanele de lucru - multe controale fizice care există pe Vita există pe Xperia și funcționalitatea a fost deja în vigoare.
Aceasta a însemnat că era într-adevăr doar o chestiune de mapare a cheilor hardware la cheile software și trecerea stărilor butoanelor "presate" și "eliberate" la codul existent de manipulare a intrărilor.
Pe măsură ce jocul provine de pe dispozitive mobile, același lucru se întâmplă și cu panoul frontal. Panoul tactil din spate a necesitat o finisare mică, problema evidentă fiind faptul că nu puteți să le alimentați pur și simplu în același flux de intrări, deoarece dacă un jucător atinge ambele panouri și eliberează partea frontală, jocul poate dori să se înregistreze ca echivalentul eliberării spatelui sau nu.
De asemenea, a fost o mică lucrare în obținerea intrărilor de pe panoul din spate (care nu are aceeași dimensiune ca ecranul) să se simtă ca și cum ar fi cartografiere corect pe ecranul frontal. Acest lucru a fost realizat prin ignorarea unei frontiere a zonei moarte în jurul marginii panoului din spate și diminuarea intrarelor din interiorul acestei zone pentru a fi cartografiate pe ecran.
// intrările din spate nu par să se potrivească complet cu gama de ecran frontal, deci întindeți în cod // acestea sunt valori care s-au simțit ușor accesibile #define REAR_DEADZONE_MIN_X 10 #define REAR_DEADZONE_MIN_Y 75 #define REAR_DEADZONE_MAX_X 950 #define REAR_DEADZONE_MAX_Y 430 #define REAR_STRETCH_X 960 # definește REAR_STRETCH_Y 544 static vec2 vitaMapRearInputToScreen (intra int int, int inputY) vec2 stretchedInput; stretchedInput.x = (inputX-REAR_DEADZONE_MIN_X) * REAR_STRETCH_X / (REAR_DEADZONE_MAX_X-REAR_DEADZONE_MIN_X); stretchedInput.x = clampf (întinsăInput.x, 0, REAR_STRETCH_X); stretchedInput.y = (inputY-REAR_DEADZONE_MIN_Y) * REAR_STRETCH_Y / (REAR_DEADZONE_MAX_Y-REAR_DEADZONE_MIN_Y); stretchedInput.y = clampf (întinsăInput.y, 0, REAR_STRETCH_Y); Întoarcere întinsă;
În general, cred că am coborât destul de ușor aici, în parte datorită modului în care jocul se bazează în întregime pe un gest simplu. Transmiterea peste interfețe radical diferite poate fi o adevărată durere de cap și, făcută prost, are potențialul de a strica un joc altfel grozav. Dacă am fi porționat un joc de acțiune terț pentru Wii, această secțiune ar fi fost considerabil mai lungă.
Nu voi minți; Am o adevărată relație de dragoste / ură cu audio. În timpul meu la Free Radical Design am petrecut mult timp lucrand cu tipii audio de la echipa de motoare și designeri de sunet pentru a obține pentru a obține audio în joc și sa bucurat de imens. Audio într-adevăr ridică un joc și îl aduce la viață.
Din păcate, partea mai joasă a lucrurilor, cu cocktailul de formate de fișiere, rate de eșantionare, comprimare, voci, autobuze, streaming de fișiere și așa mai departe, nu ma entuziasmat niciodată în același mod. Așa că am abordat această sarcină cu o anumită frică.
Din fericire, Vita SDK este umplut cu eșantioane (actualizate în mod regulat) care acoperă temeinic toate modurile de utilizare a API-ului audio. Minimul pe care doriți să-l doriți, chiar și în cele mai simple jocuri 2D, este abilitatea de a juca sunete unice (efectele sonore ale jocului) și abilitatea de a transmite audio (muzică și orice alte fișiere mari care sunt prea mari pentru a țineți încărcat în memorie tot timpul). Într-o mulțime de jocuri 2D ați putea alege chiar să rămânem doar cu mono și să vă salvați puțină memorie suplimentară - poate chiar dacă vă permiteți să evitați streamingul complet.
Cu o mare referință la lucrul din eșantioane, am avut toate audio-ul de funcționare și în câteva zile. Singura altă lucrare majoră a audio-ului a fost o comutare întârziată în format audio de la VAG la un format proprietar cu un nivel mult mai mare de compresie, ceea ce a redus utilizarea memoriei audio la aproximativ 30% din ceea ce fusese anterior.
În cele din urmă, procesul de implementare a sunetului a fost o experiență mult mai puțin dureroasă decât mă temea.
Quell Memento este un joc single player care nu are un gameplay în rețea și caracteristici limitate online, deci teoretic ar fi trebuit să fie una din zonele mai simple. Realitatea scoate în evidență una dintre provocările legate de portarea pe o platformă PlayStation: TRC-urile tematice (Lista de verificare a cerințelor tehnice - o listă a dezvoltatorilor care nu trebuie să îndeplinească cerințele de calitate).
Ar trebui să subliniez că Sony nu este unic aici; Microsoft și Nintendo au echivalentele lor. Spre deosebire de mobil, în cazul în care funcționalitatea online este adesea furnizată de o soluție terță parte a platformei terțe sau de PC, unde singura persoană care se pronunță asupra implementării dvs. va fi utilizatorul final, pe console această zonă tinde să fie foarte mult controlată. Acest lucru are de-a face cu asigurarea faptului că funcționalitatea oferită de un serviciu, cum ar fi PSN, se comportă în mod consecvent între titluri și că se respectă încuietoarea părintească, ratingul de vârstă și așa mai departe.
Ca urmare, dacă porți la o consolă, chiar și pentru un joc cu caracteristici online relativ simple, acest lucru poate dura mai mult timp decât vă așteptați. Pentru un port, conformarea cu TRC poate fi una dintre cele mai intruzive părți ale muncii pe care trebuie să o faceți. Cerințele specifice privind modul de gestionare a evenimentelor, cum ar fi pierderea conexiunii sau refuzul accesului la caracteristici datorate blocării părintești, precum și calendarul și modul în care trebuie să transmiteți aceste informații utilizatorului, pot necesita un anumit grad de întoarcere între dvs. joc și componente de rețea care pur și simplu nu existau în jocul original.
Am folosit o bibliotecă furnizată de Sony care împachetează toate setările de nivel scăzut și teardown de PSN și sarcini online într-o interfață destul de simplă, oferind callbacks pentru toate sarcinile asincrone. Apelurile din joc în funcționalitatea online ar putea fi firificate până la câteva grupuri distincte - login, store și leaderboards - fiecare cu câțiva parametri pentru a specifica detaliile.
Toate acestea însemnau că o cerere online ar putea fi declanșată cu doar câteva linii de cod și am ajuns probabil la nu mai mult de cinci sau șase funcții diferite numite din joc pentru a susține caracteristicile online.
Întoarcerile de la agendă Sony oferă detalii detaliate detaliate asupra oricărui lucru care nu merge bine, însă, în cea mai mare parte, acestea pot fi pur și simplu clasificate ca fiind un succes sau un eșec și apelul corespunzător la joc declanșat. Acest lucru a însemnat că am putea, de asemenea, să arunce înapoi apelurile de la motor în joc în apeluri în mod similar.
Stările de eroare au fost manipulate cât mai mult posibil în codul motorului. Acest lucru a însemnat că tipii de copaci Fallen ar putea continua să dezvolte Quell fără a fi nevoiți să vă faceți griji cu privire la stările de defecțiune specifice Vita.
De exemplu, dacă o funcție a motorului a avut un apel prealabil care ar putea eșua, mai degrabă decât să solicite jocului să apeleze la orice condiții prealabile și atunci solicitarea sa, am numi cerința prealabilă în tăcere, caching-ul cererii reale. Dacă condiția esențială a eșuat, am arunca cererea și vom anunța jocul prin apelul normal, invocând dialogul de pe partea motorului. Cu privire la succes, cererea va fi executată conform destinației.
În general, acest lucru a funcționat bine; ca și în cazul oricărui sistem care este adăugat mai târziu și face tot ce este mai bun pentru a nu fi intruzitiv, au existat una sau două bucăți de coduri mai puțin decât elegante,.
Salvați jocuri merită menționat, deoarece, la fel ca în cazul funcționalității de rețea de mai sus, acestea sunt supuse unui grad ridicat de control în ceea ce privește TRC-urile. Salvați jocurile sunt predispuse la două erori cheie: lipsa stocării fișierelor sau pierderea cotei de salvare.
(Am exclus excluderea corupției, deoarece într-adevăr nu puteți face multe despre o salvare coruptă, sistemul vă va avertiza și îl puteți informa pe utilizator, dar oricare dintre voi puteți face este să îl eliminați și să treceți mai departe ... și poate avea un mic strigăt liniștit în toate orele pierdute.)
Rularea sistemului de stocare a fișierelor este destul de explicativă: pur și simplu nu este suficient spațiu pentru a salva ceea ce doriți. Cota de salvare este stabilită în timpul dezvoltării jocului; este, în esență, o limită auto-declarată privind cantitatea de memorie pe care aplicația dvs. o va avea vreodată nevoie pentru a salva datele jocului. Totuși, această cotă nu este alocată la instalarea jocului dvs. - nu este garantat că există.
În tratarea fiecăruia dintre acestea aveți cu adevărat două opțiuni.
Dacă jocul nu se află în stocarea sistemului de fișiere, puteți:
În ceea ce privește depășirea cotei de salvare, puteți:
Natura lui Quell ne-a permis să facem acest lucru destul de concis, mergând cu opțiunile 2 și respectiv 1. Quell nu este un joc în cazul în care ați putea dori să sară înapoi la dvs. de salvare de cinci minute în urmă, astfel încât doar o singură salvare este necesară și acest lucru este creat automat, salvate și încărcate. Conținutul și, prin urmare, dimensiunea salvării este oarecum previzibilă.
La prima redare, sistemul nostru de salvare va încerca să aloce cantitatea maximă de memorie pe care o va avea vreodată pentru fișierul dvs. de salvare. În cazul în care nu poate face acest lucru - adică dacă sistemul de stocare a sistemului de fișiere este deja insuficient, acesta va afișa mesajul standard prezentat mai jos:
Jucătorul nu are voie să continue până când nu rezolvă această problemă (minimizând sau închizând aplicația și ștergând unele date). Odată ce au lovit OK, vor încerca din nou să aloce memoria. Odată ce această salvare inițială a fost creată cu succes, este sigur să presupunem că nu va apărea niciodată o lipsă în sistemul de fișiere și o cota de salvare.
Am menționat deja pe scurt TRC-urile (Lista de verificare a cerințelor tehnice) și, în calitate de disclaimer, aș spune că sunt fericit că există TRC-uri; ca lucruri de gamer, cum ar fi PSN, au devenit o parte integrantă a experienței pe care o apreciez că știu că mă pot aștepta la un anumit grad de consecvență în comportamentul jocurilor.
Acestea fiind spuse, ca dezvoltator, ele sunt o durere. Am avut noroc că jocul era relativ simplu și ca atare multe TRC-uri ar putea fi pur și simplu ignorate, deoarece nu se aplicau. Chiar dacă lucrați la aducerea unui joc relativ simplu la oricare dintre console, vă recomand să vă familiarizați cu regulile acelei platforme din timp și se referă la ele de multe ori. Ceea ce poate fi acceptat pe o singură platformă poate să nu zboare pe altul și nu doriți să așteptați până când veți primi o listă mare de motive pentru care ați eșuat în AQ pentru a vă da seama că faceți totul greșit.
Pentru o echipă mică fără un departament dedicat departamentului de asigurare a calității, aceasta poate părea o sarcină foarte dificilă, dar un mic sens și o planificare pot face diferența.
În primul rând, o mulțime de cerințe sunt doar o modalitate specifică de a vă solicita să nu faceți lucruri stupide pe care, probabil, nu vreți să le faceți oricum - mulțumit, băieții FTG au evitat deja să facă ceva stupid, deci a fost un început bun.
În al doilea rând, am păstrat o foaie de calcul a tuturor cerințelor și dacă acestea au trecut, au eșuat, nu au putut fi testate încă sau pur și simplu nu erau aplicabile. Deoarece caracteristicile cheie au intrat în joc, am putea face o măturică din această listă pentru a actualiza starea fiecărei cerințe și, în același timp, a ne reîmprospăta amintirile cu privire la restricțiile aplicate.
În momentul în care am ajuns la faza noastră de asigurare a calității, am avut o idee destul de clară despre locul în care am stat în ceea ce privește TRC-urile și nu ne-am confruntat cu nici o surpriză urâtă.
Asigurați-vă că ați stabilit în mod clar termenele și obiectivele. Aceasta este mai mult o chestiune de afaceri decât tehnică, dar esențială dacă transferați un joc pentru altcineva, chiar dacă este doar un proiect de hobby printre prieteni. (Vrei să rămâi prieteni, nu?)
Când am început să lucrăm la Quell Memento, nu a fost terminat și în timp ce exista un sentiment general despre data finalizării, nimic nu a fost pus în piatră. În final, întregul proiect a durat mai mult decât era de așteptat.
În retrospectivă, ar fi fost preferabil să așteptăm ca jocul să fie complet finalizat - sau cel puțin mult mai complet - înainte de a începe portul nostru. Pe măsură ce pornim motorul, acesta a fost rar afectat de noul gameplay și de conținut, dar au existat ocazii când caracteristicile au necesitat modificări ale motorului. Au fost, de asemenea, momente în care progresul la portarea motorului a fost blocat în timp ce am așteptat noi caracteristici care urmează să fie adăugate.
Avem o relatie minunata cu baietii de la FTG si am fost destul de norocosi in aceste situatii pentru a avea flexibilitatea de a trece la proiectele proprii pentru aceste perioade (inclusiv investigarea unor caracteristici unice ale Vita, cum ar fi realitatea augmentata), dar ca oricine care a încercat vreodată un pic de multitasking ar trebui să știe, acesta nu este cel mai eficient mod de a munci.
Este greu de subliniat o singură învățătură singulară pe care am învățat-o; am acumulat mai mult o acumulare incrementală de cunoștințe cu privire la noile instrumente, API-uri și procese.
În viitor, ar fi mai îndrăzneț să ne forțăm (sau cel puțin să sugerăm) schimbări în codul jocului în cazul în care s-ar fi simțit rezonabil - poate că am făcut mai multe sarcini mai greu decât trebuiau să fie de această dată. Dar definiția "rezonabilă" va fi întotdeauna diferită de la proiect la proiect.
În plus, probabil am aștepta ca un joc să fie mai complet înainte de a începe să lucreze la un port în viitor, având mai mulți oameni să lucreze pe el în mod solid pentru mai puțin timp. Din nou, fezabilitatea acestui lucru ar putea varia foarte mult între proiecte în funcție de programul de lansare. După ce am făcut o singură dată, putem acum să estimăm mult mai mult cât este de mult necesar.
Cel mai important lucru, am câștigat luni de experiență valoroasă pe o nouă platformă, inclusiv procesul de depunere - chiar și posibilitatea de a investiga unele dintre caracteristicile sale unice. Pentru o echipă care se bazează în mare parte pe munca de angajare și contractul de lucru ca sursă de venituri, valoarea acestui lucru nu poate fi subestimată.
Sfatul meu pentru oricare dintre voi care vă gândiți la un port la Vita ar fi să-i dați un crăpătură. Cred că există o anumită misiune înconjurătoare a consolei; am avut norocul de a avea experiență în acest domeniu, dar chiar și fără asta nu ar trebui să vă opriți.
Sony este foarte primitoare pentru indienii și dezvoltatorii mici (ceea ce cred că devine evident pentru comunitatea de jocuri mai extinsă) și, dacă aveți un grad rezonabil de cunoștințe tehnice de dezvoltare a jocului, atunci cu sprijinul mare din echipa de suport pentru dezvoltatorii Sony nu trebuie nu se confruntă cu nici o provocare insurmontabilă.
Quell Memento pentru Vita este disponibil acum în SCEA și SCEE.
