Le projet Agojie vise à automatiser le jeu de société Dice Throne. Le développement a débuté par des décisions fondamentales avant même la première ligne de code, abordant la structure du modèle du jeu, la mécanique de défense des héros, la découpe des tâches de développement et le choix de la pile technologique. L'objectif initial est de modéliser le cœur du jeu en un contre un, en se concentrant sur la gestion des dés, avant d'intégrer les cartes et les effets de statut.
Trois idées d'architecture ont été envisagées dès le départ : la séparation entre la définition d'un héros et l'état d'une partie, la modélisation du jeu comme un "Aggregate" pour garantir l'intégrité des règles métier, et l'utilisation d'"Domain Events" pour enregistrer les faits importants du domaine. Cependant, ces idées n'ont pas été appliquées immédiatement, privilégiant une approche où les décisions sont justifiées par les règles du jeu et non par l'intuition.
Ce projet est structuré en quatre étapes principales : la mise en place du cœur du jeu sans cartes, le développement d'une interface utilisateur basique avec sauvegarde des parties, l'intégration de la couche de cartes pour influencer le jeu, et enfin la gestion des effets de statut qui affectent les héros. La première phase consiste en la rédaction d'une spécification détaillée des règles du jeu de Dice Throne, incluant des exemples concrets pour guider le développement du code.
Résumé pour Shaarli:
Le projet Agojie se lance dans l'automatisation de Dice Throne, un jeu de dés et de combat stratégique. Les premières étapes se concentrent sur les décisions architecturales et la modélisation des règles fondamentales, sans écrire de code. L'objectif est de développer le cœur du jeu, puis d'ajouter progressivement des fonctionnalités comme les cartes et les effets de statut, en s'appuyant sur des principes de conception logiciel rigoureux.
L'article explore les stratégies pour développer des plateformes pérennes, en se basant sur l'exemple de Writizzy. Il met en avant l'importance de la réversibilité, en permettant aux utilisateurs d'exporter facilement leurs données et d'utiliser leur propre nom de domaine. L'auteur souligne aussi l'importance de prévenir la "merdification", c'est-à-dire l'évolution négative des produits due aux pressions économiques et internes. Il propose de construire uniquement ce qui est nécessaire et d'évoluer de manière mesurée, sans recourir à des investisseurs externes. L'interopérabilité et la décentralisation sont également évoquées comme des solutions pour assurer la durabilité des contenus.
Ross Wintle explore l’idée que le logiciel peut être « terminé », en proposant une définition simple : un logiciel est fini lorsqu’il est fonctionnellement complet et que rien ne doit y être ajouté, même si des évolutions restent possibles. Il souligne que des changements externes (matériel, plateformes, API, outils de build) peuvent rendre un logiciel obsolète, mais que cela ne dépend pas toujours des développeurs. Plutôt que de viser absolument la « finition », il invite à réfléchir aux leçons que cette approche peut apporter, comme la valeur de la stabilité et de la maintenance contrôlée. Il illustre son propos avec l’exemple du Gameboy, dont le logiciel embarqué fonctionne toujours des décennies plus tard, et rappelle que beaucoup d’entreprises reposent sur des mises à jour continues plutôt que sur des produits figés. Une réflexion stimulante sur la durabilité et les limites du contrôle en développement logiciel.
Tout est dans le titre
Tout est dans le titre
Rien à ajouter
Ce logiciel permet aux utilisateurs d'enregistrer les actions souris / clavier et de les reproduire à l'identique.
Permet, entre autres, de trouver un logiciel devenu non libre dans une version libre... Pratique
Tout est dans le titre
Tout est dans le titre