Contributions

Vous êtes motivé pour donner un petit coup de main sur ce projet, mais vous vous êtes déjà perdu 5 fois en parcourant le site et le wiki de long en large. Vous avez lu la doc, téléchargé les sources, mais vous n'avez rien compris à ce plat de spaghetti... Ne vous inquietez pas, vous n'êtes pas demeuré, l'effet est le même pour tout le monde ;o) C'est ce qui m'a poussé à écrire cette page...

Si vous voulez aider pour du graphisme, de la traduction, propagande, etc..., contactez directement TuxRouge. Si vous etes venu pour tester le jeu, en vous demandant "Mais il est ou le binaire pour Windows ? Comment ca faut compiler ? Hein ? Et moi qui voulait tester la derniere-regle-de-la-mort-qui-tue", vous pouvez déjà passer votre chemin. Pour l'instant, on ne peut pas faire grand chose avec tbt, ouvrir une fenetre, déplacer un joueur, et encore. Il reste encore énormement de travail sur le code, avant même de penser sérieusement aux graphismes, à la musique, à la traduction. La suite se concentre sur le coté programmation, et uniquement programmation.

Un des points fort de TBT est sa modularité. Chaque fonctionnalité est dans un répertoire séparé, compilé dans une bibliothèque séparée, et à l'exécution, vous pouvez choisir quel morceau charger (règles, interface graphique, ...). Ca veut dire que si vous voulez travailler sur un truc précis, vous n'avez pas a connaitre l'ensemble du programme, juste le morceau sur lequel vous travaillez, en vous convaincant que le reste fonctionne (oh, derrière toi, un elephant rose !). Par exemple, si vous touchez à l'interface graphique, vous n'avez pas besoin de savoir comment fonctionne le réseau, ni la partie règle de TBT.

Un des points faible de TBT est sa modularité. Eh oui, le code est éparpillé un peu partout, et il est pas toujours facile de suivre l'exécution du programme.

Globalement, la meilleure manière de s'y mettre est, dans l'ordre:

  • de passer sous linux (sous windows, pour l'instant ca ne marche pas suffisamment, et on ne pourra pas vous aider).
  • En boucle, jusqu'à ce que ca devienne limpide dans votre esprit:
    • de lire la documentation (propal.pdf, à jour pour les grandes lignes) et de saisir l'esprit et le fonctionnement global du programme.
    • de récupérer les sources, d'y jeter un coup d'oeil, et d'essayer de compiler/exécuter.
    • de choisir un domaine sur lequel vous aimeriez apporter votre contribution.
    • de passer sur irc et de me demander (victor, ou d'autres) des explications sur les points que vous n'auriez pas saisi, et de résoudre les problèmes de compilation/exécution.
  • c'est parti, vous pouvez coder !

Ci dessous, quelques idées et précisions sur des parties à faire. Attention, ca ne reste que des idées. La partie connaissances est vraiment a titre informative, elle n'est en aucun cas un prérequis indispensable. La liste est triée dans un ordre décroissant 'd'importance' (les premiers points sont nécessaires pour avoir un jour une version jouable, les derniers sont pour le fun).

Interface graphique 2D (SDL)

Là, c'est une partie délicate. C'est le point vraiment bloquant du projet actuellement (offrir un click-o-drôme aux joueurs), mais jusqu'à présent, personne ne semblait interessé pour le faire. J'ai fait depuis un mini-moteur graphique pour SDL, qui commence a être bien utilisable, et à construire l'interface graphique dessus. Mais, second problème, personne ne semble comprendre quelque chose à mon code :/. Pourtant, j'ai essayé de le documenter le plus possible (doxygen, et propal.pdf), mais il semble rester bien obscur, et je n'ai clairement pas le temps tout seul de faire toute l'interface graphique (ou alors, ca sera pour 2012).

Après cette rapide présentation de la situation, vous avez 2 solutions pour aider à débloquer la situation:

  • Comprendre ce qui existe actuellement, et m'aider à la synchroniser par rapport aux règles (ie: pouvoir effectuer toutes les actions avec les joueurs).
  • Recommencer from scratch une interface graphique, en s'appuyant sur les règles. C'est faisable. Avec n'importe quelle bibliothèque graphique, en C ou C++.

Connaissances: Ca dépend de ce vous voulez faire. Connaitre le C++ semble incontournable.

Règles LRB5 (partie client et serveur)

Un gros travail y a été fait dernièrement (mai 2007). Toutes les règles de base y sont gérées, il reste probablement quelques bugs non repérés, faute de tests assez poussés. Vous pouvez aider en débuggant, et rajouter ce qui manque, c'est à dire lancer le programme, rechercher une action qui est buggée ou ne fonctionne pas, écrire un test, corriger, et procéder itérativement jusqu'à ce que tout fonctionne. Vous pouvez aussi commencer à réfléchir aux règles avancées, aux options, au mécanisme de logs et de sauvegarde.

Pour faire fonctionner le programme et voir vos règles en action, utilisez le client en mode console.

Connaissances: Bien connaître les règles Blood Bowl, savoir programmer en C++.

Poltuiu travaille actuellement dessus, mais je crois qu'il n'est pas contre avoir une personne avec lui. A voir.

Connaissances: C++ et SDL (la SDL s'apprend rapidement).

Interface graphique 3D

Ce n'est pas à l'heure actuelle dans nos projets, mais si vous vous sentez motivé, y'a pas de raison qu'on vous en empêche ! Vous avez déjà tous les outils pour faire la connection au serveur en 3 lignes, et pour utiliser les règles de jeu. Par exemple, pour récupérer la position du joueur 3, puis lui dire de bouger: 

  cout << api_->getPlayer(3)->getPosition() << endl;
  
  Position pos_arrivee(5, 6); // (row, col)
  api_->doMovePlayer(3, pos_arrivee);

Il ne vous reste donc plus qu'à gérer l'affichage et la gestion de l'input !

Connaissance"": Un peu TBT, pour le reste, a vous de voir.

Console d'administration pour le serveur

Il serait sympa de pouvoir administrer le serveur, par exemple en se connectant en telnet dessus.

Connaissance: C++, un peu de système.

Personalisation des graphismes

Il serait intéressant de regrouper toutes les images et autres ressources dans un seul fichier, style .pk3, zip, ou un format maison. Ainsi, le joueur n'aurait plus qu'à charger le fichier voulu au démarrage, et ils pourraient se les échanger en dehors du jeu. Ainsi, on pourrait avoir un pak avec les figs de GW, un autre avec les figs de X, ...

En premier lieu, décider du format, développer (ou récupérer sur le net) la bibliothèque permettant de le charger et d'extraire/ajouter des fichiers de celui-ci, ainsi qu'un visualisateur dudit pak pour permettre de voir/éditer facilement son contenu, hors jeu.

État de TBT

Ce tableau est donné a titre vraiment informatif, il est assez difficile de donner un état d'avancement précis des modules... Surtout qu'en général, ce n'est pas le module lui-même sur lequel nous passons le plus de temps, mais sur l'interface entre modules.

Partie Commentaire Voir avec Avancement
Réseau Une version basique fonctionne, mais ca serait a refaire victor 60%
Règles de base Toutes les règles de base (jusqu'à la page 16) du LRB 5.0 sont codées, il faut débugger xilandre, deaf, victor, fekmon 99%
Règles avancées Pas commencé, on y pense... deaf, victor 1%
Menu GUI Work in progress... poltuiu 30%
GUI Elle permet vaguement de jouer les actions de base, sauf le blocage victor 6%
IA juste un squelette jerome 1%
Editeur d'équipe Un nouvel éditeur d'équipe en SDL/Paragui est en train de se faire... baru 60%
Editeur d'équipe web Il existe aussi une version php/html qui fonctionne, d'apres les regles du LRB4 toweld 100%
Editeur d'équipe web 2 Une autre version à été faite, qui gère des roster LRB5 MAB 90%
Packaging Il reste des petites choses a corriger dans l'autotoolerie, et les paquets deb, rpm a faire victor 60%
Portage Windows Ca compilait, avant... Maintenant, il reste tout le système de bibliothèque dynamique a porter, et débugger... victor 25%
Artwork (gfx, son) Pour l'instant, on peut utiliser les ressources de TBT 0.5 grp21, tuxrouge 30%
Supporter Parlez en aussi à votre copine :) tuxrouge 42%

(Si j'ai oublié qq un, signalez vous !)

May the code be with you !