04-10-2011, 07:36 PM
que le temps passe vite...
alors j'ai fait une refonte totale de mon architecture à coup de design pattern,et j'ai quelque chose de développé de beaucoup plus joli ^^ (du moins dans mon code, maintenant les goûts les couleurs...)
Alors quoi de notable :
Les tests
J'avance de plus en plus dans un développement piloté par les tests
En effet, me refusant à développer une couche présentation, les seuls résultats que je peux voir sont des résultats de tests.
J'ai donc construit un système de cas tests par domaine, et au sein de ces domaines, par grande fonctionnalité. Afin de pouvoir aisément modifier mon code (j'y reviendrais plus tard dans le post) je me suis efforcé d'automatiser complètement ma batterie de tests.
J'ai construit quelques classes (pas propre du tout comme code d'ailleurs, l'objectif est le résultat immédiat) qui me permettent de comparer un résultat attendu (saisi par moi même, éventuellement en fonction de mes fichiers de paramétrages) et le résultat généré par le cas test.
Un cas test correspond alors à un appel de la méthode d'un objet métier que j'ai instancié spécifiquement pour le cas, voire dans certains cas, à une fonction que j'ai programmée spécifiquement pour le test, par exemple une séquence d'appel de méthodes, ou encore un traitement d'un résultat "moche" (tableau, objet, etc...) pour un affichage plus clair (avec des <ul><li>... des libellés)
A partir de là mes restitutions se font à deux niveaux :
1) Pour un domaine donné (exemple module caractéristique du personnage), j'ai un tableau avec la liste des cas tests et le résultat. Si le résultat est différent de ce que j'attends, j'affiche les deux pour pouvoir comparer. Evidemment la première information que j'affiche est le nombre de cas tests en échec, histoire de ne pas lire les n lignes du tableau.
2) Un rapport global, qui passe en revue l'ensemble des scripts de tests (tous les domaines), et me restitue domaine par domaine le nombre de cas tests passés, en attente (d'un développement ultérieur) en échec, etc.. quelques % pour faire joli et surtout une barre de progression rouge (échec) / orange (fonctionnalité pas encore développée) / vert (réussite)
J'en suis très fier, même si le code est très moche (pour les tests) , ça me permet de réaliser automatiquement des tests unitaires, mais aussi d'intégration voire "métier"
A ce jour, pour disons 20-25% des développements de la couche métier, j'en suis à environ 400-450 cas tests que je relance à peu près toutes les 15 minutes quand je développe un peu
Très bien pour identifier la moindre régression
A noter en terme d'abaques... pour une heure de développement de code métier propre, je passe environ 2 heures de développement de cas tests
c'est fichtrement plus long... par contre je passe environ 5s à tester l'ensemble de mon application (enfin 5s aujourd'hui, quand j'aurais fini peut être 30s, 1 minute) Sachant que j'ai du la tester 150 fois... ca devient à long terme rentable
La documentation
Là c'est mon point noir... Je ne suis pas assez rigoureux, et surtout pas très motivé.
De fait j'ai construit un fichier backlog (liste des fonctionnalités à faire, assez détaillé, mais pas exhaustif)
J'essaie tant que faire ce peu de tenir à jour un document technico fonctionnel
Par contre, j'ai très peu de code commenté (maintenant vu que chaque méthode fait a peu près 6 lignes de code, à de rares exceptions près, ce n'est pas bien grave, même si c'est le point qui me fait grogner
Maintenant le business
Je suis toujours sur la résolution d'action. Celle ci se construit grosso modo en 4 étapes :
- identification pour chaque acteur participant des scenarii possibles pour une contrainte donnée (ex avoir plus de 15 en force, posséder la compétence machin à tant de %, utiliser un marteau,...).
- vérification que chaque scenario est toujours respecté (exemple pour une action qui dure plusieurs phases, est ce qu'à chaque phase l'acteur a encore assez d'énergie
- vérification que les contraintes de groupe sont respectées (si il faut trois acteurs pour une action et que seuls deux sont disponibles, l'action ne peut pas se faire)
- si l'action se réalise, calcul de l'impact (consommation d'énergie, destruction d'un objet, gain d'expérience...) et du résultat
Et bien j'ai donc modifié complètement l'architecture de mon jeu en intégrant en particulier le design pattern strategy. J'ai une grosse grosse factorisation du code, j'en suis très fier. Du coup quelques soient les contraintes :
+ "j'ai besoin d'un outil pour réaliser l'action" ou
+ "j'ai besoin de 15minutes (point d'action) pour réaliser l'action" ou
+ "j'ai besoin d'avoir 10 en force au minimum pour réaliser l'action"
tout fonctionne de la même manière. Avec même des subtilités : La recherche des scenarii (par exemple j'ai besoin d'un outil) peut générer des contraintes supplémentaires en fonction des outils répondant au critère (pour utiliser tel outil j'ai besoin de savoir l'utiliser à tel niveau)
Qui plus est, mon système me permet une évolutivité très forte (suffit de surcharger/modifier une méthode d'une stratégie, et hop j'intègre la magie, et hop je rajoute les talents qui pourront modifier le comportement des compétences, et hop autre chose...) Les tests automatisés sont super pour ce genre de chose, car justement ils montrent l'impact sur toute modification de mon code. De plus cela me permet de préparer l'aspect psychologie et "stratégie de choix" que je souhaite offrir au joueur. Il suffira en amont d'identifier que pour tel personnage la stratégie de sélection d'un objet (priorisation des scenarios) est basé sur rayer la mention inutile : la peur (ex des armes à feu) le plaisir (je préfère les masses aux épées, parce que le sang ça tache et l'eau ça mouille) etc... Je ne sais pas encore comment le modéliser (une seule stratégie -au sens technique- avec plein de if, ou plusieurs, ... ) mais en tout cas, le modèle répond très bien à ce genre d'évolution
Bref je me suis bien éclaté à construire mon modèle, et maintenant je rame un peu pour développer le peu de spécifique de chaque module (je gagne de l'expérience quand j'utilise une compétence, je perds de l'énergie quand j'utilise mon énergie) parce qu'il n'y a guère de challenge spécifique.
je vais arriver naturellement au système d'inventaire, en effet d'ici fin de semaine je devrais gérer les contraintes d'utilisation d'un outil pour réaliser une action, et donc me pencher sur les notions d'inventaire.
Atterrissage prévu
mmmhh, j'ai un regain de motivation en ce moment, je me fais dans les 30minutes par jour :p... donc je pense que je pourrais envisager un déploiement vers ... 2013-2015 voire si un peu de retard 2020... Bref quelque chose de proche maintenant ! faut que je me dépêche !
alors j'ai fait une refonte totale de mon architecture à coup de design pattern,et j'ai quelque chose de développé de beaucoup plus joli ^^ (du moins dans mon code, maintenant les goûts les couleurs...)
Alors quoi de notable :
Les tests
J'avance de plus en plus dans un développement piloté par les tests
En effet, me refusant à développer une couche présentation, les seuls résultats que je peux voir sont des résultats de tests.
J'ai donc construit un système de cas tests par domaine, et au sein de ces domaines, par grande fonctionnalité. Afin de pouvoir aisément modifier mon code (j'y reviendrais plus tard dans le post) je me suis efforcé d'automatiser complètement ma batterie de tests.
J'ai construit quelques classes (pas propre du tout comme code d'ailleurs, l'objectif est le résultat immédiat) qui me permettent de comparer un résultat attendu (saisi par moi même, éventuellement en fonction de mes fichiers de paramétrages) et le résultat généré par le cas test.
Un cas test correspond alors à un appel de la méthode d'un objet métier que j'ai instancié spécifiquement pour le cas, voire dans certains cas, à une fonction que j'ai programmée spécifiquement pour le test, par exemple une séquence d'appel de méthodes, ou encore un traitement d'un résultat "moche" (tableau, objet, etc...) pour un affichage plus clair (avec des <ul><li>... des libellés)
A partir de là mes restitutions se font à deux niveaux :
1) Pour un domaine donné (exemple module caractéristique du personnage), j'ai un tableau avec la liste des cas tests et le résultat. Si le résultat est différent de ce que j'attends, j'affiche les deux pour pouvoir comparer. Evidemment la première information que j'affiche est le nombre de cas tests en échec, histoire de ne pas lire les n lignes du tableau.
2) Un rapport global, qui passe en revue l'ensemble des scripts de tests (tous les domaines), et me restitue domaine par domaine le nombre de cas tests passés, en attente (d'un développement ultérieur) en échec, etc.. quelques % pour faire joli et surtout une barre de progression rouge (échec) / orange (fonctionnalité pas encore développée) / vert (réussite)
J'en suis très fier, même si le code est très moche (pour les tests) , ça me permet de réaliser automatiquement des tests unitaires, mais aussi d'intégration voire "métier"
A ce jour, pour disons 20-25% des développements de la couche métier, j'en suis à environ 400-450 cas tests que je relance à peu près toutes les 15 minutes quand je développe un peu
Très bien pour identifier la moindre régression
A noter en terme d'abaques... pour une heure de développement de code métier propre, je passe environ 2 heures de développement de cas tests
c'est fichtrement plus long... par contre je passe environ 5s à tester l'ensemble de mon application (enfin 5s aujourd'hui, quand j'aurais fini peut être 30s, 1 minute) Sachant que j'ai du la tester 150 fois... ca devient à long terme rentable
La documentation
Là c'est mon point noir... Je ne suis pas assez rigoureux, et surtout pas très motivé.
De fait j'ai construit un fichier backlog (liste des fonctionnalités à faire, assez détaillé, mais pas exhaustif)
J'essaie tant que faire ce peu de tenir à jour un document technico fonctionnel
Par contre, j'ai très peu de code commenté (maintenant vu que chaque méthode fait a peu près 6 lignes de code, à de rares exceptions près, ce n'est pas bien grave, même si c'est le point qui me fait grogner
Maintenant le business
Je suis toujours sur la résolution d'action. Celle ci se construit grosso modo en 4 étapes :
- identification pour chaque acteur participant des scenarii possibles pour une contrainte donnée (ex avoir plus de 15 en force, posséder la compétence machin à tant de %, utiliser un marteau,...).
- vérification que chaque scenario est toujours respecté (exemple pour une action qui dure plusieurs phases, est ce qu'à chaque phase l'acteur a encore assez d'énergie
- vérification que les contraintes de groupe sont respectées (si il faut trois acteurs pour une action et que seuls deux sont disponibles, l'action ne peut pas se faire)
- si l'action se réalise, calcul de l'impact (consommation d'énergie, destruction d'un objet, gain d'expérience...) et du résultat
Et bien j'ai donc modifié complètement l'architecture de mon jeu en intégrant en particulier le design pattern strategy. J'ai une grosse grosse factorisation du code, j'en suis très fier. Du coup quelques soient les contraintes :
+ "j'ai besoin d'un outil pour réaliser l'action" ou
+ "j'ai besoin de 15minutes (point d'action) pour réaliser l'action" ou
+ "j'ai besoin d'avoir 10 en force au minimum pour réaliser l'action"
tout fonctionne de la même manière. Avec même des subtilités : La recherche des scenarii (par exemple j'ai besoin d'un outil) peut générer des contraintes supplémentaires en fonction des outils répondant au critère (pour utiliser tel outil j'ai besoin de savoir l'utiliser à tel niveau)
Qui plus est, mon système me permet une évolutivité très forte (suffit de surcharger/modifier une méthode d'une stratégie, et hop j'intègre la magie, et hop je rajoute les talents qui pourront modifier le comportement des compétences, et hop autre chose...) Les tests automatisés sont super pour ce genre de chose, car justement ils montrent l'impact sur toute modification de mon code. De plus cela me permet de préparer l'aspect psychologie et "stratégie de choix" que je souhaite offrir au joueur. Il suffira en amont d'identifier que pour tel personnage la stratégie de sélection d'un objet (priorisation des scenarios) est basé sur rayer la mention inutile : la peur (ex des armes à feu) le plaisir (je préfère les masses aux épées, parce que le sang ça tache et l'eau ça mouille) etc... Je ne sais pas encore comment le modéliser (une seule stratégie -au sens technique- avec plein de if, ou plusieurs, ... ) mais en tout cas, le modèle répond très bien à ce genre d'évolution
Bref je me suis bien éclaté à construire mon modèle, et maintenant je rame un peu pour développer le peu de spécifique de chaque module (je gagne de l'expérience quand j'utilise une compétence, je perds de l'énergie quand j'utilise mon énergie) parce qu'il n'y a guère de challenge spécifique.
je vais arriver naturellement au système d'inventaire, en effet d'ici fin de semaine je devrais gérer les contraintes d'utilisation d'un outil pour réaliser une action, et donc me pencher sur les notions d'inventaire.
Atterrissage prévu
mmmhh, j'ai un regain de motivation en ce moment, je me fais dans les 30minutes par jour :p... donc je pense que je pourrais envisager un déploiement vers ... 2013-2015 voire si un peu de retard 2020... Bref quelque chose de proche maintenant ! faut que je me dépêche !