V10 - La vraie révolution arrive (On monday)...Ou pas

Merci pour la précision

Toujours autant de sel sur ce board, on adore

thomasar wrote:

Merci pour la précision

Toujours autant de sel sur ce board, on adore

Nous n'avons pas actuellement la date de sortie sur les univers.

L'annonce de cette nouvelle version, fait référence , uniquement, de sa mise en application sur le serveur test.

Dès que l'information sera délivrée par la GameForge l'annonce sera faite ici : ANNONCES JEU

Merci pour la précision !

Nydalind wrote:

L'algo de combat, c'est

"6 fois (max) les n vaisseaux tire m fois (m basé sur le rapid fire)"
Au pire, je vois un algo en 6 tours * n vaisseaux * m tirs chacun => O(n²)

J'me plante peut être mais je veux bien l'explication de ton x^n.

Réduire la complexité de l'algo, ça peut être fait "facilement" (en modifiant le système de combat j'entends)

- Réduire le nombre de tours

- Réduire le rapid fire

- Optimisations éventuelles sur la gestion des objets (j'sais pas comment c'est fait mais même après 20 ans, doit rester des détails à peaufiner)

- Modifier la mécanique du bouclier pour quelle ne face plus d'arrondi (=> les clés et autres vaisseaux léger entameront donc le bouclier, gros nerf des RIP )

Et le plus "gros gain possible" à mon sens :

- Traiter les vaisseaux par groupe et non plus individuellement

Je détaille :

1) Initialisation :

a) On récupère les tech de chaque joueurs et on calcule les stats de chacun de ses types de vaisseaux

2) A chaque tour

a) On considère pour chaque flotte de chaque joueur de chaque camp les vaisseaux du même type (clé, cro, ... ) comme un groupe

b) On calcule le bouclier total, la structure totale et l'attaque totale de chaque groupe (bouclier d'un vaisseau * nombre de vaisseau, même chose pour les 2 autres)

c) On tire aléatoirement le groupe à cibler dans l'autre camp pour chacun des groupes. La probabilité de choix d'un groupe est [Nombre de vaisseaux dans le groupe] / [Nombre total de vaisseaux]

d) On ajoute l'"attaque totale" à la liste des dégats que devra subir le groupe cible

e) On résout les tirs : Le "bouclier total" est réduit du montant de l'"attaque totale", le reste est déduit de la "structure totale"

b) On supprime les vaisseaux au prorata de la structure perdue (si au total, la "structure totale" a perdu 10%, on supprime 10% des vaisseaux du groupe)

c) On reforme le "bouclier total" en fonction du nombre de vaisseaux restants et on recalcule l'"attaque totale". La "structure totale" est déjà connue

3) Fin du combat

a) Pour chaque groupe, la "structure totale" restante détermine le nombre de vaisseaux qui rentrent à bon port

a") Calcul du pillage si applicable

b) Le nombre de vaisseaux initial - le nombre de vaisseaux vivants permet de calculer le champ de ruine

c) Calcul des PH

d) Calcul des docks

Un système de combat sous ce format a un paquet d'avantage en terme de complexité :

- On n'est plus dépendant du nombre de vaisseaux (allez, si, pour les calculs de probabilité de sélection du groupe et pour multiplier les stats individuelle : quasi nada)

- On a maximum 16 flottes x 15 types de vaisseaux en attaque VS soyons fous, la NYDG avec 8 type de défenses et 5 + 4 + 4 + 4 défenseurs * 15 types de vaisseaux : 240 + 255 + 8, en gros 500 groupes à faire jouer.
VS des M de vaisseaux, c'est ridiculement faible

A prendre en considération tout de même :

C'est un énorme buff de la RIP. Colossal même. La RIP avait un rapid fire très élevé pour compenser le fait qu'elle OS un seul et unique vaisseau par tir. Avec cette mécanique, une RIP (0/0/0) défonce 500 clé (0/0/0) par tir. Si on rajoute le rapidfire par dessus, ça va piquer

Globalement, ça nécessiterait quelques ajustement des RF mais permettrait de résoudre d'énormes combats en une fraction de seconde

Display More

En effet j'ai mal estimé la complexité

Je dois avoir mal compris leur nouveau rapidfire alors. mais selon moi l'ancien était a coup de

6 vagues ou chaque vaisseau tire, puis chaque vaisseau a une chance de tirer à nouveau, ce tir pouvant entrainer un nouveaut tir, puis un nouveau... ce qui entrainanait des logneurus monumentales à cause des RIP et de leur rapidfire élevé qui entrainait quasiment une boucle inf dans certains cas

-> 6 vagues de x*n (sachant que chaque tir semble être calculé indépendement)

Le changement vient juste apporter une "limite" à n. Mais les temps de calculs pour des grosses flottes resteront longs. Seuls les calculs des flottes de rip seront réellement impactés, le calcul semblant inchangé pour tout le reste (à moins qu'ils aient également changé la façon dont le RF est calculé).

Le problème reste que l'algo de calcul ne semblait pas optimisé dès le début (l'ajout des fdv n'aurait pas du avoir autant d'impact a partir du moment ou elles ne sont sensées être calculées qu'une fois avec les technos armes / bouclier et pourtant...). Si chaque vaisseau a son propre calcul de tir, alors il semble logique que des flottes de 900K clé 10k rip prennent deja trop de temps a se calculer (hors RF). La formule de calcul de base était bonne a l'époque (et technique) mais ne prennait pas en compte des tailles de flotte élevées ainsi que le système d'AG / DG.

il y a un besoin énorme de simplifier tout le système de résolution de combat plutôt que de le "brider" en nerfant aléatoirement.

Ton système est intéressant (le fait de regrouper les tirs déjà plutôt que de calculer 1 par 1), le calcul des techs avant (enfin ça j'espère que c'était déjà le cas sinon c'est vraiment moche). Après il faudrait surement le tester pour rééquilibrer les vaisseaux en fonction.

Lors d'une AG, l'ordre de groupement des flottes entraîne une multitude de calculs supplémentaires. Ne pas oubliez cela.

Non c'est pas une multitude, il prend chaque ligne une par une et lance le calcul dans l'ordre c'est tout.

du monde qui teste?

le probléme des construction qui ce coince a était résolu? idem pour les flotte qui mouline 10 mn avant de rentré?

si la v10 sert qu'a corrigé les bug, autant avoir des info ^^'

thomasar wrote:

Merci pour la précision

Toujours autant de sel sur ce board, on adore

Quand on en est à deux fois la question dans le thread et qu'en plus il y a une annonce jeu qui dit clairement que le déploiement se fait actuellement exclusivement sur le PTS, ouais, on a un peu la flemme de répondre en boucle à des gens qui font aucun effort pour chercher avant de demander.

Désolé ça tombe sur toi, mais c'est valable pour tout le monde : lisez et cherchez, avant de poser une question.

epage90 wrote:

6 vagues ou chaque vaisseau tire, puis chaque vaisseau a une chance de tirer à nouveau, ce tir pouvant entrainer un nouveaut tir, puis un nouveau... ce qui entrainanait des logneurus monumentales à cause des RIP et de leur rapidfire élevé qui entrainait quasiment une boucle inf dans certains cas

En fait chaque vaisseau tire, et selon sa cible, il a une chance de tirer à nouveau ou pas.

D'ailleurs ça ne change pas vraiment, c'est juste que plutôt que de calculer p entre 0 et 1 et de vérifier si p > 1/RF (et le cas échéant, tirer à nouveau, ce qui oblige au calcul d'une division à chaque étape, en PHP, qui n'a aucune optimisation de ce genre de choses), ils vont tirer p entre 0 et 1 et vérifier si p < p_RF (et si oui, tirer à nouveau) avec p_RF le pourcentage déduit du RF.

La grosse diff, c'est juste qu'il est cappé à une valeur max qui réduit la proba de tir supplémentaire, et que c'est un pourcentage fixe qui n'a pas à être recalculé, ce qui évite une division par tir (et quand tu as 1G tirs par vague sur des grosses flottes ça peut changer des choses).

Pour donner une idée du coût au pire de cette simple division, en Python3 ça donne ça sur un i7 :

Et si le RF est déjà calculé et ne résulte pas d'une division :

Alors normalement la question se pose pas, GF devrait depuis 15 ans avoir fait en sorte que la division se fasse pas à chaque fois, mais je fais le pari qu'ils n'ont jamais réglé ça.

Du coup si tu utilises un pourcentage déjà calculé et qui plus est cappé (ce qui réduit le nombre de tirs par itération de boucle), ben c'est good.

c'est sur que c'est plus simple de modifier une commande , que de mettre des serveurs physique de qualité ...

Alors il y a totalement débat.

Oui mettre des serveurs de qualité est parfois une bonne réponse. Mais si ton code est pourri, et que tu gâches 75% de ta ressource de calcul, tu peux mettre un serveur deux fois plus puissant, tu seras toujours plus lent que si tu corriges ton code.

Neoterranos wrote:

Alors il y a totalement débat.

Oui mettre des serveurs de qualité est parfois une bonne réponse. Mais si ton code est pourri, et que tu gâches 75% de ta ressource de calcul, tu peux mettre un serveur deux fois plus puissant, tu seras toujours plus lent que si tu corriges ton code.

Tout à fait. Professionnellement parlant, tu auras beau avoir le serveur de meilleure "qualité", si ton code ne suit pas (en terme d'optimisation etc...), c'est peine perdue.

Neoterranos wrote:

Alors il y a totalement débat.

Oui mettre des serveurs de qualité est parfois une bonne réponse. Mais si ton code est pourri, et que tu gâches 75% de ta ressource de calcul, tu peux mettre un serveur deux fois plus puissant, tu seras toujours plus lent que si tu corriges ton code.

Il y a débat quand tu as la possibilité de faire l'un ou l'autre.

La dernière fois qu'il y a eu un dev convenable sur OGame ça doit être ... 2007 ? Du coup là, ils vont toucher a un truc historique, le RF, mais avec les capacités qu'on leur connait. Je suis sans doute médisant mais, j'aurais plus visé sur une amélioration structurelle

Bon en fait ça corrige rien du tout cette version x)

Les mine/fdv continue de bugué comme avant, ça fini mes tourne en boucle

je veut bien que les rf soit important, mais le reste devrais étre corrigé aussi non?

Ou c'est moi qui espérè trop un jeux fluide, sans galérè 10mn pour monté un lvl de mine?

Tu as des attentes trop élevées.

Néné wrote:

Il y a débat quand tu as la possibilité de faire l'un ou l'autre.

La dernière fois qu'il y a eu un dev convenable sur OGame ça doit être ... 2007 ? Du coup là, ils vont toucher a un truc historique, le RF, mais avec les capacités qu'on leur connait. Je suis sans doute médisant mais, j'aurais plus visé sur une amélioration structurelle

Dans leur cas spécifique je partage ton avis. Mais c'est important de noter qu'en général, le refactoring reste la clef.

Pixelo wrote:

Les mine/fdv continue de bugué comme avant, ça fini mes tourne en boucle

je veut bien que les rf soit important, mais le reste devrais étre corrigé aussi non?

Pour information, pour corriger cela, il faut annuler la construction en cours et construire un autre bâtiment.

Yoh wrote:

Pour information, pour corriger cela, il faut annuler la construction en cours et construire un autre bâtiment.

la solution , serait aussi au dev de faire leur boulot , et la aussi modifier le code ...

Yoh wrote:

Pour information, pour corriger cela, il faut annuler la construction en cours et construire un autre bâtiment.

oui oui mais ça fait perdre un temps fou.

C'est un des bug typique qu'une maj du style devrais corrigé.

Everrr wrote:

la solution , serait aussi au dev de faire leur boulot , et la aussi modifier le code ...

Quelle idée saugrenue

Yoh wrote:

Quelle idée saugrenue

Tout autant que ta réponse , mais bon la rentabilité avant tout , c'est vrai que corriger un bug existant depuis des années ne devrai pas être corriger

Bon ça se fight sur bermuda histoire d'avoir des retours de RC ?