API simple ou complexe pour intéragir avec le noyau du jeu ?
#1
Coucou !

Hier en programmant le système d'appâts le plus simple possible pour Seelies, je me suis posé une question d'ordre plutôt philosophique.

Il y a 3 interactions dans le cadre des appâts : ajouter un appât à un territoire (pour un couple zone/espèce), enlever un appât et modifier un appât existant.

Du point de vue fonctionnel, modifier un appât, c'est retirer le précédent et en mettre un nouveau. Du coup, je me suis demandé si le noyau devait proposer une fonctionnalité pour modifier, ou bien si une couche supérieur devait décomposer l'opération en deux opérations élémentaires (retrait puis ajout).

Ne gérer que les deux opérations élémentaires simplifie le code du noyau, celui qu'on veut généralement le plus robuste possible. Pour prendre l'exemple de mon système, dans le cas d'un ajout, je veux contrôler que le territoire dispose d'assez de ressources pour déposer l'appât, alors que dans le cas de la modification, je veux contrôler que le territoire a suffisamment de ressources en comptant la réutilisation du précédent appât.
Répondre
#2
Si tu prends en compte l'appât récupéré pour calculer les ressources du nouvel appât, je dirais qu'il faut gérer un upgrade qui fait ça de façon atomique.

Ta vue aussi doit le prendre en compte donc c'est vraiment une opération à part et pas deux opérations collées.

D'autant plus s'il est possible que l'ajout d'un nouvel appât échoue.

D'un autre côté, si les appâts utilisent des ressources courantes qu'on peut avoir en quantité, il peut être plus simple de ne pas réutiliser les ressources de l'appât en cours. Le joueur a la possibilité de faire lui même deux opérations si les ressources lui manquent.
Répondre
#3
ma vision serait de séparer en deux ainsi, tu pourrais rajouter des fonctionnalités a retirer un appat sans rien modifier de l autre coté (ok si tu separes le code en restant dans une meme api...) exemple tu peux rajouter une fonctionnalité (fonction de x criteres avec ou sans random, l appat retiré est détruit)

autre raison
si tu veux créer la fonctionnalité "voler un appat" ou "détruire un appat" (guerre ou son propre appat pour x ou y raison) te faudra bien retirer l appat sans le remplacer
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#4
C'était un exemple propre à mon jeu, ce qui m'intéressait c'était votre approche face à ce genre de choix. 16
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)