[pré-projet] Un logiciel de gestion de tournoi

Bon on en avait parlé, et vu que je bosse pas mal en C++ actuellement je voudrais en profiter pour enfin mettre au point le logiciel de gestion de tournoi (joute ou mêlée) dont on aurait besoin dans les grosses rencontres.

Alors je n'avance pas encore de date bien sur, mais j'aimerais avoir une version bêta vers noël au plus tard !

Par contre je voudrais faire une liste des fonctionnalités que TOI Garde de Nuit, tu voudras y voir.

De quoi est ce que tu as besoin? De la gestion de la pause pipi à la bière incluse dites moi ce dont vous avez besoin (bon pour la bière y'aura surement un supplément faut bien que je gagne ma croute^^)

Fonctionnalités (pêle-mêle)

Jusqu'à présent, je gère mes tournoi sur DCI Reporter (doit être la 2.91 je crois) et ca marche très bien

Et les mêlée?

non parce que au niveau de la joute effectivement, mon programme devrait ressembler a DCI reporter... d'ailleurs j'ai hésité a mettre la joute, et puis je me suis dis que ce serait dommage de ne gérer que la mêlée, surtout une fois l'interface en place.

Parce que vu les commentaires que j'avais lu, on avait pas trouvé de solution pour gérer "facilement" une mêlée de 30/50/70 personnes (rayer la mention inutile).

Bon après je le fais aussi parce que j'aime bien l'idée, mais c'est sur que si ça sert pas....

Je "bosse" de temps en temps à un programme pour gérer la mêlée, mais c'est en Java, et je viens de commencer à apprendre le JAVA...

Comme je commence à apprendre le c++... on fait une course?

Je m'oriente vers un système proche de dci reporter. Une liste de joueur, puis un onglet par ronde avec liste de joueurs par ordre alphabétique ou par table. S'y ajouté la possibilité d'avoir le fiches de résultats.
Mon problème c'est plus la gestion de l'imprimante...

diana olympos a écrit:

Comme je commence à apprendre le c++... on fait une course?

Je m'oriente vers un système proche de dci reporter. Une liste de joueur, puis un onglet par ronde avec liste de joueurs par ordre alphabétique ou par table. S'y ajouté la possibilité d'avoir le fiches de résultats.
Mon problème c'est plus la gestion de l'imprimante...

Quitte à commencer à apprendre un langage, je te recommanderais le C#. La syntaxe est assez proche du C++, mais tu t'affranchis de toutes les contraintes liées à ce (vieux) langage : pas de gestion de mémoire donc à faire, support natif des chaînes de caractères, des imprimantes et tout le toutim.
Il y a la version Express (gratuite) de Visual Studio disponible sur le site de Microsoft.

Le C++ c'est bien, mais pour les jeux ou les applications de bas-niveau où la performance est cruciale ou la proximité avec le matériel nécessaire.

(Par rapport au java, le C# est mieux pensé aussi vu qu'ils ont "profité" et appris des erreurs du java pour pondre un langage et un environnement plus cohérent).

Pour avoir utilisé tous ces langages, je trouve le C# nettement mieux pour ce genre d'applications.

Après, ça dépend de quel compilateur c++ il veut utiliser. Si c'est celui de visual studio la gestion des imprimantes est aussi gérée en natif par la platform SDK et à fortiori par les MFC. Si c'est du gcc sous emacs par contre...

Mais je suis d'accord avec Ankha, développer un outil comme ça en c++ alors que le c# existe c'est comme tuer une mouche avec une bombe atomique.

En c#, même s'il y pas de gestion de mémoire, gaffe à disposer les ressources quand-même, sinon bonjour les memory leaks, véritable plaie en programmation .Net.

bias a écrit:

En c#, même s'il y pas de gestion de mémoire, gaffe à disposer les ressources quand-même, sinon bonjour les memory leaks, véritable plaie en programmation .Net.

Je ne pense pas que la criticité ni la complexité du projet ne nécessitent de se préoccuper de ça dans un premier temps

De ce projet-ci non. Quoique, l'algo de la mêlée a l'air assez costaud. Une usine à gaz est si vite montée .

En pratique, j'ai déjà l'algorithme de la mêlée et en fait ça va...

Bon ok pour le c# ... une adresse de cours à proposer?

Sinon, pendant que j'y pense, il est bien multiplateforme?
À et de toute façon faut que je l'apprenne dans l'année pour mes études le c++ mais ça n'empêche pas d'en bosser un autre.

Guide de programmation C#

tu veux faire un truc totalement spécifique à TdF, ou légèrement paramétrable, histoire qu'on puisse l'adapter à d'autres jeux ?

En fait il existe déjà des trucs paramétrables... après pourquoi pas, mais l'objectif ici est surtout de simplifier la vie de tout le monde sur les gros tournois de mêlée.

Après la gestion de la joute n'est pas très lourde en supplément...

diana olympos a écrit:

Sinon, pendant que j'y pense, il est bien multiplateforme?

En théorie oui, puisqu'il existe de quoi le faire tourner sur Linux et Mac (projet Mono). En pratique, je n'ai jamais utilisé Mono.
Ceci dit, avec le C++, tu as également des problèmes nécessitant des ajustements à faire pour produire les binaires sur les différentes plateformes.

Quitte à faire du C#, tu peux regarder Silverlight qui te permettra de faire une version web de ton projet et une version "application lourde" en même temps, le tout avec le même programme.

Ah ouais pourquoi pas merci Ankha.

Personnellement je suis plutôt Windows (les jeux tout ça....) mais vu qu'un certain nombre de personnes peuvent être sous linux ou mac, je préfère ne pas prendre de risque...

cette attitude t'honore : on aimerait l'avoir de la part de tous les développeurs et des fabricants de matériel (notamment les cartes graphiques, souvent le point de blocage pour les jeux)

Perso je suis Mac, alors quand les projets sont multiplateformes, je suis content.

(par exemple, ce n'est pas le cas de wippien.com )

J'ai effectivement une partition windows mais uniquement pour les jeux. (une sorte de console de luxe en somme)

Bon pour revenir au sujet :

Un algo de mélée qui respecte la new FAQ (Cad aucun joueur ne se rencontre deux fois pendant les suisses)

En discutant de ça avec Mirgwael on avait deux idée:
- la simple c'est de passer un paramètre de numéro de place au début de chaque tournoi et de faire tourner le tout
- La compliquée c'est de passer un paramètre numéro de joueur et un qui mémorise les joueurs rencontrer pour ensuite exclure du random les tables sur lesquels des joueurs on étés rencontrés, voir meme de random parmis le reste directement (mais c'est pas avec mes pov bases d'algo que je mettrai ça sur papier).

Ensuite Ce serai bien d'avoir deux types d'enregistrement et une mémorisation des joueurs, un rapide et un avancé ou tu pourrai rentrer des indications précises (maison jouée / aganda / restreinte) et puis ca permettrai de sortir plein de statistiques

Et le must ce serai un ELO pour pouvoir le faire tourner a l'année =)

alors alors merci Maekar.

Effectivement le fait de ne pas rencontrer deux fois le même joueur peut complexifier la choses... mais pas tant que ça.

En fait tu défini toutes les rondes dès le début non? donc il suffit de faire comme au loto :un numéro ne peut pas tomber deux fois... ici aussi.

ensuite pour maison jouée, agenda restreinte, j'y avais pas pensée, mais effectivement ça peut se faire, ça ne me semble pas insurmontable.

enfin pour l'ELO... faudrait me définir un système de classement et on verras... maintenant je n'ai pas encore prévu de fichier de joueur réutilisable, je pense débuter d'abord par un système au coup par coup... mais j'ai déjà quelques idées pour implémenter tout ça...

justement, les appariements de mêlée se font en fonction des résultats des rondes précédentes (style suisse) ou tout est prévu dès le départ (style vampire) ?

Alors je n'ai que les règles avant la nouvelle FAQ, mais si je me rappelle bien c'était totalement aléatoire....

Aléatoire mais sans rencontrer deux fois le même joueur

Concernant la partie Gestion de Tournoi, il faudrait penser à :

- Pouvoir importer des listes de joueurs sous format .doc, .txt, .xls et leurs variantes
- Pouvoir faire droper un joueur
- Prendre en compte le bye
- Inclure un chronomètre qui fait des bips pour annoncer certains palier de temps
- l'Impression des rondes par tables et/ou par joueurs.

Là comme ça a chaud, pour un premier jet

Et faudrait que ça fasse le café, et taille des pipes au GdN qui s'occupe des pairings!

Si c'est pas trop demander....

Mog Baelish a écrit:

et taille des pipes au GdN qui s'occupe des pairings!

Faudrait peut-être le développer en C++ après tout, voire en assembleur. C'est du très bas-niveau là.

Et voila pour tout savoir sur le taillage de pipes : ICI


Georges Brassens sera reconnaissant!