Share
Daniel Schuller en ik vormden Bigyama in 2012, na te hebben gewerkt aan verschillende titels zoals Magic the Gathering: Duel of the Planeswalkers en Star Wars: Battlefront. Het bedrijf begon met een slecht getimede sprong naar PlayStation Home en een verhuizing naar Schotland, voor een terugkeer naar Nottingham en een heroriëntatie op onze kerntalenten: programmeren en geweldige games maken! Onze eerste stap was om de technische karbonades aan te bieden om Fallen Tree Games Quell Memento naar de PlayStation Vita te laten brengen.
Dit artikel bespreekt hoe we bij Bigyama Quell Memento hebben overgedragen aan Vita. Als je meer wilt weten over het ontwerp van Quell, kijk dan eens naar Fallen Tree's artikel, The Making of Quell.
Memento is de derde game in de Quell-serie; de vorige games hadden het heel goed gedaan op mobiel en ik had Joe en Lewis al een tijdje op FTG gekend, nadat ze voor hun overlijden met Free Radical Design hadden gewerkt. Het was geweldig om de kans te krijgen om weer met ze samen te werken en om de kans te krijgen om aan een nieuw platform te werken.
Enige tijd geleden had ik het team van Honeyslug ontmoet, ontwikkelaars van de succesvolle PSP Mini Kahoots, die vervolgens Vita lanceertitel Frobisher Says ontwikkelde. Ze brachten ons in contact met het team voor ontwikkelaarsrelaties bij SCEE (Sony Computer Entertainment Europe).
We gingen naar de SCEE-studio in Londen en bespraken de opties - PSP Mini, PlayStation Mobile of PlayStation Vita - die ontwikkelaars allebei toegang geven tot Vita met verschillende functieniveaus. Na een paar e-mails heen en weer besloten we dat de beste optie voor Quell was om een native Vita-game te maken, waardoor we volledige toegang hebben tot de kracht van de Vita en alle functies van PSN, zoals scoreborden en trofeeën..
Vaak bepaalt de eerste taak bij het maken van een game welke engine moet worden gebruikt. Er zijn een aantal motoren beschikbaar op de Vita, maar de meeste zijn volledig overkill vanuit een technisch perspectief en zijn vanuit financieel oogpunt onhaalbaar voor een project van deze omvang..
Er is ook de vaak over het hoofd gezien PhyreEngine, ontwikkeld door Sony zelf en gratis te gebruiken door geregistreerde PlayStation-ontwikkelaars - het is gebruikt om games te ontwikkelen van Demon Souls tot Colin McRae: Dirt and Journey. Nogmaals, je kunt je waarschijnlijk voorstellen dat dit zoveel meer was dan we echt nodig hadden, zoals het proberen een noot te kraken met een voorhamer.
Handig genoeg gebruikte Quell Memento de eigen engine van Fallen Tree Games, en zowel de engine als de game code zijn geschreven met behulp van C. C en de varianten zijn de standaardtaal die wordt gebruikt om games te maken en als je een game ontwikkelt om op veel verschillende platforms te gebruiken, zou eigenlijk niet met iets anders moeten meegaan.
Dit maakte onze beslissing duidelijk: we zouden de motor van Fallen Tree Game zelf overhevelen naar de Vita. Het was gratis, het was speciaal gebouwd om Quell-games uit te voeren en het was een leuke codebase.
Het klinkt misschien contra-intuïtief om alle engines die al op Vita draaien te negeren en een engine te kiezen die dat niet doet, maar een game naar een nieuwe engine verplaatsen, kan betekenen dat je de hele game voor die engine moet herscheppen omdat deze op een heel andere manier werkt . Het porten van de motor adresseert de oorzaak van het probleem. Je hoeft je geen zorgen te maken over het opnieuw creëren van elke afzonderlijke gameplay-functie - je hoeft alleen maar de functionaliteit na te bootsen die ze allemaal bovenop zitten.
Als je geluk hebt, biedt een haven je de mogelijkheid om je eigen technologie voor een nieuw platform te ontwikkelen en tegelijkertijd daarvoor betaald te krijgen. Bigyama heeft een eigen interne engine en als Quell Memento was gebouwd op een engine zonder toegang tot de broncode, zoals UDK of Unity, zou dit de moeite waard zijn geweest om te overwegen.
Het mooie van het ontwikkelen van een haven is dat je een duidelijk doel hebt om naartoe te streven.
Het mooie van het ontwikkelen van een haven is dat je een duidelijk doel hebt om naartoe te streven.
Dit lijkt in eerste instantie misschien ontmoedigend, maar het kan worden opgesplitst in een paar belangrijke gebieden: afbeeldingen, gebruikersinvoer, audio, netwerken en games opslaan.
Zoals ik eerder al zei, betekende porteren van de engine dat er geen significante spelcode geschreven of herschreven moest worden; in deze situatie zou het werken aan deze kerngebieden betekenen dat het spel grotendeels voor zichzelf zorgt. De vroege stadia van het maken van een spel is een streepje voor plezier in het spel, maar met een poort is het een streepje voor voldoende gebruik om erachter te komen waar het is gebroken.
Begin bij het maken van een poort met de afbeeldingen.
Het is de beste plaats om te beginnen - als je niets op het scherm kunt weergeven, zal het erg moeilijk zijn om te weten of je vooruitgang boekt. We zijn begonnen met de graphics voordat we zelfs een Vita in handen kregen. De grafische API van de Vita lijkt sterk op OpenGL en Quell Memento gebruikte OpenGL al.
Quell gebruikte een pijplijn met vaste functie (wat betekent dat de gebruiker alleen fasen van het weergaveproces kan configureren via een vaste reeks functies), maar de Vita gebruikte een programmeerbare pijplijn (met shaderprogramma's kunnen eerder gefixeerde fasen van het renderingproces worden geprogrammeerd zoals de gebruiker wenst).
We hadden een korte periode tussen het worden van gelicentieerde ontwikkelaars en het ontvangen van de ontwikkelingskits, dus in onze eigen engine (die Lua / C ++ / OpenGL gebruikte) hebben we het gedrag van de OpenGL-matrixstapel nagebootst met behulp van shaders en kleine aangepaste code. Dit betekende dat alle bestaande Quell-code - die gebaseerd was op de traditionele vaste-functiepijplijn - grotendeels onaangetast kon blijven.
// Een deel van onze verpakking om de OpenGL-matrixstapel te emuleren // U kunt het volledige bestand hier vinden: https://github.com/balaam/glfacade Matrix4 glfCalcProjMatrix () Matrix4 mat; mat = mat.identity (); voor (int i = 0; i < (int)g_glFacade.projectStack.size(); i++) mat = mat * g_glFacade.projectStack[i]; return mat;
Zodra we kits hadden, hadden we snel iets in gebruik. Er was een beetje werk aan de winkel, zoals het converteren van het kleurformaat van de hoekpunten naar de verwachting van de arcering en het opnieuw inpakken van de hoekpuntgegevens van verschillende afzonderlijke buffers, die elk afzonderlijke hoekpuntattributen bevatten - positie, UV's, enzovoort - in een enkele interleaved buffer zoals getoond in het diagram hieronder:
Met de toevoeging van een zeer eenvoudige shader, hadden we al snel ons splash-scherm op de set staan ... soort:
Met de toevoeging van een eenvoudige shader om texturen toe te passen, werd dat snel dit:
Zoals ik al zei, gebruikte Quell de vaste-functiepijplijn en de Vita's was programmeerbaar - wat betekent dat alle rendering geconverteerd moest worden om shaders te gebruiken in plaats van de vaste functiebenadering van het instellen van een veelvoud van verschillende render-staten om een bepaald effect te bereiken.
Er zijn een paar stromingen over hoe je je shaders moet beheren. Een daarvan is om een afzonderlijke arcering te maken voor elk materiaal of effect; de andere is de 'uber-shader'-benadering, een enorme shader die gebruikmaakt van pre-processor definities om de varianten te produceren die nodig zijn bij het compileren. Elk heeft zijn eigen voor- en nadelen:
Individuele shaders - Pluspunten:
Individuele shaders - Nadelen:
Uber-shader - Pluspunten:
Uber-shader - Nadelen:
In werkelijkheid zullen de meeste projecten waarschijnlijk een combinatie van beide benaderingen gebruiken. Voor onze Quell-poort kozen we ervoor om volledig te gaan met de individuele shader-aanpak, omdat onze vereisten zo eenvoudig en vast waren.
Het spel vertrouwde op relatief weinig verschillende combinaties van de OpenGL renderstatussen. Om een idee te geven van hoe eenvoudig onze shader-vereisten waren, heb ik hier de meest complexe toegevoegd:
float4 main (float4 vColor: COLOR0, float2 vTexCoord: TEXCOORD0, float2 vTexCoord1: TEXCOORD1, float2 vTexCoord2: TEXCOORD2, uniforme sampler2D-testTex: TEXUNIT0, uniforme sampler2D-testTex1: TEXUNIT1, uniforme sampler2D-testTex2: TEXUNIT2) float4 texResult = tex2D (testTex, vTexCoord ); float4 texResult2 = tex2D (testTex1, vTexCoord1); float4 texResult3 = tex2D (testTex2, vTexCoord2); float4 currentCol = texResult; currentCol [0] = texResult3 [0] * vColor [0]; currentCol [1] = texResult3 [1] * vColor [1]; currentCol [2] = texResult3 [2] * vColor [2]; currentCol [3] = ((texResult2 [3]) * (texResult [3])) * vColor [3]; return currentCol;
De Quell Vita-code had in totaal 13 shaders: acht shader-programma's (één hoekpunt en zeven fragment-shaders), gecombineerd met specifieke overvloeimodi. Het was vrij eenvoudig om code te vervangen in de Quell-engine die alle OpenGL-variabelen instelde met oproepen om in plaats daarvan een arcering in te stellen:
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);
werd:
rlSetShader (RL_SHADER_BLEND_RGBA_4);De
Accentsconagua
rl (renderlaag) -functies zijn een reeks functies die de OpenGL-functionaliteit omwikkelen; de 4 in RL_SHADER_BLEND_RGBA_4 aangegeven dat dit onze vierde variant van deze RGBA-shader was - met zo weinig shaders hadden we geen bijzonder beschrijvende naamgevingsconventie nodig. Deze rl functies bestonden al in de Quell-engine, maar als het spel dat moet worden geporteerd geen gebruik maakt van dit soort abstractie, is het iets dat je in een vroeg stadium wilt toevoegen. Hiermee kan de renderingcode worden weggetrokken zodat platformspecifieke wijzigingen kunnen worden doorgevoerd zonder de gamecode te beïnvloeden.
De idealist in mij had echt graag een op uber-shader gebaseerd systeem geïmplementeerd. Dit zou echter overkill zijn geweest en vereist werk van de FTG-jongens om te ondersteunen, iets waar we hard aan hebben gewerkt om het te minimaliseren. Porting verschilt niet van enige andere programmeertaak, in die zin dat je altijd 'het klusje klopt' afzet tegen je geïdealiseerde visie van hoe het werkt moeten klaar zijn.
Uiteindelijk waren er maar heel weinig kopzorgen om de grafische kant van het spel op gang te krijgen, hoewel er wat frustrerende tijd verspild zat aan het opsporen van wat ik aannam als een geheugenoverschrijving in de weergavecode. Het duurde een tijdje voordat ik me dat realiseerde, in tegenstelling tot oproepen als glDrawArrays in OpenGL, waar uw array wordt gekopieerd wanneer u de oproep doet, doen de draw-oproepen van de Vita dat niet - dat wil zeggen, u kunt de vertex-buffer die u doorgeeft aan de draw-oproepen van de Vita niet opnieuw gebruiken totdat deze klaar is met tekenen. Zoals je kunt zien aan de hand van de onderstaande screenshot, kan dit een behoorlijke rommel opleveren.
... leek af en toe een beetje meer op deze, vaak voor slechts een enkel frame. De oplossing hiervoor was eenvoudigweg om bestaande functionaliteit in de API te gebruiken om te wachten totdat het met de buffer was voltooid, maar het was een tijdige herinnering aan de gevaren van het maken van aannames over de manier waarop dingen werken op een nieuw platform (en ook wat uw bug is) kan zijn, op elk platform).
We hadden hier het geluk dat de eerdere games al waren uitgebracht op Sony's Xperia Play, wat betekent dat er niet veel werk nodig was om de knoppen te laten werken - veel fysieke besturingselementen die bestaan op de Vita bestaan op de Xperia en de gerelateerde functionaliteit was al aanwezig.
Dit betekende dat het eigenlijk gewoon een kwestie was van het in kaart brengen van de hardwaresleutels van de softwaretoetsen en het doorgeven van de knop "ingedrukt" en "vrijgegeven" toestanden aan de bestaande invoerbehandelingscode.
Omdat de game afkomstig was van mobiele apparaten, gold hetzelfde voor het front-touchpaneel. Het achteraanraakpaneel had een beetje finessing nodig, het voor de hand liggende probleem is dat je deze beide niet eenvoudig in dezelfde stream van inputs kunt invoeren, want als een speler beide panelen aanraakt en de voorkant loslaat, wil het spel dat mogelijk registreren als de equivalent van het vrijgeven van de rug of het kan niet.
Er was ook een beetje werk in het verkrijgen van invoer via het achterpaneel (wat niet hetzelfde formaat is als het scherm) om aan te voelen alsof ze correct in kaart werden gebracht op het scherm aan de voorzijde. Dit werd bereikt door een dode zone langs de rand van het achterpaneel te negeren en de ingangen in dit gebied te schalen om naar het scherm toe te wijzen.
// inputs achterin lijken niet volledig overeen te komen met het bereik van het frontscherm, dus stretch in code // dit zijn waarden die gemakkelijk toegankelijk voelden. #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 # definieer REAR_STRETCH_Y 544 static vec2 vitaMapRearInputToScreen (int inputX, int inputY ext2 stretchedInput; stretchedInput.x = (inputX-REAR_DEADZONE_MIN_X) * REAR_STRETCH_X / (REAR_DEADZONE_MAX_X-REAR_DEADZONE_MIN_X); stretchedInput.x = clampf (stretchedInput.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 (stretchedInput.y, 0, REAR_STRETCH_Y); return stretchedInput;
Al met al denk ik dat we hier vrij licht zijn uitgestapt, deels vanwege de manier waarop het spel volledig afhankelijk is van een eenvoudig uithaalbeweging. Overal radicaal verschillende interfaces overbrengen kan een echte hoofdpijn zijn en, slecht gedaan, heeft het potentieel om een verder geweldige game te verlammen. Als we een third-person actiegame hadden overgedragen aan de Wii, zou dit gedeelte aanzienlijk langer zijn geweest.
Ik zal niet liegen; Ik heb een echte liefde / haat relatie met audio. In mijn tijd bij Free Radical Design heb ik veel tijd besteed aan het werken met de audiculanten van het motorteam en geluidsontwerpers om audio in het spel te krijgen en er enorm van genoten. Audio tilt een game echt op en brengt het tot leven.
Helaas heeft de meer low-level kant van de dingen, met zijn cocktail van bestandsindelingen, sample rates, compressie, stemmen, bussen, bestandsstreaming en dergelijke, me nooit op dezelfde manier enthousiast gemaakt. Dus benaderden we deze taak met enige schroom.
Gelukkig is de SDK van Vita gevuld met (regelmatig bijgewerkte) voorbeelden die alle manieren om de audio-API te gebruiken grondig omvatten. Het minimum dat je wilt, zelfs in de meest eenvoudige 2D-games, is de mogelijkheid om eenmalige geluiden (de geluidseffecten van de game) en de mogelijkheid om audio te streamen (muziek en alle andere grote bestanden die te groot zijn voor houd de hele tijd in het geheugen geladen). In veel 2D-games kun je er waarschijnlijk zelfs voor kiezen om je alleen met mono te houden en jezelf een beetje extra geheugen te besparen - misschien kun je zelfs voorkomen dat je helemaal wordt gestreamd.
Met een goede verwijzing naar het werken vanuit de voorbeelden, hadden we alle audio binnen een paar dagen gereed. Het enige andere belangrijke stuk werk aan de audio was een late overschakeling van het audioformaat van VAG naar een eigen formaat met een veel hoger compressieniveau, waardoor het gebruik van ons audiogegeheugen verminderde tot ongeveer 30% van wat eerder was gebruikt.
Uiteindelijk was het proces om de audio te implementeren een veel minder pijnlijke ervaring dan ik had gevreesd.
Quell Memento is een spel voor één speler zonder netwerkgameplay en beperkte online functies, dus in theorie zou dit een van de eenvoudigere gebieden moeten zijn geweest. De realiteit belicht een van de uitdagingen van porten naar een PlayStation-platform: de gevreesde TRC's (Technical Requirement Checklist - een lijst met do's en don'ts die ontwikkelaars moeten uitvoeren om QA te behalen).
Ik moet erop wijzen dat Sony hier niet uniek is; Microsoft en Nintendo hebben hun equivalenten. In tegenstelling tot mobiel, waarbij online functionaliteit vaak wordt geboden door een crossplatform-oplossing van een derde partij of een pc, waarbij de enige persoon die een oordeel velt over uw implementatie de eindgebruiker zal zijn, heeft dit gebied op de consoles de neiging om onder grote controle te komen. Dit heeft deels te maken met het zorgen dat de functionaliteit van een service zoals PSN zich op een consistente manier over alle titels gedraagt en dat ouderlijke vergrendelingen, leeftijdsclassificaties, enzovoort worden nageleefd.
Als gevolg hiervan, als je porteert naar een console, zelfs voor een spel met relatief eenvoudige online functies, kan dit meer tijd kosten dan je zou verwachten. Voor een haven kan het voldoen aan TRC's een van de meest indringende onderdelen zijn van het werk dat u moet doen. Specifieke vereisten voor het omgaan met gebeurtenissen zoals verlies van verbinding of ontzegging van toegang tot functies als gevolg van ouderlijk toezicht, en de timing en manier waarop u deze dingen aan de gebruiker moet doorgeven, kan een zekere mate van heen en weer vereisen tussen uw spel- en netwerkcomponenten die gewoon niet bestonden in het originele spel.
We gebruikten een door Sony verstrekte bibliotheek die alle low-level setup en demontage van PSN en online-taken omspande tot een vrij eenvoudige interface, die callbacks biedt voor alle asynchrone taken. De oproepen van het spel naar de online functionaliteit kunnen worden teruggebracht tot een paar verschillende groepen - login, store en leaderboards - elk met een paar parameters om de details te specificeren.
Dit alles betekende dat een online verzoek kon worden geactiveerd met slechts een paar regels code, en we eindigden met waarschijnlijk niet meer dan vijf of zes verschillende functies van het spel om de online functies te ondersteunen.
De terugbelverzoeken van de Sony-wrapper bieden vrij gedetailleerde informatie over alles wat fout gaat, maar voor het grootste deel kunnen deze eenvoudig worden aangemerkt als een succes of een mislukking en de juiste callback naar de game geactiveerd. Dit betekende dat we ook de callbacks van de engine naar de game konden terugbrengen in even weinig oproepen.
Foutenstaten werden zoveel mogelijk in de motorcode verwerkt. Dit betekende dat de Fallen Tree-jongens door konden gaan met het ontwikkelen van Quell zonder zich zorgen te hoeven maken over Vita-specifieke faaltoestanden.
Als een engine-functie bijvoorbeeld een vereiste call had die mogelijk zou kunnen falen, in plaats van te eisen dat de game alle vereisten oproept en dan In zijn verzoek zouden we de vereiste stil noemen, waarbij het daadwerkelijke verzoek in de cache wordt geplaatst. Als de vereiste niet zou werken, zouden we het verzoek dumpen en het spel informeren via de normale terugroepactie, waarbij het dialoogvenster van de motor wordt opgeroepen. Bij succes zou het verzoek worden uitgevoerd zoals bedoeld.
Dit werkte over het algemeen goed; zoals met elk systeem dat later wordt toegevoegd en zijn best doet om niet-opdringerig te zijn, waren er een of twee minder-dan-elegante stukjes code, maar het deed het werk.
Spaargames zijn het vermelden waard, omdat ze, net als bij de bovenstaande netwerkfunctionaliteit, onderhevig zijn aan een hoge mate van controle op het gebied van TRC's. Spaarspellen zijn gevoelig voor twee belangrijke fouten: onvoldoende bestandsopslag of onvoldoende opslagquota.
(Ik heb save corruptie uitgesloten omdat er echt niet veel is dat je kunt doen aan een corrupte save, het systeem zal je er op attenderen en je kunt de gebruiker informeren, maar een van jullie beiden kan het doen en verwijderen ... en misschien stilletjes huilen om al die verloren uren.)
Het opraken van de opslag van het bestandssysteem spreekt voor zich: er is simpelweg niet genoeg ruimte om te besparen wat u wilt. Het opslagquotum wordt ingesteld tijdens de ontwikkeling van je spel; het is in wezen een zelfverklaarde limiet voor de hoeveelheid geheugen die uw toepassing ooit nodig heeft voor opgeslagen gamegegevens. Dit quotum is echter niet allemaal toegewezen bij de installatie van je spel - het is niet gegarandeerd dat het bestaat.
Bij het hanteren van elk van deze heb je echt twee opties.
Als de opslag van het bestandssysteem vol raakt, kunt u:
Met betrekking tot onvoldoende opslagquotum kunt u:
Door de aard van Quell konden we dit nogal beknopt aanpakken door met opties 2 en 1 te gaan. Quell is geen game waar je misschien terug wilt naar je save van vijf minuten geleden, dus er is maar één save nodig en dit wordt automatisch aangemaakt, -gesaved en -loaded. De inhoud en dus de grootte van het opslaan is enigszins voorspelbaar.
Bij de eerste keer spelen probeert ons opslagsysteem de maximale hoeveelheid geheugen toe te wijzen die het ooit nodig zal hebben voor uw opslagbestand. Als dit niet het geval is, dat wil zeggen als er al onvoldoende opslagruimte voor het bestand beschikbaar is, wordt het standaardbericht hieronder weergegeven:
De speler mag niet doorgaan totdat hij dit probleem zelf heeft opgelost (door de app te minimaliseren of te sluiten en sommige gegevens te verwijderen). Zodra ze op OK drukken, zal het opnieuw proberen om het geheugen toe te wijzen. Zodra deze initiële opslag met succes is aangemaakt, is het veilig om aan te nemen dat een tekort in het bestandssysteem en het opslaan van quota nooit zal plaatsvinden.
Ik heb al kort de TRC's genoemd (de Checklist technische vereisten) en als disclaimer zou ik zeggen dat ik blije TRC's ben; als gamer zijn dingen zoals PSN zo'n integraal onderdeel van de ervaring geworden dat ik het op prijs stel dat ik een zekere mate van consistentie over het gedrag van games kan verwachten.
Dat gezegd hebbende, als ontwikkelaar zijn ze lastig. We hadden het geluk dat de game relatief eenvoudig was en daarom konden veel TRC's gewoon worden genegeerd omdat ze niet van toepassing waren. Zelfs als je eraan werkt om een relatief eenvoudig spel naar een van de consoles te brengen, raad ik je aan om je vertrouwd te maken met de regels van dat platform vroeg en verwijs naar hen vaak. Wat op het ene platform acceptabel zou kunnen zijn, mag niet op een ander platform vliegen, en je wilt niet wachten tot je een grote lijst met redenen krijgt waarom je hebt nagelaten dat QA beseft dat je het helemaal verkeerd doet.
Voor een klein team zonder een toegewijde QA-afdeling kan dit een hele ontmoedigende taak lijken, maar een klein beetje gevoel en planning kan het verschil maken.
Ten eerste zijn veel van de vereisten slechts een specifiek geformuleerde manier om je te vragen geen domme dingen te doen die je waarschijnlijk toch niet wilt doen - gelukkig hadden de FTG-jongens al vermeden om iets stoms te doen, dus dit was een goed begin.
Ten tweede hebben we een spreadsheet bijgehouden van alle vereisten en of ze nu zijn geslaagd, mislukt, nog niet konden worden getest of gewoon niet van toepassing waren. Omdat er belangrijke functies in het spel zijn opgenomen, konden we deze lijst doornemen om de status van elke vereiste bij te werken en tegelijkertijd onze herinneringen verfrissen over welke beperkingen werden toegepast.
Tegen de tijd dat we onze QA-fase bereikten, hadden we een vrij duidelijk beeld van waar we stonden met betrekking tot TRC's en we werden niet geconfronteerd met onaangename verrassingen.
Zorg ervoor dat je duidelijk afgesproken tijdschema's en doelen hebt. Dit is meer een zakelijke kwestie dan technisch, maar cruciaal als je een game voor iemand anders porteert, ook al is het maar een hobbyproject onder vrienden. (U wilt vrienden blijven, toch ?!)
Toen we aan Quell Memento begonnen, was het nog niet af en terwijl er een algemeen gevoel was over wanneer de einddatum zou zijn, was er niets dat in steen was veranderd. Uiteindelijk duurde het hele project langer dan verwacht.
Achteraf gezien had het de voorkeur gehad om te wachten tot het spel volledig af was - of in ieder geval veel completer - voordat we onze poort begonnen. Omdat we de engine porten, werd deze zelden beïnvloed door nieuwe gameplay en inhoud, maar er waren gelegenheden waarbij functies motorveranderingen vereisten. Er waren ook momenten waarop de voortgang van het porten van de motor werd geblokkeerd terwijl we wachtten op nieuwe functies die moesten worden toegevoegd.
We hebben een geweldige relatie met de jongens van FTG en hadden het geluk om in deze situaties de flexibiliteit te hebben om over te schakelen naar onze eigen projecten voor deze periodes (inclusief onderzoek van enkele van de meer unieke functies van de Vita, zoals de augmented reality), maar als iedereen wie ooit een beetje multitasking heeft geprobeerd, moet weten dat dit niet de meest efficiënte manier is om te werken.
Het is moeilijk om te wijzen op enkele uitzonderlijke opvallende lessen die we hebben geleerd; we hebben meer kennis opgebouwd over nieuwe tools, API's en processen.
In de toekomst zouden we misschien moediger zijn om veranderingen in de spelcode te forceren (of op zijn minst te suggereren), waar het redelijk leek - we hebben misschien sommige taken moeilijker gemaakt dan deze keer nodig waren. Maar de definitie van 'redelijk' varieert altijd van project tot project.
Bovendien zouden we waarschijnlijk wachten op een completere game voordat we in de toekomst aan een haven gaan werken, omdat er meer mensen voor minder tijd aan werken. Nogmaals, de haalbaarheid hiervan kan enorm variëren tussen projecten, afhankelijk van het releaseschema. Nu we het eenmaal hebben gedaan, kunnen we nu veel beter inschatten hoelang we nog nodig hebben.
Het belangrijkste is dat we maandenlange waardevolle ervaring hebben opgedaan op een nieuw platform, inclusief het indieningsproces - en zelfs de kans krijgen om enkele van zijn unieke kenmerken te onderzoeken. Voor een team dat grotendeels afhankelijk is van werk voor huur en contractwerk als bron van inkomsten inkomen, de waarde hiervan kan niet worden onderschat.
Mijn advies voor een van jullie die een haven aan Vita overweegt, is om het een kiertje te geven. Ik denk dat er een zekere mystieke omringende ontwikkeling van de console is; we hadden het geluk om ervaring op dit gebied te hebben, maar zelfs zonder dat moet je je niet laten afschrikken.
Sony is zeer gastvrij voor indies en kleine ontwikkelaars (iets waarvan ik denk dat het duidelijk wordt voor de bredere game-ontwikkelaarscommunity) en, als je een redelijke mate van technische kennis hebt over gameontwikkeling, dan moet je met de geweldige ondersteuning van het Sony supportteam voor ontwikkelaars geen onoverkomelijke uitdagingen tegenkomen.
Quell Memento voor Vita is nu beschikbaar in SCEA en SCEE.
