Share
Bienvenido a la segunda parte de esta serie de tutoriales sobre cómo hacer juegos multiplataforma con HaxePunk. Cuando lo dejamos, habíamos terminado de crear un simple juego de carreras de resistencia que se puede compilar para muchas plataformas diferentes. En esta segunda parte, le daré algunos consejos para que sus juegos funcionen bien en múltiples tipos de dispositivos. Hablaremos sobre tamaños y resoluciones de pantalla, tipos de entrada, diseños de interfaz y consejos para envíos de la tienda de aplicaciones..
La pantalla es la ventana a tu juego, y no debe dejarse como una idea de último momento. Piensa en los dispositivos en los que planeas lanzar tu juego. Una versión de Windows / Mac / Linux por lo general puede depender de que el usuario tenga una pantalla lo suficientemente grande como para ajustarse al juego en modo de ventana, y puede incluir cualquier diferencia de resolución en el modo de pantalla completa.
Los dispositivos móviles son bastante diferentes. Hay muchas pantallas de varias resoluciones y tamaños. No puedes garantizar que el jugador juegue en un dispositivo con la misma resolución que tu juego. La escalada va a suceder.
En el primer artículo de esta serie, recorrí el desarrollo de un pequeño juego de ejemplo. Puede descargar el proyecto de código fuente completo usando el botón a la derecha de este artículo. La última vez, es posible que hayas notado declaraciones como esta:
y = -imagen.escaladaHeight;
Hay propiedades de ancho y alto para las imágenes, y hay ancho de escala y escalado propiedades también. El significado del ancho y alto de una imagen es obvio. Las propiedades de escala son un poco más complejas. los ancho de escala propiedad es el ancho de la imagen multiplicado por la escala de la imagen multiplicado por la escala del juego, y escalado Es similar, pero para la altura..
Sin embargo, esto se vuelve un poco confuso cuando el juego se escala automáticamente, como podría suceder en un dispositivo Android con una resolución de pantalla más baja de la que fue diseñado para el juego. En una situación como esta, la propiedad de escala que HaxePunk lee para establecer la escala de las imágenes y, por lo tanto, su Escala de Ancho / Altura, probablemente no se configurará correctamente.
De hecho, a menudo no hay escalamiento, solo un encogimiento de la pantalla. Para solucionar este problema, podemos calcular la cantidad de escalado que nos gustaría, según la resolución del juego y la resolución de la pantalla en la que se está ejecutando el juego. En Main.hx podemos agregar este código antes de configurar la escena activa:
relación 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);
En el codigo anterior, Ancho de pantalla y screenHeight son las variables que he creado y que he establecido en el ancho y la altura que utilicé para el juego. También puedes simplemente usar constantes como 640 y 480, pero prefiero usar variables.
El código utiliza el Math.min () función para establecer la variable de relación a la diferencia más baja en las dimensiones de la pantalla para evitar que los gráficos se estiren si las diferencias en ancho y alto no son iguales. Es posible que desee permitir el estiramiento, en cuyo caso deberá establecer HXP.screen.scaleX y escalable a diferentes valores.
Una vez calculada la relación, HXP.resize () se llama. Esta función es la que realmente cambia el tamaño de la pantalla. Es posible que también desee guardar la (s) proporción (s) para usar en otros lugares, pero rara vez lo he encontrado necesario.
Con la pantalla redimensionada, todavía podemos hacer cosas como esta:
// coloca la entidad en la esquina inferior derecha de la pantalla, sea cual sea el tamaño entity.x = HXP.screen.width - entity.scaledWidth; entity.y = HXP.screen.height - entity.scaledHeight;
Esto nos permite tener una interfaz de usuario consistente para un juego en muchos dispositivos.
En el tutorial anterior, hablé sobre el proyecto.xml Archivo, que nos permite configurar fácilmente muchos aspectos de nuestro juego. Entre otras cosas, podemos establecer la orientación del juego, que es útil para dispositivos móviles. Por ejemplo, si queremos que nuestro juego se ejecute en modo vertical en dispositivos móviles pero en modo horizontal en el escritorio:
La entrada difiere bastante entre los tipos de dispositivos. No es razonable esperar que el jugador conecte un teclado y un mouse bluetooth para jugar un juego en su teléfono, y es poco probable incluso hoy en día que un escritorio esté equipado con una pantalla táctil.
En el juego de ejemplo del tutorial anterior, usé HaxePunk's Llave clase para comprobar las pulsaciones de teclas. Sin embargo, en los dispositivos con pantalla táctil, tendría sentido no importar la clase de Clave, manteniendo el tamaño del juego más bajo, ya que usaremos controles táctiles.
Haxe nos lo pone fácil al permitirnos usar la compilación condicional. Funciona así:
#if condición var x = 0; someFunction (); #elseif another_condition var y = 1; #else var z = 2; anotherFunction (); #fin
Las condiciones se evalúan en el momento de la compilación, lo que significa que podemos incluir o excluir el código según la plataforma a la que nos dirigimos. Para excluir la clase de Clave al apuntar a dispositivos móviles, simplemente haga esto:
Accentsconagua
importar com.haxepunk.utils.Input; // probablemente todavía querrá esto, porque maneja la entrada para todos los tipos de dispositivos #if! mobile import com.haxepunk.utils.Key; #end // También queremos eliminar cualquier definición de teclado que podamos tener, como #if! mobile Input.define ("left", [Key.A, Key.LEFT]); Input.define ("right", [Key.D, Key.RIGHT]); #finObserve la ! (no) operador lógico utilizado anteriormente. También podemos usar && (y) así como también || (o) en compilación condicional. Si quisiera incluir código para dispositivos móviles pero no para iOS, podría decir:
#if (mobile &&! ios) // código aquí #end
Como puedes ver, la compilación condicional es bastante poderosa! Volvamos al manejo de entrada por un minuto. Excluir la clase Clave al compilar para objetivos con una pantalla táctil es bueno, pero no comprueba automáticamente la entrada táctil.
Usando el juego de carreras del último tutorial como ejemplo, podríamos cambiar la comprobación de entrada de esto:
if (Input.pressed ("left")) move ("left"); if (Input.pressed ("right")) move ("right"); A esto:
#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
Ahora el teclado se utilizará para controlar el movimiento en las plataformas de escritorio, y al tocar el lado izquierdo o derecho de la pantalla se controlará el movimiento en las plataformas móviles!
Si lo desea, también puede especificar sus propias palabras clave para usar con la compilación condicional, tanto en el código fuente del juego como en el archivo de proyecto .xml..
#if myOwnKeyword aCoolSecretForWhateverReason (); #fin
Para incluir el código anterior, simplemente puede pasar una opción al compilar:
prueba de cal-DmyOwnKeyword
Esto podría usarse para marcar copias de revisión o lanzamientos beta como tales dentro del juego en sí, para desalentar fugas o realizar pruebas beta de diferentes partes del juego con diferentes personas. También se puede usar para crear una versión de demostración que limita las áreas del juego, o incluso para hacer una versión personal como regalo sorpresa..
Después de haber creado un gran juego multiplataforma, el siguiente paso es lanzarlo en varias tiendas de aplicaciones y mercados. Cada mercado tendrá diferentes requisitos, pero hay cosas que puede hacer que se aplicarán a todos (o al menos a la gran mayoría de) los mercados. Por supuesto, el mejor consejo que puedo ofrecerle en esta área es leer atentamente las instrucciones de envío para averiguar lo que cada mercado quiere de usted..
Un requisito obvio es proporcionar capturas de pantalla. El número y la resolución requerida variarán, pero cada mercado debe decirle lo que quiere. Recomiendo proporcionar absolutamente nada menos que dos capturas de pantalla, pero preferiblemente cuatro o más.
Así como los requisitos para las capturas de pantalla variarán, también lo harán los requisitos para los íconos. Algunas tiendas querrán un ícono de resolución más baja, así como un ícono de resolución más alta, por lo que es mejor comenzar con un ícono grande que pueda reducirse a diferentes tamaños.
Algunas tiendas también te permitirán subir uno o más videos. Sugiero crear un video que demuestre los aspectos básicos de su juego al enviar a las tiendas de aplicaciones móviles, y al menos un video para otros mercados (Steam, Desura, etc.). Recuerde: si una imagen vale más que mil palabras y se puede pensar en un video como muchas imágenes reproducidas en secuencia, un video es bastante valioso.!
También hay varias piezas de información que deben ser requeridas en cualquier tienda a la que envíes un juego: título, descripción, icono y categoría. Es útil para los jugadores (potenciales o no) si esta información es la misma en todas las plataformas..
Después de crear un juego con OpenFL, el binario debe estar listo para enviarse a cualquier mercado para la plataforma que construyó sin cambios necesarios. Solo recuerda compilar y enviar una versión de lanzamiento, no una versión de depuración!
Ahora que has visto maneras de hacer que tus juegos funcionen bien en una variedad de dispositivos, ¡espero que pongas este conocimiento en práctica y hagas algunos juegos geniales! Un último consejo: terminar un juego es genial, y es algo de lo que estar orgulloso, pero lanzar un juego puede llevarle tanto trabajo.!
