World + Entities

[Pierre-Sassoulas]

Les squelettes sont créés, mais il reste à implémenter les fonctions à l'intérieur de Character ce qui dépend de l'implémentation qu'on choisit (Hashmap/Tableau) ? Sylvain qu'en penses-tu ?

[azuryus]

Alors déjà, tu serais gentil de commit des trucs qui compilent (même si pour l'instant y'a pas grand chose...). C'est pas compliqué de créer la classe vide juste pour le permettre...

Ensuite, j'ai pas compris la question ? Tu veux dire que l'implémentation dépend de l'implémentation, quelle surprise... Tableau ou Hashmap, ça dépend de ce que tu veux stocker, est-ce que des indices numériques suffisent ou est-ce que t'as besoin d'avoir une clé de type complexe pour accéder à un élément ? Comme je ne sais pas pour quel objet tu poses la question, je ne peux pas te répondre.

[Pierre-Sassoulas]

Hello.

Je n'ai pas créé les classes vides qui devaient être fait par quelqu'un d'autre pour qu'il n'y ait pas de problème de merge vu je ne sais pas qui fait quoi pendant que je code. Donc effectivement ça compile pas mais je penses pas que ça soit très grave vu que tout reste à faire et que knowledge va être implémenté bientôt.

Je te demande un conseil pour l'implémentation étant donné que la dernière fois que j'ai fait du java c'était en 3.2 et ça date un peu. Je parle de Character que tout le monde va devoir utiliser.

[azuryus]

Les problèmes de merge n'arrivent que si les gens ne commit pas quand ils travaillent, ce qui n'est pas une bonne idée je trouve. Bref, j'ai crée la classe vide pour que ça compile...

Je ne comprends toujours pas ?! À l'intérieur de la classe Character, tu fais ce que tu veux, et la façon donc les objets Character sont stockés ailleurs ne devrait pas te déranger ?!

[Pierre-Sassoulas]

Par exemple les Knowledge et Object d'un character tu les stockerais dans un tableau ou une hashmap ?

[azuryus]

Bon, alors en fait, de base on évite les tableaux simples quand ce sont des choses vouées à changer régulièrement, il faut utiliser une implémentation de List (ArrayList par exemple). Ça permet de modifier la taille dynamiquement, et d'itérer directement sur les objets, entre autre...

Ensuite, pour les connaissances, je pense qu'une liste suffit, puisque c'est l'objet Knowledge en lui-même qui va déterminer l'information qu'il contient, non ? Donc on va parcourir toutes les connaissances quand on aura besoin de chercher quelque chose ?

Enfin, pour les objets, je pensais justement tout à l'heure, est-ce qu'il ne vaudrait pas mieux passer par une classe Inventory pour pouvoir gérer une quantité limite d'objet, ce genre de choses... Et si on veut changer le comportement plus tard (pour mettre un poids sur les objets par exemple), ça sera plus simple si c'est séparé. Quoi qu'il en soit, le stockage des objets ne nécessite qu'un identifiant pour le trouver, non ? Si on veut chercher ensuite à partir d'un nom, il suffira de parcourir la liste, mais il vaut mieux que le fonctionnement par défaut soit la recherche par id. Donc liste aussi je dirais.

[Pierre-Sassoulas]

Ok. ArrayList dans tous les cas alors.

[Pierre-Sassoulas]

J'ai un choix de conception à faire. Actuellement on n'a pas accès aux autres éléments du monde dans un Personnage.

Ce que j'ai fait pour le LearnFromZone c'est qu'on passe une array list des knowledge de la zone depuis le monde (ou peu importe) et en fonction de son intelligence le personnage apprend ou pas et renvoie les index de ce qu'il a appris.

Par contre il y'a d'autre fonction qui marche comme ça. Ça pose problème dans le cas d'un LearnFromZone mais aussi d'un SearchEntityInZone et ça posera sûrement encore problème.

Bref, on peut mettre le monde dans le Personnage et tout gérer au niveau du personnage, ou bien que les entités d'une zone soit référence dans la zone ? Ou généraliser le système fait pour LearnFromZone. (Gérer le contenu d'une zone dans le monde et passer une array list au Personnage qui se débrouille en fonction de son intelligence.)

Qu'en pensez-vous ?