[ombrephenix]

[Edit Deyonara : Début de la discussion : >> ICI <<]


C'est un paramètre très intéressant a gérer pour les quettes ou les donjons. Cela peut être le moyen idéal pour équilibré leurs difficultés et réduire le "power leveling". Créer des nouveaux chalenges par des vrais stratégies d'équipes.(ex:"waypoint" A requière groupe de "3 PJ" max pour validé script B)
Choix des sorts en synergie de groupe a la manière de GW.
Ou bien imaginez des scripts qui mesurent la taille des groupes. Ou encore des restrictions de formations influencés par les niveaux des joueurs ou leurs grades RP.

Enfin! Tout cela pour dire que c'est pas une question sans intérêt. Et qu'il y a un vrai potentiel "gameplay" pour NW2.

[MaJo]

C'est justement sur quoi je me penche particulièrement actuellement

Merci pour les infos

[krighaur]

Citation :

Publié par ombrephenix

C'est un paramètre très intéressant a gérer pour les quettes ou les donjons. Cela peut être le moyen idéal pour équilibré leurs difficultés et réduire le "power leveling". Créer des nouveaux chalenges par des vrais stratégies d'équipes.(ex:"waypoint" A requière groupe de "3 PJ" max pour validé script B)
Choix des sorts en synergie de groupe a la manière de GW.
Ou bien imaginez des scripts qui mesurent la taille des groupes. Ou encore des restrictions de formations influencés par les niveaux des joueurs ou leurs grades RP.

Enfin! Tout cela pour dire que c'est pas une question sans intérêt. Et qu'il y a un vrai potentiel "gameplay" pour NW2.

Ce message me donne une idée :

Il y a dans la bibliothèque ginc_overland.nss une fonction qui donne le Challenge Rating (CR) d'un groupe (GetPartyChallengeRating), et une autre (DisplayChallengeRating) qui modifie la couleur d'affichage des mobs en fonction de la différence de CR groupePJ/mobs. En modifiant cette fonction on devrait pouvoir créer des transitions, triggers, qui ne soient actifs qu'en fonction de cette différence de CR.

Par exemple un donjon réservé au pexage des nouveaux arrivants pourrait être rendu inaccessible aux groupes ou PJ de haut niveau, et inversement un donjon particulièrement dangereux pourrait n'être accessibles qu'aux groupes costauds.

[Deyonara]

Il me semble qu'avec une boucle définie par "GetFirstFactionMember(...)" et "GetNextFactionMember(...)", on peut mesurer la taille d'un groupe de joueurs, lorsque l'objet désigné est bien un joueur. Il suffit de vérifier si l'objet ainsi désigné est ou non un autre joueur, et on pourrait obtenir la taille d'un groupe.

A tester :

Code PHP:

void main()
{
    object oPC = GetMachinBidule();

    int nTotalGroupe,nTotalJoueurs;

    object oJoueur = GetFirstFactionMember(oPC);
    while(oJoueur != OBJECT_INVALID)
    {
        nTotalGroupe++;
        if(GetIsPC(oJoueur) || GetIsPossessedFamiliar(oJoueur))
            nTotalJoueurs++;
        oJoueur = GetNextFactionMember(oPC);
    }

    string sMessage = "Mon groupe est constitué de "+IntToString(nTotalGroupe)+" membres, dont "+IntToString(nTotalJoueurs)+" joueurs.";

    AssignCommand(oPC,SpeakString(sMessage,TALKVOLUME_SHOUT));
} 

[Laban]

Si ça vous intéresse, j'ai une structure et une fonction pour lire pas mal de données sur un groupe de joueurs. Elle fonctionne bien.

PS@Deyonara : on devrait pas faire un nouveau topic pour ça ? Me paraît avoir dévié du premier post.

[Deyonara]

C'est chose faite.