Question de Mise à jour.....

[uriak]

Je précise que dans mon système, tous les gains sont perçus à la connexion, puisque c'est le taux total qui est enregistré pour chacun. Sinon les propositions de paiement volontaires peuvent être intéressantes, mais là ça dépend de ta vision du système de jeu et de l'intérêt/nécessité de faire partie de cette hierarchie.

[joshua]

Il y a une petite possibilité... mettre à jour à la connexion avec répercutions sur les inférieurs risque de mettre ton serveur à genoux pour l'empereur (ou ceux situés très haut). Donc il faut inverser le problème : à chaque changement de gain d'un personnage, il faut propager ce changement à son supérieur. Donc chaque personnage aura deux taux de gain d'argent : le sien et celui provenant de ses inférieurs. Lorsqu'un joueur se connecte, il suffit d'utiliser la règle de différence de timestamp pour lui et que pour lui. Du coup, les mises à jours peuvent concernent au pire qu'un nombre de joueurs égal au nombre d'étages de ton empire, et ne se manifeste qu'en cas de changement de gains.

C'est ce que je pensais faire au debut. En gros, la personne a ses gains, mais elle recoit celle de son inférieur lorsque celui-ci se connecte. Le soucis est par exemple le cas ou un joueur arrete de jouer ou le cas ou il part en vacances... si rien n'est mis en cron il est dur de gérer un automatisme.

Moi j'ai une autre idée 1

Pourquoi faire ça en automatique? Il faut, à mon avis, permettre au joueur de donner ce qu'il considère comme 20% à son N+1... en lui laissant la possibilité de donner plus (c'est une buse) ou moins (et là, il arnaque son N+1 10). Là dessus, tu ajoutes donc un système d'espionnage chez le N+1 qui permettra, pour une somme plus ou moins importante, d'envoyer un espion chez son N-1 pour voir s'il n'a pas été arnaqué! En contre partie, ce N-1 peut aussi avoir un niveau d'espionnage qui permet de camouffler à ces espions les fraudes 1
C'est assez tordu comme idée, mais ça rajoute un peu de piquant au jeu!

Tu peux aussi mettre en place ce système dans lequel c'est le joueur qui choisi quel est le pourcentage de ses revenus qu'il donnera à son N+1.

Je pense que les reversement ne doivent pas se faire plus d'une fois par jour... Toi, quand tu paie tes impots, c'est tous les mois (ou tous les ans), pas tous les jours!

Voilà, j'ai donné mon idée...

Ca j'y ai pensé aussi ! Mais le systeme me cause un soucis, c'est que comme pourra le confirmer pascaltje, j'ai deja une très grosse complexité de jeu au sein des empires (genre un lieutenant se barre de 'lempire avec toute sa branche, ou un responsable de quadrant destitue son responsable de région, bref j'ai peur au bout d'un moment de me noyer dans les fonctionnalités et de noyer mes joueurs...
Ensuite, quid des représailles? comment punir un joueur qui ne paie pas... Je ne sais pas

Je rejoins Denisc sur un point :
Le paiement devrait se faire, à l'instar des impôts, à un moment donné et pas en continue.

Le plus adapté pour ce genre de système semble être un traitement quotidien, pendant lequel le site (ou juste certaines parties du site) sont inaccessibles, une sorte de calcul de "fin de tour".
Un traitement global à l'avantage de n'oublier personne. tout le monde payera ses impôts, le joueur qui se connecte 10 fois par jours tout comme celui qui ne passe qu'une fois par semaine.

En liant le paiement d'impôts à la connexion des joueurs, on entre dans une politique de revenus très aléatoires qui rend extrêmement difficile la planification (Obligé d'attendre que ce @#$% de subordonné rentre de vacance et se connecte pour avoir l'argent nécessaire à la construction de ce fichu destroyer...)

Bon visiblement j'ai tout interet a prévoir une mise a jour des finances journalières a froid....
Maintenant il va falloir voir comment je mele ca avec les combats spaciaux... Imaginons deux flottes qui sont proches, pretes a combattre, et... *pour des raisons de mise à jour le serveur sera disponible dans quelques minutes*[/quote]

[joshua]

Je précise que dans mon système, tous les gains sont perçus à la connexion, puisque c'est le taux total qui est enregistré pour chacun. Sinon les propositions de paiement volontaires peuvent être intéressantes, mais là ça dépend de ta vision du système de jeu et de l'intérêt/nécessité de faire partie de cette hierarchie.

Ca ca m'ennuie plus car ca veut dire que si je veux que le transfert se fasse réellement, Je vais devoir reellement modifier al valeur en base regulierement. En gros si les joueurs se connecte souvent je vais vite m'ecrouler!

[uriak]

C'est ce que je pensais faire au debut. En gros, la personne a ses gains, mais elle recoit celle de son inférieur lorsque celui-ci se connecte. Le soucis est par exemple le cas ou un joueur arrete de jouer ou le cas ou il part en vacances... si rien n'est mis en cron il est dur de gérer un automatisme.

non, non, on ne s'est pas compris

dans ma technique le fonctionnement est le suivant
chaque joueur à deux taux de gains : le PRincipal, et le SEcondaire.
A sa connexion, il gagne deltaTime *(PR+SE)
Le secondaire correspond aux gains des inférieurs. Donc à chaque fois qu'un sous fifre augmente son taux PR+SE de N revenus/temps, ton programme doit aller ajouter 20% de N au SE du supérieur et ainsi de suite. Cette mise à jour se propage jusqu'au sommet et n'a lieu qu'en cas de changement effectif de taux de gains, et non pas simplement du temps qui passe.

De même en cas d'accident ou autre (joueur viré ou qui part), il faut retrancher au SE de ses supérieur le manque à gagner.
Donc non un supérieur n'a pas besoin de la présence de son inférieur pour toucher sa part du magot, dans ce cas.

[joshua]

j'ai encore du mal a comprendre -_-"
désolé je me reveille encore au boulot et va falloir que je fasse un exemple pour voir comment arranger ca :p

[uriak]

dur, dur ^^

Dans mon système on tient en compte le système de reversement directement dans le taux horaire des gains des joueurs. Donc chacun gagne ce qu'il est censé gagner à sa connexion, sans avoir besoin de la connexion des autres. Le seul moment où il faut modifier des valeurs du bas vers le haut, c'est quand les gains d'un joueur sont modifiés (vacances, pillage, investissement, etc)

[joshua]

ok mais imaginons qu'un joueur se conencte pas pendant un mois. Au bout de 3 semaines il se fait attaquer et perds sa planete.
Comment calcule tu le reversement au N+1 des 3 semaines?

[uriak]

et bien, durant les 3 premières semaines, le N+1 gagne 20% des revenus de la planète fois le temps entre deux ses connexions. L'évènement perte de planète provoque un changement de gains :
->donc la cible se voit soldée tous l'argent restant qui lui manque (3 semaines dans son cas), il ne reverse RIEN à son N+1 car ce dernier avait déjà perçu l'argent automatiquement via les taux.
->ensuite elle transmet son changement de gain à son N+1, la fonction calcule l'argent gagné juqu'à cette date pour le N+1 (donc diff de temps entre l'instant de la perte de planète et dernière connexion du N+1) et applique la modification au SE du chef.

A sa prochaine connexion, le chef gagnera son argent normalement à un taux plus faible (les 20% de planète en moins)

[joshua]

oki je commence a comprendre. Effectivement ca peut le faire.... Mais ca pose toujours un probleme.
Ca amrche dans le cas ou tu as un N et un N+1
Mais quand tu vas de N à N-10.
et que les gains suivent toujours la regle des 20%
en gros tu as [N]=20%[N-1]+20%*20%[ N-2]+20%^(N-1)[1] a multiplier apr le nombre de branche et tous les N-....

[uriak]

Il faut que ta fonction de mise à jour de gains soit récursive, effectivement. Elle remontera au plus les N rangs de ta hierarchie. A chaque étape, elle réalise une mise à jour de l'argent du joueur concerné, modifie le taux SE et s'appelle à nouveau avec 20% de son propre appel s'il y a un supérieur.
Ou alors tu appelles N fois la fonction dans un for, en multipliant à chaque fois 0.2 la valeur de la modif pour chaque rang parcouru.