I. Présentation▲
L'équipe Qt vous souhaite la bienvenue sur la page du troisième défi Qt.
Les défis Qt sont des exercices à faire soi-même ou en équipe sur un sujet précis, à la manière des exercices de livres, dont le but principal est de s'amuser. Ces codes à écrire sont étudiés de sorte que tous y trouvent leur compte : parfois de l'algorithmique, mais pas uniquement, car Qt ne fait pas que dans ce domaine spécifique. Il s'agit d'un framework complet : les défis essayent d'exploiter cette richesse. Ceci ne signifie pas qu'aucune réflexion n'est nécessaire : il faut connaître Qt, il ne s'agit pas d'écrire quelques lignes sans y réfléchir.
En 2010, l'équipe Qt de Developpez.com vous proposait le premier défi Qt : un logiciel de génération de fractales. Ce défi vous a permis d'aborder les problématiques de la génération et de l'affichage d'images de grande taille, de travailler sur la création d'interfaces utilisateur et de gérer les threads.
En 2011, un deuxième défi Qt a vu le jour, cette fois plus orienté mobile avec un logiciel de gestion de dossiers médicaux pour tablette. Ce défi vous a orienté sur les modules de réseau (client/serveur) ainsi que de base de données pour la conception mais également sur la notion de multiplateforme et la réalisation d'une interface intuitive et adaptée aux terminaux mobiles tels que les tablettes PC.
Voici aujourd'hui le troisième défi Qt : un jeu d'échecs pour mobile ou ordinateur de bureau.
Retrouvez ce défi sur le forum.
Merci à Claude Leloup pour sa relecture orthographique !
II. Jeu d'échecs▲
Pour cette troisième édition, nous avons pensé à un jeu. Cela permet d'avoir à la fois un défi ludique mais également touchant de nombreux aspects de la programmation (interface graphique, réseau, algorithme, IA, etc.) et le tout facilement déployable sur périphérique mobile comme sur ordinateur de bureau grâce au côté multiplateforme de Qt.
L'idée du jeu d'échecs vient du fait qu'il s'agit d'un jeu très connu, qui peut se jouer à deux et avec des règles suffisamment complexes pour rendre le défi intéressant. Il a aussi l'avantage de n'avoir que peu de données à gérer, ce qui permet de passer plus de temps sur l'implémentation et l'interface en comparaison avec le précédent défi où un certain nombre de données étaient manipulées. D'un point de vue de la correction, il est plus facile d'avoir un jeu commun à tous les participants plutôt qu'un type de jeu qui rend l'uniformisation des résultats difficile.
III. Les données fournies▲
Le défi ne contient pas de données à proprement parler comme du code ou des images. Vous pouvez cependant demander des conseils sur les forums de Developpez.com pour bien démarrer.
IV. Consignes▲
Dans nos défis, nous aimons laisser une grande liberté aux participants afin de leur permettre d'exprimer pleinement leur créativité. Quoi de plus frustrant que d'être limité à devoir réaliser une interface utilisateur précise aux fonctionnalités données ? Certes, vous êtes libre, mais cette liberté va être atteinte par quelques restrictions détaillées dans la sous-partie suivante.
Le défi dure trois mois. Il débute le 16/04/2012 à minuit (00h00) et se termine le 16/07/2012 à minuit (23h59). Les dernières participations pourront être rendues jusqu'à cette date, au-delà de laquelle elles ne seront pas acceptées. Toutefois, cette durée de réalisation est amplement suffisante pour avoir le temps d'élaborer une participation complète. En effet, elle est bien trop élevée pour la présentation d'une simple candidature, mais appropriée pour réaliser un jeu complet, débordant de fonctionnalités, bien au-delà de ce qui est demandé ou proposé.
IV-A. Réalisation du jeu d'échecs▲
Vous devez réaliser une application de jeu d'échecs sur téléphone portable (testable sur le Qt Simulator, comme ceux de marque Nokia) ou ordinateur de bureau. Le programme devra comprendre une interface graphique permettant de jouer, en utilisant les contrôles dont dispose le périphérique ciblé (clavier/souris, touche de téléphone, écran tactile, indicateur de mouvement, etc.).
IV-A-1. Restrictions▲
Les consignes suivantes sont obligatoires et doivent normalement faire partie du programme que vous devez rendre à la fin du défi. Vous serez noté sur l'intégralité des points obligatoires de la section si vous répondez à toutes les consignes ci-dessous (cela ne veut pas dire que vous aurez nécessairement tous les points). Si vous désirez aller plus loin dans le défi (et c'est bien ce qu'on espère ;)), une section bonus attribue des points aux fonctionnalités complémentaires. La section fonctionnalités complémentaires vous donne des idées sur ce que vous pouvez implémenter pour avoir des bonus par rapport aux autres candidats.
IV-A-2. Interface graphique▲
Au minimum, votre jeu doit comporter un échiquier (plateau de 8 par 8 cases avec alternance des couleurs) comportant les 16 pièces blanches et 16 pièces noires d'un jeu d'échecs traditionnel. Au début d'une nouvelle partie, le plateau devra ressembler à l'image ci-dessous :
Cela dit, vous avez quartier libre concernant l'implémentation de l'interface graphique. Vous pouvez utiliser :
- Qt Quick avec QML ;
- la vue graphique (QGraphicsView et QGraphicsScene) ;
- OpenGL (QGLWidget) ;
- votre méthode personnalisée à définir.
IV-A-3. Règles▲
IV-A-3-a. Règles standard▲
L'ensemble des règles standard des échecs devra être implémenté pour obtenir le maximum de points sur le critère "Règles standard". Par règles standard, nous désignons :
- le déplacement des pièces ;
- mise en échec et échec et mat ;
- le roque ;
- la prise en passant ;
- le pat ;
- la promotion.
Le détail de ces règles est disponible sur la page Wikipédia des échecs. Attention, cette page désigne comme règles spéciales les quatre derniers points ci-dessus qui pour ce défi sont qualifiés de standard. Ne prenez pas en compte la terminologie adoptée par Wikipédia.
IV-A-3-b. Règles de fin de partie▲
Il est tout à fait possible qu'une partie ne se termine pas par un échec et mat, certaines règles particulières de fin de partie existent et seront considérées comme bonus si implémentées. Nous faisons par exemple allusion à :
- un dépassement du quota de temps si une minuterie est implémentée ;
- un accord mutuel entre les deux joueurs ;
- la troisième répétition d'une même position ;
- la règle des 50 coups.
IV-A-4. Intelligence artificielle▲
Lorsque l'on veut jouer aux échecs et que l'on est tout seul, on a besoin d'une intelligence artificielle (IA) pour jouer. Il est possible dans ce défi de créer votre propre IA pour faire un mode de jeu contre l'ordinateur, cependant cela n'est pas une mince affaire et pousse le défi à un tout autre niveau.
Une autre solution pour avoir un mode de jeu contre l'ordinateur dans votre application et d'utiliser une IA existante et de communiquer avec elle dans un langage de communication commun. Si vous faites ce choix, vous devez expliquer les étapes au jury pour installer cette IA au même titre que votre application. Le programme d'IA peut être d'un autre langage que C++ et Qt et il est également autorisé d'utiliser un langage ou bibliothèque approprié pour faciliter la communication avec celle-ci. L'utilisation d'un autre langage que ceux qui permettent le développement en Qt (C++, Python, Java...) ainsi que tous les langages que Qt utilise (en ce compris ECMAScript/JavaScript, QML, (X)HTML, Lua via QtLua/LQt, etc.) sont réservés uniquement à la communication avec une IA éventuelle.
À notre connaissance, l'intelligence artificielle idoine pour jouer aux échecs est GNU Chess.
IV-B. Équipes▲
Ce défi peut très bien être réalisé individuellement dans le délai imparti, il est cependant possible de participer par équipe. Les équipes peuvent compter deux personnes maximum pour ce défi. Les présentations rendues par une équipe seront évaluées selon les mêmes critères, avec la même sévérité que les candidatures de personnes seules.
Afin de faciliter le travail en équipe pour ce défi, il est possible d'obtenir un dépôt Subversion ainsi qu'un espace Redmine. Ces outils sont principalement destinés aux équipes. Pour y avoir accès, il suffit d'en faire la demande à un membre organisateur.
IV-C. Fichier à rendre▲
Le fichier que vous rendrez au jury par l'intermédiaire de la page prévue à cet effet devra impérativement contenir un fichier de projet .pro. Si vous utilisez un EDI qui ne supporte pas ces fichiers, vous pouvez fournir le fichier de projet pour cet EDI en supplément.
Les fichiers source de votre application seront rangés dans un répertoire spécifique.
La documentation pourra être rangée à la racine de l'archive à rendre si elle tient en un seul fichier (fichier texte, TEX, PDF, etc.), mais devra être dans un sous-dossier dans le cas contraire (par exemple, une documentation Doxygen).
Aussi, vous fournirez un fichier de type README, dans lequel vous marquerez votre accord pour une éventuelle diffusion sur les pages Sources de Developpez.com. Vos sources seront libres de droits (open source). Vous y marquerez aussi votre environnement de développement (version de Qt, compilateur et version, système d'exploitation et version) pour en faciliter la correction.
Dans un autre fichier, vous décrirez brièvement votre projet et comment vous l'avez mené à bien (problèmes rencontrés, difficultés surmontées sans problème, recherche d'idées, idées abandonnées, le temps approximatif de développement, choix de tel algorithme, paradigme de conception...).
Toute proposition ne respectant pas ce point pourra être rejetée !
IV-D. Environnements cibles▲
Votre programme devra fonctionner avec Qt en version 4.7 ou 4.8. Vous devrez l'indiquer dans l'archive rendue afin de permettre au jury de tester les données avec la même configuration que vous. Si vous avez utilisé un simulateur pour le déploiement de votre jeu ou un périphérique mobile existant, merci de le préciser dans le fichier README à rendre décrit ci-dessus.
Qt supportant par nature plusieurs compilateurs et systèmes d'exploitation, il est possible que votre code soit testé sous un autre environnement que celui que vous utilisez. Ceci ne doit changer en rien les parties qui utilisent directement Qt dans votre code.
Nous essayerons autant que possible de tester vos propositions avec la même configuration que vous, mais cela ne sera pas toujours possible.
V. Évaluation▲
V-A. Critères▲
Ces critères sont obligatoires : toute participation sera jugée selon ceux-ci au minimum.
- Qualité du code C++ (lisible, modulaire, commenté, bien présenté, respect des principes de la programmation orientée objet et de conception tels que SRP, OCP et Liskov, sans s'y limiter).
- Qualité du code Qt (exploitation de Qt, multiplateforme...).
- Qualité de la gestion mémoire (pas de fuite mémoire, mémoire bien gérée...).
- Documentation minimale.
- Interface graphique : ergonomie et design (adaptée à un jeu, à plusieurs joueurs...)
- Respect des consignes du défi (fonctionnement minimal attendu : fonctionnalités de base, esthétisme et fluidité, modules requis).
Il est aussi possible de dépasser le minimum demandé : évidemment, cela sera récompensé à sa juste valeur. Ces critères peuvent vous mettre sur la piste pour dépasser nos attentes.
- Module réseau pour jouer à distance.
- Utilisation d'une IA externe.
- Mode 3D (OpenGL).
- Utilisation des capteurs accessibles sur le périphérique cible.
- Animation de jeu (déplacement de pièce, capture de pièce, échec et mat...).
- Mise en ligne des scores via webservice, système de comptes.
V-B. Jury▲
Voici la constitution du jury. En cas de problèmes pour remettre votre candidature ou d'incompréhension des règles, vous pouvez les contacter.
V-C. Grille de cotation▲
| Critère | Points à accumuler (60 au total) |
|---|---|
| Fonctionnement minimal du programme | Total : 20 |
| Fonctionnement de base | 8 |
| Interface graphique | 6 |
| Fluidité | 6 |
| Qualité du code | Total : 14 |
| Qualité d'un point de vue du code | 4 |
| Qualité d'un point de vue Qt | 4 |
| Gestion des structures de données | 3 |
| Gestion de la mémoire | 2 |
| Documentation minimale | 1 |
| Fonctionnalités obligatoires | Total : 14 |
| Règles standard | 10 |
| Mode de jeu 1 contre 1 | 4 |
| Bonus (critères facultatifs) | Total : + 38 |
| Documentation en suffisance | 2 |
| Module réseau pour jouer à distance | 3 |
| Utilisation d'une IA externe | 3 |
| Implémentation d'une IA | 9 |
| Mode 3D | 6 |
| Utilisation des capteurs accessibles sur le périphérique cible | 5 |
| Comptes utilisateur et gestion des scores en ligne | 3 |
| Animation de jeu | 2 |
| Surprenez-nous ! | 5 |
| Malus | Total : -16 |
| Utilisation d'un autre langage (sont autorisés tous les langages qui peuvent utiliser Qt directement (C++, Python, Java...) ainsi que tous les langages que Qt utilise (en ce compris ECMAScript/JavaScript, QML, (X)HTML, Lua via QtLua/LQt, etc.)) hors communication avec une IA. | -4 |
| Utilisation d'une autre bibliothèque non prévue pour Qt hors éventuelle IA (comme GNU chess). | -4 |
| Application peu robuste | -2 |
| Application semblant plantée | -2 |
| Erreurs à la compilation | -2 |
| Avertissements à la compilation (sauf si justification dans le README) | -1 |
| Fichiers inutiles dans l'archive | -1 |
Cette même grille sera utilisée pour tous les projets, qu'ils soient rendus par une seule personne ou par une équipe.