Scrivi una volta, pubblica ovunque con HaxePunk suggerimenti multipiattaforma

Benvenuti alla seconda parte di questa serie di tutorial su come realizzare giochi multipiattaforma con HaxePunk. Quando abbiamo interrotto, avevamo finito di creare un semplice gioco di drag-racing che può essere compilato per molte piattaforme diverse. In questa seconda parte, darò alcuni suggerimenti per far sì che i tuoi giochi funzionino bene su più tipi di dispositivi. Parleremo di dimensioni e risoluzioni dello schermo, tipi di input, layout dell'interfaccia e suggerimenti per l'invio di app store.

Dimensioni e risoluzioni dello schermo

Lo schermo è la finestra del tuo gioco e non dovrebbe essere lasciato in secondo piano. Pensa ai dispositivi su cui prevedi di pubblicare il tuo gioco. Una versione Windows / Mac / Linux può solitamente dipendere dal fatto che l'utente abbia uno schermo abbastanza grande da adattarsi al gioco in modalità finestra e può letterboxare qualsiasi differenza di risoluzione in modalità schermo intero. 

I dispositivi mobili sono molto diversi. Ci sono molti schermi di varie risoluzioni e dimensioni. Non è possibile garantire che il giocatore possa giocare su un dispositivo con la stessa risoluzione del gioco. Il ridimensionamento sta per accadere.

Nel primo articolo di questa serie, ho seguito lo sviluppo di un piccolo gioco di esempio. Puoi scaricare il progetto completo del codice sorgente usando il pulsante a destra di questo articolo. L'ultima volta, potresti aver notato affermazioni come questa:

y = -image.scaledHeight;

Ci sono proprietà di larghezza e altezza per le immagini, e ce ne sono scaledWidth e scaledHeight proprietà pure. Il significato della larghezza e dell'altezza di un'immagine è ovvio. Le proprietà ridimensionate sono un po 'più complesse. Il scaledWidth proprietà è la larghezza dell'immagine moltiplicata per la scala dell'immagine moltiplicata per la scala del gioco, e scaledHeight è simile, ma per altezza.

Tuttavia, questo diventa un po 'confuso quando il gioco viene ridimensionato automaticamente, come potrebbe accadere su un dispositivo Android con una risoluzione dello schermo inferiore a quella per cui il gioco è stato creato. In una situazione come questa, la proprietà della scala che HaxePunk legge per impostare la scala delle immagini, e quindi la loro scala Larghezza / Altezza, probabilmente non sarà impostata correttamente. 

In effetti, spesso non c'è alcun ridimensionamento, solo un restringimento dello schermo. Per risolvere questo problema, possiamo calcolare la quantità di ridimensionamento che vorremmo, in base alla risoluzione del gioco e alla risoluzione dello schermo su cui è in esecuzione il gioco. In Main.hx possiamo aggiungere questo codice prima di impostare la scena attiva:

var ratio: Float = Math.min (HXP.stage.stageWidth / screenWidth, HXP.stage.stageHeight / screenHeight); HXP.screen.scaleX = ratio; HXP.screen.scaleY = ratio; HXP.resize (HXP.stage.stageWidth, HXP.stage.stageHeight);

Nel codice sopra, screenwidth e ScreenHeight sono variabili che ho creato e ho impostato sulla larghezza e l'altezza che ho usato per il gioco. Potresti anche usare semplicemente costanti come 640 e 480, ma preferisco usare le variabili.

Il codice usa il Math.min () funzione per impostare la variabile di rapporto sulla differenza minima delle dimensioni dello schermo per evitare che la grafica venga allungata se le differenze di larghezza e altezza non sono uguali. Si consiglia di consentire lo stretching, nel qual caso sarà necessario impostare HXP.screen.scaleX e scaleY a diversi valori.

Dopo aver calcolato il rapporto, HXP.resize () è chiamato. Questa funzione è ciò che effettivamente ridimensiona lo schermo. Si potrebbe anche voler salvare il rapporto (s) per l'uso altrove, ma raramente ho trovato necessario.

Con lo schermo ridimensionato, siamo ancora in grado di fare cose del genere:

// posiziona l'entità nell'angolo in basso a destra dello schermo, qualunque sia la dimensione entity.x = HXP.screen.width - entity.scaledWidth; entity.y = HXP.screen.height - entity.scaledHeight;

Questo ci permette di avere un'interfaccia utente coerente per un gioco su molti dispositivi.

Orientamento del gioco

Nel precedente tutorial, ho parlato del project.xml file, che ci consente di configurare facilmente molti aspetti del nostro gioco. Tra le altre cose, possiamo impostare l'orientamento del gioco, che è utile per i dispositivi mobili. Ad esempio, se volessimo che il nostro gioco fosse eseguito in modalità verticale su dispositivi mobili, ma in modalità orizzontale su desktop:

Input e compilazione condizionale

L'input è abbastanza diverso tra i tipi di dispositivi. È irragionevole aspettarsi che il giocatore leghi una tastiera e un mouse bluetooth per giocare sul proprio telefono, ed è improbabile che anche oggi un desktop sia dotato di un touchscreen.

Nel gioco di esempio del tutorial precedente, ho usato HaxePunk Chiave classe per verificare la pressione dei tasti. Sui dispositivi touchscreen, tuttavia, avrebbe senso non importare la classe Key, mantenendo le dimensioni del gioco più basse, perché useremo i touch control.

Haxe rende questo facile per noi lasciandoci usare la compilazione condizionale. Funziona così:

condizione #if var x = 0; someFunction (); #elseif another_condition var y = 1; #else var z = 2; anotherFunction (); #fine

Le condizioni vengono valutate in fase di compilazione, il che significa che possiamo includere o escludere il codice a seconda della piattaforma che stiamo prendendo di mira! Per escludere la classe Key durante il targeting di dispositivi mobili, esegui semplicemente questa operazione:

import com.haxepunk.utils.Input; // probabilmente lo vuoi ancora, perché gestisce l'input per tutti i tipi di dispositivi #if! mobile import com.haxepunk.utils.Key; #end // Desideriamo anche rimuovere qualsiasi definizione di tastiera che potremmo avere, come ad esempio #if! mobile Input.define ("left", [Key.A, Key.LEFT]); Input.define ("right", [Key.D, Key.RIGHT]); #fine

Notare il! (non) operatore logico usato sopra. Possiamo anche usare && (e) così come || (o) nella compilazione condizionale. Se si desidera includere il codice per i dispositivi mobili ma non per iOS, si potrebbe dire

#if (mobile &&! ios) // codice qui #end

Come puoi vedere, la compilazione condizionale è abbastanza potente! Torniamo alla gestione degli input per un minuto. L'esclusione della classe Key durante la compilazione per obiettivi con un touchscreen è buona, ma non controlla automaticamente l'input tattile. 

Usando il gioco di corse dell'ultimo tutorial come esempio, potremmo cambiare il controllo degli input da questo:

if (Input.pressed ("left")) move ("left");  if (Input.pressed ("right")) move ("right"); 

A questo:

#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

Ora la tastiera sarà utilizzata per controllare il movimento su piattaforme desktop e toccare il lato sinistro o destro dello schermo controllerà il movimento su piattaforme mobili!

Se lo desideri, puoi anche specificare le tue parole chiave da utilizzare con la compilazione condizionale, sia nel codice sorgente del gioco che nel file di progetto .xml.

#if myOwnKeyword aCoolSecretForWhateverReason (); #fine

Per includere il codice sopra, puoi semplicemente passare un'opzione durante la compilazione:

test di calce  -DmyOwnKeyword

Questo potrebbe essere usato per contrassegnare copie di recensione o versioni beta come tali all'interno del gioco stesso, per scoraggiare perdite o beta test di diverse parti del gioco con persone diverse. Potrebbe anche essere usato per creare una versione demo che limiti le aree del gioco, o anche usato per fare una versione personale come regalo a sorpresa.

Invio a più app store

Dopo aver realizzato un grande gioco multipiattaforma, il passo successivo è quello di rilasciarlo su vari app store e marketplace. Ogni mercato avrà requisiti diversi, ma ci sono cose che puoi fare che si applicano a tutti (o almeno alla stragrande maggioranza dei) mercati. Naturalmente, il miglior consiglio che posso offrire in quest'area è leggere attentamente le istruzioni per la presentazione per scoprire cosa ogni mercato vuole da voi.

Un ovvio requisito è fornire screenshot. Il numero e la risoluzione richiesta varieranno, ma ogni marketplace dovrebbe dirti cosa vogliono. Consiglierei di fornire assolutamente non meno di due screenshot, ma preferibilmente quattro o più.

Proprio come i requisiti per gli screenshot variano, così anche i requisiti per le icone. Alcuni negozi vorranno un'icona a bassa risoluzione e un'icona a risoluzione più alta, quindi è meglio iniziare con un'icona grande che può essere ridotta a diverse dimensioni.

Alcuni negozi ti permetteranno anche di caricare uno o più video. Ti suggerisco di creare un video che mostri le basi del tuo gioco quando ti invii agli app store per dispositivi mobili e almeno un video per altri mercati (Steam, Desura, ecc.). Ricorda: se un'immagine vale più di mille parole e un video può essere pensato per il numero di immagini riprodotte in sequenza, un video è piuttosto prezioso!

Ci sono anche molte informazioni che dovrebbero essere richieste a qualsiasi negozio a cui invii un gioco: titolo, descrizione, icona e categoria. È utile per i giocatori (potenziali o meno) se queste informazioni sono le stesse su tutte le piattaforme.

Ora puoi pubblicare ovunque

Dopo aver creato un gioco con OpenFL, il file binario dovrebbe essere pronto per essere inviato a qualsiasi marketplace per la piattaforma creata senza alcuna modifica. Ricorda solo di creare e inviare una versione di rilascio, non una versione di debug!

Ora che hai visto i modi per far funzionare bene i tuoi giochi su una varietà di dispositivi, spero che metterai a frutto questa conoscenza e realizzerai alcuni fantastici giochi! Un ultimo consiglio: finire un gioco è grandioso e qualcosa di cui essere orgogliosi, ma il rilascio di un gioco può richiedere altrettanto lavoro!