Share
Daniel Schuller og jeg dannet Bigyama i 2012, etter å ha jobbet med mange titler som Magic the Gathering: Duel of the Planeswalkers og Star Wars: Battlefront. Selskapet startet med en dårlig tid i PlayStation Home og et skritt til Skottland, før en retur til Nottingham og en ny fokusering på våre kjernetall: programmering og gode spill! Vårt første skritt var å levere de tekniske koteletter for å hjelpe Fallen Tree Games ta med Quell Memento til PlayStation Vita.
Denne artikkelen diskuterer hvordan vi på Bigyama portlette Quell Memento til Vita. Hvis du vil vite mer om designen til Quell, vennligst sjekk ut Fallen Trees artikkel, The Making of Quell.
Memento er det tredje spillet i Quell-serien; De forrige spillene hadde gjort det veldig bra på mobilen, og jeg hadde kjent Joe og Lewis på FTG for en stund, etter å ha jobbet med dem på Free Radical Design før det ble avsluttet. Det var flott å få sjansen til å jobbe med dem igjen og ha sjansen til å jobbe på en ny plattform.
Noen gang tilbake hadde jeg møtt teamet fra Honeyslug, utviklere av den vellykkede PSP Mini Kahoots som deretter fortsatte å utvikle Vita lanseringen tittelen Frobisher Says. De setter oss i kontakt med utviklerrelasjonerteamet på SCEE (Sony Computer Entertainment Europe).
Vi dro til SCEE-studioet i London og diskutert alternativene - PSP Mini, PlayStation Mobile eller PlayStation Vita - som gir utviklere tilgang til Vita med varierende grad av funksjonalitet. Etter noen få e-postmeldinger frem og tilbake, bestemte vi oss for at det beste alternativet for Quell var å lage et innfødt Vita-spill, noe som gir oss full tilgang til kraften til Vita og alle funksjonene i PSN, som topplister og trofeer.
Ofte bestemmer den første oppgaven med å lage et spill hvilken motor du skal bruke. Det finnes en rekke motorer tilgjengelig på Vita, men de fleste er fullstendige overkill fra et teknisk perspektiv og bare unfeasible fra et økonomisk perspektiv for et prosjekt av denne størrelsen.
Det er også ofte oversett PhyreEngine, utviklet av Sony selv og gratis å bruke av registrerte PlayStation-utviklere. Det har blitt brukt til å utvikle spill fra Demon Souls til Colin McRae: Dirt and Journey. Igjen, som du sannsynligvis kan forestille deg, var dette så mye mer enn vi virkelig trengte, som å prøve å knekke en mutter med en sledgehammer.
Heldigvis brukte Quell Memento Fallen Tree Games egen motor, og både motor- og spillkoden ble skrevet ved hjelp av C. C, og varianter er standardspråket som brukes til å lage spill, og hvis du utvikler et spill for å slippe ut på mange forskjellige plattformer, Jeg burde ikke gå med noe annet.
Dette gjorde vår beslutning åpenbar: vi ville porten Fallen Tree Game's motor i seg selv til Vita. Det var gratis, det ble bygget spesielt for å kjøre Quell-spillene, og det var en fin kodebase.
Det kan høres motintetivt å ignorere alle motorer som allerede kjører på Vita og velge en motor som ikke gjør det, men å flytte et spill til en ny motor kan bety å gjenopprette hele spillet for den motoren fordi den opererer på en helt annen måte . Drift av motoren adresserer roten til problemet. Du trenger ikke å bekymre deg for å gjenskape hver enkelt spillfunksjon - du må bare gjenskape funksjonaliteten de alle sitter på toppen av.
Hvis du er heldig, kan en port gi deg muligheten til å utvikle din egen teknologi for en ny plattform mens du blir betalt for å gjøre det. Bigyama har sin egen interne motor, og hvis Quell Memento hadde blitt bygget på en motor uten tilgang til kildekoden, for eksempel UDK eller Unity, ville dette vært verdt å vurdere.
Skjønnheten med å utvikle en port er at du har et klart mål å sikte på.
Skjønnheten med å utvikle en port er at du har et klart mål å sikte på.
Dette kan virke skremmende først, men det kan brytes ned på noen få viktige områder: grafikk, brukerinngang, lyd, nettverk og lagre spill.
Som jeg allerede har nevnt, portet motoren mente det var ingen signifikant spillkode som skulle skrives eller omskrives; i denne situasjonen bør man få disse viktige områdene til å bety at spillet i stor grad tar vare på seg selv. De tidlige stadiene av å lage et spill er et dash for å finne det morsomme i spillet, men med en port er det en dash for å få nok opp og løp for å finne ut hvor den er ødelagt.
Når du gjør en port, start med grafikken.
Det er det beste stedet å starte - hvis du ikke kan vise noe på skjermen, vil det være veldig vanskelig å vite om du gjør fremgang. Vi begynte på grafikken før vi selv fikk hendene på en Vita. Vita's grafikk-API er svært lik OpenGL, og Quell Memento brukte allerede OpenGL.
Quell brukte en fastfunksjonsrørledning (noe som betyr at brukeren kun kan konfigurere stadier av renderingsprosessen gjennom et fast sett med funksjoner), men Vita brukte en programmerbar rørledning (shader-programmer tillater trinn i gjengivelsesprosessen som tidligere ble fikset for å bli programmert som brukeren ønsker).
Vi hadde en kort periode mellom å bli lisensierte utviklere og mottatt utviklingssettene, så i vår egen motor (som brukte Lua / C ++ / OpenGL) emulerte vi oppførselen til OpenGL-matriksstakken ved hjelp av shaders og lite tilpasset kode. Dette betydde at alle eksisterende Quell-koden - som var basert på den tradisjonelle fastfunksjonsrørledningen - kunne forbli stort sett uberørt.
// Del av vår wrapper for å etterligne OpenGL-matrisestakken // Du kan finne hele filen her: https://github.com/balaam/glfacade Matrix4 glfCalcProjMatrix () Matrix4 mat; matte = mat.identitet (); for (int i = 0; i < (int)g_glFacade.projectStack.size(); i++) mat = mat * g_glFacade.projectStack[i]; return mat;
Når vi hadde kits, hadde vi raskt noe oppe. Det var lite arbeid å gjøre, for eksempel konvertering av fargestørrelsen til vertikene til det som forventes av shader og ompakning av vertexdata fra flere separate buffere, som hver inneholder separate verteksattributter - posisjon, UV og så videre - til en enkelt interleaved buffer som vist i diagrammet nedenfor:
Med tillegg av en veldig grunnleggende shader, hadde vi snart vår sprutskjerm oppe i kjøreturen ... type:
Med tillegg av en enkel skygge for å påføre teksturer, ble det snart dette:
Som nevnt, brukte Quell Permanent-funksjonen, og Vita-programmene var programmerbare. Det betyr at all gjengivelsen måtte konverteres for å bruke shaders i stedet for den faste funksjonen tilnærming til å sette en rekke forskjellige gjengivende stater for å oppnå en gitt effekt.
Det er et par tankeskoler om hvordan du skal håndtere dine shaders. Den ene er å skape en separat skygge for hvert materiale eller effekt; den andre er "uber-shader" -tilnærmingen, en stor skygge ved bruk av pre-prosessor definisjoner for å produsere varianter som trengs på kompileringstidspunktet. Hver har sine egne fordeler og ulemper:
Individuelle shaders - Pros:
Individuelle shaders - Cons:
Uber-shader - Pros:
Uber-shader - Ulemper:
I virkeligheten vil de fleste prosjekter sannsynligvis bruke en kombinasjon av begge tilnærminger. For vår Quell-port valgte vi å gå helt med den individuelle shader-tilnærmingen, da våre krav var så enkle og faste.
Spillet stod på relativt få forskjellige kombinasjoner av OpenGL-gjengestatusene. For å gi en ide om hvor enkelt våre skyggekrav var, har jeg lagt til det mest komplekse her:
float4 main (float4 vColor: COLOR0, float2 vTexCoord: TEXCOORD0, float2 vTexCoord1: TEXCOORD1, float2 vTexCoord2: TEXCOORD2, enhetlig sampler2D testTex: TEXUNIT0, uniform sampler2D testTex1: TEXUNIT1, uniform 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;
Quell Vita-koden hadde totalt 13 shaders: åtte shader-programmer (en toppunkt og syv fragment shaders) kombinert med spesifikke blandemoduser. Det var ganske enkelt å erstatte kode i Quell-motoren som satt opp alle OpenGL-variablene med samtaler for å angi en skygge i stedet:
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);
ble til:
rlSetShader (RL_SHADER_BLEND_RGBA_4);De
Accentsconagua
rl (gjengelag) funksjoner er et sett med funksjoner som pakker inn OpenGL-funksjonaliteten; de 4 i RL_SHADER_BLEND_RGBA_4 rett og slett antydet dette var vår fjerde variant av denne RGBA shaderen - med så få shaders vi ikke krever en spesielt beskrivende navngivningskonvensjon. Disse rl Funksjoner eksisterte allerede i Quell-motoren, men hvis spillet som skal portes ikke bruker denne typen abstraksjon, er det noe du vil legge til tidlig på. Det tillater renderingskoden å bli abstrakt bort, slik at plattformspesifikke endringer kan gjøres uten å påvirke spillkoden.
Idealisten i meg ville virkelig ha likt å ha implementert et uber-shader-basert system. Dette ville imidlertid vært overkill og kreves arbeid av FTG-gutta for å støtte noe vi jobbet hardt for å minimere. Porting er ikke forskjellig fra noen annen programmeringsoppgave, ved at du alltid skal veie opp "få jobben gjort" mot din idealiserte visjon om hvordan det bør bli ferdig.
Til slutt var det svært få hodepine i å få grafikk siden av spillet oppe, selv om det var litt frustrerende tid bortkastet sporing av hva jeg antok var et minne overskrive i gjengivelsen koden. Det var en stund før jeg skjønte at, i motsetning til samtaler som glDrawArrays i OpenGL, hvor matrisen din kopieres når du ringer, gjør Vita's ringer ikke det - det vil si, du kan ikke gjenbruke den vertexbufferen du passerer til Vitas tegneanrop til den er ferdig tegnet. Som du kan se fra skjermbildet under, kan det være ganske rotet å gjøre det.
... noen ganger så litt mer ut som dette, ofte for bare en enkelt ramme. Løsningen for dette var rett og slett å bruke eksisterende funksjonalitet i API-en for å vente til den var ferdig med bufferen, men det var en rettidig påminnelse om farene ved å gjøre forutsetninger om hvordan ting fungerer på en ny plattform (og også hva din feil kan være på hvilken som helst plattform).
Vi var heldige her da de tidligere spillene allerede var utgitt på Sonys Xperia Play, noe som betyr at det ikke var nødvendig med mye arbeid for å få knappene til å fungere - mange fysiske kontroller som eksisterer på Vita eksisterer på Xperia og relatert funksjonalitet var allerede på plass.
Dette betydde at det egentlig bare handlet om å kartlegge maskinvarenøklene til programvarenøklene og sende knappene "presset" og "frigitt" til den eksisterende inngangshåndteringskoden.
Da spillet hadde sin opprinnelse på mobilenheter, var det samme for frontpanelet. Det bakre berøringspanelet krever litt finessing, det åpenbare problemet er at du ikke bare kan mate disse begge inn i samme strøm av innganger, fordi hvis en spiller berører begge panelene og slipper fronten, kan spillet kanskje registrere det som tilsvarende å slippe tilbake eller det kan ikke.
Det var også lite arbeid med å få innspill fra bakpanelet (som ikke er like stor som skjermen) for å føle seg som om de var kartlegging riktig til frontskjermbildet. Dette ble oppnådd ved å se bort fra en døde sone grense rundt kanten av bakpanelet og skalere inngangene i dette området for å kartlegge til skjermen.
// bakre innganger ser ikke ut til å passe helt til rekkevidden på frontskjermet, slik at de strekker seg i kode // disse er verdier som var lett tilgjengelige #definere REAR_DEADZONE_MIN_X 10 #define REAR_DEADZONE_MIN_Y 75 #define REAR_DEADZONE_MAX_X 950 #define REAR_DEADZONE_MAX_Y 430 #definere REAR_STRETCH_X 960 # definer REAR_STRETCH_Y 544 statisk vec2 vitaMapRearInputToScreen (int inputX, int inputY) vec2 strukketInput; stretchedInput.x = (inputX-REAR_DEADZONE_MIN_X) * REAR_STRETCH_X / (REAR_DEADZONE_MAX_X-REAR_DEADZONE_MIN_X); stretchedInput.x = clampf (strukketInput.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 (strukketInput.y, 0, REAR_STRETCH_Y); returnere straktInput;
Alt i alt tror jeg at vi kom ganske lett her, delvis på grunn av hvordan spillet er helt avhengig av en enkel sveipebevegelse. Porting på tvers av radikalt forskjellige grensesnitt kan være en ekte hodepine, og dårligere har potensial til å kreve et ellers flott spill. Hadde vi portrettet et tredje person action spill til Wii, hadde denne delen vært betydelig lengre.
Jeg vil ikke lyve; Jeg har en ekte kjærlighet / hate forhold med lyd. I min tid på Free Radical Design tilbrakte jeg mye tid med å jobbe med lydgutta på motorspillet og lyddesignerne for å få lyd til spill og likte det utrolig. Audio løfter virkelig et spill og bringer det til liv.
Dessverre, jo mer lavt nivå av ting, med sin cocktail av filformater, samplingsfrekvenser, komprimering, stemmer, busser, filstrøm og så videre, har jeg aldri virkelig begeistret meg på samme måte. Så vi nærmet oss denne oppgaven med litt begeistring.
Heldigvis kommer Vita SDK fylt med (jevnlig oppdaterte) prøver som grundig dekker alle måter å bruke lyd-API. Det minste du vil ønske, selv i de mest enkle 2D-spillene, er muligheten til å spille engangslang (spillelydene) og muligheten til å streame lyd (musikk og andre store filer som er for store til å fortsett å lastes inn i minnet hele tiden). I mange 2D-spill kan du sannsynligvis selv velge å holde seg alene med mono og spare deg litt ekstra minne - kanskje til og med tillate deg å unngå streaming helt.
Med noen gode referanser til arbeid fra prøver, hadde vi all lyden oppe og løp om et par dager. Det eneste andre store arbeidet med lyden var en sen bryter i lydformat fra VAG til et proprietært format med et mye høyere komprimeringsnivå, noe som reduserte lydminneforbruket til omtrent 30% av det som tidligere hadde vært.
Til slutt var prosessen med å implementere lyden en langt mindre smertefull opplevelse enn jeg hadde fryktet.
Quell Memento er et singleplayer spill uten nettverksspill og begrensede onlinefunksjoner, så teoretisk sett burde dette vært et av de enkleste områdene. Virkeligheten peker høyt på en av utfordringene med å overføre til en PlayStation-plattform: De fryktede TRC-er (Technical Requirement Checklist - En liste over Do's og Don'ts utviklere må oppfylle for å passere QA).
Jeg skal påpeke at Sony ikke er unikt her; Microsoft og Nintendo har sine ekvivalenter. I motsetning til mobil, der nettbasert funksjonalitet ofte leveres av en tredjeparts kryssplattformløsning eller PC, hvor den eneste personen som dømmer på implementeringen din, vil være sluttbruker, har dette området tendens til å komme mye underveis på konsollene. Dette har delvis å gjøre med å sikre at funksjonaliteten som tilbys av en tjeneste som PSN, oppfører seg på en konsistent måte på tvers av titler, og at foreldringslås, aldersgrader og så videre overholdes.
Som et resultat, kan du ta mer tid enn du forventer, hvis du overfører til en konsoll, selv for et spill med relativt enkle nettverksfunksjoner. For en havn kan det være en av de mest påtrengende delene av arbeidet du må gjøre for å overholde TRC. Spesifikke krav til hvordan man håndterer hendelser som tap av tilkobling eller nektelse av tilgang til funksjoner på grunn av foreldringslås, og tidspunktet og måten du må videresende disse tingene til brukeren, kan hende kreve en viss grad frem og tilbake mellom dine spill og nettverkskomponenter som bare ikke eksisterte i det opprinnelige spillet.
Vi brukte et bibliotek levert av Sony som bryter opp alle de lave oppsett og nedriving av PSN og online-oppgaver til et ganske enkelt grensesnitt, og gir tilbakekallinger for alle asynkrone oppgaver. Samtalen fra spillet til den elektroniske funksjonaliteten kan kokes ned til noen forskjellige grupper - innlogging, butikk og leaderboards - hver med noen parametere for å spesifisere detaljene.
Alt dette betydde at en online forespørsel kunne utløses med bare noen få linjer med kode, og vi endte opp med sannsynligvis ikke mer enn fem eller seks forskjellige funksjoner kalt fra spillet for å støtte onlinefunksjonene.
Tilbakekallingene fra Sony-wrapper gir ganske detaljert detalj på alt som går galt, men for det meste kan disse enkeltvises klassifisert som en suksess eller en feil og passende tilbakeringing til spillet utløst. Dette betydde at vi også kunne koke ned tilbakekallingene fra motoren inn i spillet til like få samtaler.
Feiltilstandene ble håndtert så mye som mulig i motorkoden. Dette betydde at Fallen Tree-gutta kunne fortsette å utvikle Quell uten å måtte bekymre seg for Vita-spesifikke feiltilstander.
For eksempel, hvis en motorfunksjon hadde et forutgående anrop som potensielt kan mislykkes, i stedet for å kreve at spillet kaller noen forutsetninger og deretter sin forespørsel, vi ville ringe forutsetningen stille, caching selve forespørselen. Hvis forutsetningen mislyktes, vil vi dumpe forespørselen og varsle spillet gjennom normal tilbakeringing, og påberope dialogboksen fra motorsiden. Etter suksess vil forespørselen bli utført som ønsket.
Dette fungerte generelt bra; som med ethvert system som legges til senere og gjør sitt beste for å være ikke-påtrengende, var det ett eller to mindre enn elegante kodestykker, men det gjorde jobben.
Lagre spill er verdt å nevne fordi, som med nettverksfunksjonaliteten ovenfor, er de utsatt for høy grad av kontroll når det gjelder TRCer. Lagre spill er utsatt for to viktige feil: går tom for lagringsplass eller går tom for lagre kvote.
(Jeg har utelukket å redde korrupsjon, da det egentlig ikke er mye du kan gjøre med en korrupt lagring, systemet vil varsle deg om det, og du kan informere brukeren, men alt du kan gjøre er å fjerne det og gå videre ... og kanskje ha roligt lite gråt på alle de tapte timer.)
Å kjøre ut av filsystemlagring er ganske selvforklarende: det er rett og slett ikke nok plass til å lagre det du vil ha. Lagre kvoten er satt under utviklingen av spillet ditt; Det er i utgangspunktet en selvoppgitt grense for hvor mye minne søknaden din vil trenge for å lagre spilldata. Denne kvoten er ikke allokert ved installasjon av spillet ditt, men det er ikke garantert å eksistere.
Ved håndtering av hver av disse har du virkelig to alternativer.
Hvis spillet går tom for filsystemlagring, kan du:
Når det gjelder å løpe ut av lagre kvote, kan du:
Naturen til Quell tillot oss å håndtere dette ganske kortfattet ved å gå med alternativene 2 og 1, henholdsvis. Quell er ikke et spill hvor du kanskje vil hoppe tilbake til lagringen din for fem minutter siden, så det er bare nødvendig med en lagring, og dette er automatisk opprettet, lagret og lastet. Innholdet og størrelsen på lagringen er noe forutsigbart.
På det første avspillingssystemet forsøker vårt lagringssystem å tildele den maksimale mengden minne det vil trenge for lagringsfilen din. Hvis det ikke kan gjøre det - det vil si hvis det allerede er utilstrekkelig filsystemlagring tilgjengelig - det vil vise standardmeldingen vist nedenfor:
Spilleren har ikke lov til å fortsette før de har løst dette problemet selv (ved å minimere eller lukke appen og slette noen data). Når de slår OK, vil det forsøke å tildele minnet igjen. Når denne første lagringen er opprettet, er det trygt å anta at en mangel i filsystemet og lagre kvoten aldri vil oppstå.
Jeg har allerede kort nevnt TRCs (The Technical Requirements Checklist) og som en ansvarsfraskrivelse vil jeg si at jeg er glad TRCs eksisterer; som en gamer ting, som PSN, har blitt en så viktig del av opplevelsen som jeg setter pris på å vite at jeg kan forvente en viss grad av konsistens i spillets oppførsel.
Som sagt, som en utvikler, er de en smerte. Vi var heldige at spillet var relativt enkelt, og som sådan kunne mange TRCer bare ignorere som de ikke gjaldt. Selv om du jobber med å bringe et relativt enkelt spill til noen av konsollene, vil jeg sterkt anbefale deg å gjøre deg kjent med reglene for plattformen tidlig og referere til dem ofte. Det som kanskje har vært akseptabelt på en plattform, kan ikke fly på en annen, og du vil ikke vente til du får en stor liste med grunner til hvorfor du mislyktes QA til å innse at du gjør det helt galt.
For et lite team uten en dedikert QA-avdeling, kan dette virke som en veldig skremmende oppgave, men en liten følelse og planlegging kan gjøre hele forskjellen.
For det første er mange av kravene bare en spesifikt formulert måte å be deg om ikke å gjøre dumme ting som du sannsynligvis ikke vil gjøre i alle fall - heldigvis hadde FTG-gutta allerede unngått å gjøre noe dumt, så dette var en god start.
For det andre holdt vi et regneark for alle kravene, og om de for tiden passerte, mislyktes, ikke kunne testes ennå, eller bare ikke var aktuelt. Som viktige funksjoner gikk inn i spillet, kunne vi gjøre en feiing av denne listen for å oppdatere statusen til hvert krav og samtidig oppdatere våre minner om hvilke restriksjoner som ble brukt.
Da vi nådde vår QA-fase, hadde vi en ganske klar ide om hvor vi sto med hensyn til TRCs, og fant oss ikke til å møte noen ubehagelige overraskelser.
Sørg for at du har klart avtalt tidsrammer og mål. Dette er mer et forretningsmessig problem enn teknisk, men viktig hvis du portretterer et spill til noen andre, selv om det bare er et hobbyprosjekt blant venner. (Du vil bli venner, ikke sant ?!)
Da vi begynte å jobbe med Quell Memento, var det ikke ferdig, og mens det var generell følelse av når sluttdato skulle være, ble ingenting satt i stein. Til slutt tok hele prosjektet lengre tid enn forventet.
Etterpå hadde det vært å foretrekke å vente på at spillet skal være helt ferdig - eller i hvert fall langt mer komplett - før vi begynner vår port. Da vi portporterte motoren, ble det sjelden påvirket av ny spill og innhold, men det var anledninger da funksjonene krevde motorendringer. Det var også tider da fremdriften på porting motoren ble blokkert da vi ventet på nye funksjoner som skulle legges til.
Vi har et godt forhold til gutta på FTG og var så heldige i disse situasjonene å ha fleksibilitet til å bytte til våre egne prosjekter for disse periodene (inkludert å undersøke noen av Vitas mer unike funksjoner som den utvidede virkeligheten), men som noen hvem som noen gang har forsøkt litt multitasking burde vite, dette er ikke den mest effektive måten å jobbe på.
Det er vanskelig å peke på noen enestående standout-leksjoner som vi lærte; vi fikk mer av en inkrementell akkumulering av kunnskap om nye verktøy, APIer og prosesser.
I fremtiden vil vi kanskje være mer dristige i å tvinge (eller i det minste antyde) endringer i spillkoden der det føltes rimelig - vi kan ha gjort noen oppgaver vanskeligere enn de måtte være denne gangen. Men definisjonen av "rimelig" vil alltid variere vilt fra prosjekt til prosjekt.
I tillegg vil vi sannsynligvis vente på at et spill skal være mer komplett før du begynner å jobbe på en havn i fremtiden, fordi flere mennesker jobber solidt, for mindre tid. Igjen kan muligheten for dette variere enormt mellom prosjekter avhengig av utgivelsesplanen. Etter å ha gjort det en gang, kan vi nå langt bedre estimere hvor lenge vi kan trenge.
Viktigst av alt har vi fått måneder med verdifull erfaring på en ny plattform, inkludert innsendingsprosessen - selv får en sjanse til å undersøke noen av sine unike egenskaper. For et team som i stor grad bygger på arbeid for utleie og kontraktsarbeid som kilde til Inntekt, verdien av dette kan ikke undervurderes.
Mitt råd for noen av dere som vurderer en port til Vita, ville være å gi den en sprekk. Jeg tror det er en viss mystikk rundt konsollutvikling; Vi var heldige å ha erfaring på dette feltet, men selv uten at du ikke skulle bli slått av.
Sony er svært imøtekommende til indies og små utviklere (noe jeg synes er blitt tydelig for det bredere game dev-fellesskapet), og hvis du har en rimelig grad av teknisk spillutviklingskunnskap, så med den store støtten fra Sony Developer Support Team, bør du ikke Ikke gå inn i noen uoverstigelige utfordringer.
Quell Memento for Vita er tilgjengelig nå i SCEA og SCEE.
