Share
Bienvenue dans la deuxième partie de cette série de didacticiels sur la création de jeux multiplates-formes avec HaxePunk. Lorsque nous nous sommes arrêtés, nous avions fini de créer un simple jeu de courses de dragsters pouvant être compilé pour différentes plateformes. Dans cette deuxième partie, je vous donnerai quelques conseils pour que vos jeux fonctionnent correctement sur plusieurs types d’appareils. Nous parlerons de la taille et de la résolution de l'écran, des types de saisie, de la disposition des interfaces et des astuces pour les soumissions d'applications..
L’écran est la fenêtre de votre jeu et ne doit pas être laissé après coup. Pensez aux appareils sur lesquels vous prévoyez de lancer votre jeu. Une version Windows / Mac / Linux peut généralement dépendre du fait que l'utilisateur dispose d'un écran suffisamment grand pour s'adapter au jeu en mode fenêtré, et peut utiliser Letterbox toute différence de résolution en mode plein écran..
Les appareils mobiles sont très différents. Il existe de nombreux écrans de différentes résolutions et tailles. Vous ne pouvez pas garantir que le joueur jouera sur un appareil avec la même résolution que votre partie. La mise à l'échelle va se produire.
Dans le premier article de cette série, j'ai décrit le développement d'un petit exemple de jeu. Vous pouvez télécharger le projet de code source complet en utilisant le bouton situé à droite de cet article. La dernière fois, vous avez peut-être remarqué des déclarations comme celle-ci:
y = -image.scaledHeight;
Il existe des propriétés de largeur et de hauteur pour les images, et scaledWidth et scaledHeight propriétés aussi. Les significations de la largeur et de la hauteur d'une image sont évidentes. Les propriétés mises à l'échelle sont un peu plus complexes. le scaledWidth propriété est la largeur de l'image multipliée par l'échelle de l'image multipliée par l'échelle du jeu, et scaledHeight est similaire, mais pour la hauteur.
Cependant, cela devient un peu déroutant lorsque le jeu est redimensionné automatiquement, comme cela pourrait arriver sur un appareil Android avec une résolution d'écran inférieure à celle pour laquelle le jeu a été créé. Dans une situation comme celle-ci, la propriété scale que HaxePunk lit pour définir l'échelle des images, et donc leur largeur / hauteur scaledWW, ne sera probablement pas définie correctement..
En fait, il n’ya souvent aucune mise à l’échelle, seulement une réduction de l’écran. Pour résoudre ce problème, nous pouvons calculer la quantité de mise à l'échelle souhaitée, en fonction de la résolution du jeu et de la résolution de l'écran sur lequel le jeu est exécuté. Dans Main.hx, nous pouvons ajouter ce code avant de définir la scène active:
rapport var: 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);
Dans le code ci-dessus, largeur d'écran et screenHeight sont des variables que j'ai créées et définies à la largeur et à la hauteur que j'ai utilisées pour le jeu. Vous pouvez aussi simplement utiliser des constantes telles que 640 et 480, mais je préfère utiliser des variables.
Le code utilise le Math.min () fonction pour définir la variable de ratio sur la plus petite différence de dimensions de l'écran afin d'éviter que les graphiques ne soient étirés si les différences de largeur et de hauteur ne sont pas égales. Vous pouvez autoriser l’étirement, auquel cas vous devrez définir HXP.screen.scaleX et échelleY à des valeurs différentes.
Après le ratio est calculé, HXP.resize () est appelé. Cette fonction est ce qui redimensionne réellement l’écran. Vous voudrez peut-être aussi enregistrer le (s) ratio (s) pour l’utiliser ailleurs, mais j’ai rarement jugé nécessaire.
Avec l'écran redimensionné, nous sommes toujours en mesure de faire les choses suivantes:
// place l'entité dans le coin inférieur droit de l'écran, quelle que soit sa taille entity.x = HXP.screen.width - entity.scaledWidth; entity.y = HXP.screen.height - entity.scaledHeight;
Cela nous permet d'avoir une interface utilisateur cohérente pour un jeu sur plusieurs appareils..
Dans le tutoriel précédent, j'ai parlé de la project.xml fichier, ce qui nous permet de configurer facilement de nombreux aspects de notre jeu. Entre autres choses, nous pouvons définir l'orientation du jeu, ce qui est utile pour les appareils mobiles. Par exemple, si nous voulions que notre jeu fonctionne en mode portrait sur les appareils mobiles mais en mode paysage sur le bureau:
L'entrée diffère un peu d'un type d'appareil à l'autre. Il est déraisonnable de s’attendre à ce que le joueur connecte un clavier et une souris Bluetooth pour jouer à un jeu sur son téléphone, et il est peu probable encore aujourd’hui qu’un ordinateur de bureau soit équipé d’un écran tactile..
Dans l'exemple de jeu du tutoriel précédent, j'ai utilisé celui de HaxePunk Clé classe pour vérifier les touches. Cependant, sur les appareils à écran tactile, il serait logique de ne pas importer la classe Key, en gardant une taille de jeu inférieure, car nous utiliserons des commandes tactiles..
Haxe nous facilite la tâche en nous permettant d'utiliser la compilation conditionnelle. Cela fonctionne comme ceci:
#if condition var x = 0; une fonction (); #elseif another_condition var y = 1; #else var z = 2; une autre fonction (); #fin
Les conditions sont évaluées au moment de la compilation, ce qui signifie que nous pouvons inclure ou exclure du code en fonction de la plate-forme que nous ciblons! Pour exclure la classe Key lors du ciblage d'appareils mobiles, procédez comme suit:
Accentsconagua
import com.haxepunk.utils.Input; // vous le souhaiterez probablement encore, car il gère les entrées pour tous les types de périphériques #if! mobile import com.haxepunk.utils.Key; #end // Nous souhaitons également supprimer toutes les définitions de clavier que nous pourrions avoir, comme ceci #if! mobile Input.define ("left", [Key.A, Key.LEFT]); Input.define ("right", [Key.D, Key.RIGHT]); #finRemarquez le! Opérateur logique (non) utilisé ci-dessus. Nous pouvons également utiliser && (et) ainsi que || (ou) en compilation conditionnelle. Si vous souhaitez inclure du code pour les appareils mobiles mais pas pour iOS, vous pouvez dire
#if (mobile &&! ios) // code ici #end
Comme vous pouvez le constater, la compilation conditionnelle est assez puissante! Revenons à la gestion des entrées pendant une minute. Exclure la classe Key lors de la compilation pour les cibles avec un écran tactile est agréable, mais cela ne vérifie pas automatiquement la saisie tactile.
En utilisant comme exemple le jeu de course du dernier tutoriel, nous pourrions modifier la vérification des entrées à partir de ceci:
if (Input.pressed ("left")) move ("left"); if (Input.pressed ("right")) move ("right"); Pour ça:
#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
Maintenant, le clavier sera utilisé pour contrôler le mouvement sur les plates-formes de bureau, et toucher le côté gauche ou droit de l'écran contrôlera le mouvement sur les plates-formes mobiles!
Si vous le souhaitez, vous pouvez également spécifier vos propres mots-clés à utiliser avec la compilation conditionnelle, à la fois dans le code source du jeu et dans le fichier de projet .xml..
#if myOwnKeyword aCoolSecretForWurtherReason (); #fin
Pour inclure le code ci-dessus, vous pouvez simplement passer une option lors de la compilation:
test à la chaux-DmyOwnKeyword
Cela pourrait être utilisé pour marquer les copies de révision ou les versions bêta en tant que telles dans le jeu lui-même, pour décourager les fuites ou tester les différentes parties du jeu avec différentes personnes. Il pourrait également être utilisé pour créer une version de démonstration qui limite les zones du jeu, ou même pour créer une version personnelle comme cadeau surprise..
Une fois que vous avez créé un excellent jeu multi-plateformes, l'étape suivante consiste à le publier sur différents magasins d'applications et marchés. Chaque marché aura des exigences différentes, mais vous pouvez faire certaines choses qui s’appliqueront à tous (ou du moins à la grande majorité des) marchés. Bien entendu, le meilleur conseil que je puisse offrir à cet égard est de lire attentivement les instructions de soumission pour savoir ce que chaque marché attend de vous..
Une exigence évidente est de fournir des captures d'écran. Le nombre et la résolution requise varieront, mais chaque marché devrait vous dire ce qu'il veut. Je recommanderais de ne fournir absolument pas moins de deux captures d'écran, mais de préférence quatre ou plus.
Tout comme les exigences pour les captures d'écran, les exigences pour les icônes varient. Certains magasins voudront une icône basse résolution ainsi qu'une icône haute résolution. Il est donc préférable de commencer par une grande icône pouvant être réduite à différentes tailles..
Certains magasins vous permettront également de télécharger une ou plusieurs vidéos. Je suggère de créer une vidéo qui présente les bases de votre jeu lors de la soumission à des magasins d'applications pour appareils mobiles, et au moins une vidéo destinée à d'autres marchés (Steam, Desura, etc.). Rappelez-vous: si une image vaut mille mots et qu'une vidéo peut être pensée comme autant d'images jouées en séquence, une vidéo a toute sa valeur!
Plusieurs informations sont également nécessaires dans tous les magasins auxquels vous soumettez un jeu: titre, description, icône et catégorie. Il est utile pour les joueurs (potentiels ou non) si cette information est la même sur toutes les plateformes..
Après avoir créé un jeu avec OpenFL, le binaire doit être prêt à être soumis à n'importe quel marché pour la plate-forme pour laquelle vous avez construit, sans aucune modification nécessaire. Rappelez-vous juste de construire et de soumettre une version, pas une version de débogage!
Maintenant que vous avez trouvé des moyens de faire en sorte que vos jeux fonctionnent correctement sur divers appareils, j'espère que vous tirerez parti de ces connaissances et créerez des jeux sympas! Un dernier conseil: terminer un jeu est une bonne chose et il faut en être fier, mais publier un jeu peut prendre tout autant de travail!
