Page Neopolis de Vincent Lefèvre

Ceci est ma page sur le jeu Neopolis, basé sur la géolocalisation et s'inspirant de Monopoly. Il a été créé par Ben Kaltenbaek, Roland Lamidieu et Lucas Odion, et lancé à Lyon en mars 2019 sous le nom Metropolis, avant d'être renommé en Neopolis en juillet 2019.

J'ai participé aux parties suivantes:

J'ai aussi trouvé une explication du bug d'affichage du pourcentage des bénéfices, présent dans les parties de 2019-08 à 2019-11, et corrigé pour la partie de 2019-12. Et une explication du bug d'arrondi des multiplicateurs, présent dans la partie de 2019-12.

Bêta d'août 2019 à Lyon

Cette première bêta sous le nom Neopolis a été lancée le 31 juillet 2019 à Lyon et à Marseille et s'est terminée le 1er septembre. J'ai participé à Lyon, où il y avait plus de 1000 joueurs (peut-être même plusieurs milliers), et j'ai terminé très largement 1er.

Pour aller ramasser des pièces et des cartes, j'ai fait plus de 250 km à vélo (traces GPS) et aussi pas mal de marche à pied. À cette occasion, j'ai découvert de nouvelles pistes cyclables, en particulier celle très agréable qui longe la voie du tramway T4 (notamment la partie entre la Manufacture des Tabacs et la rue de l'Épargne, juste au nord de l'avenue Berthelot):

[piste cyclable] [piste cyclable] [piste cyclable] [piste cyclable] [piste cyclable]

J'avais assez bien commencé, en atteignant la première place le 4 août, et ensuite, l'argent gagné m'a permis de racheter de plus en plus de bâtiments aux enchères. J'ai ainsi terminé avec 209 bâtiments! La liste, par ville, puis par ordre de construction ou d'achat aux enchères, tels qu'ils sont nommés dans le jeu:

Note: un (+) dans la liste ci-dessus indique un bâtiment culturel spécial.

En résumé, plus j'avais d'argent, plus je gagnais d'argent, et plus mon score (correspondant en gros à l'argent gagné) augmentait. Vers la fin de la partie:

[un de mes bâtiments] [ma fiche] [ma fiche] [classement final]

Classement final des 100 premiers:

  1. vinc17 (343270518)

  2. Anthony (80491357)

  3. Chouche (60911623)

  4. sanh (44226795)

  5. gg625969 (40853362)

  6. conquerant (40723959)

  7. Dehoussable (39382917)

  8. Juninho (35746446)

  9. Nep (33225079)

  10. mens (32890137)

  11. SunshiN (32080392)

  12. Soif (28889615)

  13. Emm (27157343)

  14. m4arm (26598779)

  15. sebastianfdez (26595302)

  16. DonPatata (24954007)

  17. Mouth (24781289)

  18. Pyrrhus (19997246)

  19. AllStarz69 (19192893)

  20. Carpette (18258107)

  21. Anicky (17050456)

  22. Waen (15469397)

  23. roiLeo (14686397)

  24. RonWood (13689900)

  25. franzp (12228315)

  26. Angelo (12211801)

  27. aub (12020816)

  28. Yelfog (10837681)

  29. kik (10516320)

  30. Biscione (10501755)

  31. maxtav (9569689)

  32. minouxos (9314271)

  33. Darkashara (9017962)

  34. Enly (8295732)

  35. Floris (8136122)

  36. kataco (7363231)

  37. Mickael (7231924)

  38. Picol (7194783)

  39. NEM (6979887)

  40. johanna (6838816)

  41. yohanarchiste (6828264)

  42. juju (6470240)

  43. Mym69 (6305285)

  44. djebou (5717076)

  45. haloxis (5447084)

  46. adi (5216525)

  47. Tamia (5140064)

  48. Gary (5002999)

  49. Derass (4822898)

  50. elastella (4604042)

  51. pioupiou67 (4556417)

  52. Gossbust (4266999)

  53. zaze69 (4256390)

  54. Kleinast (4180107)

  55. KylarThaddeus (4164226)

  56. tade42 (4145366)

  57. Ai07 (4040804)

  58. 007 (3999465)

  59. Bab (3979428)

  60. jownoo (3940286)

  61. Davets (3914658)

  62. LMDG (3852421)

  63. Ezeldaa (3776320)

  64. manonti (3716340)

  65. mtj (3547391)

  66. krinscal (3472436)

  67. Dodojudo69 (3386014)

  68. mae (3375049)

  69. delph27 (3332584)

  70. Castalantoine (3316698)

  71. Maimod (3246177)

  72. tyty (3228578)

  73. XvKsl (3215182)

  74. hayuda (3195333)

  75. ElMacho69 (3164135)

  76. Absolutvero (3093936)

  77. Mappy (3060599)

  78. Fif (3022645)

  79. Tom65380 (2991004)

  80. Chris (2892864)

  81. Delfin (2635899)

  82. guilainch (2622872)

  83. dadoume (2606548)

  84. Imperia (2521344)

  85. tzi (2467072)

  86. YoruNoHikage (2371858)

  87. sofaws (2370708)

  88. Touklakos (2328977)

  89. Ididber (2300992)

  90. Prisca (2297896)

  91. Leo (2211128)

  92. HUEXTRAT (2206145)

  93. HelloPomyx (2153620)

  94. Lau (2140799)

  95. Ophelie (2032571)

  96. GrandGaillard (2027945)

  97. Yoc (2003742)

  98. Xav (1981304)

  99. Antoine (1967322)

  100. pbx (1902450)

Partie d'octobre 2019 à Lyon

Il s'agissait du lancement national, dans plusieurs villes de France, avec une limite de 500 joueurs par serveur (dans une même ville, un nouveau serveur est lancé lorsque cette limite est atteinte). J'ai participé à Lyon (serveur principal) et j'ai terminé 3e.

Le principal changement est le nombre beaucoup plus important de pièces et de cartes qu'on pouvait ramasser dans une zone donnée, avec deux conséquences: d'une part, le ramassage (farming) prenait un temps considérable, et d'autre part, les revenus des bâtiments possédés ne comptaient quasiment plus; cela semblait d'ailleurs être le principal reproche fait par les joueurs. J'ai eu nettement moins de plaisir à jouer à cette partie.

Autre changement important: pour pouvoir obtenir un nouveau bâtiment au-delà de la limite initiale, il faut acheter un titre de propriété, dont le coût augmente de manière exponentielle. Il était donc impossible d'obtenir un très grand nombre de bâtiments comme j'avais pu le faire à la bêta d'août. J'ai terminé avec 16 bâtiments (les autres joueurs en avaient tous moins, mais avec des bâtiments de plus haut niveau que les miens).

Dans certaines villes, il y a eu de la triche manifeste, mais apparemment pas à Lyon.

Le premier à Lyon a obtenu son score notamment grâce à de longs trajets en voiture, avec ses enfants qui ramassaient; d'autres joueurs faisaient cela en train. Bref, l'intérêt est très limité. Une suggestion faite par plusieurs joueurs: empêcher ou limiter la collecte en déplacement.

[un de mes bâtiments] [classement final]

Classement final des 9 premiers:

  1. scetnoly (58.7M)

  2. Totostat (38.2M)

  3. vinc17 (34.2M)

  4. Conquerant (24.8M)

  5. Max (24.6M)

  6. Mallo (24.4M)

  7. Soif (23.9M)

  8. chaloom (22.9M)

  9. JeanGreggy1er (21.2M)

Une stratégie: cacher ses revenus

Dans le même temps, à la partie d'octobre 2019 à Paris, il s'est passé quelque chose d'intéressant tout à la fin. Voici un message posté sur Discord (légèrement édité):

Est-ce que vous trouvez ça normal que quelqu'un fasse +11M en 3h?

Je m'explique. Sur le serveur Paris, moi et un autre joueur on a toujours était en mode coude à coude sur la première place. Ce matin en me levant j'avais 4M d'avance sur lui, et là après passage de tour il a 6M de plus que moi. Je trouve ça un peu abusé mais comme je suis biaisée je voudrais votre avis.

La stratégie révélée par le joueur était en fait de ne pas récupérer ses revenus vers la fin, ce qui a surpris tout le monde. Cela fait un manque à gagner temporaire (il est impossible de se servir de cet argent en attente), mais cela permet de cacher le score que l'on devrait avoir, le score correspondant à l'argent gagné (hors vente des bâtiments aux enchères).

Il est possible d'avoir une vague idée des revenus cachés d'un joueur en suivant sa fiche personnelle et l'évolution du score du joueur: on a sa liste de bâtiments avec leur niveau (et un peu plus d'information, difficile à suivre). Mais je pense qu'il est impossible d'obtenir quelque chose de précis. Tout au plus, on peut deviner que le joueur n'a pas récupéré ses revenus, jusqu'à ce que son score fasse un bond.

Partie de novembre 2019 à Lyon

Nouveautés:

Nous faisons le même reproche que sur la partie précédente: le farming prime sur la stratégie, et les meilleurs sont donc ceux qui passent du temps à collecter des pièces et des cartes, et ceci, sans même privilégier la marche ou le vélo, qui sont même des moyens désavantagés par rapport à des déplacements rapides (voiture, train). Voir par exemple ce que dit le joueur qui a terminé premier à Lyon en octobre (extrait du chat):

[texte de scetnoly sur le farming]

[classement final]

J'étais deuxième la plupart du temps: du 2019-11-06 au 2019-12-01, sauf 3 jours en milieu de partie, où j'ai dépassé le premier, qui était coincé dans un lieu isolé. Vers la fin, nous avons tous les deux attendu avant de récupérer nos revenus, pour cacher un peu notre progression. Et j'ai profité d'un aller-retour Lyon-Toulon en train pour farmer, ce qui a permis de rattraper mon retard; c'est le moment le plus intéressant, à cause de l'inflation: la valeur des pièces a augmenté, ainsi que le niveau de mes bâtiments. J'ai aussi farmé les deux derniers jours (week-end juste avant la fin de la partie). Entre temps, le premier avait récupéré ses revenus à un moment, suite à une fausse manip. Résultat: j'ai fini premier avec 24.3M, le deuxième terminant à 24.0M. C'était serré!

Classement final des 9 premiers:

  1. vinc17 (24.3M)

  2. Dcv (24.0M)

  3. CosaNostraLyon (10.9M)

  4. caro (9.0M)

  5. Log4nz (7.8M)

  6. Adi (7.8M)

  7. Tromba (7.6M)

  8. jownoo (7.2M)

  9. Nikyo (6.9M)

Bug d'affichage du pourcentage des bénéfices

À l'aide de certaines cartes, on peut augmenter le revenu de base d'un bâtiment (par tour et par visite) de 10% ou de 50%, et ces augmentations sont cumulables. Le pourcentage des bénéfices est donc un multiple de 10. Cependant, j'ai remarqué que certaines valeurs affichées sur la fiche du bâtiment sont incorrectes: le pourcentage affiché est inférieur de 1% par rapport à la vraie valeur. Au moins les pourcentages 230%, 460% et 510% sont affectés, les valeurs affichées étant respectivement 229%, 459% et 509%:

[bâtiment avec pourcentage de bénéfices affiché: 229%] [bâtiment avec pourcentage de bénéfices affiché: 459%] [bâtiment avec pourcentage de bénéfices affiché: 509%]

Note: la première fiche provient de la partie du 2019-08 et les deux autres de la partie du 2019-11.

Une explication peut être la suivante. Je pense que l'application divise le pourcentage par 100, et remultiplie la valeur obtenue par 100, ces deux opérations étant effectuées en virgule flottante, probablement en double précision (format IEEE 754 binary64), qui est le format usuel. Ces deux opérations sont donc arrondies, et le résultat peut donc être sensiblement différent de l'entier de départ. Si ce résultat est converti à l'entier le plus proche, alors on obtient forcément le pourcentage correct (puisque l'erreur d'arrondi est petite par rapport à 0.5). Mais si ce résultat est arrondi en tronquant, qui est généralement la règle de conversion en entier dans les langages de programmation, alors cela pourrait expliquer pourquoi certaines valeurs sont inférieures d'une unité. Le petit programme C suivant affiche, pour chaque cas erroné parmi les bénéfices de 10% à 1600%, l'entier de départ, l'entier calculé par cette méthode, et la valeur flottante avant conversion à un entier.

#include <stdio.h>

int main (void)
{
  for (int b = 10; b <= 1600; b += 10)
    {
      double d = (b / 100.0) * 100.0;
      int i = (int) d;
      if (i != b)
        printf ("%4d %4d (%.20g)\n", b, i, d);
    }
  return 0;
}

Lorsqu'on exécute ce programme, on obtient:

 230  229 (229.99999999999997158)
 410  409 (409.99999999999994316)
 460  459 (459.99999999999994316)
 510  509 (509.99999999999994316)
 820  819 (819.99999999999988631)
 870  869 (869.99999999999988631)
 920  919 (919.99999999999988631)
 970  969 (969.99999999999988631)
1020 1019 (1019.9999999999998863)

Parmi les 4 premiers cas erronés, on retrouve bien les 3 que j'avais remarqués. Noter que je n'ai pas testé tous les pourcentages dans Neopolis (les cartes, il faut aller les chercher…), mais il semble que 230 soit effectivement la plus petite valeur affectée par le bug d'affichage. Je n'avais alors pas encore d'information sur le cas du 410. Le lendemain (2019-11-04), j'ai pu atteindre 410%, et cette valeur est bien affectée par le bug, avec donc 409% affiché:

[bâtiment avec pourcentage de bénéfices affiché: 409%]

À la fin du mois, j'ai pu aussi vérifier que les pourcentages 820%, 870%, 920%, 970% et 1020% sont aussi erronés:

[bâtiment avec pourcentage de bénéfices affiché: 819%] [bâtiment avec pourcentage de bénéfices affiché: 869%] [bâtiment avec pourcentage de bénéfices affiché: 919%] [bâtiment avec pourcentage de bénéfices affiché: 969%] [bâtiment avec pourcentage de bénéfices affiché: 1019%]

Bug d'arrondi des multiplicateurs

En décembre 2019, un nouveau bug lié aux multiplicateurs est apparu. Lorsqu'on possède n bâtiments de même type, les revenus associés sont normalement multipliés par 1 + (n−1)/10. Ainsi, lorsqu'on possède 8 bâtiments de même type, le multiplicateur associé devrait être 1.7, mais ce qui est affiché est 1.7000000000000002. De même, lorsqu'on possède 15 bâtiments de même type, le multiplicateur associé devrait être 2.4, mais ce qui est affiché est 2.4000000000000004. Ce sont les deux seules valeurs incorrectement affichées jusqu'à 16 bâtiments de même type. Cf images ci-dessous (j'ai repris la seconde sur Discord: source).

[multiplicateur affiché: 1.7000000000000002] [multiplicateur affiché: 2.4000000000000004]

J'ai trouvé que lorsqu'on utilise le code 1 + i * 0.1 où en interne, les calculs sont faits en double précision (format IEEE 754 binary64), on obtient le comportement observé. Attention! i * 0.1 n'est pas équivalent à i / 10, car dans le premier cas, 0.1 est converti en binaire, avec une erreur d'arrondi (car contrairement à 10, 0.1 n'est pas représentable exactement en base 2 avec une précision finie).

Cela peut être testé avec le programme Java suivant.

public class multiplicateurs
{
  public static void main(String[] args)
  {
    for (int i = 0; i <= 15; i++)
      {
        double x = 1 + i * 0.1;
        System.out.println("x = " + x);
      }
  }
}

On obtient effectivement:

x = 1.0
x = 1.1
x = 1.2
x = 1.3
x = 1.4
x = 1.5
x = 1.6
x = 1.7000000000000002
x = 1.8
x = 1.9
x = 2.0
x = 2.1
x = 2.2
x = 2.3
x = 2.4000000000000004
x = 2.5

Une solution serait d'utiliser le code (10 + i) / 10.0, car seule la dernière opération (la division) est ici arrondie, ce qui donne donc l'arrondi correct de l'expression mathématique du multiplicateur.

Note: j'avais commencé par écrire un programme de test en langage C en utilisant GNU MPFR (je ne programme pas en Java), mais j'ai découvert à cette occasion un bug dans la fonction mpfr_printf (et trouvé la cause de ce bug), empêchant de montrer le comportement observé.

[HOME] [BACK]

Powered By...? (http://www.vinc17.org) Powered By...? (https://www.vinc17.net) Valid XHTML 1.0!
Dernière modification:

Page générée à partir du fichier neopolis.fr.xml le 2024-03-17 par xsltproc (using libxml 20914, libxslt 10135 and libexslt 820).

Note: cette conversion à partir de fichiers DocBook est toujours expérimentale; merci de me signaler tout problème.

webmaster@vinc17.org