Share
Velkommen til den andre delen av denne opplæringsserien om å lage plattformspill med HaxePunk. Da vi sluttet, var vi ferdige med å lage et enkelt drag-racing spill som kan kompileres for mange forskjellige plattformer. I denne andre delen gir jeg noen tips for å få spillene dine til å fungere godt på flere typer enheter. Vi snakker om skjermstørrelser og oppløsninger, inntastetyper, grensesnittoppsett og tips for appbutikkinnlegg.
Skjermen er vinduet inn i spillet ditt, og bør ikke stå som en ettertanke. Tenk på enhetene du planlegger å frigjøre spillet på. En Windows / Mac / Linux-utgivelse kan vanligvis avhenge av at brukeren har en skjerm som er stor nok til å passe spillet i windowed-modus, og kan brevboks noen oppløsningsforskjeller i fullskjermmodus.
Mobile enheter er ganske forskjellige. Det finnes mange skjermer med ulike oppløsninger og størrelser. Du kan ikke garantere at spilleren vil spille på en enhet med samme oppløsning som spillet ditt. Skalering skal skje.
I den første artikkelen i denne serien gikk jeg gjennom utviklingen av et lite eksempelspill. Du kan laste ned fullkildekodeprosjektet ved hjelp av knappen til høyre for denne artikkelen. Siste gang har du kanskje lagt merke til uttalelser som dette:
y = -image.scaledHeight;
Det er bredde- og høydeegenskaper for bilder, og det finnes scaledWidth og scaledHeight egenskaper også. Betydningen av bredde og høyde på et bilde er åpenbart. De skalerte egenskapene er litt mer komplekse. De scaledWidth Egenskapen er bildens bredde multiplisert med skalaen av bildet multiplisert med skalaen av spillet, og scaledHeight er lik, men for høyde.
Dette blir imidlertid litt forvirrende når spillet skaleres automatisk, som det kan skje på en Android-enhet med en lavere skjermoppløsning enn spillet ble bygget for. I en slik situasjon vil skalaegenskapen som HaxePunk leser for å angi skalaen av bilder, og dermed deres skalerte bredde / høyde, sannsynligvis ikke bli satt riktig.
Faktisk er det ofte ingen skalering, bare en krymping av skjermen. For å fikse dette kan vi beregne mengden skalering vi ønsker, basert på oppløsningen av spillet og oppløsningen på skjermen som spillet kjører på. I Main.hx kan vi legge til denne koden før vi setter den aktive scenen:
var-forhold: Float = Math.min (HXP.stage.stageWidth / screenWidth, HXP.stage.stageHeight / screenHeight); HXP.screen.scaleX = ratio; HXP.screen.scaleY = forhold; HXP.resize (HXP.stage.stageWidth, HXP.stage.stageHeight);
I ovennevnte kode, screenWidth og screenHeight er variabler jeg har laget og har satt til bredden og høyden jeg brukte til spillet. Du kan også bare bruke konstanter som 640 og 480, men jeg foretrekker å bruke variabler.
Koden bruker Math.min () funksjonen til å stille forholdsvariabelen til den laveste forskjellen i skjermdimensjonene for å hindre at grafikken strekkes hvis forskjellene i bredde og høyde ikke er like. Du vil kanskje tillate strekk, i så fall må du sette HXP.screen.scaleX og Scaley til forskjellige verdier.
Etter at forholdet er beregnet, HXP.resize () er kalt. Denne funksjonen er det som faktisk endrer størrelsen på skjermen. Du vil kanskje også lagre forholdet (er) for bruk andre steder, men jeg har sjelden funnet det nødvendig.
Med skjermstørrelsen er vi fortsatt i stand til å gjøre ting som dette:
// plassere enhet i nederste høyre hjørne av skjermen, uansett størrelsen entity.x = HXP.screen.width - entity.scaledWidth; entity.y = HXP.screen.height - entity.scaledHeight;
Dette gir oss et konsistent brukergrensesnitt for et spill på tvers av mange enheter.
I den forrige opplæringen snakket jeg om project.xml fil, som lar oss enkelt konfigurere mange aspekter av spillet vårt. Blant annet kan vi angi retningen til spillet, som er nyttig for mobile enheter. For eksempel, hvis vi ønsket at spillet skulle kjøres i stående modus på mobile enheter, men i liggende modus på skrivebordet:
Inndata er ganske forskjellig mellom typer enheter. Det er urimelig å forvente at spilleren skal feste et Bluetooth-tastatur og en mus for å spille et spill på telefonen, og det er usannsynlig at i dag vil en stasjonær PC være utstyrt med en berøringsskjerm.
I eksempelspillet fra den forrige opplæringen brukte jeg HaxePunk Nøkkel klasse for å sjekke om tastetrykk. På touchscreen-enheter vil det imidlertid være fornuftig å ikke importere nøkkelklassen, slik at størrelsen på spillet lavere, fordi vi vil bruke berørings kontroller.
Haxe gjør det enkelt for oss ved å la oss bruke betinget kompilering. Det virker slik:
#if tilstand var x = 0; someFunction (); #elseif another_condition var y = 1; #else var z = 2; anotherFunction (); #slutt
Betingelsene vurderes på kompileringstid, noe som betyr at vi kan inkludere eller ekskludere kode, avhengig av plattformen vi målretter mot! For å utelukke Nøkkelklassen når du målretter mot mobilenheter, gjør du dette:
Accentsconagua
importer com.haxepunk.utils.Input; // du vil sikkert fortsatt ha dette, fordi det håndterer inngang for alle typer enheter #if! mobil import com.haxepunk.utils.Key; #end // Vi vil også fjerne tastatur definerer vi kanskje, som så #if! mobile Input.define ("left", [Key.A, Key.LEFT]); Input.define ("right", [Key.D, Key.RIGHT]); #sluttLegg merke til! (ikke) logisk operatør brukt ovenfor. Vi kan også bruke && (og) samt || (eller) i betinget samling. Hvis du ønsket å inkludere kode for mobile enheter, men ikke for iOS, kan du si
#if (mobil &&! ios) // kode her #end
Som du kan se er betinget kompilering ganske kraftig! La oss gå tilbake til inntakshåndtering i et minutt. Eksklusive nøkkelklassen når du samler mål med en berøringsskjerm, er fin, men det kontrolleres ikke automatisk for berøringsinngang.
Ved å bruke racing spillet fra den siste opplæringen som et eksempel, kan vi endre inntastingskontrollen fra dette:
hvis (Input.pressed ("left")) move ("left"); hvis (Input.pressed ("right")) move ("right"); Til dette:
#if mobil hvis (Input.mousePressed) if (Input.mouseX < HXP.screen.width * .5) move("left"); else move("right"); #else if(Input.pressed("left")) move("left"); if(Input.pressed("right")) move("right"); #end
Nå vil tastaturet bli brukt til å styre bevegelse på stasjonære plattformer, og berøring til venstre eller høyre side av skjermen vil styre bevegelsen på mobile plattformer!
Hvis du vil, kan du også angi dine egne søkeord for bruk med betinget kompilering, både i kildekoden til spillet og i .xml-prosjektfilen.
#if myOwnKeyword aCoolSecretForWhateverReason (); #slutt
For å inkludere koden ovenfor kan du enkelt passere et alternativ når du kompilerer:
limtest-DmyOwnKeyword
Dette kan brukes til å markere gjennomgangskopier eller beta-utgivelser som sådan i selve spillet, for å motvirke lekkasjer eller beta-test forskjellige deler av spillet med forskjellige personer. Det kan også brukes til å lage en demoversjon som begrenser områder av spillet, eller til og med pleide å lage en personlig versjon som en overraskelsesgave.
Etter at du har laget et flott tversplattformsspill, er neste skritt å frigjøre det på ulike appbutikker og markedsplasser. Hver markedsplass vil ha forskjellige krav, men det er ting du kan gjøre som gjelder for alle (eller i det minste de aller fleste) markedsplasser. Selvfølgelig, det beste rådet jeg kan tilby i dette området er å lese nøye innleveringsinstruksjonene for å finne ut hva hver markedsplass ønsker av deg.
Et åpenbart krav er å gi skjermbilder. Nummeret og ønsket oppløsning vil variere, men hver markedsplass bør fortelle deg hva de vil. Jeg vil anbefale å gi absolutt ikke mindre enn to skjermbilder, men helst fire eller flere.
Akkurat som kravene til skjermbilder vil variere, så vil kravene til ikoner. Noen butikker vil ha et ikon med lavere oppløsning og et ikon med høyere oppløsning, så det er best å starte med et stort ikon som kan skaleres ned i forskjellige størrelser.
Noen butikker vil også tillate deg å laste opp en eller flere videoer. Jeg foreslår at du lager en video som viser grunnleggende om spillet ditt når du sender inn til mobilappbutikker, og minst en video for andre markedsplasser (Steam, Desura, etc.). Husk: hvis et bilde er verdt tusen ord, og en video kan tenkes på så mange bilder som spilles i rekkefølge, er en video ganske verdifull!
Det er også flere deler av informasjonen som bør kreves i hvilken som helst butikk du sender inn et spill til: tittel, beskrivelse, ikon og kategori. Det er nyttig for spillere (potensielt eller annet) hvis denne informasjonen er den samme på alle plattformer.
Etter å ha bygget et spill med OpenFL, bør binæret være klar til å sende til hvilken som helst markedsplass for plattformen du bygget for uten endringer som trengs. Bare husk å bygge og sende inn en utgivelsesversjon, ikke en feilsøkingsversjon!
Nå som du har sett måter å få spillene dine til å fungere godt på en rekke enheter, håper jeg at du vil sette denne kunnskapen til nytte og gjøre noen kule spill! Et siste ord av råd: å fullføre et spill er flott, og noe å være stolt av, men å slippe et spill kan ta like mye arbeid!
