+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Les réalisations de la communauté (https://jeuweb.org/forumdisplay.php?fid=39)
+--- Forum : Jeux en développement (https://jeuweb.org/forumdisplay.php?fid=53)
+--- Sujet : Rivages (DBark v2) (/showthread.php?tid=5105)
Pages :
1
2
Rivages (DBark v2) - Ter Rowan - 20-08-2010
Aller, après avoir perdu mon précédent post (mais bon je vais peut être le retrouver ^^) je refais un thread ce qui coïncide d'ailleurs avec une refonte complète (from scratch même) du programme
Nom du jeu : indéterminé mais une petite idée
Nom du projet : Rivages (ou DBark v2 pour ceux qui se souviennent)
Url : localhost
Style de jeu : RPG (avec des leviers de jeu d'élevage)
le détail en bas du post
Technologie : PHP 5.2 (passage à 5.3 prévu... un jour) côté serveur. Côté client à définir (voir ci dessous)
Type de codage : Objet, un peu événementiel, utilisation des....
Design pattern : surtout singleton/multiton, factory et probablement strategy
Framwork : aucun (probablement un pour la couche présentation, exemple jquery si javascript+html)
Charge en terme de programmation : énorme
Charge en terme de jeu : humpf entre 10 minutes et plusieurs heures (enfin la routine habituelle)
Situation de l'équipe : boulot + wow + femme = pas beaucoup de temps pour avancer
Utilisation de documentation : j'essaie autant que faire ce peut de réaliser une documentation tant côté commentaire du code que rédaction de la logique métier/base de données dans un document à part
Volonté bénévole du jeu : Oui et non (j'aimerais bien m'arrêter de bosser ^^) dans un modèle "accroche gratuite du jeu, et on paie pour plus tard mais quel plus tard => pas payer pour avoir un avantage face à un concurrent mais payer pour accèder à un nouveau "niveau" du jeu
Fonction et utilité du nouveau programmeur : c'est mon Grand Oeuvre, je ne veux PERSONNE mais je solliciterai certainement un graphiste (voire designer) une fois le jeu sorti. A voir aussi si je ne solliciterai pas une aide pour une installation (et choix) serveur et validation sécurité.
Quelle est la complexité du jeu ? je souhaite rendre le jeu à la fois accessible et complexe :
accessible on peut joueur sans se prendre la tête (dans les mécanismes du jeu bien sûr) où rentrer dans des systèmes de paramétrages plus ou moins poussés qui peuvent rendre complexe
Combien de joueurs vise le jeu ? j'aimerais plus de 1000 et espère +10000
Univers : le choix n'est pas encore déterminé, plusieurs sont compatibles med fans, préhistorique, historique ancien, far west, japon ancien fantastique, post apo, space opéra, même si ma préférence va vers un univers celtique
dans l'optique "celtique" (ou autre fantastique) un premier background a été imaginé expliquant un certain nombre de mécanisme de l'univers... basé sur le meurtre d'une femme enceinte (mais je ne vous en dis pas plus, ce sera la surprise)
Principe du jeu :
Jeu de rôle : chaque joueur joue un personnage avec caractéristique, compétence, etc..
Sa première "mission" sera de survivre (manger, dormir, s'habiller)
Pour obtenir de quoi survivre, plusieurs possibilités s'offre au joueur :
cueillette / chasse / artisanat / agriculture / échange / vol / etc...
quelques éléments de précision/différenciation
- pas de classe de personnage
- pas d'expérience / de niveau
- probablement pas de pnj (que des animaux etc...) même si parfois certains "animaux exceptionnels" existeront
- pas de "repop" (les animaux normaux n'existent pas en base car pas d'id) dans tous les cas si un animal exceptionnel (avec son id) est tué, ben il est tué bravo à celui/ceux qui l'ont eu, dommage pour les autres
- pas de quête, je souhaite faire en sorte que ce soit les joueurs aient besoin d'autres joueurs et donc lancent eux même leur propre quête (exemple un magicien pour acquérir plus de pouvoir a besoin de différents objets qu'il ne peut pas lui même obtenir, il fait appel à d'autres pour les obtenir)
- l'artisanat sera un élément important du jeu (grosse réflexion, conception en cours)
- l'art sera une facette de l'artisanat
- l'aspect "psychologie" du personnage sera travaillé
+ recherche du plaisir à rapprocher de la notion d'art
+ action du personnage parfois différente du choix du joueur (genre fuite, colère, refus de faire)
- l'aspect collaboratif sera privilégié (vivre ensemble pour vivre mieux) mais pas obligatoire (le joueur solitaire doit pouvoir s'amuser, bon évidement il faudra construire un personnage qui peut survivre seul genre chasseur, etc..)
je posterais plus tard l'avancée projet
tiens du coup j'ai retrouvé le précédent post ^^
RE: Rivages (DBark v2) - Sephi-Chan - 20-08-2010
Pour trouver facilement un sujet sur le forum, tu peux utiliser Google en spécifiant le nom de domaine avec l'option site.
Sephi-Chan
RE: Rivages (DBark v2) - Ter Rowan - 21-08-2010
Alors d'un point de vue technique maintenant
j'ai décidé de ne développer que les couches métiers et accès aux données
ceci pour deux raisons :
d'une, au moins ainsi je suis sur d'avoir une vraie séparation forte entre présentation et métier ^^
de deux, le temps que le métier soit terminé les "innovations" "tendances" technologiques auront changé (me connaissant... on discutera d'html 6) alors, contrairement au projet v1 ou j'avançais en "voyant" ce que je faisais mais où je passais bcp de temps sur les problématiques d'ihm là je me concentre sur le côté serveur
et on verra bien qui l'emportera entre flash silverlight, htm5 ou autre que je ne connais pas/rappelle plus ou qui n'existe pas encore
évidemment pour mesurer un peu l'avancement et vérifier que ça marche c'est tout de suite moins facile... du coup j'ai des pages de test (et donc des jeux de tests, je dois avoir plusieurs centaines de donner de tests) et à chaque fois que je touche à une partie, je regarde mes pages de tests (pour la non régression) et j'enrichis pour tester les nouvelles fonctionnalités
au début c'est très chiant, mais une fois qu'on réalise les tests pour la sixième fois et ben on est bien content
---------------------------------------------------------
Le jeu en lui même est construit autours de 4 grands systèmes qui fonctionnent tous de la même manière :
système " autour du personnage " : bah tout ce qui concerne le personnage (nom, caractéristiques, compétences, hauts faits, etc...)
système " autour de l'environnement " : tout ce qui concerne la géographie (carte mais aussi lieu notable, etc...) on y trouvera entre autres les éléments permettant d'identifier quelles "ressources" (y compris vivantes) on peut y trouver (je rappelle pas de mob avec id et repop : la solution => quand j'arrive à un endroit j'ai une probabilité de tomber sur ....)
système "autour des actions " tout le système qui calcule la résolution d'une action, en vérifiant les contraintes (je forge une charrue mais ai je du métal ?), en consommant l'énergie et les matières premières (si y en a ) en utilisant les outils / armes, en produisant des objets ou effets
système "autour des objets" de la même manière que le personnage, tout ce qui concerne les objets, on y trouvera les caractéristiques (poids, encombrement, etc...) les propriétaires utilisateurs, etc..
en avançant , je me retrouve parfois avec des éléments "paradoxaux"
par exemple où mettre les véhicules ? et bien pour des raisons que je vous laisse imaginer (jeu concours ? ) un véhicule est un lieu ^^
Tous ces systèmes s'articulent de la même manière (avec quelques spécificités) Ayant choisi de faire un moteur "complexe", il y aura bcp de données de nature différente qui fonction du besoin (je réfléchis en asynchrone donc bcp de "micro" demandes du joueur, après ferai je de l'asynchrone... une autre histoire) ne sont pas nécessairement à charger
de fait chaque système est organisé ainsi : (exemple du personnage)
une classe usine de personnages qui, lorsque on lui demande de charger un ou plusieurs personnages construit la requête sql, la lance (via pdo) et génère les objets personnages
une classe personnage avec quelques attributs (l'identité du personnage)
jusque là simple
maintenant il n'y a pas les caractéristiques du personnage dans cette classe
pour les avoir, il faut interroger une autre table du modèle (toujours par la classe usine) qui générera un objet "caractéristiques du personnage" et l'attachera à l'objet personnage
évidemment on n'a pas toujours besoin d'avoir les caractéristiques (exemple "qui est à côté de moi ?")
en fait seul l'objet personnage décide du chargement de ses modules (ex module caractéristique)
pour ce faire j'ai cherché à rendre ma programmation des interractions entre système assez simple :
quand je développe un script qui nécessite les caractéristiques du personnage, je fais $perso->getModule('caracteristique')->getValeur( $idCarac);
j'ignore en écrivant cela si les caractéristiques ont été ou non chargé précédemment. C'est le problème de la classe personnage et de l'usine :
lors du getModule, l'objet personnage vérifie si il a ou non ses données. S'il les a, il les utilise. Sinon, il lance un événement ("besoin du module caracteristique") qui est "attrapé" par l'usine, celle ci se chargeant de charger les données et de les fournir à l'objet personnage
dernier point et je ne vous embête plus avec ça, pour réduire au maximum le nombre de requete, quand l'usine apprend qu'elle doit charger les données d'un module, elle le fait pour l'ensemble des personnages qu'elle a généré (il est probable en effet, que si j'ai besoin des caractéristiques d'un personnage et que j'ai chargé d'autres personnages, c'est que je vais "confronter" ou "associer" ces personnages et donc les manipuler ensemble
a noter enfin... au début j'étais très fier de ma trouvaille (issue de ma propre analyse) mais en avançant dessus je me demande si je n'ai pas complexifier le système... (pour cela que je l'expose) maintenant il marche alors je l'applique mais si vous identifiez une "anomalie génétique importante" je n'hésiterai pas à refactorer cette partie (guère d'impact sur le reste vu la séparation que j'ai faite)
épisode suivant : où j'en suis
RE: Rivages (DBark v2) - Ter Rowan - 16-09-2010
Oh le gros pavé pour ceux qui veulent lire pendant les longues soirées d'hiver
donc voici un peu l'état d'avancement :
Côté gameplay, j’ai quelques idées pistes que j’ai commencé à poser sur papier. Cependant, le gameplay dépendra des possibilités technologiques et media choisis (même si je suis très old school souris + écran 14 pouces vga 16 couleurs, sait on jamais je m’adapterais peut être à des écrans plus réduits avec stylet ou doigt :p ) J’imagine quelque chose de type interface assez riche (ajax, manipulation des « objets », etc..)
Pour le background, j’ai construit une explication du monde (et de fait du pourquoi le personnage est là) adapté à un monde celtique ou encore certains types de médiéval fantastique plus exotiques comme japonais, indien ou africain (version magique hein…) , etc… (du moment qu’il y a plusieurs divinités) J’ai aussi quelques idées si le bg est plus space opéra. Mon plus gros « problème » serait de construire un bg sur un monde réaliste que ce soit contemporain, passé ou futuriste proche. En effet dans un monde réaliste, il y a des enfants, et je ne sais pas comment gérer d’un point de vue gameplay la fonctionnalité de donner à des joueurs la capacité à enfanter. C’est chiant les RP istes en fait ^^. Donc voilà côté background une base assez riche pour l’univers que je préfère (a peu près celtique) même si celui-ci n’est pas encore définitivement arrêté (mais bon je tend furieusement à rester sur ce choix, un peu « facile » car tellement… commun… mais qui me plait).
Concernant les données métiers et de référence, je n’ai pas encore cherché plus que cela. Par exemple la liste des caractéristiques n’est pas figée, encore moins, bien sur la liste des compétences, des types d’objet ou de lieu. Je développe justement « sans savoir » pour rester le plus générique possible au sein du code, afin (rêvons un peu) de faire évoluer simplement et rapidement le système une fois le jeu en ligne. Aujourd'hui donc, on a la caractéristique 1 qui vaut 8, l'énergie 3 qui vaut 80, etc..
Côté programmation et analyse, je ne parlerai que de la partie métier.
En effet rien de la partie développement d’interface n’est réalisé, la technologie n’étant même pas encore définie. Ce choix s’explique par le temps (délai) que je mets à avancer sur le développement du « cœur » du jeu, je préfère avoir un maximum de visibilité sur la situation des technologies du web en termes d’interface (html5, canvas, flash, silverlight, autres ?) et de stabilisation et maturité du marché (ordinateur ou pocket pour les rpg ?) lorsque j’aurais fini (ou presque) la partie serveur. Enfin concernant la partie données, le modèle évolue avec le métier par contre mon développement maison ne traite que de la partie lecture. Je ne construirais la partie écriture en base qu’un peu plus tard (je me concentre sur le métier, et puis je ne suis pas à l’abri de me pencher sur Memcached et compagnie)
Maintenant d’un point de vue métier
Autour du personnage :
Environ 30% de ce qui concerne le personnage a été développé. L’identité, les caractéristiques, énergies et autres compétences sont réalisées ainsi que les modifications (augmentation/diminution, expérience, etc…).
Reste à faire l’aspect psychologie et caractère (je souhaite que le joueur soit la conscience du personnage, et on ne réagit pas forcément comme on le veut consciemment, de plus fonction de ses actions ou réactions la psychologie évolue), les « talents » (des bonus/malus spécifiques), la réputation (fonction de ses actions) ainsi que l’impact de l’équipement sur les statistiques du personnage.
Autour de l’environnement :
Système beaucoup plus réduit en termes de charge et de complexité que les autres, l’environnement correspond à la carte, aux lieux ainsi que les véhicules (qui sont des lieux « mouvants »)
Environ 30% de ce qui concerne l’environnement a été développé. Grosso modo tout ce qui alimente le système d’action est opérationnel et tout le reste n’a pas été réalisé.
Reste à faire les véhicules, les conditions d’utilisation d’un lieu (la mine peut elle être exploitée ou doit elle être nettoyée avant, le cheval peut il avancer ou doit il se reposer, y a-t-il du combustible pour la voiture, etc…)
Autour de l’action :
Probablement le système le plus complexe de tous, le système Action permet de résoudre tous les types … d’actions (se nourrir, construire un bâtiment, produire un objet, exploiter un lieu, se battre,…)
Environ 60% du système a été développé, et 80% de la partie générique. Le plus gros du chantier a été de réaliser un système permettant les actions de groupe (plusieurs personnages participent à une même action) qui ma foi, me satisfait bien. A ce jour est donc disponible la gestion du groupe de participants, le niveau de réussite de l’action (fonction des compétences de chacun, etc…), la présence obligatoire ou non d’un lieu (on pêche là où il y a de l’eau, on forge là où il y a une forge, on se cache là où on peut…) avec l’impact sur les compétences et résultats.
Reste à faire d’un point de vue générique l’utilisation d’outil et de matière première (donc issu du système Objet), la production d’un résultat physique (système objet), la production d’un effet qui ne serait pas un objet (grosse réflexion future) ainsi que la sauvegarde de l’état d’avancement d’une action non terminée (on ne construit pas une maison en un cycle de jeu (semaine ou jour irl) mais en plusieurs.
Reste à faire d’un point de vue spécifique le combat et le déplacement (un pilote déplace un bateau, tous les passagers sont déplacés, enfin… sauf ceux qui tombent à l’eau)
Autour de l’objet :
Ce qui tourne autour de l’inventaire, des ressources, etc…
Au-delà d’une conception presque aboutie, tout est à développer. Je commencerai par la partie permettant à une action de se réaliser (outil, matière, résultat) puis on passera sur la gestion de l’inventaire, de la propriété et sur la notion de ressources « naturelles », point un peu spécifique que j’aborderais en son heure.
Dans les travaux en cours, la refactorisation pour être complètement en ligne face au lazy loading (merci oxman), petite satisfaction personnelle d’ailleurs, mon propre cheminent m’amenait vraiment pas loin du modèle proposé.
Puis la finalisation de la partie générique du système Action soit :
Définition des objets
Contrôle sur la disponibilité des objets
Destruction (du consommé)
Création (de la réalisation)
vois lis, vois l'eau (ben oui Rivages...)
Tiens d'ailleurs maintenant le projet s'appelle rivages mais je souhaitais que le jeu s'appelle ainsi il y a ... bouuhh longtemp, simplement comme les domaines associés (fr, com, ...) ont été peu ou prou déjà acheté, me faudra un nouveau nom... j'ai bien une idée mais il sera fonction du background (donc un nom propre et non un mot commun)
RE: Rivages (DBark v2) - Jeckel - 01-12-2010
(21-08-2010, 02:14 PM)Ter Rowan a écrit : de fait chaque système est organisé ainsi : (exemple du personnage)
une classe usine de personnages qui, lorsque on lui demande de charger un ou plusieurs personnages construit la requête sql, la lance (via pdo) et génère les objets personnages
une classe personnage avec quelques attributs (l'identité du personnage)
jusque là simple
maintenant il n'y a pas les caractéristiques du personnage dans cette classe
pour les avoir, il faut interroger une autre table du modèle (toujours par la classe usine) qui générera un objet "caractéristiques du personnage" et l'attachera à l'objet personnage
évidemment on n'a pas toujours besoin d'avoir les caractéristiques (exemple "qui est à côté de moi ?")
en fait seul l'objet personnage décide du chargement de ses modules (ex module caractéristique)
pour ce faire j'ai cherché à rendre ma programmation des interractions entre système assez simple :
quand je développe un script qui nécessite les caractéristiques du personnage, je fais $perso->getModule('caracteristique')->getValeur( $idCarac);
j'ignore en écrivant cela si les caractéristiques ont été ou non chargé précédemment.
Hello,
Je répond sur cette partie, parce que je passe à peu près par là moi aussi, dés que l'on veut faire un système générique, cela revient souvent au même modèle : une table correspondant à l'objet métier avec les caractéristiques minimales, et une tables (1-n) correspondant à la spécialisation de l'objet, pouvant elle contenir autant de valeur que voulue...
Personnellement je suis passé par deux problèmes avec ce modèle (que j'ai gardé malgré tout)
- premièrement, en terme de performance, il s'avère que parfois lorsque sur la carte il y a plusieurs personnages, on finit par charger pour chaque personnage l'ensemble de ses caractéristiques (comme la skin par exemple) si l'objet usine peut renvoyer une liste de personnage avec l'objet "minimum", on aura tendance à recherche pour chaque objet les caractéristiques dans la seconde table autant de fois qu'il y a de personnage sur la map (c'est un exemple, mais ce cas peut arriver dans plusieurs situations... comme un inventaire du sac à dos)
Pour ce premier, j'ai mis en place plusieurs solution...
tout d'abord un mise en cache, pour tous les objets qui ne "vivent" pas (cas de l'inventaire) l'inventaire complet est ensuite sérializé et stocké dans un fichier (par personnage), lors du second chargement je reprend l'objet depuis le fichier, plus rapide que de tout reconstruire depuis la base de donnée.
ensuite, la mise en place d'une vue, constituant la jointure entre ces deux tables, et mon objet usine est alors capable de construire mon objet métier (et ses caracs) en une seule requête sur la vue, j'utilise cette méthode de l'objet usine dés que je dois travailler sur une collection d'objet et que je dois pouvoir consulter leurs caractéristiques, après quelques tests (dans mon cas) c'est plus rapide, il faut bien construire a vue, les clés, les jointures et ne charger que les éléments de la collection dont on aura besoin et ça roule.
Le second problème... heu... et bien je l'ai oublié en écrivant tout ça (c'est le matin pas encore bien réveillé) j'en reparlerai donc plus tard quand ça me reviendra...
RE: Rivages (DBark v2) - Ter Rowan - 01-12-2010
hehe
bon je rame un peu en ce moment sur le sujet action car mon algorithme était un peu trop générique :
je partais du principe que toutes les conditions devaient être traitées de la même manière (compétences, énergie, matière première, localisation, etc...) or après avoir réaliser 80% des contraintes, je m'aperçois que non, qu'un ordre doit être réalisé, que certaines contraintes ne doivent être calculées qu'une fois, etc...
donc je rame à revoir le modèle
le problème que j'ai avec ton concept de cache pour l'inventaire Jeckel est la capacité de voler un personnage : cela veut dire qu'il faut changer le fichier cache à d'autres reprises que juste une "date" mais c'est peut être aussi performant, je ne sais pas.
Pour le moment j'imagine m'orienter sur du memcache ou quelque chose comme cela, mais ce n'est peut êtrepas la meilleure idée, il me faudra creuser (après avoir fini le système d'action)
RE: Rivages (DBark v2) - Jeckel - 01-12-2010
memcache est un solution de gestion de cache, que ce soit ça, du cache fichier, ram disque (que l'on utilise au boulot), cache APC ou le cache inclue dans la zend platform (qui parait-il est très mauvais) ce n'est qu'un mode de stockage, décider de quand on cache, quand on charge depuis le cache et quand on renouvelle est différent.
Pour reprendre l'exemple de l'inventaire, le principe est le suivant :
Dans ta classe usine, lorsque tu souhaite charger l'inventaire d'un personnage, tu vérifies s'il est présent dans le cache, si oui tu le prend, sinon tu le reconstruis et tu le stockes (avec une clé)
Ensuite, il faut identifier les différents endroits où ton objet est susceptible d'avoir été modifié (le joueur achète, trouve, vend on objet, un autre joueur lui vole un objet) dans ces cas là, tu supprimes simplement l'élément du cache... au prochain appel il sera alors reconstruit.
Je ne suis pas encore à la gestion de l'inventaire, mais c'est déjà ce que j'utilise pour les maps, celle-ci peuvent être assez complexe et tapent sur 4 ou 5 tables (voir plus si je prend la configuration des interactions sur les cases) et du coup, je stocke cette map en cache.
Bon après il y a des astuces pour stocker un objets complexe en cache, sans stocker les objets "vivants" en même temps (comme les personnages en mouvement sur la map) mais autant lancer un sujet complet sur le cache alors...
Pour ce qui est des actions avec pré-conditions d'exécution, j'ai aussi réfléchi au problème et j'ai peut-être une solution (non testée) si tu veux, ça m'intéresse d'en discuter...
RE: Rivages (DBark v2) - Ter Rowan - 04-10-2011
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 !
RE: Rivages (DBark v2) - Sephi-Chan - 04-10-2011
As-tu essayé Cucumber pour les tests ? Et pourquoi développer ton propre framework de test plutôt qu'utiliser PHPSpec ou PHPUnit ?
RE: Rivages (DBark v2) - niahoo - 04-10-2011
perso j'utilise simpletest pour php, c'est vraiment ultra basique mais je ne fais (pratiquement) que des assertTrue et ça s'installe en posant un dossier.
je vais voir ce que donne phpspec
arf c'est 5.3, c'est mort pour moi