23-10-2013, 11:50 PM
Effectivement, je ne vois aucun avantage coté "évolution" du joueur (aka, "le joueur de chaque système aura la même progression").
Le 1er présente l'inconvénient de gérer 2 variables (le niveau courant, et les points dans le niveau courant). C'est plus lourd niveau algorithme, et cela empêche souvent l'utilisation de fonctions mathématiques classes, type f(points) = bonus_sante puisqu'on doit alors passer à f(niveau, points_dans_ce_niveau) = bonus_sante.
Le 2nd présente l'intérêt de ne gérer qu'une seule variables (les points). Il permet aussi de changer les seuils des niveaux à la volée puisqu'on enregistre les points totaux, et qu'on n'a plus qu'à trouver le niveau correspondant. Dans le 1er cas, il était impossible de changer les seuils à la volée, puisque cela aurait perturbé les niveaux (je suis niveau 2 car j'ai eu 100 points, mais si on change et que le niveau 2 passe à 200points, comme je reste niveau 2, ce sera comme si je gagnais 100 points).
Donc, je privilégierai le 2nd, pour sa simplicité et sa souplesse.
Son inconvénient réside dans le fait que, définis ainsi, les niveaux peuvent être:
niveau 1 : 100 pts
niveau 2 : 500 pts
niveau 3 : 300 pts
Et donc, personne ne "reste" niveau 2, puisque le niveau 3 a un nombre de points plus faible. A gérer via une alerte ("attention M le développeur: vos niveaux sont étrangement étagés!").
Sinon, on peut aussi mélanger les deux approches:
* stocker les niveaux sous la forme niveau N : points requis pour passer N+1
* stocker uniquement les points du joueur
Ainsi, à partir du stockage-type du 1er modèle, on génère la grille du 2nd modèle (où les points requis pour le niveau N+1 seront forcément > aux points requis pour le niveau N, sous condition que le tableau du 1er modèle n'accepte pas les nombres négatifs). On utilise alors cette grill dans le 2nd modèle.
Autre proposition, ma favorite
Personnellement, je préfère une approche type du 2nd modèle, où je ne stocke que des points: cela me permet d'utiliser des fonctions simples, à une seule variable, donnant le bonus en fonction du nombre de points. Et je procède de même pour le niveau: avec une fonction. Au lieu d'un tableaux de niveaux (tableau fini, donc on peut atteindre le dernier niveau et il faut alors gérer ce cas particulier), je crée une fonction qui, au nombre de points, associe immédiatement le niveau (en plus, cela évite de chercher le niveau dans le tableau des points, opération potentiellement lente au vue du grand nombre de fois où elle sera exécutée). Par exemple (E() = partie entière):
Niveau = E(sqrt(Points))
ou
Niveau = E(log(Points))
C'est ma méthode favorite: simple (1 variable), continue (niveaux régulièrement réparties: pas de surprise), infinie (pas de niveau max).
Le 1er présente l'inconvénient de gérer 2 variables (le niveau courant, et les points dans le niveau courant). C'est plus lourd niveau algorithme, et cela empêche souvent l'utilisation de fonctions mathématiques classes, type f(points) = bonus_sante puisqu'on doit alors passer à f(niveau, points_dans_ce_niveau) = bonus_sante.
Le 2nd présente l'intérêt de ne gérer qu'une seule variables (les points). Il permet aussi de changer les seuils des niveaux à la volée puisqu'on enregistre les points totaux, et qu'on n'a plus qu'à trouver le niveau correspondant. Dans le 1er cas, il était impossible de changer les seuils à la volée, puisque cela aurait perturbé les niveaux (je suis niveau 2 car j'ai eu 100 points, mais si on change et que le niveau 2 passe à 200points, comme je reste niveau 2, ce sera comme si je gagnais 100 points).
Donc, je privilégierai le 2nd, pour sa simplicité et sa souplesse.
Son inconvénient réside dans le fait que, définis ainsi, les niveaux peuvent être:
niveau 1 : 100 pts
niveau 2 : 500 pts
niveau 3 : 300 pts
Et donc, personne ne "reste" niveau 2, puisque le niveau 3 a un nombre de points plus faible. A gérer via une alerte ("attention M le développeur: vos niveaux sont étrangement étagés!").
Sinon, on peut aussi mélanger les deux approches:
* stocker les niveaux sous la forme niveau N : points requis pour passer N+1
* stocker uniquement les points du joueur
Ainsi, à partir du stockage-type du 1er modèle, on génère la grille du 2nd modèle (où les points requis pour le niveau N+1 seront forcément > aux points requis pour le niveau N, sous condition que le tableau du 1er modèle n'accepte pas les nombres négatifs). On utilise alors cette grill dans le 2nd modèle.
Autre proposition, ma favorite
Personnellement, je préfère une approche type du 2nd modèle, où je ne stocke que des points: cela me permet d'utiliser des fonctions simples, à une seule variable, donnant le bonus en fonction du nombre de points. Et je procède de même pour le niveau: avec une fonction. Au lieu d'un tableaux de niveaux (tableau fini, donc on peut atteindre le dernier niveau et il faut alors gérer ce cas particulier), je crée une fonction qui, au nombre de points, associe immédiatement le niveau (en plus, cela évite de chercher le niveau dans le tableau des points, opération potentiellement lente au vue du grand nombre de fois où elle sera exécutée). Par exemple (E() = partie entière):
Niveau = E(sqrt(Points))
ou
Niveau = E(log(Points))
C'est ma méthode favorite: simple (1 variable), continue (niveaux régulièrement réparties: pas de surprise), infinie (pas de niveau max).