21-08-2010, 02:14 PM
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
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