Rappel sur Dandale.
A l’origine, Dandale était un projet global pour repenser le micromonde selon des bases radicalement nouvelles. Très vite, il est apparu qu’il fallait un système de gestion d’informations pour ce nouveau système et c’est ce système qui a été développé. Le reste du projet a été totalement abandonné.
Dandale 1
Cette version a été développée sous la direction de Matthieu Duclos par Anne Etien, François Guerry et Matthieu Duclos. Elle gérait les joueurs et les personnages, les comptes bancaires, les immeubles, la presse, les procès, les transactions internationales, ... la programmatyon était encore décentralisée et il n’y avait pas de classes.
Dandale 1 a été utilisée par Nautia, le Krassland et surtout par les pays de Pseudopolis.
Progressivement, Dandale 1 a été repensé et réécrit sous forme de classes.
Dandale 2
Entière réécriture du code, sous forme de classe, Dandale 2 a été écrit pour Pseudopolis. L’apparence graphique était radicalement différente également.
Dandale 2.1 Sans réécriture du Code, Dandale 2.1 se signalait par une factorisation plus grande, et surtout une nouvelle apparence graphique.
Dandale 2.2, devenue Clyo La factorisatyon est fortement poussée, avec la créatyon de dobjet.php, et le code est progressivement adapté au php4. Dandale 2.2 n’étant plus utilisé que par Ys, et malgré quelques tentatives d’adaptatyon au Zollernberg, elle est renommée en Clyo. La charte graphique est modifiée.
Pour la première fois depuis Dandale 1, d’autres programmateurs ajoutent des fonctions : Xavier et Nicolas.
Le système est fréquemment modifié. Il est maintenu sur dandale@yahoogroupes.fr
Projets
-
gptc : générateur de programmes de type Clyo. Ce projet est destiné à mettre en place un générateur automatique de programmes afin de simplifier la programmation, voire le portage de Clyo sur d’autres pays. Dandale 3 pourrait être entièrement généré par le gpct.
-
dandale 2.3 : les progrès envisagés sur le fond du système sont une meilleure sécurisation de la connexion, un meilleur contrôle des transactions (notamment des transactions non passées), une réorganisation des tables, une administration plus interactive (avec échange de mails systématiques). Le code devrait être d’avantage factorisé. La gestion des communautés, après avoir considérablement fluctué, devrait enfin être finalisée selon un modèle cohérent et fiable. Les classes devraient être réécrites selon un modèle type. Des méthodes générales de programmation devraient être dégagées et décrites de façon systématique.