Discussion d’une fonction calendrier

[Yom]

Avant-propos : Ceci n’est en aucun cas une promesse de réalisation, pour l’instant il s’agit juste d’une discussion pour évaluer l’intérêt que pourrait revêtir une fonction calendrier sur pole-jeux.org et la faisabilité des caractéristiques souhaitées. En d’autres termes : vous pouvez demander la lune (dans le cadre de la discussion), mais restez conscients qu’au final vous n’aurez peut être rien du tout.
---

Imaginons que finalement je me colle à la tâche de programmer une fonction « calendrier » pour aider à la gestion des parties que nous organisons au pôle jeux. Qu’est-ce que vous en attendriez ?

En commençant à réfléchir au sujet, voici ce que j’envisagerais pour ma part :

- Il s’agirait d’une application web hébergée sur le domaine `pole-jeux.org` (peut-être bien à l’adresse `http://calendrier.pole-jeux.org/`).

- Elle fonctionnerait sur n’importe quel navigateur web moderne (compatible HTML5 / Javascript).

- Dans la mesure du possible, son affichage serait adaptatif pour pouvoir être utilisé sur ordinateur, tablette et téléphone (dans le jargon, on appelle cela du « responsive design »).

Elle gérerait les données suivantes :



(NB pour les autres informaticiens du forum : il ne s’agit pas d’un diagramme conforme à UML ni à aucune autre méthode de modélisation ; c’est fait exprès pour simplifier. Ca se rapproche un peu d’un MPD Merise.)

Dans le diagramme ci-dessus, chaque case est un concept (une entité et/ou une relation entre des entités).

Les flèches sont des associations entre ces concepts :

- Une flèche dont la pointe est vide indique que le concept pointé est optionnellement associé au concept d’où part la flèche (c’est à dire zéro ou une fois pour chaque occurrence du concept de départ).

- Une flèche dont la pointe est noircie indique que le concept est obligatoirement associé au concept d’où part la flèche (c’est à dire exactement une fois pour chaque occurrence du concept de départ).

Les concepts ont eux-mêmes des propriétés, obligatoirement renseignées quand elles sont précédées d’un rond noirci, optionnellement renseignées quand elles sont précédées d’un rond vide. A droite du nom de chaque propriété se trouve une désignation évocatrice de son type de données (chaîne de caractères, nombre, date …) ; peu importe pour l’instant.

NB : Les propriétés seront typiquement des champs à remplir dans un formulaire ; celles précédées d’un rond noirci devant l’être obligatoirement. Il y a cependant quelques petites exceptions ou subtilités de ce point de vue :

- Certaines pourront être automatiquement renseignées plutôt que saisies, par exemple la date à laquelle une partie a été proposée.

- Les propriétés de type « Booleen » (c’est à dire soit « vrai », soit « faux ») seront typiquement saisies via des cases à cocher. Dans ce cas, elles ont beau être marquées obligatoires, cela ne change pas grand chose puisque le fait de laisser une case non cochée suffit déjà à donner la valeur « faux » à la propriété.

Ce que signifie le diagramme ci-dessus :

- Il existe des séances (du pôle jeux), chacune étant programmée à une date.

- Une séance qui a été programmée peut être annulée (par la MJC). La prise en compte de cette donnée pourra laisser envisager des mécanismes de notification aux joueurs qui étaient impliqués dans des parties (y compris aux organisateurs qui pourront alors reporter la partie à une nouvelle séance ou tout simplement l’annuler).

- Il existe des catégories de jeux. Typiquement : jeux de rôle, de figurines, de plateau …

- Il existe des jeux, que nous caractérisons par leur noms et éventuellement leurs versions (par exemple « D&D 3.5 »).

- Chacun de ces jeux peut, ou pas, appartenir à une ou plusieurs catégories (e.g. on pourra envisager qu’un jeu comme Krosmaster Arena soit à la fois un jeu de figurines et un jeu de plateau).

- Il existe des joueurs, qui sont les utilisateurs de l’application. Chaque joueur a un vrai nom (d’état civil) et peut avoir un pseudonyme (de préférence le même que sur le forum). Chaque joueur peut également (optionnellement) avoir une adresse de courrier électronique pour recevoir les notifications concernant les parties auxquelles il a prévu de participer.

- Des joueurs peuvent organiser des campagnes et des parties qui s’inscrivent ou non dans ces campagnes.

- Une même partie ou campagne pourra être organisée par un ou plusieurs joueurs, même s’il sera probablement plus typique que chacune d’elle le soit par un seul joueur. Dans le cadre de parties de jeu de rôle, ces organisateurs sont a priori les MJ. Mais le concept d’organisateur reste valable par les autres catégories de jeux qui n’impliquent pas un rôle de « chef » parmi les participants. L’organisateur est tout simplement celui qui propose la partie.

- Une partie pourra être ouverte ou pas.

- Pour une partie ouverte, l’organisateur pourra définir un nombre maximum de joueurs. Elle sera affichée sur un « panneau d’affichage » virtuel consultable par tous les joueurs qui auront alors la possibilité de s’y joindre selon le mode « premier arrivé, premier servi » (les organisateurs seront évidemment d’office inscrits).

- Pour une partie fermée, la participation sera réservée aux seuls joueurs invités par les organisateurs.

- Une partie pourra être proposée fermée dans un premier temps, puis être ultérieurement ouverte pour les places restantes. A débattre.

- Pour les campagnes comme pour les parties, on pourra renseigner une URL de discussion pour naviguer plus facilement entre le calendrier et le forum.

- Une partie pourra éventuellement être annulée par ses organisateurs (par exemple en cas de changements dans les disponibilités de l’organisateur ou faute de joueurs ayant confirmé leurs participations).

- La notion de campagne peut s’envisager pour toutes les catégories de jeu, pas seulement pour les jeux de rôles.

- Une campagne peut même éventuellement impliquer différents jeux, y-compris des jeux de catégories différentes. Ce système laisserait par exemple envisager des campagnes de Warhammer le jeu de rôle ponctuées de batailles simulées avec Warhammer le jeu de figurines ; ou du jeu de rôle James Bond avec de véritables parties de Poker …

- Une campagne pourra être mise en pause ou déclarée terminée (cela servira à les faire disparaître des écrans « en cours » des organisateurs et des joueurs).

- La participation d’un joueur pourra être déclarée au niveau d’une campagne, ce qui permettra d’automatiquement l’inviter à toutes les parties qui seront proposées dans le cadre de cette campagne.

- La participation d’un joueur à une campagne pourra être suspendue (fonction utile si par exemple il déménage ou ne peut durablement plus être disponible).

- Avant qu’une partie ait lieu, un joueur invité peut confirmer sa participation ou décliner l’invitation. Il peut passer de l’un à l’autre de ces statuts tant que la partie n’a pas eu lieu (ou n’a pas été annulée). Les autres participants en sont alors informés.

- Après qu’une partie a eu lieu, les organisateurs peuvent constater l’absence d’un joueur, à des fins statistiques ou, par exemple, pour les aider à effectuer certains calculs comme ceux des points d’expérience en jeu de rôle.

[Pascal]

ca m'a l'air une bonne idée

certaine guilde de MMO en on des très bien mais il faut être sur le forum pour les voirs

[syrhil]

C'est intéressant comme fonction, après, la question est de savoir à quel intervalle on peut poser une partie car certaines personnes ne connaissent pas forcément leur emploi du temps longtemps à l'avance (juste une réflexion, cela ne me touche pas forcément directement).

[Yom]

Suite à quelques réflexions supplémentaires, j’ai amendé le modèle de données pour y faire apparaître la notion de contexte.

Il s’agit d’apporter la possibilité de définir des contextes dans lesquels s’inscrivent des séances, et donc des parties.

Par exemple, dans le cadre du pôle jeux, chaque saison d’activité pourrait être un contexte, avec ses séances fixées en début de saison (aux annulations et reports près qui interviennent chaque année pour une ou deux séances). J’envisage aussi de proposer un contexte « Parties à domicile » pour permettre l’utilisation de l’application pour des parties organisées en dehors du pôle jeux.



Cet apport m’a été inspiré par une nouvelle ambition : celle de rendre cette application suffisamment générique et configurable pour en faire un logiciel (libre) téléchargeable et utilisable par d’autres clubs de jeu qui la trouveraient utile, ou même par des boutiques ou des groupes de joueurs privés qui disposeraient d’un espace pour en héberger une instance. Un peu de la même façon que nous avons téléchargé et utilisé le logiciel libre phpBB pour créer notre forum.

---

Après les données à gérer par l’application représentées dans le diagramme précédent, j’ai commencé à réfléchir a son découpage en différents écrans. Ce qui nous donne un nouveau diagramme :


Sur ce diagramme, chaque rectangle représente un écran.

Une flèche allant d’un écran vers un autre représente une possibilité de navigation.

Par exemple, la flèche allant de l’écran « seance » vers l’écran « partie » indique que l’on pourra activer un lien sur une liste résumée de parties présentée dans l’écran « seance » pour ouvrir l’écran de détail d’une partie en particulier avec ses informations complètes.

Un joueur pourra simplement consulter ces détails, alors qu’un organisateur de la partie pourra basculer l’écran en mode édition pour modifier les informations.

Le losange « menu » représente un menu de navigation commun à tous les écrans de l’application.

Un joueur donné arrivera sur l’écran « calendrier » qui lui exposera les listes des séances à venir et des parties publiques ou auxquelles il a été invité.

Outre un lien lui permettant à tout instant de revenir à ce calendrier, le menu général de l’application lui proposera deux autres liens :

1. Un lien vers l’écran « joueur » lui permettant de mettre à jour ses informations personnelles et ses préférences (notification par courrier électronique ou pas, façon dont lui seront présentés les autres joueurs, soit par le pseudo, soit par le nom réel, soit par diverses combinaisons des deux, …).

2. Un lien vers l’écran « organisation » lui permettant de proposer des campagnes et/ou des parties indépendantes, en effectuant les choix associés (déclaration du ou des jeux impliqués, caractère ouvert ou fermé des parties, invitations …).

- Tout joueur pourra, depuis les écrans « partie » et « campagne », accéder à un écran « jeu » pour contribuer à alimenter la base de données des jeux pratiqués au fur et à mesure que les parties seront organisées. Cela évitera que ce soient les administrateurs qui se tapent forcément tout ce boulot. Mais surtout cela évitera à un utilisateur souhaitant organiser une partie pour un nouveau jeu dont il vient de faire l’acquisition de se retrouver bloqué devant une liste qui ne le contient pas encore.

- En revanche certaines notions seront réservées aux administrateurs de l’application. Ils y accéderont via un écran spécial « administration ». Ces notions, et leurs écrans associés, seront :

    - « contexte » : la création de contextes (tels qu’expliqués au début du présent message) dans le cadre desquels pourront être ajoutés des séances.

    - « categorie-jeu » : pour éviter le foutoir, je pense qu’il serait bon d’éviter de laisser à tout utilisateur la possibilité de créer des nouvelles catégories à tous bouts de champs. J’envisage a priori les catégories « Jeu de rôle », « Jeu de plateau », « Jeu de figurines », « Wargame » et « Jeu de carte » ; en gardant à l’esprit qu’un même jeu pourra être associé à plusieurs de ces catégories. Cela peut être débattu.

    - « joueur » : alors que les utilisateurs conventionnels ne pourront accéder à cet écran que pour modifier leurs propres données, les administrateurs pourront y accéder pour :

        - Inscrire de nouveaux joueurs.

        - Réinitialiser des mots de passe oubliés.

Je pense que l’on pourrait partir sur l’idée que seront administrateurs les intervenants du pôle jeux.