D8S EURL blog

← Back to Index

Exemple de projet de jeu en C - Cursedinal

> Cet article tente de décrire comment réaliser proprement un projet de programmation en langage C dans les règles de l'art. Le jeu présenté ici a été l'objet d'un projet d'étudiants en programmation suite à une série de cours de langage C. Nous tenterons donc d'expliquer en détail les attendus d'un projet et ce qui est demandé en terme de connaissances pour être à l'aise avec ce langage. C'est une sorte de correction en sommes !

Parenthèse sur la pédagogie

L'objectif de vos enseignants est de vous former, vous faire passer leur savoir. Ils vous apprennent votre futur métier. Pour cela, ils font appel à la pédagogie : ils vont créer des situations, des travaux pour assurer le transfert du savoir.

Donc, ce n'est pas pour vous embêter si on vous demande plusieurs types de travaux ; ils ont tous un objectif derrière. Gardez cela en tête et surtout la finalité.

Dans le cadre des études informatique de type programmation, on va former généralement des ingénieurs. Un ingénieur, selon ma définition, est un technicien qui possède des compétences plus transversales :

J'ajoute donc à la fin de chaque chapitre un dernier paragraphe expliquant l'objectif pédagogique sur ce que l'on vous demande ; en comprenant pourquoi l'enseignant vous demande de réaliser un travail barbant, il est mieux accepté car l'objectif est connu.

L'attendu : découverte du cahier des charges

La découverte et la compréhension d'un sujet fait parti intégrante du processus d'apprentissage. On semande ainsi à l'étdudiant se se comporter comme il le fera en entreprise plus tard, en tant qu'ingénieur informaticien, qui découvre le cahier des charges d'un client (liste non exhaustive) :

Bien entendu, la majorité des étudiants travailleront au dernier moment. Attention, c'est le piège lorsque l'on apprend un nouveau langage : on se retrouve très vite bloqué, perdant plusieurs heures à trouver l'origine d'un bug car on ne maîtrise et on ne comprend pas le langage.

Les classiques entendus le jour de la présentation orale :

« Monsieur ! Je suis resté bloqué des heures à cause des pointeurs ! » Les fameux pointeurs coupables et non leur utilisation !

« Mais, tu n'as pas rendu de documentation technique ?

Ok, voyons ce qui leur avait été demandé : de développer un clone du jeu Cardinal Chains dans un terminal (console) ou graphiquement pour les plus courageux (en utilisant une librairie tierce genre SDL2 ou Gtk).

image

Le jeu doit avoir plusieurs niveaux dans des fichiers séparés de l'exécutable et dès qu'un niveau est terminé on passe au suivant. L'ensemble tourne dans une console, avec des couleurs, une difficulté croissante et plusieurs chaînes. Une interface utilisateur minimale permet de basculer entre les chaînes, choisir un niveau, quitter ... bref, tout ce que l'on attend d'un vrai jeu.

Le code source doit être livré dans une archive contenant le code source, une documentation technique et une documentation utilisateur.

Voilà en simplifié le cahier des charges. La livraison elle seule est tout un roman, j'en ai vu des erreurs ! Je vais y consacrer un chapître à la fin de cet article.

Les grandes erreurs obervées

Globalement, les étudiants ont eu beaucoup de mal concernant les points suivants :

Bref, les élèves de première année ne savent pas comment organiser les livraisons, écire des documents professionnels et présenter leur travail. C'est normal, ils sont là pour apprendre, mais certaines compétences que je pensais acquises ne l'étaient pas du tout ! (genre Word ...)

Ce que l'on attend d'un programme en langage C

Je vais tenter de décrire ici ce que j'ai appris en terme d'organisation de code et d'architecture statique en langage C depuis que je développe. Ce sont des connaissances qui ne font généralement pas parties du programme enseigné, ce dernier se contentant de se focaliser sur la grammaire du langage.

Globalement

La NASA a ses propres règles de codage (http://web.archive.org/web/20190125125043/http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf)

Utilisez la votre, prendez des exemples connus dans la nature (Linux, Gnome, GNU, Microsoft ...).

Un autre exemple avec de bonnes justifications : [indhill-cstyle.pdf](indhill-cstyle.pdf).

Voici un exemple d'organisation par modules pour notre petit jeu en lignes de commandes :

image

Les contextes

La modélisation par structures est la base du langage C qui est de type procédural. Les fonctions vont travailler sur ce que l'on nomme des contextes : des structures regroupant les données nécessaires à un module particuler (moteur de jeu, graphisme, réseau ...).

Les gros avantages de travailler de base avec des structures sont les suivants :

Donc, ne lésinez pas, de base sortez la structure pour représenter la plupart des éléments de votre logiciel, même s'il possède une petite variable. Demain, l'évolution sera plus aisée.

Commençons par la fin : quoi livrer et comment

Posons nous dès le départ sur l'objectif du projet et réfléchissons sur les livrables, c'est à dire ce que l'on va envoyer au Client. Dans le cadre de l'école, le Client c'est le professeur. Notez que dans le cadre professionnel le Client peut aussi être interne à votre entreprise, par exemple l'équipe chargée des tests.

Connaître les fichiers à livrer va nous aider à plannifier les différents travaux : le code, mais aussi la documentation, à ne pas négliger, ainsi que les éventuels tests (à coder aussi !).

Lister les livrables va nous permettre de commencer à réfléchir sur les outils :

Le code source

Placez tous les fichiers dans un répertoire dédié (nommé 'src' ou 'sources', comme toujours un nom explicite). On va demander à tourver plusieurs modules (couples .c / .h) :

Le fichier main contenant :

1. init

2. game loop

3. nettoyage mémoire et code de sortie

Le binaire

Un répertoire contenant le binaire (exécutable) et fichiers associés (images, sons, fichiers de configuration ...). S'il nécessite des DLL, les placer dans ce répertoire.

> Astuce : Votre ordinateur de développeur n'est pas représentatif d'un système lambda ; vous possédez toutes les librairies pour compiler votre code. L'idée est de tester votre exécutable sur un OS vierge, fraichement installé, voire un peu différent (par exemple une Fedora si vous développez sur Ubuntu).

Le fichier de projet

La somme des fichiers .c et .h de votre projet ne suffit pas à savoir comment construire votre projet (enfin, pas toujours). Il faut, comme beaucoup de langage, un fichier de projet ou constructeur d'application.

Certains IDE jouent le rôle de constructeur d'application mais ce n'est pas l'idéal ; il faudra installer le même logiciel (lourd) et s'il est propriétaire et payant ... ça sera difficile pour les autres de reconstruire votre application. De plus, en milieu professionnel, il n'est pas rare d'utiliser des machines de "build" (construction) automatisé totalement sans interface graphique.

En C/C++, généralement on va séparer l'IDE, qui sert à éditer le code dans de bonne conditions, du constructeur de projet. Il existe plusieurs outils assez populaires :

Voici un exemple de CMakeLists.txt classique, propre et simple :


cmake_minimum_required(VERSION 3.10)

# set the project name and version
project(cursedinal VERSION 1.0)

find_package(Curses REQUIRED)
include_directories(${CURSES_INCLUDE_DIR})

set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/bin)

# add the executable
add_executable(${PROJECT_NAME}
    src/main.c
    src/gfx.c
    src/gfx.h
    src/cursedinal.c
    src/cursedinal.h
    src/files_io.c
    src/files_io.h
)
target_link_libraries(${PROJECT_NAME} ${CURSES_LIBRARIES} )

Points bonus

Éventuellement, pour des points bonus :

Voici un exemple classique d'organisation de votre archive :

image

Points malus

> Objectif pédagogique : Le produit livré sera la première chose que votre client verra. Il convient de soigner sa présentation, cela montrera votre sérieux. Généralement, le même sérieux sera apporté à tous les éléments donc vorte Client sera dans de bonnes dispositions.

Comment bien commenter mon code ?

Alors concernant les commentaires, je vous donne mon avis qui n'est que le miens. Selon ma conception, un commentaire est nécessaire pour aider l'autre.

L'autre c'est :

Donc, déjà si vous appelez convenablement vos fonctions et variables, il n'y a pas trop besoin de commentaire.

Ensuite, le classique : ne commentez pas le code trivial (i++; // incrémentation de i, sans blague ?).

Décrivez donc en priorité toutes les interfaces publiques : les fonctions qui sont dans le header et qui sont utilisées par les autres modules.

Vous pouvez utiliser la syntaxe Doxygen.

Le reste, l'implémentation, commentez uniquement les parties difficiles.

Voici un exemple de fichier C selon moi bien écrit :

image

Voici l'en-tête associée :

image

À l'aide, c'est quoi une doc utilisateur ?

Mettez-vous à la place de tati Ginette qui ne connaît rien en informatique. Pour cette personne, rien n'est évident, de la décompression d'une archive au lancement de l'exécutable. C'est une notice d'utilisation, la même notice que vous trouvez avec tout appareil neuf que vous achetez.

Une équipe d'étudiants a créé un manuel en une seule page. C'est parfait, c'est concis, c'est exactement ce qui est demandé.

image

> Objectif pédagogique : Savoir expliquer avec des mots simple, non techniques et de façon concise votre logiciel. Typiquement ce que vous aurez à faire professionnellement lorsque votre interlocuteur ne sera pas ingénieur informaticien et ce sera souvent votre Client.

Comment modéliser un langage procédural comme le C ?

Les langages objets ont leur standard de représentation "graphique" : l'UML. Même si je ne suis pas ultra fan, cela est pratique pour documenter un code de façon "haut niveau", c'est-à-dire sans entrer dans les détails, de façon macroscopique. Surtout lorsque vous devez expliquer l'architecture d'un logiciel rapidement à un collègue, c'est pratique. Le reste, le détail, pour moi c'est de la perte de temps surtout que le code d'un logiciel évolue très vite.

Donc, oui, l'UML peut servir à décrire un programme C !

image

La documentation technique : votre rapport (ou mémoire)

Il porte des noms différents : rapport, mémoire. C'est votre présentation en plus précis. Ce document suit exactement les mêmes chapitres. Le but est de vous faire réfléchir, à tête reposée, sur les éléments de votre projet et apporter un regard critique.

On y trouve :

Concernant la forme, utilisez un modèle de document convenablement paramétré. Un epeu de professionalisme ! Dans le monde du travail, vous aurez à utiliser les modèles de votre équipe et de votre entreprise; c'est une question d'image, de transmission des connaissances, d'archivage et de qualité.

Un modèle de document doit avoir :

Les informations redondantes sur toutes les feuilles ont plusieurs utilités notamment celle de retrouver l'auteur d'une feuille perdue.

image

> Objectif pédagogique : Laisser une trace de votre savoir à l'entreprise, ou à vous même. Il est plus facile de prendre en main un code complexe en lisant d'abord la documentation technique.

Dans ma présentation (slides, diapositives), je mets quoi ?

Voici quelques points importants à assimiler pour produire des slides de bonne qualité. L'examinateur devine assez vite la qualité de ce qu'il va voir à partir de la page de garde et du sommaire (quand il existe !!).

Quand rédiger la présentation

Dans l'idée, rédigez votre présentation en toute fin : ce n'est qu'un résumé de votre documentation technique encore plus abstraite.

De plus, il vous faudra des captures d'écran de votre logiciel donc, mieux vaut repousser.

Combien de pages

Généralement, il faut passer une à deux minutes par écran de slide maximum. Si votre exposé oral dure 15 minutes, il vous faudra environ 10 slides, pas plus ! (hors sommaire et denière page de Q&A)

Entrainez-vous deux ou trois fois en conditions réelles en vous chronométrant. Peaufinez votre phrases : simples, concises, allez droit à l'objectif sans utiliser de vocabulaire trop technique.

Architecture de votre présentation.

Il faut aller du général au particulier et terminer par une ouverture. Une sorte de double entonoir. Gardez cette recette pour toutes vos présentation, à vie !

image

Il doit contenir :

Le sommaire

Voici un exemple de sommaire assez classique :

image

Le contenu

Pas de code.

Non, aucun code, quasiment. Au secours. Personne ne veut voir sur un slide une fonction de 300 lignes écrit en tout petit avec des fautes d'orthographe, de nommage et des bugs gros comme une maison.

Pourquoi ? Parce que ce n'est pas intéressant pour la partie "orale" de votre exposé. Le code sera revu et noté à part. Ce qui va intéresser le jury est la réflexion, votre analyse, l'architecture du code. Élevez-vous. Éloignez-vous de la technique. Regardez votre code vue d'avion : on ne voit pas les détails mais le fonctionnement global.

Lisez le chapitre sur la modélisation d'un code en langage C pour savoir quoi mettre.

Exemple de contenu :

Conclusion / perspective

Exemple d'éléments à placer dans votre conclusion :

Points bonus

> Objectif pédagogique : Savoir décrire le fonctionnement de votre logiciel à quelqu'un. Par exemple, à des collègues de travail qui arrivent sur votre projet, ou à un nouvel embauché. Votre auditoire est _relativement_ technique mais il va s'intéresser à avoir une vue globale du système, il verra les détails seuls par la suite.

De l'importance de l'ergonomie de votre programme

Ne pas négliger l'interface utilisateur, surtout pour une application en ligne de commandes !

Conclusion

Voici un exemple de résultat attentu vous octroyant une bonne note :

image