Share
Welkom bij het tweede deel van deze tutorialserie over het maken van platformonafhankelijke games met HaxePunk. Toen we stopten, waren we klaar met het maken van een eenvoudig drag-race-spel dat voor veel verschillende platforms kan worden gecompileerd. In dit tweede deel zal ik enkele tips geven om uw games goed te laten werken op meerdere soorten apparaten. We zullen het hebben over schermafmetingen en -resoluties, invoertypen, interface-indelingen en tips voor het indienen van app-winkels.
Het scherm is het venster in je spel en moet niet als bijzaak achterblijven. Denk aan de apparaten waarop je je spel wilt spelen. Een Windows / Mac / Linux-release kan meestal afhankelijk zijn van het feit dat de gebruiker een scherm heeft dat groot genoeg is om in het spel te passen in de venstermodus, en kan eventuele resolutieverschillen in de volledig schermmodus letterboxen.
Mobiele apparaten zijn heel anders. Er zijn veel schermen met verschillende resoluties en formaten. Je kunt niet garanderen dat de speler zal spelen op een apparaat met dezelfde resolutie als je spel. Scaling gaat gebeuren.
In het eerste artikel in deze serie heb ik de ontwikkeling van een klein voorbeeldspel doorlopen. U kunt het volledige broncodeproject downloaden met de knop rechts van dit artikel. De laatste keer hebt u misschien dergelijke opmerkingen opgemerkt:
y = -image.scaledHeight;
Er zijn eigenschappen voor de breedte en hoogte van afbeeldingen, en die zijn er scaledWidth en scaledHeight eigenschappen ook. De betekenis van de breedte en hoogte van een afbeelding is duidelijk. De geschaalde eigenschappen zijn iets complexer. De scaledWidth eigenschap is de breedte van het beeld vermenigvuldigd met de schaal van het beeld vermenigvuldigd met de schaal van het spel, en scaledHeight is vergelijkbaar, maar voor lengte.
Dit wordt echter een beetje verwarrend wanneer het spel automatisch wordt geschaald, zoals kan gebeuren op een Android-apparaat met een lagere schermresolutie dan waarvoor het spel is gebouwd. In een situatie als deze is de schaaleigenschap die HaxePunk leest om de schaal van afbeeldingen in te stellen, en dus hun geschaalde breedte / hoogte, waarschijnlijk niet correct ingesteld.
In feite is er vaak helemaal geen schaalvergroting, slechts een inkrimping van het scherm. Om dit te verhelpen, kunnen we de hoeveelheid schalen berekenen die we zouden willen, gebaseerd op de resolutie van het spel en de resolutie van het scherm waarop het spel draait. In Main.hx kunnen we deze code toevoegen voordat we de actieve scène instellen:
var ratio: Float = Math.min (HXP.stage.stageWidth / screenWidth, HXP.stage.stageHeight / screenHeight); HXP.screen.scaleX = ratio; HXP.screen.scaleY = verhouding; HXP.resize (HXP.stage.stageWidth, HXP.stage.stageHeight);
In de bovenstaande code, screenWidth en screenHeight zijn variabelen die ik heb gemaakt en die ik heb ingesteld op de breedte en hoogte die ik heb gebruikt voor het spel. Je kunt ook eenvoudig constanten gebruiken zoals 640 en 480, maar ik gebruik liever variabelen.
De code gebruikt de Math.min () functie om de verhoudingsvariabele in te stellen op het laagste verschil in schermafmetingen om te voorkomen dat afbeeldingen worden uitgerekt als de verschillen in breedte en hoogte niet gelijk zijn. U kunt stretchen toestaan, in welk geval u moet instellen HXP.screen.scaleX en scaleY naar verschillende waarden.
Nadat de verhouding is berekend, HXP.resize () wordt genoemd. Met deze functie wordt het formaat van het scherm gewijzigd. U kunt ook de ratio (s) voor gebruik elders opslaan, maar ik heb het zelden nodig gevonden.
Met het formaat van het scherm kunnen we dit soort dingen nog steeds doen:
// plaats de entiteit in de rechterbenedenhoek van het scherm, ongeacht de grootte entity.x = HXP.screen.width - entity.scaledWidth; entity.y = HXP.screen.height - entity.scaledHeight;
Hierdoor hebben we een consistente gebruikersinterface voor een game op veel apparaten.
In de vorige tutorial had ik het over de project.xml bestand, waarmee we gemakkelijk veel aspecten van ons spel kunnen configureren. We kunnen onder andere de oriëntatie van het spel instellen, wat handig is voor mobiele apparaten. Bijvoorbeeld, als we wilden dat onze game in portretmodus op mobiele apparaten zou draaien, maar in landschapsmodus op desktop:
Invoer verschilt nogal tussen soorten apparaten. Het is onredelijk om van de speler te verwachten dat hij een bluetooth-toetsenbord en -muis bevestigt om een game op zijn telefoon te spelen, en het is onwaarschijnlijk dat zelfs een desktop zal worden uitgerust met een touchscreen.
In het voorbeeldspel van de vorige zelfstudie gebruikte ik HaxePunk's Sleutel klasse om te controleren op toetsaanslagen. Op touchscreen-apparaten zou het echter logisch zijn om de klasse Key niet te importeren, waardoor de grootte van het spel lager blijft, omdat we touch controls zullen gebruiken.
Haxe maakt dit gemakkelijk voor ons door ons voorwaardelijke compilatie te laten gebruiken. Het werkt als volgt:
#voorwaarde var x = 0; someFunction (); #elseif another_condition var y = 1; #else var z = 2; anotherFunction (); #einde
De voorwaarden worden tijdens het compileren geëvalueerd, wat betekent dat we code kunnen opnemen of uitsluiten, afhankelijk van het platform dat we targeten! Ga als volgt te werk om de klasse Key uit te sluiten bij het targeten van mobiele apparaten:
Accentsconagua
import com.haxepunk.utils.Input; // u zult dit waarschijnlijk nog steeds willen, omdat het de invoer verwerkt voor alle soorten apparaten #if! mobile import com.haxepunk.utils.Key; #end // We willen ook alle toetsenborddefinities verwijderen die we mogelijk hebben, zoals bijvoorbeeld #if! mobile Input.define ("left", [Key.A, Key.LEFT]); Input.define ("right", [Key.D, Key.RIGHT]); #eindeLet op de! (niet) logische operator hierboven gebruikt. We kunnen ook && (en) evenals || gebruiken (of) in voorwaardelijke compilatie. Als je code voor mobiele apparaten wilde opnemen, maar niet voor iOS, zou je kunnen zeggen
#if (mobiel &&! ios) // code hier #end
Zoals je ziet is voorwaardelijke compilatie vrij krachtig! Laten we teruggaan naar de verwerking van de invoer voor een minuut. Het uitsluiten van de klasse Key bij het compileren voor doelen met een touchscreen is leuk, maar er wordt niet automatisch gecontroleerd op aanraakinvoer.
Als we de racegame uit de laatste zelfstudie gebruiken als voorbeeld, kunnen we de invoercontrole hieruit wijzigen:
if (Input.pressed ("left")) move ("left"); if (Input.pressed ("right")) move ("right"); Hiernaar:
#if mobile if (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
Het toetsenbord wordt nu gebruikt om bewegingen op desktopplatformen te regelen en door de linker- of rechterkant van het scherm aan te raken, wordt de beweging op mobiele platforms geregeld!
Als je wilt, kun je ook je eigen sleutelwoorden opgeven om te gebruiken met voorwaardelijke compilatie, zowel in de broncode van het spel als in het .xml-projectbestand.
#als myOwnKeyword aCoolSecretForWevereverReason (); #einde
Als u de bovenstaande code wilt opnemen, kunt u tijdens het compileren eenvoudig een optie doorgeven:
kalkproef-DmyOwnKeyword
Dit kan worden gebruikt om recensie-exemplaren of bètaversies als zodanig in het spel zelf te markeren om lekken te ontmoedigen of verschillende delen van het spel met verschillende mensen te testen. Het kan ook worden gebruikt om een demoversie te maken die gebieden van het spel beperkt, of zelfs wordt gebruikt om een persoonlijke versie als een verrassingsgeschenk te maken.
Nadat je een geweldige platformonafhankelijke game hebt gemaakt, is de volgende stap om het uit te brengen in verschillende app stores en marktplaatsen. Elke marktplaats heeft andere vereisten, maar er zijn dingen die u kunt doen die van toepassing zijn op alle (of op zijn minst verreweg de meeste) marktplaatsen. Natuurlijk is het beste advies dat ik op dit gebied kan geven, het zorgvuldig lezen van de inzendingsinstructies om erachter te komen wat elke marktplaats van je wil.
Een voor de hand liggende vereiste is het leveren van screenshots. Het aantal en de vereiste resolutie kan variëren, maar elke marktplaats moet u vertellen wat ze willen. Ik zou aanraden om absoluut niet minder dan twee screenshots te maken, maar bij voorkeur vier of meer.
Net zoals de vereisten voor schermafbeeldingen variëren, net als de vereisten voor pictogrammen. Sommige winkels willen een pictogram met een lagere resolutie en een pictogram met een hogere resolutie, dus u kunt het beste beginnen met een groot pictogram dat kan worden verkleind naar verschillende formaten.
In sommige winkels kunt u ook een of meer video's uploaden. Ik stel voor één video te maken die de basis van je game laat zien bij het indienen bij mobiele app-winkels en minstens één video voor andere markten (Steam, Desura, enzovoort). Onthoud: als een foto meer dan duizend woorden waard is en een video kan worden gezien als opeenvolgende foto's, is een video behoorlijk waardevol!
Er zijn ook verschillende soorten informatie die vereist moeten zijn in elke winkel waar je een game aan toevoegt: titel, beschrijving, pictogram en categorie. Het is nuttig voor spelers (potentieel of anderszins) als deze informatie voor alle platforms hetzelfde is.
Na het bouwen van een spel met OpenFL, moet het binaire bestand klaar zijn om naar elke marktplaats te worden verzonden voor het platform waarvoor je hebt gebouwd zonder dat er wijzigingen nodig zijn. Vergeet niet om een releaseversie samen te stellen en in te dienen, niet een foutopsporingsversie!
Nu je manieren hebt gezien om je games op verschillende apparaten goed te laten werken, hoop ik dat je deze kennis goed gebruikt en coole games maakt! Nog een laatste advies: het afsluiten van een game is geweldig en iets om trots op te zijn, maar het vrijgeven van een game kan evenveel werk kosten.!
