Roadmap de openESub 2

De OpenESubWiki.


Ce document est en cours de réalisation. Toutes les idées sont données ici sont donc sans aucune garantie et vous êtes invités à donner votre avis dans le corps du document même (mais n'enlevez rien, commentez seulement au besoin).

Sommaire

Principes généraux

Modularité

Les buts recherchés sont les suivants :

  • abaisser le ticket d'entrée pour le développement d'openESub (actuellement, pour pouvoir tester la moindre correction (même minime), il faut installer un SGBD postgreSQL, créer et remplir une base avec des procédures stockées en python... => ce n'est pas simple tout particulièrement sous Windows) ;
  • pouvoir ouvrir le noyau du jeu à d'autres clients (pas forcément web, on pourrait donc jouer entièrement depuis un SAD mais aussi depuis de simples commandes saisies dans un mail...) ;
  • faciliter la mise en place de parties temps réel ou pseudo temps réel tout en s'appuyant sur des composants existants.

L'idée serait de découper le projet en parties plus ou moins indépendantes :

  • openESub-database : la base de données du jeu et les scripts qui vont avec (création, migration...) ;
  • openESub-kernel : le noyau du jeu (seul autorisé à accéder directement à la base de données), fournit un ensemble de service SOAP, XMLRPC ou simple fichiers XML sur HTTP (pour le catalogue par exemple...) ;
  • openESub-site : la partie "site web" qui n'a pas besoin de base de données (en principe) puisqu'il ne fait qu'utiliser les services web du kernel. Cette séparation et l'absence de BDD devrait largement faciliter la maintenance, les contributions... ;
  • openESub-moteur : la partie "moteur" qui n'aurait pas non plus besoin de BDD puisqu'il utiliserait simplement les services de openESub-kernel (en lecture comme en écriture) ;

Eventuellement, d'autres sous-projets seraient possibles :

  • openESub-sequenceur : l'ensemble des scripts de gestion des compilations, créations des parties...
  • openESub-mailClient : permettant l'envoi des ordres par mail...
  • openESub-ircClient : pouvoir interroger et passer ses ordres par irc ;-)

[...]

Outre la simplicité, ce système permettrait d'héberger physiquement les différents sous-systèmes sur des machines différentes, ce qui pourrait permettre de limiter la charge lors des compilations par exemple en faisant tourner le moteur en local chez qqn tout en utilisant le noyau et la base de données présents sur le serveur Ludimail. De même, pour la maintenance / développement, on pourrait tester très simplement une modification du site chez soi en local avec un simple couple apache/php tout en utilisant le couple kernel/database officiel...

Limiter le nombre de login/passwords

Chez certains joueurs, on note une incompréhension du principe "outils différents / logins différents". Certains essayent de se loguer sur les forums avec leur mot de passe openESub...

Il conviendrait donc de limiter cela même si c'est très difficile de brancher un forum sur le système d'identification d'openESub sans trop s'éloigner (forker) de la version officielle de manière à profiter rapidement des updates de sécurité...

Pour les autres outils (gazette, wiki, gestionnaires de bug...), le besoin est moins fort. Mais pour les forums, il semble que ce soit une fonctionnalité absolument nécessaire.

Outre l'idée d'écrire notre propre système de forum, un compromis acceptable pourrait être de forcer quotidiennement les tables d'identification du forum à partir des tables d'openESub (login, password, photos...).

Régler définitivement ce problème de cache

Le cache est nécessaire mais devrait être transparent par rapport à un visiteur lambda. La séparation du jeu en modules devrait permettre de figer plus facilement un état "officiel" après chaque compilation.

Faciliter la traduction (?)

Centraliser toutes les chaines de caractères dans un seul fichier (pour le client Web, par exemple) pour faciliter la traduction du jeu. Prévoir un flag Langue dans le schema de la bdd pacha pour pouvoir exploiter plusieurs langues dans un même site.

  • Utiliser simplement différents squelettes pour cela ? Il suffirait d'ajouter un sous-répertoire sur la langue (fr ou en par exemple) Nojhan 19 ao?05 à 18:33 (CEST)
    • mais ca veut dire maintenir les modifications du html dans plusieurs fichiers ? c'est plus simple c'est vrai.

Fonctionnalités nouvelles et visibles pour les joueurs

Il faut une valeur ajoutée pour cette version qui soit visible pour les joueurs, autrement que par l'outil technique d'accès.

jeu au sens strict

  • nouveau types de parties ? (a voir si cela ne va pas trop disperser (disséminer) les joueurs ?)
    • pouvoir forcer la cooperation (cooperation = 'only') pour pouvoir faire des parties types Mac entre guilde, 2 pachas x 2 soums x 4)
      • pouvoir défier une guilde/pacha (création auto si accepté) pour choisir son adversaire. (attention toutefois à ne pas trop généraliser ce principe, donc mettre un "malus" sur ces parties, type points de victoire inférieurs))
    • pouvoir faire des parties de type monotype (mais voir sur la dispersion des joueurs)
    • introduction d'iles sous forme de polygones, cela permettrait également de gérer des bords de carte non carré (exemple hexagone pour une partie à 6 pachas)
    • [Bulle] bords de zdop irréguliers (criques, anses, caps, ...)
    • [Bulle] convois ou SNLEs à protéger
  • sonar actif ?
  • individualisation des perfs des soums ? pour :
    • les faire viellir (vitesse max moindre, par ex.)
    • tenir compte de leur expérience (maniabilité > pour un équipage entrainé, par ex)
    • avoir un catalogue qui évolue en fonction de la demande (qui doit en théorie tendre vers un équilibre et des caractèristiques les + équilibrées)
  • vmtop (voir les forums)
  • [Caeies] Ajouter la possibilité de "tracer" des trajectoires de sous-marin transitoire. Par exemple un soum peut ne pas être audible au tour N et pas audible au tour N-1, mais être audible entre les minitours 5 - 60 par exemple. On afficherait une trainée avec peut être moins d'infos (vitesse / direction) ... a discuter
  • introduction au niveau du site du système de parainage
    • faut il une incitation sous forme de points ou de sub supp ?
  • 10j après la fin d'une partie, rendre disponible l'ensemble des tours de façon complète (carte avec tous les objets) pendant un certain temps
    • on pourrait "scorer" les parties interessantes qui resteraient ainsi visible plus longtemps.
    • il serait également interessant de pouvoir commenter chaque tour.

clients

(mail, irc, cf suppra)

autour du jeu

  • integrer directement des stats plus complètes dans le kernel / la bdd pour que le site et les sad puissent y accèder
  • integrer la gazette au site ? (en adoptant un squelette spip proche de la charte graphique du site, par exemple)
  • authentification forum (cf suppra)
  • ajouter un "fil d'évènement", qui serait basique (id, type, date, texte) donc extensible et qui contiendrait des évènements a afficher sur l'accueil : blasts traditionnels, créations de partie, mouvement au sein des guildes, etc... on ferait un nettoyage a j-30 pour ne pas surcharger la base, et un affichage des 20 derniers évènements ou un truc comme ça

Choix techniques

openESub-database

  • on garde postgreSQL mais on passe en version 8.x (peu d'impacts) ;
  • simplifier le schéma sans le bouleverser (suppression en particulier de l'intermédiaire complexe open_sousmarin_affectation pour revenir à une structure plus proche de celle d'E-Sub 2) ;
  • supprimer toutes les redondances notamment en terme de stats qui ne sont plus nécessaires du fait de la structure modulaire (on devrait pouvoir s'en sortir avec des vues)
  • supprimer les procédures stockées en python (pas vraiment maintenues ni recommandées par l'équipe de dev de postgreSQL) :
    • la simplification du schéma, l'abandon des redondances... devrait permettre d'éviter le recours à 95% des procédures stockées (en utilisant à fond les mécanismes de vues et de clefs étrangères...) ;
    • si il reste des besoins ponctuels en procédures stockées, elles seront écrites en PL/SQL (plus standard et plus répendu, moins de dépendances, facilité à l'installation...).
  • mise en place de vraies scripts de création / upgrade de la base.

openESub-kernel

  • PHP4 (avec compatibilité PHP5) ou PHP5only ? ;
  • SOAP ou XMLRPC ? ;
  • simples pages XML quasi statiques (catalogue, liste des grades...) sur du HTTP classique ou du SOAP/XMLRPC only ;
  • mécanismes de protections anti-abus (trop de requêtes SOAP par minutes, ou trop d'échecs d'identification (cassage en force brute)...) débrayable par IP (pour les sites officiels) ;
  • peu de dépendances PHP (à prioris, aucun besoin de SMARTY (templates) et au niveau de PEAR, peu de modules seraient nécessaires) ;
  • séparation franche du core (parties du code impactants potentiellement l'ensemble des services) et des services eux mêmes (identification, getCR...) afin de faciliter la mise en place rapide, propre et sécurisée de nouveaux services au sein d'une branche "stable".

openESub-site

  • PHP4 (avec compatibilité PHP5) ou PHP5only ? ;
  • pas besoin de SGBD (simples accès locaux ou distants à openESub-kernel) ;
  • séparation franche du core et des différentes pages ;
  • XHTML/CSS à tous les étages (modernisation du design... fond blanc ?) ;
  • N'autoriser que les caractères alphanumériques et/ou "_" et/ou "-" dans les noms de sousmarin et de pacha ;

openESub-moteur

  • Python >= 2.3 ;
  • simplification et optimisation du code en réécrivant from scratch tout en évitant de faire de l'objet pour faire de l'objet (par rapport au code actuel, la seule valeur ajoutée de l'objet est au niveau des classes objetmarin, torpille et sousmarin (vrai héritage et factorisation), le reste n'est que contrainte ;
    • paparazzia : je ne suis pas un fan de l'objet, mais justement, dans une optique de réutilisation par les SAD, le problème du code actuel est qu'il ne tire pas assez parti de l'objet en ne segmentant pas assez les methodes (cas du module de compilation, par exemple).
  • possibilité de fixer dynamiquement des options (pour pouvoir faire des parties spécifiques de tests type vmtop...).
    • possibilité de faire des zdop différentes selon le moteur, le catalogue, les règles générales. il faudrait sans doute faire un groupe d'opération différents pour chaque type de zdop. Nojhan 19 ao?05 à 18:30 (CEST)

Ne pas oublier

  • balayer les différents bugs de openESub 1.x pour ne pas refaire les mêmes "erreurs" (le mot est trop fort)
  • penser l'encodage dans la base (actuellement, on stocke plus ou moins une chaine HTML pour les noms...) voir la validité de ce choix (Cf #420)
  • nettoyage de la base de joueurs "innactifs", reste à définir les critères
  • révision de la formule de calcul des points
Outils personnels