Méthode de calcul de niveaux de personnages

[niahoo]

Hello,

Aujourd'hui je me penche sur l'évolution du niveau d'un personnage (ou d'une de ses compétences) et je retiens deux modèles principaux.

Le premier modèle attribue un certain nombre de points à chaque niveau :

Code :

niveau   points
2          100
3          300
4          1200

Les points du joueur niveau 1 sont à 0. Quand il atteint 100 points, il passe niveau 2 et ses points sont remis à zero. Il commence à monter le niveau suivant. S'il passe directement de 90 à 105 points, il passe niveau deux et commence à 5 points, ou bien il passe niveau 2 et repart à 0 points, au choix du développeur, mais cette seconde solution n'est pas terrible.

Le second modèle est similaire mais les niveaux sont définis ainsi

Code :

niveau   points
2          100
3          400       (100 + 300)
4          1600     (100 + 300 + 1200)

Ici, quand le joueur niveau 1 atteint 100 points, il passe niveau 2 et garde ses 100 points. S'il atteint directement 105, il passe niveau 2 et garde 105 points. (Il est facile pour le développeur de le remettre à 100 points, mais encore une fois pour moi l'expérience est continue, le niveau indique simplement un progrès, un mec en classe de troisième en juin et un mec en seconde en septembre sont sensiblement au même niveau - le lycéen peut simplement activer la skill "sécher les cours". À ce compte là le premier modèle est meilleur mais je ne veux pas "détruire" des points d'XP).

Le second modèle est le système retenu sur wow par exemple.

Je voudrais savoir si vous voyez un avantage particulier à l'un des deux modèles. Dans mon exemple, le joueur de chaque système aura la même progression. Donc, l'avantage de l'un ou l'autre se situerait peut-être au niveau algorithmique ?

Dans un cas, on compare les points courants avec le nombre de points a atteindre au niveau suivant (cas 1). Dans le second cas ... ben c'est pareil.

Dans la capacité à choisir la "taille" de chaque niveau ? Non puisque on peut basculer d'un système à l'autre, voire les implémenter en même temps dans excel.

Alors ?

[Xenos]

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).

[niahoo]

Haha je savais que j'allais aggro Xenos sur ce coup. Effectivement les calculs sont (un peu) plus simples avec la seconde méthode.

Personnellement je souhaite avoir un niveau maximum, au moins pour les compétences. Pour le personnage, le contenu n'étant pas infini, il faut que le niveau soit maxé. ça ne veut pas forcément dire qu'il faut écrire dans le code un niveau maximum, tu peux très bien avoir une fonction infinie, mais qu'à un moment donné il n'est plus possible de gagner de l'XP avec le contenu (Mobs pas assez forts, quêtes accomplies ou de niveau trop bas, ...). Du coup, il devient plus simple de fixer arbitrairement dans le code ce niveau maximum pour l'équilibrage, et pour garder une certaine difficulté sur le contenu de plus haut niveau.

[GeGe_KAT]

Clairement la 2nd méthode est à privilégier.

D'un point de vue non-technique mais complètement orienté coté "joueur" : remettre les points d'expérience à zéro (une fois un niveau atteint), c'est vraiment étrange. L'expérience c'est quelque chose qui s'aquière et qui ne se perd pas. Remettre à zéro ces points, ça peut donner l'impression au joueur de régresser, de perdre un aquis. Le joueur aime garder des "gros chiffres culmulés", ça lui donne directement une image du chemin parcouru.

D'un point de vue technique maintenant, tu peux totalement lier ta méthode 2 avec celle de Xenos : en simulant ton tableau avec une fonction de type "série arithmétique".
Par exemple dans un certains JDR (papier) très connu, l'xp est gérée de cette façon :
XP(n) = XP(n-1) + n * constante
Ce qui donne (avec constante = 1000) :
Level : XP_min
1 : 1000
2 : 3000
3 : 6000
4 : 10000
...

Tu peux très bien t'inspirer de cet exemple. Pour moi, c'est une très bonne méthode dans le sens ou ça respect bien le fait que les levels deviennent de plus en plus difficile à aquérir tout en respectant une règle "carré".

[Xenos]

@niahoo: si tu veux un niveau max, il sera encore plus simple d'avoir une fonction qui ne tend pas vers l'infini, mais vers N_max (le niveau maximum).

Par exemple:
Niveau = E(Nmax * (1-exp(-x)))

Cette fonction tend vers Nmax quand x (l'expérience) tend vers l'infini. Tu as donc des points "infinis" (qui peuvent ne pas être affichés si besoin, on donnc juste le niveau du joueur), mais un niveau maximum (qui ne sera, ici, jamais atteint; il suffit d'utiliser l'arrondis au lieux de la troncature pour l'atteindre).

D'un point de vue technique, si tu retiens la solution de Gege_KAT, évite les calculs type "U(n) = f(U(n-1))", car ces calculs sont récursifs, et ralentissent souvent le serveur pour rien (on peut trouver une formule qui ne requiert pas f(n-1) pour trouver f(n)).

[niahoo]

D'un point de vue non-technique mais complètement orienté coté "joueur" : remettre les points d'expérience à zéro (une fois un niveau atteint), c'est vraiment étrange.

Effectivement si on affiche les points au joueur et pas simplement une barre c'est un bon argument.

Pour l'implémentation ce n'est pas très important. Avoir une ou deux variables et un appel récursif ne change même pas un appel de fonction d'une milliseconde.

Le plus difficile est de choisir le nombre de points de chaque pallier. Il faut que je liste tout ce qui rapporte de l'expérience pour essayer de fixer une quantité d'actions à réaliser et ainsi choisir le temps moyen pour passer chaque niveau.

Donc bon je partirais sur une XP qui se cumule, ok, merci

[CaptainJS]

D'un point de vue non-technique mais complètement orienté coté "joueur" : remettre les points d'expérience à zéro (une fois un niveau atteint), c'est vraiment étrange. L'expérience c'est quelque chose qui s'aquière et qui ne se perd pas. Remettre à zéro ces points, ça peut donner l'impression au joueur de régresser, de perdre un aquis. Le joueur aime garder des "gros chiffres culmulés", ça lui donne directement une image du chemin parcouru.

Sur plusieurs jeux (FF Tactics par exemple) le nombre de points d'xp entre 2 niveaux est fixe (100 points d'xp), mais le nombre d'xp gagné varie en fonction du niveau (ça c'est le point de vue gameplay).
Au niveau de la technique c'est relativement galère à gérer, et du coup il faut le gérer à plusieurs endroits (combats, hausse de niveau ...)

[Xenos]

Tu peux aussi avoir un système de points d'XP qui s'incrémente régulièrement, mais avoir une fonction qui transforme cette XP "brute" en un XP "réelle", qui est alors utilisée pour les niveaux Cela revient à déporter le problème: au lieu d'incrémenter irrégulièrement en fonction du niveau, tu incrémente régulièrement, puis tu applique une fonction qui va "tasser" l'expérience quand le niveau augmente.

[Ter Rowan]

wow a les deux :

calcul du gain d xp fonction du niveau du joueur et du niveau du mob
gain de niveau en fonction du niveau du joueur

ça me semble aussi simple de poser une fonction qui calcule l xp gagnée que l xp à acquérir pour gagner un niveau non ?

[Xenos]

Si l'XP peut être gagnée de plusieurs façons, alors il vaut mieux avoir juste une fonction qui calcul l'xp nécessaire pour gagner le niveau, et une constante pour chaque façon de gagner de l'xp, plutôt qu'une fonction pour chaque façon de gagner de l'xp.
Et l'approche "le gain d'xp change en fonction de son niveau" me semble un peu surréaliste, mais après, dans le fond, les deux sont envisageables. C'est probablement du ressort de la préférence personnelle et de la méthode de réflexion de chacun (et je réfléchis souvent bizarement... comme tout le monde?!)