Un guide pour créer des jeux avec QML

Qt Labs est un site géré par les développeurs de Qt. Ils y publient des projets, des idées propres et des composants afin d'obtenir les retours d'informations sur les API, le code et les fonctionnalités ou simplement pour partager avec nous ce qui les intéresse. Le code que vous y trouverez peut fonctionner tel quel mais c'est sans aucune garantie ni support. Voir les conditions d'utilisation pour plus d'informations.

Nokia, Qt, Qt Labs et leurs logos sont des marques déposées de Nokia Corporation en Finlande et/ou dans les autres pays. Les autres marques déposées sont détenues par leurs propriétaires respectifs.

Cet article est la traduction de l'article A Guide to Writing Games with QML d'Alan Alpert paru dans Qt Labs.

Sur mon dernier post sur QML, beaucoup de gens m'ont demandé des exemples plutôt qu'un long discours. Selon moi, si vous voulez des exemples concrets, vous devez passer du blog au code réel. En partant de cette constatation, j'ai écrit une application simple qui expose les principaux points de mon dernier post (Écrire du code C++ pour une utilisation de QML), de ce post (créer des jeux avec QML) et du prochain post sur QML que j'ai prévu d'écrire (le système de versionning QML, quand je vais utiliser la version 2 de cet exemple). C'est un module C++ contenant des jeux de mots logiques conçus pour une utilisation avec QML, plus un jeu QML l'utilisant. Vous pourrez les trouver respectivement dans les dossiers wordgame et longwords sur le dépôt qt-qml-demo-playground. Ils sont simplement destinés à fournir des exemples concrets. Vous ne devriez pas jouer avec avant d'avoir lu le reste de ce post (mais c'est un jeu, donc vous pouvez !). Mais revenons au thème de ce post : écrire des jeux avec QML.

QML est développé pour des applications graphiques fluides et il fait très bien son travail. J'ai découvert que c'est aussi suffisamment flexible pour implémenter un jeu à l'intérieur de cette interface. Donc, pour des jeux simples où l'interface intuitive et fluide est souvent aussi dure à réaliser que la partie "jeu", QML marche étonnamment bien pour créer le tout. Je vais ici séparer les jeux en deux groupes : les jeux simples et les jeux complexes. Les jeux simples, en 2D, sont basés sur un système de tuiles ou avec des formes très simples et une logique honnêtement simple. Les jeux complexes représentent tout le reste (3D, de grandes cartes ou des formes complexes ou avec beaucoup de détections de collisions ou d'effets physiques). Comme vous pouvez tout faire avec QML, vous pouvez bien sûr créer les deux types de jeux. De plus, les jeux simples peuvent être facilement produits en utilisant uniquement QML et du JavaScript. Si vous voulez juste écrire des jeux simples pour vos périphériques mobiles comme Symbian et Meego qui vont, en temps voulu, embarquer Qt 4.7, QML va être suffisant.

Bien sûr, la distinction que j'ai faite entre simple et complexe se brouille davantage chaque jour. Ceux d'entre vous qui ont lu le récent Lab-blog QML/3D vont être quelque peu désorientés par mon point de vue sur la 2D. Avec QML/3D, vous serez capable d'écrire des jeux simples avec de la 3D (aussi longtemps que vous ne devez pas aussi utiliser une logique 3D complexe comme une gestion de la physique réaliste), en utilisant juste du QML et du JavaScript (QML/JS). Vous pourrez aussi faire des jeux simples avec des parties C++ préexistantes, en utilisant par exemple le module WordGame, en dépit de mon amalgame entre le C++ et les jeux complexes. Vous pourrez même faire des jeux complexes utilisant ma formule de jeu simple, bien que cela puisse mener à un code assez confus et long. Bien sûr, dans le monde réel, il semble tout simple pour débuter. Un point clef est que, avec QML, vous pouvez obtenir une complexité accrue sans pour autant devoir abandonner ni votre code, ni votre perspective de le faire fonctionner.

Je vais maintenant fournir un guide basique sur l’insertion d’un ensemble de pièces QML pour former un jeu QML/JS simple. Pour plus de détails, essayez le tutoriel Samegame dans la documentation Qt Quick. Notez que ce n'est pas un guide définitif, ce sont juste mes notes sur ce que j'ai fait jusqu'à présent.

Un jeu QML/JS, au moins celui que j'ai écrit, doit suivre une structure : un fichier principal qui contient un élément GameBoard et l'interface autour, un fichier JavaScript qui contient toute la logique du jeu et des éléments QML pour les pièces du jeu (et des éléments de l'interface). Le fichier principal contient l'interface entière du jeu en QML, comprenant le plateau de jeu dimensionné et positionné de manière appropriée.

L'élément GameBoard est toujours juste un type Item, avec une image de fond pour enfant. Cependant, je lui donne un identifiant que j'utilise dans le fichier logique et, souvent, je définis la taille des tuiles du jeu à partir de sa taille. Cela vous permet de faire que cet élément occupe le plus d'espace disponible et soit ainsi redimensionnable (mais cela n'a pas vraiment d'importance sur mobile).

Le fichier logique, un fichier .js avec toute la logique du jeu, est la partie impérative de la logique. Si vous essayez de faire quelque chose de trop complexe sans être maître de JavaScript, ça va devenir moche et c'est la raison principale pour laquelle je recommande seulement du pur QML/JS pour les jeux simples. Comme il fait tout le travail impératif, il en résulte un flux bien plus impératif que le QML. J'ai donc tendance à avoir un init() dans le .js appelé par Component.onCompleted dans le .qml principal et un newGame() appelé par le bouton "new game". Vous voudrez peut-être aussi un état gameOver dans l'interface et que le flux impératif du JS définisse ces propriétés (sur l'objet GameBoard, qui est de préférence le seul objet qu'il connaît) de sorte que l'interface puisse répondre.

Les éléments du jeu comme les pierres dans Samegame, je préfère les créer du côté impératif. Cela signifie que, dans la fonction newGame(), vous créez, initialisez et positionnez les instances des pièces de votre jeu à partir des fichiers QML qui définissent leur aspect, puis vous les positionnez sur le tableau de jeu. Vous devrez aussi importer les fichiers d'état logique du jeu afin d'appeler les méthodes qui altèrent les états du jeu (quand ils sont cliqués, par exemple). La dernière fois que j'ai vérifié, il était sûr de sauvegarder des états dans le fichier logique JS  : ainsi, quand le fichier des pièces ou le fichier principal appelle le fichier JS, ils agissent sur les mêmes variables. Par conséquent, aussi longtemps que vous stockerez tous les états du jeu dans le fichier logique JS et que vous le manipulerez via des fonctions dans ce fichier, alors vous opérerez sur le même état depuis tous vos composants. Un avantage supplémentaire à utiliser un composant séparé pour les éléments du jeu est qu'on peut facilement leur associer un thème. Vous pouvez avoir un fichier QML différent pour une pierre avec un autre thème pour Samegame et tout ce qu'il vous reste à faire est d'alterner les fichiers chargés dans la logique JS ; tout le reste peut fonctionner si vous utilisez les composants QML correctement. Ces différents éléments peuvent être plus que de simples images et ainsi avoir différentes animations.

Pour conclure, des jeux simples peuvent être facilement écrits en QML/JS en combinant les trois choses suivantes :

• un élément central dans l'interface pour y apparenter tous les éléments du jeu ;
• des fichiers QML qui définissent l'aspect des éléments du jeu et permettent qu'ils soient ainsi fluides dans leurs mouvements ;
• un fichier JS avec toute la logique impérative et les états de jeu.

Malheureusement, il est assez difficile d'être plus précis, car tous les jeux sont différents. Même QML ne peut pas arriver avec une brillante idée de jeu pour vous. Vous pouvez regarder des démos du Samegame et du jeu Snake (l'image ci-dessous, par exemple), dans les démos de Qt pour des exemples et dans la démo Minehunt qui est similaire mais avec la logique dans un plug-in C++ à la place. Il y a aussi l'exemple du WordGame, mentionné plus haut, qui fournit un module C++ qui vous permet d'écrire votre propre jeu en QML avec au moins un jeu l'utilisant.

Pour revenir à des jeux complexes, la méthode pour commencer à écrire ce jeu en QML est plus comme dans l'exemple Minehunt : vous réalisez la partie logique du jeu et les parties complexes en C++ et vous les utilisez dans une interface en QML. Par exemple, vous pouvez juste avoir la position du joueur en C++, faire toutes les manipulations logiques complexes sur cette position pour la déplacer, et le code QML pourrait éventuellement faire défiler les sprites pour animer la marche, ce qui donne au designer beaucoup plus de flexibilité. Malheureusement, il n'y a pas de solution générale pour appliquer cette approche en fonction des besoins, contrairement aux autres interfaces utilisateurs avec le QML. Si votre jeu est trop complexe pour utiliser le QML dans la partie principale (par exemple, un RTS ou un FPS moderne en 3D, avec des milliers d'acteurs et de la physique réaliste), QML fonctionnera encore correctement pour la superposition d'une interface utilisateur par dessus. Il est malheureux que je n'aie pas le temps d'écrire un RTS épique, juste pour prouver ce dernier point.

Le nouveau site Qt DevNet beta est grand et contient des forums pour le développement de Qt Quick et le développement de jeux avec Qt. Je recommande d'y mettre les commentaires et les questions qui ne sont pas spécifiques à cet article, plutôt que de les mettre en commentaire dans Qt Labs, car ils seront vus beaucoup plus facilement et par plus de personnes.

Au nom de toute l'équipe Qt, j'aimerais adresser le plus grand remerciement à Nokia pour nous avoir autorisés à traduire cet article !

Merci également à Mahefasoa pour sa relecture et ses conseils, ainsi qu’à Bruno Barthel et Claude Leloup pour leur relecture orthographique.