Share
Välkommen till den andra delen av denna handledningsserie om att göra plattformsspel med HaxePunk. När vi slutade, hade vi slutat skapa ett enkelt dragspel som kan sammanställas för många olika plattformar. I den här andra delen kommer jag att ge några tips för att dina spel ska fungera bra på flera typer av enheter. Vi pratar om skärmstorlekar och upplösningar, inmatningstyper, gränssnittslayouter och tips för appbutikinsändningar.
Skärmen är fönstret i ditt spel och bör inte lämnas som en eftertanke. Tänk på de enheter du planerar att släppa ditt spel på. En Windows / Mac / Linux-version kan vanligtvis bero på att användaren har en skärm som är tillräckligt stor för att passa spelet i windowed-läge och kan brevlådan eventuella upplösningsskillnader i helskärmsläge.
Mobila enheter är ganska olika. Det finns många skärmar med olika upplösningar och storlekar. Du kan inte garantera att spelaren kommer att spela på en enhet med samma upplösning som ditt spel. Skalning kommer att hända.
I den första artikeln i denna serie gick jag igenom utvecklingen av ett litet exempel spel. Du kan ladda ner hela källkodsprojektet med knappen till höger om den här artikeln. Förra gången kanske du har märkt påståenden som följande:
y = -image.scaledHeight;
Det finns bredd och höjd egenskaper för bilder, och det finns scaledWidth och scaledHeight egenskaper också. Betydelsen av bredden och höjden på en bild är uppenbar. De skalade egenskaperna är lite mer komplexa. De scaledWidth egenskapen är bildens bredd multiplicerad med bildskalan multiplicerad med spelets skala och scaledHeight är liknande, men för höjd.
Men det blir lite förvirrande när spelet automatiskt skalas, vilket kan hända på en Android-enhet med en lägre skärmupplösning än vad spelet byggdes för. I en sådan situation, kommer den skalaegenskap som HaxePunk läser för att ställa in bildskalan och därigenom deras skalade bredd / höjd, sannolikt inte vara korrekt inställd.
Faktum är att det ofta inte finns någon skalning alls, bara en krympning av skärmen. För att fixa detta kan vi beräkna den mängd skalning vi vill ha baserat på spelets upplösning och upplösningen på skärmen som spelet körs på. I Main.hx kan vi lägga till den här koden innan vi ställer in den aktiva scenen:
var-förhållande: Float = Math.min (HXP.stage.stageWidth / screenWidth, HXP.stage.stageHeight / screenHeight); HXP.screen.scaleX = förhållande; HXP.screen.scaleY = förhållande; HXP.resize (HXP.stage.stageWidth, HXP.stage.stageHeight);
I ovanstående kod, screenWidth och screenHeight är variabler jag har skapat och har satt till bredden och höjden som jag använde för spelet. Du kan också helt enkelt använda konstanter som 640 och 480, men jag föredrar att använda variabler.
Koden använder Math.min () funktionen för att ställa in förhållandevariabeln till den lägsta skillnaden i skärmdimensioner för att förhindra att grafik sträcker sig om skillnaderna i bredd och höjd inte är lika. Du kanske vill tillåta att sträcka, i vilket fall måste du ställa in HXP.screen.scaleX och scaleY till olika värden.
När förhållandet beräknas, HXP.resize () kallas. Den här funktionen är vad som verkligen ändrar skärmen. Du kanske också vill spara förhållandet / förhållandena för användning på annat håll, men jag har sällan funnit det nödvändigt.
Med storleken på skärmen kan vi fortfarande göra saker som följande:
// placera enhet i nedre högra hörnet av skärmen, oavsett storlek entity.x = HXP.screen.width - entity.scaledWidth; entity.y = HXP.screen.height - entity.scaledHeight;
Detta gör att vi kan ha ett konsekvent användargränssnitt för ett spel på många enheter.
I den tidigare handledningen talade jag om project.xml fil, vilket gör att vi enkelt kan konfigurera många aspekter av vårt spel. Bland annat kan vi ställa in orienteringen i spelet, vilket är användbart för mobila enheter. Om vi till exempel vill att vårt spel ska köras i porträttläge på mobila enheter men i liggande läge på skrivbordet:
Input skiljer sig ganska lite mellan typer av enheter. Det är orimligt att förvänta sig att spelaren bifogar ett bluetooth-tangentbord och en mus för att spela ett spel på sin telefon, och det är osannolikt även att ett skrivbord kommer att vara utrustat med en pekskärm.
I exempelspelet från den tidigare handledningen använde jag HaxePunk Nyckel klass för att kontrollera om tangenttryckningar. På pekskärmsenheter kan det dock vara meningsfullt att inte importera Key-klassen, så att storleken på spelet blir lägre, eftersom vi kommer att använda pekontroller.
Haxe gör det enkelt för oss genom att låta oss använda villkorad sammanställning. Det fungerar så här:
#if villkor var x = 0; someFunction (); #elseif another_condition var y = 1; #else var z = 2; anotherFunction (); #slutet
Villkoren utvärderas vid sammanställningstid, vilket innebär att vi kan inkludera eller utesluta kod beroende på vilken plattform vi riktar in mot! Om du vill utesluta nyckelklassen när du riktar in mobila enheter gör du det här:
Accentsconagua
importera com.haxepunk.utils.Input; // du kommer nog att vilja ha det här eftersom det hanterar inmatning för alla typer av enheter #if! mobil import com.haxepunk.utils.Key; #end // Vi vill också ta bort eventuella tangentbord som vi kanske har, som så #if! mobile Input.define ("left", [Key.A, Key.LEFT]); Input.define ("right", [Key.D, Key.RIGHT]); #slutetLägg märke till! (ej) logisk operatör som används ovan. Vi kan också använda && (och) samt || (eller) i villkorlig sammanställning. Om du ville inkludera kod för mobila enheter men inte för iOS, kan du säga
#if (mobil &&! ios) // kod här #end
Som du kan se är villkorlig sammanställning ganska kraftfull! Låt oss gå tillbaka till inmatningshantering i en minut. Exklusive nyckelklassen vid sammansättning för mål med pekskärm är bra, men det kontrolleras inte automatiskt för pekinmatning.
Med hjälp av tävlingsspelet från den sista handledningen kan vi ändra ingångskontrollen från detta:
om (Input.pressed ("left")) move ("left"); om (Input.pressed ("right")) move ("right"); Till detta:
#if mobil om (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
Nu kommer tangentbordet att användas för att styra rörelsen på stationära plattformar, och rörande vänster eller höger sida av skärmen styr rörelsen på mobila plattformar!
Om du vill kan du också ange dina egna nyckelord som ska användas med villkorlig kompilering, både i källkoden för spelet och i .xml-projektfilen.
#if myOwnKeyword aCoolSecretForWhateverReason (); #slutet
För att inkludera koden ovan kan du enkelt skicka ett alternativ när du sammanställer:
kalkprov-DmyOwnKeyword
Detta kan användas för att markera översynskrav eller betaversioner som sådana inom själva spelet, för att motverka läckage eller beta-test olika delar av spelet med olika personer. Det kan också användas för att skapa en demoversion som begränsar delar av spelet, eller till och med brukade göra en personlig version som en överraskningsgåva.
När du har gjort ett bra plattformsspel är nästa steg att släppa det på olika appbutiker och marknadsplatser. Varje marknadsplats kommer att ha olika krav, men det finns saker du kan göra som gäller för alla (eller åtminstone de allra flesta) marknadsplatserna. Det bästa rådet jag kan erbjuda på detta område är naturligtvis att noga läsa inlämningsinstruktionerna för att ta reda på vad varje marknadsplats vill ha av dig.
Ett uppenbart krav är att ge skärmdumpar. Antalet och den önskade upplösningen varierar, men varje marknadsplats ska berätta vad de vill ha. Jag skulle rekommendera att ge absolut inte mindre än två skärmdumpar, men helst fyra eller fler.
Precis som kraven på skärmdumpar kommer att variera, så kommer kraven på ikoner. Vissa butiker vill ha en ikon med lägre upplösning och en ikon med högre upplösning, så det är bäst att börja med en stor ikon som kan skalas ner till olika storlekar.
Vissa butiker tillåter dig också att ladda upp en eller flera videoklipp. Jag föreslår att du skapar en video som visar grunderna i ditt spel när du skickar till mobilappbutiker och minst en video för andra marknadsplatser (Steam, Desura, etc.). Kom ihåg: om en bild är värd tusen ord, och en video kan tänkas på så många bilder som spelas i följd, är en video ganska värdefull!
Det finns också flera bitar av information som borde krävas i vilken butik du skickar ett spel till: titel, beskrivning, ikon och kategori. Det är till hjälp för spelare (potentiellt eller annars) om denna information är densamma över alla plattformar.
Efter att ha byggt ett spel med OpenFL, bör binären vara redo att skicka till någon marknad för den plattform du byggt för utan att behöva ändras. Kom bara ihåg att bygga och skicka in en version, inte en debug-version!
Nu när du har sett sätt att få dina spel att fungera bra på en rad olika enheter hoppas jag att du ska använda denna kunskap till god användning och göra några coola spel! Ett sista ord av råd: Att avsluta ett spel är bra, och något att vara stolt över, men att släppa ett spel kan ta lika mycket arbete!
