Idea principal

Se han escrito muchos libros, artículos y tutoriales sobre aplicaciones de evaluación comparativa, motores y diversos sistemas de software.

Esto es lo que nos da la antigua Wikipedia sobre este tema:

Prueba de rendimiento, punto de referencia (punto de referencia en inglés): la tarea de control necesaria para determinar las características comparativas de rendimiento de un sistema informático.

Pero, ¿qué pasa si llegamos al tema de los motores de juego de evaluación comparativa un poco desde el otro lado? Todos los motores de juegos y SDK para el desarrollo de juegos (y no solo) a menudo se anuncian como herramientas muy intuitivas y fáciles de digerir. Estamos vendiendo simplicidad para aprender, una sorprendente curva de aprendizaje y entrada, se muestran ejemplos livianos y hermosos, donde una pantalla de código, cuando se lanza, crea algún tipo de magia maravillosa. Entonces, en preparación para el próximo evento de Ludum Dare , una vez más decidí mirar a mi alrededor y ver qué ofrecen los "mercados" a Emele, alguien que ha estado en desarrollo de juegos durante una semana sin un año. Es decir, uno de los grupos de personas de la misma CA que vende estas cualidades sorprendentes de fácil digestibilidad del motor.

¿Qué pasa si ... intentamos compararnos mientras trabajamos con varios motores para escribir juegos? Sí, sí, es decir, su productividad en ellos. Literalmente, tome algunos de ellos, encerrarnos en una cueva con una computadora portátil, Internet y un cronómetro y anote todos nuestros resultados en una tableta ordenada, y luego intente sacar algunas conclusiones. Al mismo tiempo, notamos que me gustó, lo que sorprendió o forzó el trabajo con uno u otro motor.

Sobre punto de referencia

Entonces, los objetos de prueba son tres motores de juego. Aquí probablemente valga la pena describir de manera más o menos formal (tanto como sea posible) su "configuración" (sí, como en el caso de los resultados de referencia típicos, escriben la configuración de hierro, dónde hicieron las ejecuciones, la descripción de la referencia, etc.).

"Configuración" o Acerca de mí

Soy un desarrollador de Java. Experiencia en desarrollo industrial 5+ años. También en el trabajo escribí un poco en JavaScript, Lua (realmente, realmente un poco), shell. Educación técnica superior. No asistí a cursos de diseño, no aprendí diseño de juegos, solo era un fanático ardiente de varios juegos de PC. El año pasado se interesó en crear los juegos de computadora más simples.

Sobre la tarea

Se seleccionó un proyecto de prueba del clon del juego Doodle Jump. Estoy seguro de que mucha gente lo sabe o lo ha jugado, este es un juego muy bueno y muy bien desarrollado para Android.

El reglamento será el siguiente:

1. Cada motor tiene 4 horas de tiempo. Esto incluye estudiar, conocer, hurgarse en la nariz, tratar de escribir un prototipo, depurar el juego, en general, el ciclo completo de creación del juego.
2. Cada media hora, en un breve descanso, trataré de arreglar lo que se ha hecho para corregir mi trabajo de alguna manera, para delinear un plan de trabajo adicional, tomar notas, notas, etc.
3. Antes de comenzar a probar cada motor, intentaremos descomponer el proyecto del juego en sus elementos constitutivos para asignarles unidades convencionales. Por lo tanto, medimos nuestra "productividad" del desarrollador del juego para cada motor en loros y podemos comparar los resultados no en palabras, sino en al menos algunos números.

Descomposición del juego en componentes.

En una forma muy abstracta y de alto nivel, me veo a mí mismo como componentes constitutivos del juego así:

1. Jugador (sprite, comportamiento de salto, reacción a los botones presionados)
2. Objetos de nivel: plataformas, enemigos, etc.
3. Física: la velocidad de salto del jugador, la aceleración de la caída libre, las plataformas solo deben manejar las colisiones si se saltaron desde arriba y dejar que el jugador lo atraviese si lo cruza desde la parte inferior de la plataforma.
4. Generación de nivel de procedimiento: inicialización y adición al nivel (a lugares arbitrarios, pero con ciertas reglas y restricciones) sobre la marcha de nuevas plataformas y enemigos, creando una situación de juego atractiva para el jugador
5. Una "cámara" que sigue al jugador mientras sube el nivel. La cámara debe mantener al jugador en visibilidad para el jugador y gradualmente "rebotar" con él, mostrando nuevas plataformas que aparecen en el área de renderizado (en la visibilidad de la cámara)
6. Game Over mecanismo de disparo. Un jugador pierde si alcanza el borde inferior del área visible (después de haber saltado al menos una vez)
7. Puntuación de un jugador. Simplemente actualizaremos el contador de altura del jugador. Actualizaremos el contador de acuerdo con la última plataforma alcanzada (la que empujó la última vez)
8. HUD : muestra el progreso del jugador. Pantalla de altura.

Para simplificar, asignamos a cada componente un punto de nuestras unidades de loros. Máximo total, es decir La versión jugable completa del proyecto es de 8 puntos.

A continuación se muestran los activos utilizados en la pantalla. Estos son sprites de personajes y plataformas dibujados a mano (no soy un artista, como puedes ver) con dimensiones de 64x64, formato * .png.

Y también da un par de diagramas de flujo:

1. Por lo tanto, se implementará el cálculo del "género" para el jugador (recuerde, con un salto hacia arriba, la pantalla cambia y la salida sobre el borde de la pantalla significa una zanja)
   
2. Y así, calculamos y actualizamos la velocidad vertical ( y_velocity ) y la coordenada y del jugador con cada latido, está influenciada por dos factores: la aceleración de la gravedad ( GRAVITY ) y las plataformas, al llegar a la cual, el jugador se repele con la velocidad restaurada por completo
   
3. El algoritmo para calcular la velocidad horizontal, como otros mecanismos, quedó fuera del alcance del artículo.

Por cierto, todavía tengo preguntas:

1. ¿Cómo es mejor implementar el seguimiento de cámara para un jugador? Hasta ahora, estará vinculado a la coordenada vertical de la última plataforma más alta que el jugador pudo alcanzar, por lo que esta plataforma está en la parte inferior del área visible, y vemos nuevas piezas del nivel generado.
2. El algoritmo de generación de plataforma en sí. Según mi idea, esta será una especie de "fábrica de plataformas", que en cada ciclo del ciclo del juego ( dt ) conoce la plataforma más alta que existe en el nivel y con un valor de altura aleatorio (un cierto umbral, no más que la altura de salto del jugador, pero también no menos de una cierta fracción de sus alturas, para que las plataformas no se peguen entre sí) agrega una nueva plataforma al nivel cuando el jugador ha avanzado. La cuestión de la creciente complejidad del juego también es interesante aquí, cómo debería cambiar el modo de generar estas plataformas.

Estaría muy feliz por sus ideas, trucos de vida y sugerencias en los comentarios y PM sobre estos dos temas de diseño de juegos.

Sobre motores

Se seleccionaron tres candidatos con características muy interesantes para mí. Por lo tanto, los parámetros que serán útiles para tener en cuenta al analizar los resultados de sus pruebas se resumen a continuación.

Entonces, vemos que la selección es bastante interesante. Es interesante porque trataremos con diferentes combinaciones de nuestras cualidades y características de los motores. Y veamos qué se resuelve al final: un motor en el que ya tuve un poco de mi mano, un YP bombeado o un motor completamente nuevo y nuevo para mí con chips prometedores, pero no dominado en absoluto, y tampoco en mi lenguaje principal de desarrollo.

¿Por qué no Unity / Unreal Engine / Other Awesome Engine, etc.?

Muchos probablemente se preguntarán por qué, no tomé el camino estándar y no tomé los buques insignia más comunes de nuestro tiempo: ¿Unity o Unreal Engine? Formularía mis pensamientos de esta manera: quiero construir un juego muy simple, minimalista y pequeño. Con un par de elementos del juego que componen la mecánica del juego, un personaje jugable, generación simple de niveles y sin efectos especiales o efectos especiales muy convencionales, como en las máquinas arcade antiguas. Entonces, en sentido figurado, mi tarea es dibujar un círculo rojo en un cuadrado negro, y para esto estoy invitado a tomar Photoshop . En pocas palabras, un conjunto de características, modos y capacidades de Unity me asustó. En esta etapa, me gustaría entender cada detalle de mi juego.

Esto se hace mejor con motores simples y pequeños, con un conjunto limitado de características, quizás no con el mejor ajuste y ecosistema, pero la simplicidad y la limitación también tienen su propia belleza. Con solo un conjunto limitado de herramientas, y en el caso de Love2D, tu herramienta es tu código y nada más, te enfocas en el fanático, en escribir algo genial, revivir el personaje o el entorno del jugador. Los motores más complicados ya amplían su elección, y escribir código fluye suavemente en muchas cosas: escribir scripts (código), vincular scripts, asignar recursos, agregar configuraciones, redefinir configuraciones, mezclar complementos de terceros, escribir scripts y configuraciones para complementos de terceros, múltiples clics en docenas y docenas de diálogos y ventanas ... Digamos que por el momento todavía tengo miedo de motores de desarrollo de juegos tan sofisticados, indudablemente avanzados y potentes. Bueno, no quiero recordar C # / JS / C ++ nuevamente y escribir en ellos.

Resumiré mi motivación al elegir un motor con un enlace a este video, donde me parece que el autor literalmente eliminó literalmente de mi idioma lo que intenté formular con palabras para mí y para los demás todo este tiempo: https://www.youtube.com/watch ? v = JH8xwNOQ0TM

Desplegar

Defold es un motor multiplataforma de King.
Plataformas compatibles:

• Html5 (WebGl)
• Android 2.3 (API nivel 9) +
• iOS 8.0+
• Windows Vista +
• OSX 10.7+
• Linux

El hecho curioso es que King es propiedad de Activision Blizzard .
El motor de desarrollo me atrajo: Lua , el soporte para un montón de plataformas para las compilaciones del juego, así como la distribución de su propio IDE multiplataforma, también se puede instalar en Linux. Esto me sobornó al elegir entre Defold vs. Corona SDK .
Y a continuación se muestra el registro de lo que se hizo en los puntos de control:

A continuación, en el spoiler, hay algunas animaciones gif que muestran el progreso en el tiempo:

Resultado, puntos de referencia:

1. Jugador (sprite, comportamiento de salto, reacción a los botones presionados) (V) Yes
2. Objetos de nivel: plataformas, enemigos, etc. (V) Yes
3. Física: velocidad de salto del jugador, aceleración de caída libre, las plataformas solo deben manejar las colisiones si se saltan desde arriba y dejan que el jugador lo atraviese si lo cruza desde la parte inferior de la plataforma. (V) Yes
4. Generación de nivel de procedimiento: inicialización y adición al nivel (a lugares arbitrarios, pero con ciertas reglas y restricciones) sobre la marcha de nuevas plataformas y enemigos, creando para el jugador una situación de juego atractiva (X) No
5. Una "cámara" que sigue al jugador mientras sube el nivel. La cámara debe mantener al jugador en visibilidad para el jugador y gradualmente "rebotar" con él, mostrando nuevas plataformas que aparecen en el área de renderizado (en la visibilidad de la cámara) (X) No
6. Game Over mecanismo de disparo. Un jugador pierde si alcanza el borde inferior del área visible (después de haber saltado al menos una vez) (X) No
7. Puntuación de un jugador. Simplemente actualizaremos el contador de altura del jugador. Actualizaremos el contador de acuerdo con la última plataforma alcanzada (la que empujó la última vez) (V) Yes
8. HUD: muestra el progreso del jugador. Pantalla de altura. Opcionalmente, parece que no hay indicadores de progreso en el juego original. (V) Yes

Puntuación de referencia: 5/8

Love2d

Este es un motor muy minimalista, pero lo suficientemente potente y flexible para crear prototipos. En general, con la debida destreza, incluso es adecuado para publicar juegos completos en el mercado. Hay algunos buenos ejemplos inspiradores. Por casualidad, uno y dos .

En general, para este motor, recomiendo una serie muy adecuada de tutoriales de Habr, que me impulsó y dio un fuerte impulso al desarrollo de este motor, solo le daré un enlace a la primera parte, luego puede acceder a las partes restantes: Crear un juego en Lua y LÖVE - 1

Entonces, a continuación se muestra el registro de lo que se hizo en los puntos de control:

Calcule el "rendimiento" del motor:

1. Jugador (sprite, comportamiento de salto, reacción a los botones presionados) (V) Yes
2. Objetos de nivel: plataformas, enemigos, etc. (V) Yes
3. Física: velocidad de salto del jugador, aceleración de caída libre, las plataformas solo deben manejar las colisiones si se saltan desde arriba y dejan que el jugador lo atraviese si lo cruza desde la parte inferior de la plataforma.
   (V) Yes / (X) No // * Implementado, pero no del todo perfecto, con fallas significativas. Pondría aquí 0.5 puntos por completar el artículo.
4. Generación de nivel de procedimiento: inicialización y adición al nivel (a lugares arbitrarios, pero con ciertas reglas y restricciones) sobre la marcha nuevas plataformas y enemigos, creando para el jugador una situación de juego atractiva (V) Yes
5. Una "cámara" que sigue al jugador mientras sube el nivel. La cámara debe mantener al jugador en visibilidad para el jugador y gradualmente "rebotar" con él, mostrando nuevas plataformas que aparecen en el área de renderizado (en la visibilidad de la cámara) (V) Yes
6. Game Over mecanismo de disparo. Un jugador pierde si alcanza el borde inferior del área visible (después de haber saltado al menos una vez) (V) Yes
7. Puntuación de un jugador. Simplemente actualizaremos el contador de altura del jugador. Actualizaremos el contador de acuerdo con la última plataforma alcanzada (la que empujó la última vez) (V) Yes
8. HUD: muestra el progreso del jugador. Pantalla de altura. Opcionalmente, parece que no hay indicadores de progreso en el juego original. (V) Yes

Puntuación de referencia: 7,5 / 8

Java

Quizás un paso lógico y lógico sería echar un vistazo más de cerca a los motores, donde el lenguaje de desarrollo es aquel en el que tengo más experiencia y destreza, ¿no es así? En realidad, la intuición y algunas sensaciones internas me alejaron un poco de esto. El hecho es que, como estudiante, de alguna manera vi jMonkey mi compañero de clase con el motor jMonkey . Las herramientas, el trabajo con el motor, la documentación, todo esto en conjunto creó una especie de imagen no muy agradable. Parecía que el motor simplemente no le daba la oportunidad de hacerse amigo de él, en gran medida su uso parecía de alguna manera desagradable.

Pero, sin embargo, decidí mirar lo que está disponible hoy, y solo miré en la dirección de los motores que bien garantizan solo 2D , no me importaba 3D soporte 3D . Uno de los motores, Lightweight Java Game Library 3 , tiene su nombre y la palabra introductoria Lightweight . Irónicamente, los ejemplos básicos más simples en la página principal, varias pantallas de largo, simplemente se espantaron.

Sí, por supuesto, Java muy detallado, dices lo que querías. Pero sé que puedes escribir cosas muy compactas y muy expresivas en él. Vi una API hermosa y compacta.
Y al final, la elección recayó en FXGL . Al principio, no tenía ningún entusiasmo y una emoción agradable, lo que sucede antes del comienzo del desarrollo de algo interesante o biblioteca. Pero ya desde los primeros ejemplos y breves páginas de documentación y ejemplos, este motor me sorprendió gratamente cada vez más. Todo era lógico, comprensible y consistente en el enfoque y API que propuso. Definitivamente lo ayudó a construir un ciclo claro y flexible para su juego, lógica de manejador, HUD , AI , colisiones y otros elementos.

Momentos interesantes y chips FXGL:

• Como su nombre indica, para la parte visual, el motor usa la API JavaFX ( JavaFX se usa como marco de gráficos) con todas sus ventajas y propiedades para la representación y el diseño. En general, creo que esta es una decisión buena y bastante sólida. Por lo tanto, el autor evitó una serie de problemas (no es necesario implementar y mantener su componente de representación, puede usar una solución refinada del ecosistema de Java ). Esto es lo que el propio autor dice en uno de sus primeros tutoriales, y realmente me gustó esta frase:

  
  

  "Para la mayoría de los objetos de interfaz de usuario, simplemente usamos objetos JavaFX, ya que no hay necesidad de reinventar la rueda".

  Pero en general, por supuesto, también obtienes un montón de características y algunas desventajas de JavaFX (no conozco los detalles), pero que yo sepa, hay algunas restricciones de licencia en el uso de JavaFX en tus proyectos, y parece que JavaFX va e irá solo en entregas limitadas de JDK ( Oracle , tal vez un poco más).

  
  

• Un proyecto de prueba, inclinado desde el repositorio, en base al cual comencé a esculpir el juego, amablemente coloca los registros en la logs/ proyectos después de cada inicio del juego. Esto es muy conveniente, puede ver de inmediato la información de depuración, es muy útil para el diagnóstico, comprender dónde se equivocó si de repente se encontró con un tapón en el estudio del motor.

  
  

• Además (aparentemente de nuevo, con configuraciones básicas) el juego proporciona un menú emergente presionando la Esc . También es una buena ventaja, espero que esté personalizado o al menos deshabilitado por código o configuraciones.

  
  

• ¡Debag finalmente trabaja aquí ! Por fin! En Love2D por decir lo menos, es inconveniente y desagradable.

  
  

  Registro de desarrollo

  
  

  A continuación se muestra un breve resumen de mi progreso, donde noté brevemente lo que se logró después del intervalo de 30 minutos, así como algunos de mis pensamientos y comentarios. ¡Mira el registro de mi conciencia en estas 4 horas!

  
  

GIF- , .

"" … , , , ? .

Benchmark Score: 8

, ,

:

, , , ( ). , , Java FXGL , , Lua , . , , .

:

1. FXGL ? . Love2D , Defold , , , , Love2D - , .
2. , . , . (, ), . , - . , , , , . , , , . .
3. gif-, . . , , "" , .

?

, - , ?

Entonces

1. , . , , , , . - , - ( Love2D ).
2. - , Love2D , . F to pay respect .
3. . , , , - - , , (, , )
4. . 4 , . - Game Jam , .
5. ! , , - Roadmap , , . (!) (?) . 30 . , . , , ! , pet- 44 - Ludum Dare .