Je pense avoir un système de pnj assez abouti, alors voici ce que je conseille :
_ il faut séparer le comportement du pnj (je fais ca : son fichier php associé) de son entité physique (je ressemble à ca et je suis là : base de données)
_ il faut créer des comportements par défaut dans des classes (banque, marchand, hopital)
_ il faut limiter la taille des scripts au minimum, et d'ailleurs limiter le nombre de scripts (ca économise le codeur et limite les erreurs)
En gros, ca donne une table pnj : id, nom, description, carte, x , y, type
Si le type est connu (banque, marchand, hopital) = > on crée une instance de cette classe (pas besoin de fichier php), à la limite une seconde table peut fournir des rensignements complémentaires (biens_vendus : id_bien, id_marchand pour le marchand).
Si le type est inconnu, alors on charge le fichier php associé (pour une quete unique par exemple).
Un classe générale pnj dont hérite tout pnj doit être créée, elle réalise les "tests de collision" (le personnage doit être à côté, sur la même case, et en vie; et le pnj doit etre disponible), et donne une structure à l'affichage du rendu html (cadres, nom, image, description, lien de retour).
Il faut abandonner l'idée du "je crée un fichier php pour chaque pnj". Par expérience, on fait trop d'erreurs (incohérence dans l'étape des quêtes, dans les tests de collision); et les tests complets sont quasiment impossibles (pour une quete de 2h, on ne peut pas revoir 10x tous les aspects). C'est pourquoi il faut s'appuyer sur des classes spécialisées qui vous mâchent le boulot.
Pour les clés étrangères (ex : nom du fichier), EVITEZ DE PRENDRE LE NOM DU PNJ !! car soit tous vos pnj s'appelleront toto et tata, soit vous aurez des fichiers "daleth d'Ukhran le borgne.php"
Créez un id (autoincrémentable) pour différencier vos éléments
_ il faut séparer le comportement du pnj (je fais ca : son fichier php associé) de son entité physique (je ressemble à ca et je suis là : base de données)
_ il faut créer des comportements par défaut dans des classes (banque, marchand, hopital)
_ il faut limiter la taille des scripts au minimum, et d'ailleurs limiter le nombre de scripts (ca économise le codeur et limite les erreurs)
En gros, ca donne une table pnj : id, nom, description, carte, x , y, type
Si le type est connu (banque, marchand, hopital) = > on crée une instance de cette classe (pas besoin de fichier php), à la limite une seconde table peut fournir des rensignements complémentaires (biens_vendus : id_bien, id_marchand pour le marchand).
Si le type est inconnu, alors on charge le fichier php associé (pour une quete unique par exemple).
Un classe générale pnj dont hérite tout pnj doit être créée, elle réalise les "tests de collision" (le personnage doit être à côté, sur la même case, et en vie; et le pnj doit etre disponible), et donne une structure à l'affichage du rendu html (cadres, nom, image, description, lien de retour).
Il faut abandonner l'idée du "je crée un fichier php pour chaque pnj". Par expérience, on fait trop d'erreurs (incohérence dans l'étape des quêtes, dans les tests de collision); et les tests complets sont quasiment impossibles (pour une quete de 2h, on ne peut pas revoir 10x tous les aspects). C'est pourquoi il faut s'appuyer sur des classes spécialisées qui vous mâchent le boulot.
Pour les clés étrangères (ex : nom du fichier), EVITEZ DE PRENDRE LE NOM DU PNJ !! car soit tous vos pnj s'appelleront toto et tata, soit vous aurez des fichiers "daleth d'Ukhran le borgne.php"
Créez un id (autoincrémentable) pour différencier vos éléments