Idée principale

De nombreux livres, articles et tutoriels ont été écrits sur les applications de benchmarking, les moteurs et divers systèmes logiciels.

Voici ce que l'ancien Wikipédia nous donne à ce sujet:

Test de performance, benchmark (benchmark anglais) - la tâche de contrôle nécessaire pour déterminer les caractéristiques de performance comparatives d'un système informatique.

Mais que se passe-t-il si nous arrivons à la question de l'analyse comparative des moteurs de jeu un peu de l'autre côté? Tous les moteurs de jeu et SDK pour le développement de jeux (et pas seulement) se présentent souvent comme des outils très intuitifs et faciles à digérer. Nous vendons la simplicité pour apprendre, une courbe d'apprentissage et d'entrée incroyable, des exemples légers et beaux sont montrés, où un seul écran de code, lorsqu'il est lancé, crée une sorte de magie merveilleuse. Donc, en préparation du prochain événement Ludum Dare , j'ai de nouveau décidé de regarder autour de moi et de voir ce que les «marchés» offrent à Emele simple - quelqu'un qui est en développement de jeu depuis une semaine sans un an. Autrement dit, l'un des groupes de personnes de la très CA qui vend ces qualités très étonnantes de digestibilité facile du moteur.

Et si nous ... essayons de nous comparer tout en travaillant avec différents moteurs pour écrire des jeux? Oui, oui, c'est-à-dire leur productivité sur eux. Littéralement, prenez-en quelques-uns, enfermez-vous dans une grotte avec un ordinateur portable, Internet et un chronomètre et notez tous nos résultats dans une tablette soignée, puis essayez de tirer des conclusions. En même temps, on constate que j'ai bien aimé, ce qui a surpris ou tendu à travailler avec l'un ou l'autre moteur.

À propos de benchmark

Ainsi, les objets de test sont trois moteurs de jeu. Ici, cela vaut probablement la peine de décrire de manière plus ou moins formelle (autant que possible) votre «configuration» (oui, comme dans le cas des résultats de référence typiques, ils écrivent la configuration de fer, où ils ont fait les analyses, la description de la référence, etc.).

"Configuration" ou À propos de moi

Je suis développeur Java. Expérience en développement industriel 5+ ans. Aussi dans le travail, j'ai écrit un peu en JavaScript, Lua (vraiment, vraiment un peu), shell. Enseignement technique supérieur. Je n'ai pas suivi de cours de conception, je n'ai pas appris la conception de jeux, je n'étais qu'un ardent fan de divers jeux PC. L'année dernière, il s'est intéressé à la création des jeux informatiques les plus simples.

À propos de la tâche

Un projet de test du clone du jeu Doodle Jump a été sélectionné. Je suis sûr que beaucoup de gens le connaissent ou l'ont joué, c'est un jeu très cool et très bien développé pour Android.

Le règlement sera le suivant:

1. Chaque moteur a 4 heures de temps. Cela comprend l'étude, la connaissance, le choix du nez, la tentative d'écriture d'un prototype, le débogage du jeu, en général, le cycle complet de création du jeu.
2. Toutes les demi-heures, pendant une courte pause, j'essaierai de corriger ce qui a été fait pour corriger en quelque sorte mon travail, pour définir un plan de travail supplémentaire, prendre des notes, des notes, etc.
3. Avant de commencer à tester chaque moteur, nous essaierons de décomposer le projet de jeu en ses éléments constitutifs afin de leur attribuer des unités conventionnelles. Ainsi, nous mesurons notre "productivité" du développeur de jeu pour chaque moteur en perroquets et pouvons comparer les résultats non pas avec des mots, mais au moins en quelques chiffres.

Décomposition du jeu en composants

Dans une forme très abstraite et de haut niveau, je me vois comme des composants constitutifs du jeu comme ceci:

1. Joueur (sprite, comportement de saut, réaction aux boutons pressés)
2. Objets de niveau: plates-formes, ennemis, etc.
3. Physique: vitesse de saut du joueur, accélération de la chute libre, les plates-formes ne doivent gérer les collisions que si elles ont été sautées d'en haut et laisser le joueur le traverser s'il le traverse du bas de la plate-forme.
4. Génération de niveau procédural: initialisation et ajout au niveau (à des endroits arbitraires, mais avec certaines règles et restrictions) à la volée de nouvelles plates-formes et ennemis, créant une situation de jeu attrayante pour le joueur
5. Une «caméra» qui suit le joueur alors qu'il monte dans le niveau. La caméra doit garder le joueur dans la visibilité du joueur et «rebondir» progressivement avec lui, affichant de nouvelles plateformes apparaissant dans la zone de rendu (dans la visibilité de la caméra)
6. Mécanisme de déclenchement Game Over . Un joueur perd s'il atteint le bord inférieur de la zone visible (après avoir déjà sauté au moins une fois)
7. Marquer un joueur. Nous allons simplement mettre à jour le compteur de hauteur du joueur. Nous mettrons à jour le compteur en fonction de la dernière plateforme atteinte (celle dont il a repoussé la dernière fois)
8. HUD : affiche la progression du joueur. Affichage de la hauteur.

Pour plus de simplicité, nous attribuons à chaque composant un point de nos unités de perroquet. Maximum total - c.-à-d. La version jouable complète du projet est de 8 points.

Voici les actifs utilisés dans l'affichage. Ce sont des sprites de personnages et de plates-formes dessinés à la main (je ne suis pas un artiste, comme vous pouvez le voir) avec des dimensions de 64x64, au format * .png.

Et donnez également quelques organigrammes:

1. Ainsi, le calcul du "genre" pour le joueur sera implémenté (rappelez-vous, avec un saut vers le haut, l'écran se décale, et le départ sur le bord de l'écran signifie un fossé)
   
2. Et donc nous calculons et mettons à jour la vitesse verticale ( y_velocity ) et la coordonnée y du joueur à chaque battement, elle est influencée par deux facteurs: l'accélération de la gravité ( GRAVITY ) et les plates-formes, en atteignant laquelle, le joueur est repoussé avec une vitesse entièrement restaurée
   
3. L'algorithme de calcul de la vitesse horizontale, comme les autres mécanismes, a été exclu du champ d'application de l'article.

Au fait, j'ai encore des questions:

1. Comment est-il préférable de mettre en œuvre le suivi de la caméra pour un joueur? Jusqu'à présent, il sera lié aux coordonnées verticales de la dernière plate-forme la plus haute que le joueur a pu atteindre, donc cette plate-forme est dans la partie inférieure de la zone visible, et nous voyons de nouvelles pièces du niveau généré.
2. L'algorithme de génération de plateforme lui-même. Selon mon idée, ce sera une sorte de «plate-forme d'usine» qui, à chaque cycle du cycle de jeu ( dt ), connaît la plate-forme la plus élevée qui existe au niveau et avec une valeur de hauteur aléatoire (un certain seuil, pas plus que la hauteur de saut du joueur, mais aussi pas moins qu'une certaine fraction de ses hauteurs, afin que les plates-formes ne s'accrochent pas les unes aux autres) ajoute une nouvelle plate-forme au niveau lorsque le joueur a avancé. La question de la complexité croissante du jeu est également intéressante ici, comment le mode de génération de ces plateformes devrait changer.

Je serais très heureux pour vos idées, astuces de vie et suggestions dans les commentaires et PM sur ces deux problèmes de conception de jeu sans aucun doute.

À propos des moteurs

Trois candidats ont été sélectionnés avec des caractéristiques très intéressantes pour moi. Ainsi, les paramètres qui seront utiles à garder à l'esprit lors de l'analyse des résultats de vos tests sont résumés ci-dessous.

On voit donc que la sélection est assez intéressante. Il est intéressant de noter que nous traiterons différentes combinaisons de nos qualités et caractéristiques des moteurs. Et voyons ce qui se résout au final: un moteur dans lequel j'ai déjà un peu mis la main, un YP pompé ou un moteur complètement frais et nouveau pour moi avec des puces prometteuses, mais pas du tout maîtrisé, et pas non plus dans mon langage de développement principal.

Pourquoi pas Unity / Unreal Engine / Other Awesome Engine etc.?

Beaucoup se demanderaient probablement pourquoi, je ne suis pas allé de la manière standard, et je n'ai pas pris les produits phares les plus courants de notre temps: Unity ou Unreal Engine? Je formulerais mes pensées de cette façon: je veux construire un jeu très simple, minimaliste et minuscule. Avec quelques éléments de jeu qui composent la mécanique du jeu, un personnage jouable, une génération simple de niveaux et sans effets spéciaux ou effets spéciaux très conventionnels, comme sur les vieilles machines d'arcade. Donc, au sens figuré, ma tâche est de dessiner un cercle rouge sur un carré noir, et pour cela je suis invité à prendre Photoshop . Autrement dit, un ensemble de fonctionnalités, de modes et de capacités d' Unity m'a fait peur. A ce stade, j'aimerais comprendre chaque détail de mon jeu.

Cela est mieux fait par des moteurs simples et petits, avec un ensemble limité de fonctionnalités, peut-être pas avec le meilleur réglage et l'écosystème, mais la simplicité et la limitation ont également leur propre beauté. Avec seulement un ensemble limité d'outils - et dans le cas de Love2D, votre outil est votre code et rien de plus, vous vous concentrez sur le fan, sur l'écriture de quelque chose de cool, relançant le personnage ou l'environnement du joueur. Des moteurs déjà plus compliqués élargissent votre choix et l'écriture de code se déroule en douceur dans de nombreuses choses: écriture de scripts (code), liaison de scripts, mappage d'actifs, ajout de configurations, redéfinition des configurations, mélange de plugins tiers, écriture de scripts et configurations pour les plugins tiers, plusieurs clics sur des dizaines et des dizaines de dialogues et de fenêtres ... Disons simplement que pour le moment, j'ai toujours peur de moteurs de développement de jeux aussi sophistiqués et sans aucun doute avancés et puissants. Eh bien, je ne veux plus me souvenir de C # / JS / C ++ et écrire dessus.

Je résumerai ma motivation en choisissant le moteur avec un lien vers cette vidéo, où il me semble que l'auteur a littéralement littéralement retiré de ma langue ce que j'ai essayé de formuler avec des mots pour moi-même et pour les autres tout ce temps: https://www.youtube.com/watch ? v = JH8xwNOQ0TM

Defold

Defold est un moteur multiplateforme de King.
Plateformes prises en charge:

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

Le fait curieux est que King appartient à Activision Blizzard .
Le moteur a été attiré par le langage de développement - Lua , le support d'un tas de plates-formes pour les builds du jeu, ainsi que la distribution de leur propre IDE multiplateforme - peut également être installé sur Linux. Cela m'a soudoyé lorsque j'ai choisi entre Defold et Corona SDK .
Et ci-dessous est le journal de ce qui a été fait aux points de contrôle:

Ci-dessous, dans le spoiler, il y a quelques animations gif montrant la progression dans le temps:

Résultat, points de repère:

1. Joueur (sprite, comportement de saut, réaction aux boutons enfoncés) (V) Yes
2. Objets de niveau: plates-formes, ennemis, etc. (V) Yes
3. Physique: vitesse de saut du joueur, accélération en chute libre, les plates-formes ne doivent gérer les collisions que si elles ont été sautées d'en haut et laisser le joueur le traverser s'il le traverse du bas de la plate-forme. (V) Yes
4. Génération de niveau procédural: initialisation et ajout au niveau (à des endroits arbitraires, mais avec certaines règles et restrictions) à la volée de nouvelles plateformes et ennemis, créant pour le joueur une situation de jeu séduisante (X) No
5. Une «caméra» qui suit le joueur alors qu'il monte dans le niveau. La caméra doit garder le joueur dans le champ de vision du joueur et «rebondir» progressivement avec lui, affichant de nouvelles plateformes qui apparaissent dans la zone de rendu (dans le champ de vision de la caméra) (X) No
6. Mécanisme de déclenchement Game Over. Un joueur perd s'il atteint le bord inférieur de la zone visible (après avoir déjà sauté au moins une fois) (X) No
7. Marquer un joueur. Nous allons simplement mettre à jour le compteur de hauteur du joueur. Nous mettrons à jour le compteur en fonction de la dernière plateforme atteinte (celle dont il a repoussé la dernière fois) (V) Yes
8. HUD: affiche la progression du joueur. Affichage de la hauteur. En option, il semble qu'il n'y ait aucun indicateur de progression dans le jeu original. (V) Yes

Score de référence: 5/8

Love2d

Il s'agit d'un moteur très minimaliste, mais suffisamment puissant et flexible pour créer des prototypes. En général, avec une dextérité suffisante, il est même adapté à la publication de jeux à part entière sur le marché. Il existe de bons exemples inspirants. Désinvolte, un et deux .

En général, pour ce moteur, je recommande une série de tutoriels très adaptés de Habr, ce qui m'a stimulé et a donné une impulsion puissante au développement de ce moteur, je ne donnerai qu'un lien vers la première partie, puis vous pourrez passer de celui-ci aux parties restantes: Création d'un jeu sur Lua et LÖVE - 1

Voici donc le journal de ce qui a été fait aux points de contrôle:

Calculez les "performances" du moteur:

1. Joueur (sprite, comportement de saut, réaction aux boutons enfoncés) (V) Yes
2. Objets de niveau: plates-formes, ennemis, etc. (V) Yes
3. Physique: vitesse de saut du joueur, accélération en chute libre, les plates-formes ne doivent gérer les collisions que si elles sont sautées d'en haut et laisser le joueur le traverser s'il le traverse du bas de la plate-forme.
   (V) Yes / (X) No // * Mis en œuvre, mais pas tout à fait parfait, avec des défauts importants. Je mettrais ici 0,5 point pour avoir terminé l'item.
4. Génération de niveau procédural: initialisation et ajout au niveau (à des endroits arbitraires, mais avec certaines règles et restrictions) à la volée de nouvelles plates-formes et ennemis, créant pour le joueur une situation de jeu attrayante (V) Yes
5. Une «caméra» qui suit le joueur alors qu'il monte dans le niveau. La caméra doit garder le joueur dans la visibilité du joueur et «rebondir» progressivement avec lui, affichant de nouvelles plateformes apparaissant dans la zone de rendu (dans la visibilité de la caméra) (V) Yes
6. Mécanisme de déclenchement Game Over. Un joueur perd s'il atteint le bord inférieur de la zone visible (après avoir déjà sauté au moins une fois) (V) Yes
7. Marquer un joueur. Nous allons simplement mettre à jour le compteur de hauteur du joueur. Nous mettrons à jour le compteur en fonction de la dernière plateforme atteinte (celle dont il a repoussé la dernière fois) (V) Yes
8. HUD: affiche la progression du joueur. Affichage de la hauteur. En option, il semble qu'il n'y ait aucun indicateur de progression dans le jeu original. (V) Yes

Score de référence: 7,5 / 8

Java

Une étape logique et logique serait peut-être de regarder de plus près les moteurs, où le langage de développement est celui dans lequel j'ai le plus d'expérience et de dextérité, n'est-ce pas? En fait, l'intuition et certaines sensations internes m'en ont un peu empêché. Le fait est qu'en tant qu'étudiant, j'ai en quelque sorte vu mon camarade de classe avec le moteur jMonkey . L'outillage, le travail avec le moteur, la documentation, tout cela ensemble a créé une sorte d'image pas très agréable. Il semblait que le moteur ne vous donnait tout simplement pas la possibilité de vous lier d'amitié, son utilisation semblait en quelque sorte désagréable.

Mais néanmoins, j'ai décidé de regarder ce qui est disponible aujourd'hui, et je n'ai regardé que dans le sens de moteurs qui ne garantissent bien que la 2D , je me 3D support 3D . L'un des moteurs, Lightweight Java Game Library 3 , a son nom et le mot d'introduction Lightweight . Ironiquement, les exemples de base les plus simples de la page principale, longue de plusieurs écrans, ont simplement été effrayés.

Oui, bien sûr, Java très verbeux, ce que vous vouliez, dites-vous. Mais je sais que vous pouvez y écrire des choses très compactes et très expressives. J'ai vu une API belle et compacte.
Et au final, le choix s'est FXGL sur FXGL . Au début, je n'avais pas d'enthousiasme et d'excitation agréable, ce qui se produit avant le début du développement d'une chose ou d'une bibliothèque intéressante. Mais déjà dès les premiers exemples et les brèves pages de documentation et d'exemples, ce moteur m'a agréablement surpris de plus en plus. Tout était logique, compréhensible et cohérent dans l'approche et l'API qu'il proposait. Cela vous a certainement aidé à créer une boucle claire et flexible pour votre jeu, la logique du gestionnaire, le HUD , l' AI , les collisions et d'autres éléments.

Moments intéressants et puces FXGL:

• Comme son nom l'indique, pour la partie visuelle, le moteur utilise l'API JavaFX ( JavaFX est utilisé comme cadre graphique) avec tous ses goodies et anti-goodies pour le rendu et la mise en page. En général, je pense que c'est une bonne et assez bonne décision. Ainsi, l'auteur a évité un certain nombre de problèmes (il n'est pas nécessaire d'implémenter et de maintenir votre composant de rendu, vous pouvez utiliser une solution raffinée de l'écosystème Java ). Voici ce que l'auteur lui-même dit dans l'un de ses premiers tutoriels, et j'ai vraiment aimé cette phrase:

  
  

  "Pour la plupart des objets d'interface utilisateur, nous utilisons simplement des objets JavaFX, car il n'est pas nécessaire de réinventer la roue."

  Mais en général, bien sûr, vous obtenez également un tas de fonctionnalités et certains inconvénients de JavaFX (je ne connais pas très bien les détails), mais pour autant que je sache, il existe des restrictions de licence sur l'utilisation de JavaFX dans vos projets, et il semble que JavaFX va et ira seulement dans des livraisons limitées de JDK ( Oracle , peut-être un peu plus).

  
  

• Un projet de test, en pente depuis le référentiel, sur la base duquel j'ai commencé à sculpter le jeu, place gentiment les logs dans le logs/ project après chaque démarrage du jeu. C'est très pratique, vous pouvez immédiatement consulter les informations de débogage de la boîte, c'est très utile pour le diagnostic, comprendre où vous vous êtes trompé si vous rencontrez soudainement une prise dans l'étude du moteur.

  
  

• De plus (apparemment à nouveau, avec les paramètres de base), le jeu propose un menu contextuel en appuyant sur la Esc . Aussi un bon bonus, j'espère qu'il est personnalisé ou au moins désactivé par le code ou les configs.

  
  

• Debag fonctionne enfin ici ! Enfin! In Love2D pour le moins, est gênant et désagréable.

  
  

  Journal de développement

  
  

  Voici un bref résumé de mes progrès, où j'ai brièvement noté ce qui a été réalisé après l'intervalle de 30 minutes, ainsi que certaines de mes réflexions et commentaires. Voici le journal de ma conscience dans ces 4 heures!

  
  

GIF- , .

"" … , , , ? .

Benchmark Score: 8

, ,

:

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

:

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

?

, - , ?

Donc:

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