GPL AI T LE FEVRE Page 1 GRAND PRIX LEGENDS ARTIFICIAL INTELLIGENCE TUTORIAL LEE BOWDEN REVISION 4.0 - JANUARY 2006 Ed_FR 1.0 (novembre 2007) pour tous les simracers francophones. L'être humain croira toujours que plus le robot paraît humain, plus il est avancé, complexe et intelligent. Isaac Asimov Traduction librement adaptée : Tristan LE FEVRE Relecture et conseils : Frank Verplanken - Pierre-Henri Paulet Autorisation : Lee Bowden Illustration couverture : Hervé Nicolas Illustrations « texte » : sites database F1 GPL AI T LE FEVRE Page 2 GRAND PRIX LEGENDS ARTIFICIAL INTELLIGENCE TUTORIAL LEE BOWDEN REVISION 4.0 - JANUARY 2006 INTRODUCTION Bienvenue au tutorial d'Intelligence Artificielle [AI] de la simulation de courses de formule 1 Grand Prix Legends [GPL]! Ce petit fascicule constitue la contribution de Lee Bowden pour expliquer le fonctionnement de l'Intelligence Artificielle de GPL et par suite, les réglages pour rendre les pilotes gérés par l'ordinateur [les AI] plus réalistes et fidèles à leurs modèles originaux. Pour ceux d'entre nous qui ne concourent pas «on_line» les AI sont nos seuls compétiteurs. Aussi, produire des AI plus intéressants rendra notre utilisation de GPL encore plus excitante. Le fascicule est divisé en 7 parties. La première explore les AI en détail. Nous verrons quels fichiers éditer pour ajuster les paramètres d'AI. Nous apprendrons comment chacun des paramètres intervient sur les temps au tour des pilotes AI, aussi bien en qualification qu'en course. Une analyse de la modélisation par GPL des performances des voitures est également incluse. Ensuite, nous explorerons une méthode d'ajustement des paramètres d'AI afin que les pilotes se comportent comme nous le souhaitons en termes de performances. Enfin, nous verrons la meilleure technique pour contrôler la vitesse globale des AI de telle sorte que vous puissiez faire effectivement la course contre eux, voire la gagner, ceci quel que soit votre niveau de pilotage! La Partie II décline des méthodes pour quantifier la performance réelle historique d'un pilote. Nous jetterons aussi un oeil rapide sur les travaux antérieurs comparables d'autres chercheurs. La Partie III applique les leçons de la Partie I aux exigences de performance dérivées de la Partie II pour définir les nouveaux réglages des pilotes AI. La Partie IV teste les nouveaux réglages définis pour les valider. Deux méthodes d'ajustement des AI, pour qu'ils se qualifient en cohérence avec leur historique réel, sont présentées. Les Parties V et VI appliquent ces mêmes méthodes respectivement aux saisons 1965 et 1969 (mod65 et mod69).. Enfin, la Partie VII s'intéressera, pour la première fois, à la gestion de la fiabilité des voitures par l'Intelligence Artificielle de GPL. Seront examinés les paramètres qui peuvent être ajustés pour modifier la fiabilité d'une auto. Cette partie fournit une méthode pour ajuster les risques de défaillance ou de mauvais fonctionnement en cohérence avec les monoplaces originales pour obtenir des taux de défaillances similaires. L'auteur remercie en particulier deux chercheurs qui l'ont inspiré par leurs travaux antérieurs d'exploration du fonctionnement de l'Intelligence Artificielle de GPL, à savoir : David Wright, du site http://fp.gplegends.plus.com Ondrej Haderka – alias Kuratko – du site http://gplseasons.euweb.cz/index.htm, ainsi que Stefan Magnusson – alias Nenne – du site http://gplpp.com, avec lequel il collabora sur 2 utilitaires GPL (GPL Sound Player et GPL Image Viewer), sans qui rien n'aurait été possible. Alors, allons–y ! C’est parti pour un voyage semé de défis, mais si excitant ! NDLT: a/ Le fichier original de Lee Bowden est disponible à cette adresse : http://gplpp.com/index.htm?track=piclong (puis Utilities , 6 Lee and Stephan) b/ Pour toute information sur l'AI en général se reporter par exemple à l'article de « wikipedia » http://fr.wikipedia.org/wiki/Intelligence_artificielle GPL AI T LE FEVRE Page 3 PART I TESTS OF GPL’S AI PARAMETERS METHODOLOGY GPL AI T LE FEVRE Page 4 TESTS OF GPL’S AI PARAMETERS METHODOLOGY Au cours des différents chapitres, référence sera faite aux fichiers ".ini" qui ne sont rien d'autres que de simples fichiers textes. Ces fichiers peuvent être édités avec tout programme idoine, tel que Notpad, Wordpad etc. pour y introduire les modifications souhaitées (le programme GPL AI Manager développé par Peter O'Connor, n'est pas conseillé en raison de bugs identifiés). Notez que vous devez sauver ces fichiers comme de simples fichiers texte, sans formatage même s'ils ont des suffixes ''.ini''. La méthode pour tester l'influence des paramètres AI sur les performances des pilotes est simple, mais prend beaucoup de temps même avec un PC rapide : modifier un réglage à la fois, lancer une session de qualification et/ou une course GPL, puis enregistrer les résultats obtenus... Simple mais aussi extrêmement monotone... Non recommandé à moins d'avoir beaucoup de temps libre ! Pour commencer, le fichier par défaut ''gpl_ai.ini'' du programme original GPL est modifié pour utiliser les réglages suivants: 1. npt_override = 1.00. Ce réglage à 1.00 passe outre l'historique de pilotage du joueur (vous !) de façon à obtenir des résultats consistants (robustes, dans le sens reproductibles, invariants). 2. disable_random_modifiers = 1.00. GPL.exe applique des modifications aléatoires aux paramètres des pilotes lors d'une qualification ou d'une course. Cette configuration rend GPL plus intéressant et surprenant à jouer mais créerait des perturbations pour notre propos en renvoyant des résultats inconstants... Par conséquent cette fonction est désactivée durant nos essais. GPL.exe incluant aussi d'autres variables aléatoires non maîtrisables, nous éliminons et rejouons les tests qui donnent des temps au tour très différents de résultats antérieurs. 3. override_difficulty_hype = 1.00. GPL.exe modifie le paramètre d'exagération (« hype ») selon le réglage novice, intermédiaire ou pro de la simulation. Réglé à 1.00 ce paramètre bloque cette fonction ce qui permet d'obtenir des résultats consistants (stables). 4. n_ai_cars = 2. Lorsque GPL est lancé, on peut normalement définir de 5 à 19 le nombre de pilotes adverses. Non nécessaire au cours de cette étude et consommateur de temps de faire tourner 19 pilotes ! Ainsi réglé, on impose de fait le nombre de pilotes à 2. (Pour que le programme tourne le minimum est de 2 pilotes, sinon nous l'aurions réglé à 1 !). Ensuite, le fichier 'driver.ini' est modifié pour que Jim Clark, en tête du fichier, soit utilisé comme pilote de référence, car Jim Clark pilote la Lotus, monoplace de référence, la plus rapide de toutes. (Nous aurions tout aussi bien pu choisir Graham Hill mais Clark apparaît en tête de liste des pilotes : ainsi il n'est jamais éliminé d'une course lorsque l'on réduit le nombre de pilotes). Puis les paramètres de pilotage de Clark tels que : agressivité ('agression'), vigilance ('alertness'), expérience, exagération ('hype'), rapidité ('quickness'), souplesse ('smoothness'), qualification, 'magic_grip', et 'global_hype_scaling' sont réglés chacun à une valeur de 1.00. Clark est maintenant notre conducteur de référence et tous les résultats seront mesurés par rapport à cette référence. Une fois la performance du pilote de référence enregistrée, nous commençons alors à modifier les paramètres de pilotage, un par un, jusqu'à identifier leur influence sur les temps de qualification et les temps en course. CAR PERFORMANCE Chaque voiture modélisée par GPL fonctionne différemment. Ceci est à mettre à l'actif du réalisme des travaux de l'équipe de conception de Papyrus, et rend la simulation beaucoup plus passionnante et excitante pour le joueur. Après les avoir toutes conduites, il apparaît clairement combien elles diffèrent toutes. Elles se comportent et accélèrent/décélèrent différemment. L'Intelligence Artificielle des autos fonctionne donc différemment. On ne peut définir si ces différences résultent de plusieurs caractéristiques qui les distinguent (facteurs tels que puissance, maître couple, suspensions, etc.) ou bien s'il s'agit plutôt d'un simple facteur global ("fudge factor"). En tout cas, ces différences doivent être prises en compte pour comparer les performances historiques des vrais pilotes et pour définir les paramètres appropriés du pilote dans le fichier 'driver.ini'. Sans quoi, impossible d'obtenir la performance désirée. Pour tester la performance de chaque voiture, nous modifions simplement le fichier 'driver.ini' pour que le pilote leader de chaque auto ait ses paramètres propres réglés à 1.00. En d'autres termes, on installe le pilote de référence dans chacune des 7 monoplaces. Les différences obtenues mesurent alors les différences de performances des voitures et non des pilotes. Pour compliquer le sujet, chaque voiture se comporte, en relatif, différemment selon la piste. Par conséquent il est nécessaire de tester chaque voiture sur chaque circuit, et d'enregistrer sa performance relative vis à vis de la plus rapide, normée à 1.00, puis de moyenner les résultats de toutes les pistes. Papyrus utilisa le circuit de Rouen pour le GP de l’A.C.F. alors que celui-ci s'est tenu au Mans, sur le Bugatti. De ce fait cet add-on 'Le Mans Bugatti' est aussi utilisé pour comparer les performances des bolides. GPL AI T LE FEVRE Page 5 Le graphique suivant indique les performances relatives de chaque F1 pour chaque piste, incluant le Bugatti. La table suivante compare les moyennes relatives de chaque auto telles que modélisées par GPL. La Lotus, la plus rapide du lot, sert de référence et est normée à 1.000. Les performances des autres voitures sont exprimées par rapport à cette référence (valeurs relatives par rapport à la Lotus), ce qui permet d'identifier facilement les différences de performances. Average Car Performance NB: cette table est comparable aux résultats de Kuratko qui obtint pratiquement les mêmes. La Lotus est la plus rapide, mais l' Eagle est très proche, suivie de près aussi par la Ferrari. La Brabham se situe dans le milieu du paquet tandis que les Cooper, BRM, et Honda se tiennent en retrait. Ces résultats correspondent à ceux obtenus par l'expérience des joueurs au volant des différentes autos. Se rappeler que ces différences sont celles de GPL et non les écarts réels; cependant il apparaît que le modèle Papyrus utilisé pour concevoir cette simulation fut du très bon boulot! AI PARAMETERS Les paramètres d'AI sont contrôlés via le programme 'GPL.exe' et les paramètres 3 fichiers '*.ini' suivants : driver.ini, gpl_ai.ini, track.ini. 1. Le fichier 'driver.ini' contient les paramètres de réglage de chaque pilote. A. Il y a plusieurs réglages divers: 1). team_number — définit la voiture du pilote. Il est ainsi possible d'avoir tous les pilotes sur une même voiture durant une course. Les valeurs sont: 0 = Brabham, 1 = BRM, 2 = Cooper, 3 = Eagle 4 = Ferrari, 5 = Lotus, 6 = Honda 2). team_order—indique la position du pilote dans le team. 3). car_number—indique le numéro de la voiture du pilote qui sélectionne le bon fichier graphique (.mip). 4). first_name— prénom. GPL AI T LE FEVRE Page 6 5). last_name—nom 6). home_town—ville 7). nationality—nationalité 8). helmet_color—couleur de casque 9). bump_order— ordre d'éjection. Lorsque l'on réduit le nombre de pilotes dans GPL, ils sont éjectés dans l'ordre inverse de leur ordre dans la liste du fichier 'driver.ini'. Le dernier pilote est supprimé en premier, etc. 10). starting_grid_seed— effet méconnu. N'influence pas la position sur la grille de départ du tout (!?). 10). photo—sélectionne la photo du vainqueur de la course. B. Les paramètres les plus importants pour contrôler vitesse et comportement du pilote sont a priori : 1). Agressivité (Agression) 2). Vigilance (Alertness) 3). Expérience 4). Exagération (Hype) 5). Rapidité (Quickness) 6). Souplesse '(Smoothness) 7). Qualification (Qualifying) 8). Magic_grip Plus loin, nous montrerons en détail comment chacun de ces paramètres influe sur les temps de qualification et de course. Pour l'instant discutons ces paramètres en termes plus généraux. Premièrement, personne ne sait exactement comment les changements de ces paramètres sont modélisés dans GPL. Certes nous pouvons identifier les effets d'un paramètre sur le temps au tour; mais on ne sait pas comment ces changements affectent le style de pilotage. Accroître l'Exagération (« hype ») améliore t il l'utilisation par l'AI des capacités de passage en courbe de la voiture ? On ne peut répondre simplement à ce style de question en modifiant seulement les paramètres et en regardant les temps au tour... En second lieu, nous avons seulement des indices de ce que chaque paramètre affecte. Dans 'gpl_ai.ini' se trouve la section [PARAMETER-SPECIFIC SCALING], qui contient des facteurs d'échelle (scaling factors) appliqués aux paramètres individuels des pilotes et utilisés par le programme 'GPL.exe'. L'examen de ces facteurs d'échelle donne un éclairage sur la façon dont les paramètres des pilotes se comportent. Troisièmement, notons que certains paramètres ont apparemment un effet uniquement sur le comportement en course d'un pilote (tel que l'habileté à passer) tandis que d'autres affectent exclusivement la vitesse pure. La table suivante indique les facteurs d'échelle affectés en fonction des paramètres de pilotage. Si il y a un effet inverse (négatif), des parenthèses sont indiquées. Mais tout d'abord définissons chacun des facteurs d'échelle avant de discuter de l'effet des paramètres les affectant : A. Desired_sep_scaling—modifie la distance longitudinale (devant/derrière) et latérale (côté) que le pilote AI essaie de maintenir entre lui-même et une autre voiture. B. Trans_time_scaling—modifie la durée que l'AI prévoit d'utiliser pour revenir sur la trajectoire (racing line). C. Yaw_k1_scaling—modifie la constante utilisée pour l'accélération de lacet (yaw). Cette constante n'est pas complètement comprise (dans GPL). D. Lookahead_scaling—modifie la durée qui sert d'anticipation à l'AI (équivaut à une distance d'anticipation). E. Nom_traction_scaling—modifie le cercle de traction, nominalement fixé à 1.475 G dans la section [CAR CLASS PARAMETER] du fichier 'gpl_ai.ini'. Discuter de la théorie du cercle de traction dépasse le cadre de ce tutorial mais une simple explication suffit. Exprimé par le grand champion de CanAm, Mark Donohue, le cercle de traction est une représentation graphique, normée en force-G, de ce qu'une voiture peut supporter, combinant 2 accélérations: latérale (passage en courbe) et longitudinale (accélération ou freinage). F. Adj_traction_scaling— modifie le cercle de traction nominal, et ajuste les capacités de passage en courbe. G. Dlong_accel_scaling—modifie l'accélération longitudinale. H. Gearshift_scaling—modifie le temps pour changer de vitesse. Les facteurs d'échelle étant définis, voyons comment les changements des paramètres de pilotage les affectent. A. Agressivité (Agression) – comme il s'agit d'un effet inverse, augmenter l'agressivité raccourcit la distance que l'AI cherche à maintenir avec un adversaire, améliorant ainsi les possibilités de dépassement. Augmenter l'agressivité réduit aussi le temps de retour à la bonne trajectoire. Enfin, elle augmente la constante lié au phénomène de lacet, dont l'effet n'est pas défini. Evidemment, réduire ce paramètre entraîne des effets opposés. B. Vigilance (Alertness) – l'augmenter, réduit la distance inter adversaires, et accroît les capacités d'anticipation. C. Experience – l’augmenter, accroît aussi les capacités d'anticipation ainsi que le cercle de traction nominal. D. Exagération (Hype) – l'augmenter, accroît les capacités d'accélération longitudinales et latérales (cercle de traction). GPL AI T LE FEVRE Page 7 E Rapidité (Quickness) – l'augmenter, accroît le cercle de traction et réduit le temps de changement de vitesses. F. Souplesse (Smoothness) – l'augmenter, augmente temps de retour à la trajectoire, lacet et cercle de traction. G. Qualification – l'augmenter, accroît le cercle de traction et réduit le temps de changement de vitesse. H. Magic_grip – Dans le fichier original Papyrus 'driver.ini', certains pilotes ont un réglage «magic grip», d'autres non. L'objet de ce paramètre n'est pas déterminé; dans ce tutorial ce facteur est ignoré et tous les pilotes sont réglés sur 1.00. Comme déjà indiqué, certains paramètres affectent uniquement le comportement du pilote (tel que l'habileté à dépasser) tandis que d'autres impactent uniquement le temps au tour et la vitesse pure. La table suivante clarifie ces relations : 2. Le fichier 'gpl_ai.ini' contient des réglages qui affectent TOUS les pilotes (simultanément). En plus des facteurs d'échelle mentionnés précédemment, 'gpl_ai.ini' contient des réglages qui influent aussi sur la performance des pilotes AI. Comme indiqué par Kuratko sur son Website, des réglages du fichier gpl_ai.ini ont été discutés sur le forum de GPL. Pour la plupart, ces changements impactent seulement les comportements aux dépassements et non la rapidité intrinsèque. Ce tutorial ne traite lui même que des paramètres du fichier 'driver.ini'. Aucune modification du fichier 'gpl_ai.ini', autre que 'npt_override' n'a été testée. Par conséquent, si vous le faites, c'est à vos propres « risques »! A ce jour, les changements introduits sont : A. base_race_start_hiatus = 25.00 (par défaut 18.0) – régit le temps de réaction au départ de la course. Typiquement, les AI démarrent trop vite avec le réglage par défaut. Augmenter ce réglage les ralentit, pour que le joueur (c'est vous!) puisse se maintenir au contact. Comme pour tous les paramètres « temporels » de GPL, celui-ci est réglé en unités 'ticks'. Dans GPL un 'tick' vaut 1/36ième de seconde (36 images par secondes maximum d'affichage dans GPL). B. attempt_outbrake_dlong_sep = 25.00 (par défaut 12.4104). Les AI doivent être à moins de cette distance équivalente pour pouvoir passer au freinage la voiture qui les précède. C. auto_blocker_line_speed_pct = 0.93 (par défaut .74). Sauf erreur, les AI comparent la vitesse de la voiture qui précède à la leur; si le ratio est inférieur au réglage indiqué, alors la voiture qui précède est considérée comme un « bouchon » et les AI sont moins agressifs pour la passer. Avec le réglage par défaut, les AI ont tendance à traîner derrière des voitures beaucoup plus lentes pendant de longues périodes sans passer. D. being_squeezed_speed_coeff = 0.80 (par défaut: 0.85). Ceci rend les AI moins agressifs à défendre leur position. Plus le coefficient est faible, plus les AI , étant passés, donneront du champ à la voiture qui les double. E. straightaway_pass_speed_coeff = 1.0001 (par défaut : 0.000). L'effet de ce paramètre est incertain; des « posts » sur GPL forum indiquent que des valeurs au dessus de 1.00 peuvent causer problème sur certains circuits. Quelques essais de Lee Bowden confirment ce fait. Lee Bowden ne recommande donc pas de changer le réglage par défaut (0.000). F. braking_efficiency_coeff = 0.95 (par défaut:0 .80). Des pilotes AI (Surtees sur Honda en particulier) ont tendance à vous « suppoter » au freinage. Augmenter ce facteur limite ce risque, améliorant l'habileté de toutes les AI voitures. Kuratko a réalisé un très gros travail de tests et de revue des effets des diverses erreurs de pilotage et défaillances mécaniques sur la performance AI. Lee Bowden renvoie donc sur ces points vers les travaux de Kuratko. 3. Les fichiers 'track.ini' (il y en a un par piste) contiennent des réglages propres à chaque piste. Dans chaque section [STATISTICS] de fichier 'track.ini' se trouve un réglage 'reference_value setting'. Cependant, changer cette valeur ne modifie pas les temps au tour. Il y a une méthode pour rendre tous les AI plus lents ou rapides pour toutes les pistes, qui sera vue plus tard. En plus, certaines pistes utilisent des ajustements tels que : track_dlong_sep_coeff, dlong_speed_adj_coeff, and dlong_speed_maximum, pour modifier le comportement et la vitesse des pilotes AI pour prendre en compte les spécificités de ces circuits. Ces paramètres affectent donc seulement ces pistes spécifiques. A. track_dlong_sep_coeff— au-dessus de 1.00, accroît la distance que l'AI tente de maintenir entre les autos. Effet inverse au dessous de 1.00, réduction de la séparation. B. dlong_speed_adj_coeff— Au-dessus de 1.00, accroît la vitesse des pilotes AI. Inversement au dessous de 1.00. C. dlong_speed_maximum—règle la vitesse maximale, après prise en compte de tous les facteurs d'échelle. Ce paramètre est réglé en unité « mètre par tick ». Un réglage à 1.00 induit une vitesse de pointe de 80 mph (130 km/h), un réglage à 2.00 conduit à une vitesse double de 160 mph, etc. 4. Le fichier 'gpl.exe' contient quant à lui le code qui fait tourner le programme GPL. Evidemment, il contient aussi beaucoup de valeurs inconnues, qui conditionnent le fonctionnement de l'Intelligence Artificielle de GPL. Des modifications du code ne sont possibles qu'au moyen d'un patch logiciel (tel les MOD65 ou MOD69 par ex.) ou par un éditeur hexadécimal. On ne GPL AI T LE FEVRE Page 8 peut donc changer ces valeurs facilement, et on comprendra que ce tutorial ne couvrira pas le changement de ces données ! TESTS OF AI QUALIFICATION PERFORMANCE Lee Bowden a conduit toute une série d'essais pour examiner l'effet des modifications apportées aux paramètres de pilotage concernant la performance en essais de qualification. Tous les tests furent réalisés avec le pilote de référence dans la Lotus sur la piste de MONZA. Par convention, pour toutes les tables ou graphes présentés, la performance relative la plus élevée est définie comme étant la vitesse la plus élevée ou bien le temps au tour le plus faible. La table suivante synthétise les résultats de ces essais. PERFORMANCE RELATIVE EN QUALIFICATION En résumé les 3 seuls paramètres de pilote qui affectent la performance en qualification sont présentés graphiquement ci- après : Quickness (RAPIDITE) : effet modéré. Qualifying (QUALIFICATION) : effet modéré. Hype (EXAGERATION) : effet FONDAMENTAL sur la perfo. C'est LE paramètre majeur de la vitesse d'un pilote AI. GPL AI T LE FEVRE Page 9 TESTS OF AI RACE PERFORMANCE Lee Bowden a également conduit dans les mêmes conditions, une série de tests pour étudier l'effet des modifications de ces mêmes paramètres sur la performance en course. Noter que les effets sont estimés sur la perfo en course hors effet de compétition. Ceci ne signifie donc pas que ces modifications n'affectent pas le comportement et la performance lors de courses contre d'autres compétiteurs. La table suivante synthétise les résultats de ces essais. Performance relative en course En somme, les seuls paramètres qui affectent la performance en course (hors compétition) sont l'Exagération (« hype ») et la Rapidité (« quickness »). Les autres paramètres n'ont pas d'effet quelconque. Comme déjà mentionné, ce n'est pas parce qu'un paramètre n'affecte pas cette perfo en course sans compétiteurs qu'il n'aura pas d'effet sur le comportement du pilote face à d'autres. En effet nous avons vu que « aggression », « alertness », « experience », et « smoothness » affectent probablement le comportement d'un pilote pour doubler ou poursuivre les autres. Comparer ces résultats à ceux de la perfo en qualification indique en outre que les effets sont exactement identiques (!), à l'exception du paramètre «qualification» qui, évidemment, ne joue pas sur la perfo en course. TESTS OF HYPE VERSUS QUICKNESS ON RACE PERFORMANCE Jusqu'ici, seuls les effets de modification d'un paramètre à la fois ont été considérés. Que se passe-t-il lorsque deux paramètres différents sont modifiés ? Tester toutes les combinaisons de variation de tous les paramètres reste matériellement impossible 7 (NDLT : 5^ combinaisons soit 78125 essais !). Cela prendrait littéralement une éternité. Cependant, nous savons déjà que seuls 2 ou 3 des 7 facteurs ont un effet. Par conséquent le nombre de tests combinant 2 à 2 ces paramètres reste acceptable et ne prendra pas trop de temps. La table et les graphes qui suivent montrent ainsi l'effet des variations combinées de Exagération (Hype), Rapidité (quickness) sur la perfo en course Performance en Course_ Hype Versus Quickness GPL AI T LE FEVRE Page 10 En jouant à la fois sur Exagération et Rapidité (hype & quickness), on peut ralentir ou accélérer un pilote de -19% à +14% (soit une amplitude de réglage de 33%) pour sa perfo en course (de Quickness=.80 et Hype=.80 jusqu'à Quickness=1.20, Hype=1.20). C'est une gamme énorme d'ajustement qui va bien au-delà des besoins en général. En jouant uniquement sur « Hype », on peut déjà ajuster la perfo de -19% à +12% (Quickness=1.00, Hype=.80 --> 1.20). Avec le paramètre Rapidité seul (Quickness), on ne peut ajuster la perfo en course que de -5% à +1% (Quickness=.80 --> 1.20, Hype=1.00) ce qui est nettement plus réduit, voire insuffisant. La conclusion est qu'il n'est pas nécessaire de modifier les 2 paramètres puisqu'il suffit d'ajuster le paramètre Exagération (hype) pour obtenir la performance en course souhaitée. Pourquoi compliquer la chose en ajustant les 2 paramètres sachant que la modification de la Rapidité (quickness) impacte aussi la performance de qualif.’ ? Il est suffisant de régler la performance en course d'un pilote en utilisant seulement le « Hype » ce qui permet des écarts de -10% à +5% en le variant de -10% à +5%. Pour rendre encore plus facile l'évaluation du réglage selon la performance attendue, Lee Bowden a réalisé une régression statistique (technique mathématique qui consiste à déterminer l'équation de la courbe la plus représentative liant les 2 séries de données) pour relier le paramètre « Hype » et la performance en course. La formule obtenue est la suivante : Hype = 1.056 - (1.355 * Race Performance) + (1.302 * Race Performance ^ 2) Où « Race Performance » est la performance relative en course comparée à la référence. Cette formule de régression est très bien adaptée aux données, le coefficient de corrélation étant de 99.9% ! A titre d'exemple, supposons que vous désiriez un pilote dont la performance soit à 96% de la référence. En substituant 0.960 dans la formule ci- dessus, on obtient le réglage nécessaire d'Exagération (« Hype »), qui serait alors de 0.970. TESTS OF HYPE VERSUS QUALIFYING ON QUALIFYING PERFORMANCE Nous avons vu que les 3 paramètres « Hype », « Quickness », et « Qualifying » seulement ont un effet mesurable sur la perfo en qualif'. Nous avons vu aussi qu'utiliser l'Exagération '(« Hype ») seule fournit suffisamment de possibilité d'ajustement de la performance en course. Par conséquent nous avons besoin de savoir comment faire varier « Hype » et « Qualification » pour contrôler la performance en qualification. La table qui suit présente justement ces effets. Qualification Performance _ Hype Versus Qualification Par exemple, avec un réglage « hype » de 1.10 la perfo en qualif' peut être ajustée de 97.7 % à 108.9% de la référence en jouant sur le facteur « Qualification » de 0.70 à 1.20 Avec un réglage « hype » de 0.80 ou plus bas, on ne peut plus ajuster le temps de qualification par un réglage du facteur « Qualification ». Ainsi, on constate que plus le « hype » est réglé bas moins il y a de possibilité d'ajuster le temps de qualification. Pour les pilotes AI dont la perfo en qualif' est pire que leur perfo en course, vous devriez avoir suffisamment de latitude de réglage; par contre pour ceux qui se qualifient bien mieux que leur perfo en course, il est possible de ne pas disposer GPL AI T LE FEVRE Page 11 de suffisamment de possibilité d'ajustement. Les données présentées par le graphe ci avant sont très intéressantes, puisqu’elles illustrent dans quelle mesure peut varier la perfo en qualif' sur une large plage de variation des paramètres. Cependant on note aussi les inconvénients suivants : La plus grande plage d'ajustement est disponible quand le paramètre « hype » est proche de 1.00. Pour des réglages extrêmes de « hype », la plage de réglage efficace du paramètre « qualification » se réduit. Ainsi, selon le « hype » donné, il y aura ou non possibilité d'améliorer la vitesse d'un pilote. On peut faire se qualifier un pilote beaucoup plus lentement que sa performance en course, mais il est difficile de faire vraiment l'inverse. En raison des résultats assez variés obtenus en fonction de « hype » et « qualification », aucune régression multiple ne fonctionne suffisamment bien pour estimer la performance en qualif'. Il n'y a donc pas de formule simple pour décrire le lien entre la performance en qualif' et le réglage de ces 2 paramètres. A la place, nous devons utiliser la table précédente et procéder par interpolation (c'est ce que l'auteur fait sur la base d'une table plus détaillée que celle présentée). La conclusion de Lee Bowden est que la meilleure approche pour maîtriser les performances des pilotes AI est : 1. d'ajuster « Hype » seul d'abord, pour régler la performance en course, 2. puis d'ajuster le paramètre « Qualifying » pour régler la perfo' en qualif' (sans plus changer le « hype »). TESTS OF CONTROLLING THE AI FIELD’S SPEED Pour rendre la simulation plus excitante, il serait sympathique d'ajuster la vitesse de tous les AI pour que le joueur (c'est à dire vous) puisse faire la course dès le départ. Comme nous le savons tous, GPL est une simulation très difficile. Il faut du temps, de la patience et de la compétence pour bien rouler sur GPL. Certains d'entre nous sont des pilotes plus rapides que d'autres... notamment quand ils commencent à apprendre la simulation. Mais, courir contre les AI peut être frustrant car ils sont invariablement trop rapides pour les débutants. Après plusieurs années, à moins de faire partie des pilotes les plus rapides de GPL, il reste souvent nécessaire de ralentir les AI pour participer à une véritable compétition et pour pouvoir gagner une course!! Aussi, comment faire pour ralentir globalement l'ensemble des AI ? Beaucoup de choses ont déjà été écrites sur le sujet (Cf. GPL forum). Ce qui suit précise la méthode la plus facile pour contrôler la vitesse de l'ensemble des AI, bien que celle ci ne soit pas sans inconvénients. Félicitons à ce propos David Wright, qui fut certainement le premier à découvrir cette méthode. Les résultats et conclusions tirées proviennent en effet des essais antérieurs de David. Tout d'abord, un mot sur la façon dont GPL contrôle la vitesse des AI. A son crédit, l'équipe de Papyrus voulait que les AI ajustent leur vitesse en fonction de la compétence du joueur. Lorsque la vitesse du joueur s'améliorait, les AI devaient aussi progresser, de telle sorte que les AI représentent toujours un challenge pour le joueur, quelle que soit sa rapidité. Malheureusement, Papyrus rendit les AI trop rapides ! Pour voir comment tout ça fonctionne, introduisons le concept du NPT, Normalized Player Time (« temps de joueur normalisé »). Lorsqu'un joueur rejoue à GPL, le programme conserve en mémoire les 10 derniers temps au tour et en prend la moyenne pour définir le NPT du joueur pour une piste donnée. Cette donnée est sauvée dans le fichier 'player.sts' du répertoire du joueur. (N’essayez pas d'ouvrir ni d'éditer ce fichier car il s'agit d'un format propriétaire). Tant qu'un joueur n'a pas réalisé plus de 10 tours, la valeur par défaut du NPT est réglée à 1.20 par le paramètre 'startup_npt setting' du fichier 'gpl_ai.ini'. Evidemment si le temps au tour du joueur s'améliore le NPT baissera. GPL réduira alors les temps de l'ensemble des AI en fonction du propre temps du joueur. C'était une super idée, cependant Papyrus ne l'a pas bien rendue, car certains pilotes sont plus ou moins sensibles au NPT. Pour l'illustrer, Jimmy Clark reste toujours aussi rapide indépendamment de la vitesse du joueur. Pour paraphraser Rhett Butler dans "Gone With The Wind", Clark franchement ne se soucie guère de votre vitesse. Il roule à sa guise, descend des temps incroyables, se bagarre roue dans roue... Apparemment, il n'y a rien que vous puissiez faire à son sujet... ou bien ceci... En plus du NPT du joueur (qui dépend de vous), chaque pilote AI a un paramètre appelé 'global_hype_scaling' réglable dans le fichier 'driver.ini'. Ce paramètre règle la sensibilité du pilote au NPT. Comme attendu, Clark a un réglage incroyablement bas de 0.05 pour ce facteur 'global_hype_scaling' ce qui le rend effectivement invulnérable au NPT d'un joueur. En conséquence, il est toujours aussi rapide pour le joueur novice. Les pilotes AI ayant un réglage élevé de 'global_hype_scaling' sont eux beaucoup plus affectés par le NPT. Avant de regarder les efforts déployés pour contrôler l'ensemble des AI, voyons en détail comment interagissent ces 2 paramètres que sont 'npt_override' et 'global_hype_scaling'. Ceci peut être confus, traitons le. En un mot : 1. Si 'npt_override' = 0.00 (off), alors les AI sont affectés par les modifications apportées au 'global_hype_scaling' et au NPT. C'est normalement le réglage par défaut de GPL. 2. Si 'npt_override' > 0.00 et < ou égal à 1.00, alors les AI ne sont pas affectés par le 'global_hype_scaling', ni le NPT. Les AI sont et restent à fond de leurs possibilités ! (Ils sont à leur niveau de référence). 3. Si 'npt_override' est > 1.00, alors les AI sont affectés des changement du 'global_hype_scaling', mais pas du NPT. Les AI sont ralentis. GPL AI T LE FEVRE Page 12 La table qui suit synthétise ces effets : Armés de cette connaissance, examinons comment maîtriser la vitesse globale des AI. La table suivante présente les valeurs de NPT de testeurs réputés et des valeurs de 'global_hype_scaling' pour Clark, par exemple, utilisées par le passé. Papyrus utilisait un 'npt_override' de 0.00 pour rendre actif l'effet du NPT, mais avec un 'global_hype_scaling' très faible de seulement 0.05 qui rend Clark insensible au NPT d'un joueur. Bonne et mauvaise nouvelle ! Alison Hine, l'un des beta testeurs du programme, découvrit le problème avec cette vitesse par défaut de l'AI et corrigea le 'global_hype_scaling' de Clark à 0.45...une valeur plus raisonnable. Ceci rendit Clark plus sensible au NPT qui le ralentit considérablement. Cependant, chaque 'global_hype_scaling' de chaque pilote devait être ajusté individuellement. Il n'était pas possible d'ajuster la vitesse de l'ensemble des AI en réglant un seul paramètre. Cette méthode était donc un pas dans la bonne direction, mais nécessitait plus de raffinement. C'est alors que David Wright approfondit la relation entre 'npt_override' et 'global_hype_scaling'; il mit au point la méthode de contrôle global de la vitesse des AI. Il régla tous les pilotes avec un 'global_hype_scaling' à 1.00, ce qui les rendit tous également sensibles aux changements de NPT, puis il intervint sur le 'npt_override' pour maîtriser la vitesse globale des AI. Ce fut une grande découverte et ceci reste la meilleure méthode à ce jour ! Toutefois, même cette méthode a un inconvénient, bientôt indiqué. Plus récemment Kuratko utilisa aussi cette méthode. Mais, quel effet obtient-on en ajustant le 'npt_override’ ? La table suivante fournit les temps de qualif' relatifs pour notre pilote de référence quand le 'npt_override' est modifié de 0.80 à 1.20. Et ci-contre le graphique correspondant : En résumé, accroître 'npt_override' au-dessus de 1.00 augmente le temps de qualification dans le même ratio. Par exemple, si le 'npt_override' vaut 1.20, les AI ralentiront de 19.3%. Quand 'npt_override' descend sous 1.00, le temps de qualification se réduit aussi mais plus lentement. Par exemple, pour 'npt_override' à 0.80 (soit -20%) le temps est augmenté seulement de 11.7%. Lee Bowden pense, comme David et Kuratko, que la meilleure méthode pour maîtriser les AI est de régler tous les AI à 1.00 par le paramètre 'global_hype_scaling' et d'ajuster alors le 'npt_override'. Cette méthode fonctionne très bien, mais présente GPL AI T LE FEVRE Page 13 un « brillant » inconvénient : lorsqu'on change le 'npt_override' au-dessus ou au-dessous de 1.00, tous les pilotes ne sont pas également affectés vis à vis de leur perfo en qualif'. C'est un sujet complexe, développé ici. On voudrait, quand on modifie le 'npt_override' que tous les AI accélèrent ou ralentissent dans les mêmes proportions. C'est le cas pour la plupart des pilotes mais pas pour tous ! 1. Les pilotes qui ont un réglage fort en « hype » (1.00 ou plus) avec un réglage faible en « qualifying » (0.90 ou moins) ne ralentissent pas autant que les autres en qualification quand le 'npt_override' est au dessus de 1.00. Ces pilotes se qualifient donc plus haut qu'ils ne le devraient. 2. Les pilotes qui ont un réglage faible en « hype » (< 1.00) avec un réglage fort en « qualifying » (> 1.00) sont plus vites en qualification que d'autres quand le 'npt_override' est réglé au-dessous de 1.00. Ces pilotes se qualifient donc plus haut qu'ils ne le devraient. 3. Apparemment, modifier le 'npt_override' affecte tous les pilotes de la même manière en course. Par conséquent, modifier le 'npt_override' n'affecte pas les positions relatives finales des pilotes. Par exemple la table suivante identifie l'effet d'une modification du 'npt_override' de 0.80 à 1.20 sur la position en qualif' de tous les pilotes. On peut observer que Jackie Stewart, en particulier, marche beaucoup mieux qu'il ne le devrait lorsque le paramètre est augmenté. Ceci se produit parce qu'il a un « hype » élevé (1.004) ET un réglage bas en « qualifying » (0.860). D'autre part, Chris Amon et Pedro Rodriguez marchent mieux quand le 'npt_override' est réduit, en raison de leur réglage faible en « hype » et fort en « qualifying » (1.25). Nota : Lee Bowden expliquera plus loin comment déterminer ces valeurs. Aucune solution n’a été trouvée à ce « problème » lorsque nous utilisons le 'npt_override' pour contrôler la vitesse globale des AI. Il faut donc vivre avec le fait que certains pilotes seront simplement meilleurs que souhaités pendant les qualifications. Heureusement, les temps de course ne subissent pas cette distorsion et les positions finales doivent donc être respectées. GPL AI T LE FEVRE Page 14 PART II QUANTIFYING HISTORICAL DRIVER PERFORMANCE D.GURNEY - SPA GPL AI T LE FEVRE Page 15 PART II QUANTIFYING HISTORICAL DRIVER PERFORMANCE Naturellement, nous avons passé tout ce temps et ces efforts à déterminer les réactions des pilotes [AI] aux modifications de paramètres dans l'espoir de les régler pour qu'ils se comportent autant que faire se peut comme leurs équivalents dans le monde réel. Qu'y aurait il de mieux que l'AI de Jim Clark conduise exactement comme il le fit en 1967 ? En d'autres termes, voici nos objectifs : 1. La performance en qualif' devrait refléter la performance du monde réel. Le temps de qualif’, et la performance relative aux autres, devraient être comparables aux performances originales. 2. La performance en course, idem : le temps de course final devrait être celui réellement enregistré dans le monde réel, ainsi que la position relative des différents pilotes. Il est douteux d'atteindre ces 2 objectifs simplement en modifiant seulement les fichiers 'driver.ini' et 'gpl_ai.ini'. Plus probablement, il faudrait intervenir au sein du code du programme 'gpl.exe' pour faire ce travail parfaitement. Cependant, ce step irait bien au-delà de ce tutorial, et nous nous limiterons à la modification des 2 fichiers '*.ini' (Nota Lee :''façon de dire que je n'ai pas d'indice pour modifier le code !''). Avant de régler les paramètres des AI, il est nécessaire de connaître ce que firent les pilotes réels durant la saison de course 1967. D'une façon ou d'une autre il faut quantifier leur performance. Heureusement, il y a de nombreuses sources d'information disponibles pour obtenir tous les renseignements nécessaires : temps de qualif', position sur la grille, temps de course, position en course. Les sites préférés mentionnés de Lee Bowden : 1. Grand Prix Stats : http://www.f1-stats.de 2. F1 Gamers: http://www.f1gamers.com 3. F1 Database : http://www.f1db.com Papyrus et d'autres chercheurs ajustèrent les paramètres AI selon différentes approches. A titre d'exemple des paramètres pour Jimmy Clark sont présentés par la table ci-dessous : Alison and Nate Hine ont utilisé les réglages originaux de Papyrus mais ont fait varier la vitesse en ajustant uniquement le paramètre 'global_hype_scaling'. David Wright utilisa les réglages d'origine sauf concernant les « hype » (Exagération), « quickness » (Rapidité), et « qualifying » (Qualification). Kuratko fit un pas de plus en ajustant tous les paramètres. Cette table pose quelques questions intéressantes : Comment quantifier le comportement d'un pilote ? Comment régler les paramètres d'un pilote pour refléter sa vitesse et son style de conduite ? Nous savons que Clark était plus rapide que Guy Ligier, mais que savons nous de leurs agressivités respectives ? Comme Kuratko le fit remarquer si justement, nous ne pouvons réellement pas accéder à cette information. Tout ce que nous pouvons faire, est d'approximer la performance d'un pilote avec les contraintes de 'gpl.exe' et notre connaissance limitée de son mode de fonctionnement. Je suis sûr que les concepteurs de GPL se sont débattus avec ces questions aussi. Maintenant, allons y ! Premièrement, quelles sont les données nécessaires pour quantifier les paramètres pilotes ? Plus de données seront collectées, meilleure sera la chance d'en déduire les bons réglages. Typiquement, on peut identifier pour chaque course, ces données : 1. Les temps de qualif' de chacun, 2. La position de qualif' de chacun, 3. Le temps de course du vainqueur, 4. Le nombre de tours du vainqueur, 5. Les temps de course de ceux qui finirent dans le même tour que le vainqueur, 6. Le nombre de tours de retard de ceux qui finirent la course sans être dans le même tour que le vainqueur, 7. La position (classement) de chacun à l'arrivée de la course (pour ceux qui furent classés). En second lieu, définissons une méthode de quantification de la performance en qualif' à partir de ces données. Par convention, le temps de référence (meilleur temps) est normé à 1.00. Les autres pilotes sont comparés en relatif vis à vis de cette référence, par la simple formule suivante : GPL AI T LE FEVRE Page 16 avec : Driver's Time = Temps du pilote Fastest Driver's Time = Temps du pole man Connaissant les temps de qualif' relatifs pour chaque course, la valeur moyenne de toutes les courses (pour chaque pilote) donne la valeur relative annuelle du pilote considéré. Heureusement, ce travail ingrat a déjà été fait par le site « Grand Prix Stats » qui tient un listing des "Average Gap To Pole Position" par pilote pour chaque saison. Pour l'année 1967, Jimmy Clark fut le pilote le mieux qualifié (en moyenne) puisqu'il a un gap moyen par rapport à la super-pole de seulement « 0.638% ». Par conséquent, Jimmy se qualifia en moyenne à « 1- 0.00638= 0.99362 » du temps du pole man (autant dire, c'est bien connu, qu'il fut très souvent le pole man) . 1967 Average Gap to Pole Position 1967 Average Grid Position (en %) Après un peu d'expérimentation, Lee Bowden établit une formule liant la position sur la grille à l'écart ou gap (en %) moyen du temps de la pole. Cette formule, pour 1967, est : Qual. Position = 1.005 - Average Grid Position/200 Si un pilote remporte toutes les poles, il doit avoir une position de qualification de 1.00. En 1967, Jimmy Clark se qualifia en une position moyenne de 2.546, soit à mi chemin entre deuxième et troisième. Substituer cette valeur dans la formule conduit à une valeur de 0.992 quasi-identique au temps de qualification relatif obtenu de 0.994. A partir de là, le temps relatif de qualif' et la position de qualif' sont moyennés pour obtenir la performance globale de qualification : Qual Performance = (Qual Time + Qual Position) /2 On pourrait argumenter qu'utiliser le temps de qualif' seul suffit pour classer les performances de pilotes. Mais Lee Bowden pense que plus on tient compte d'éléments, plus le résultat sera efficace. Dans le cas de Clark sa performance globale de qualif' ressort donc à 0.993 après arrondis. En d'autres termes il s'est qualifié à 99.3% d'un pilote « mythique » qui aurait réalisé les pole positions de toutes les courses de la saison!. Troisièmement, examinons une méthode similaire pour quantifier la performance d'un pilote en course. Malheureusement nous n'avons pas les temps pour tous les pilotes qui finissent la course, seuls sont disponibles ceux qui terminent dans le même tour que le leader. Les autres pilotes qui sont classés à plus d'un tour sont répertoriés comme étant à « tant de tours ». Pouvons nous utiliser ces données ? Lee Bowden estime que oui. Pour le vainqueur, et ceux dans le même tour, nous avons les temps exacts de course. Nous pouvons donc établir un temps GPL AI T LE FEVRE Page 17 moyen au tour du vainqueur. Si un pilote finit un tour derrière le leader, il a mis au moins plus de temps que le leader. Donc nous pouvons simplement ajouter le temps d'un tour au temps du vainqueur pour avoir une idée du temps mis par le pilote pour couvrir la distance totale. En fait, c'est généreux car ce pilote n'a probablement pas terminé juste derrière le leader, mais entre un et deux tours de retard. Par conséquent, ajouter 1.5 fois le temps au tour serait plus approprié. Une approche plus sophistiquée serait de regarder combien de pilotes finissent à un tour et d'en tenir compte. Il est certainement plus réaliste que certains -les derniers- soient plus proches de 2 tours de retard. Par conséquent, si 2 pilotes finissaient à 1 tour, le premier devrait subir une pénalité de 1.33 tour (au lieu de 1.5 quand il est seul) et le second, de 1.66 (au lieu de 1.5). Pour 3 pilotes à un tour, les pénalités seraient respectivement de 1.25, 1.50 et 1.75 tour; etc. en fonction du nombre de pilotes. Le temps de course relatif pour ces pilotes est alors donné par la formule qui suit : Où « Laps Down » est déterminé comme expliqué précédemment. On moyenne alors les temps de course de toutes les courses terminées dans l'année pour chaque pilote. Par exemple, Jimmy Clark finit six courses en 1967 pour lesquelles il obtient un temps relatif de 0.991. En d'autres termes, la moyenne des temps de course (terminées) de Jimmy est seulement 0.92% moins bonne que la moyenne des temps d'un vainqueur mythique de toutes les courses. 1967 Average Race Time 1967 Average Finish Position (en % du vainqueur) Il n'est pas difficile de calculer ces temps pour tous les pilotes « classés » à chaque course. Naturellement ce ne sont que des estimations, mais ce sont de très bons indicateurs de performance en course d'un pilote; sans ces estimations, nous n'aurions eu que les temps des pilotes terminant dans le même tour que le vainqueur. Evidemment, il y a de nombreux pilotes qui n'ont jamais terminé dans le même tour que le vainqueur, donc nous n'aurions eu aucune valeur pour eux ! Un problème avec cette approche est que certains pilotes n'ont pas fini beaucoup de courses. Dan Gurney, par exemple, qui finit seulement 2 courses dans l'année. Dans ce cas on dispose d'un échantillon très limité pour réaliser cette estimation. Une possibilité pour contourner ce manque de données pour certains pilotes est d'analyser les données autrement. Non seulement nous avons les temps de course, mais nous disposons aussi des places (positions), lorsque le pilote est classé. Utilisons alors ces données d'une manière similaire à celle des positions en qualification. Le justificatif pour utiliser la position de GPL AI T LE FEVRE Page 18 fin de course est que les pilotes ne vont pas toujours pied à la planche tout au long d'une course. Ils peuvent aussi conduire juste assez vite pour gagner ou maintenir leur position. Heureusement, le site « F1 Gamers » dispose des listings "Average Finish Position" par année et par pilote, ce qui nous évite de tout calculer. Cette information est précisée dans le tableau précédent (colonne droite). La formule qui donne alors la position relative en fin de course est donnée par: Race Position = 1.01 - Average Finish Position/100 Si un pilote gagnait chaque course, il aurait une valeur de 1.00 pour sa position de course (race position). Par exemple, Jimmy Clark, en 1967, a obtenu une position moyenne de 2.17; par conséquent sa valeur relative pour sa position en course est de 0.988. Ce qui est très comparable à sa valeur de temps relatif en course, qui vaut 0.991. Enfin, on moyenne les deux informations (temps relatif en course et position relative en course) pour obtenir la performance globale en course. Dans le cas de Clark, sa performance en course ressort à 0.990 après arrondis. En d'autres termes, Jimmy courut à 99.0% d'un pilote mythique qui aurait gagné toutes les courses. La formule pour la performance globale en course est : Race Performance = (Race Time + Race Position) / 2 La table suivante montre les performances en qualif' et en course des pilotes réels, estimées par cette approche pour la saison 1967. Les pilotes sont listés dans l'ordre réel obtenu au championnat du monde. 1967 Actual Driver Performance En commentaire, Clark marcha vraiment très fort en 1967 même si il ne gagna pas le championnat ! Il surclassa vraiment d'un poil, Hulme, le champion du monde. Mais la fiabilité de la Brabham fut l'élément décisif pour que Hulme remporte ce championnat là. Notons aussi que Dan Gurney tourna au niveau des meilleurs mais qu'il finit, comme mentionné avant, seulement 2 courses ! La fiabilité de l'Eagle n'était pas au rendez-vous ! En ce qui concerne les qualifications, Clark fut clairement le meilleur : personne ne pouvait se mesurer à Jim dans sa Lotus 49. Voilà... Nous avons vu méthode et formules pour quantifier la performance historique des pilotes réels. Mais nous n'avons pas encore discuté comment utiliser cette information dans GPL. C'est l'objet de la prochaine partie (PART III) ! GPL AI T LE FEVRE Page 19 PART III PUTTING IT ALL TOGETHER Lors des parties précédentes, nous avons vu comment GPL modélise les pilotes AI et comment contrôler dans une certaine mesure leur comportement et leur vitesse. On a développé des méthodes pour quantifier les performances des vrais pilotes, basées sur leur historique. Ici, nous allons mettre tout cela ensemble et montrer comment utiliser la performance historique pour en déduire les réglages des paramètres des pilotes pour qu'ils fonctionnent au plus près de leurs modèles originaux. La 1ère chose à considérer est la façon dont GPL modélise chaque auto. Souvenez vous que chaque voiture possède des performances relatives différentes selon les circuits. Nous avons calculé une performance relative moyenne basée sur les 10 pistes d'origine PAPYRUS plus l'add-on du Mans (Bugatti). Avant de pouvoir assigner des valeurs à nos paramètres de pilotes AI, il faut ajuster les valeurs de performances (en qualif' et en course) à leur voitures. On y arrive en « normalisant » les valeurs vis à vis de la Lotus, prise en référence, arbitrairement égale à 1.00. Ceci est un ajustement important car sinon les pilotes des autres voitures seraient pénalisés. Par exemple, considérons Chris Amon qui pilota pour Ferrari en 1967. La performance de sa Ferrari était seulement de 99.74% par rapport à la Lotus. Or les performances de Amon sont en qualif' et en course respectivement de 0.976 et 0.970. Or nous voulons qu'il ait exactement ces résultats dans la simulation lorsqu'il conduit la Ferrari. Pour normaliser la performance de Chris Amon, on doit donc diviser ses résultats observés par la performance moyenne de sa voiture, soit 0.994, pour identifier sa performance intrinsèque. Cet ajustement permettrait de dire quelle aurait été sa performance s'il avait conduit une Lotus en 1967 ! Dans la simulation la performance de Amon sera automatiquement rabaissée puisqu'il sera affecté à la Ferrari, moins performante, et reflètera alors les performances observées. La table suivante indique les performances intrinsèques de chaque pilote 1967 (perfo corrigée de la performance de leur voiture): 1967 Driver Performance Adjusted For Car GPL AI T LE FEVRE Page 20 Cette table est intéressante car elle permet de comparer les performances d'un pilote à ses contemporains en supposant qu'ils pilotent tous une voiture de performance égale (en l'occurrence une Lotus !). Clark reste le meilleur en qualif' mais est cette fois égalé par Brabham. Et voyez Jackie Stewart ! Il fut clairement le meilleur performer en course compte tenu de sa chienne de voiture, la BRM ! Ces situations « et si... » sont amusantes et peuvent générer leur lot de discussions pour dire qui était vraiment le meilleur pilote. A vous de dire par vous même ! Une seule chose certaine : Ligier n'était pas à sa place en F1 en 1967. Pour les paramètres d'Agressivité, Vigilance, Experience et Souplesse, nous utiliserons les réglages par défaut de Papyrus. Concernant la Rapidité (quickness), nous réglerons à 1.00 tous les pilotes. Valeurs correctes ou non, Lee Bowden n'en sait rien, ni comment Papyrus les détermina. On ne peut justifier comment régler ces facteurs. Donc pour l'instant laissons les par défaut. En second lieu, nous établissons un réglage d'Exagération (« hype ») en utilisant la formule de régression appliquée à la valeur de performance ajustée du pilote considéré. Pour rappel, la formule est : Hype = 1.056 - (1.355 * Race Performance) + (1.302 * Race Performance ^ 2) Enfin, nous utilisons la table d'interaction « Hype Versus Qualification » (Part I) pour déterminer un réglage de qualification (qualifying) basé sur le réglage « hype » précédent de manière à obtenir la performance de qualification ajustée (Cf. tableau précédent). Lee Bowden utilise une version étendue de cette table pour affiner le réglage de qualification. Cette table plus complète est ainsi fournie ci-dessous : Qualifying Performance Expanded Hype Versus Qualifying Pour l'utiliser, entrer dans la table par le réglage « hype », lire dans la colonne en descendant jusqu'à atteindre la valeur de perfo en qualif' ajustée voulue puis lire alors à gauche le réglage « qualifying » nécessaire. Une petite interpolation (règle de trois) peut s'avérer nécessaire. Pour exemple, si le « hype » calculé est de 0.95, et la perfo en qualif' de 0.955, on trouve le réglage « qualifying » nécessaire de 0.90. La table qui suit indique les nouveaux réglages des AI pour tendre vers l'historique réel 1967. Leur label est « Settings #1 », car comme on le verra plus loin, il y a une seconde méthode pour contrôler les AI qui conduit à un jeu différent de paramètres. Driver.ini File Settings #1 NB: Amon et Rodriguez ont des réglages de « qualifying » inhabituellement élevés, mais il faut se rappeler que ceux-ci tiennent compte du second facteur « hype » nécessité pour définir la performance en course. Il n'y a donc là rien d'anormal en définitive. GPL AI T LE FEVRE Page 21 ET A PROPOS DE BANDINI ? Lorenzo Bandini présente un problème particulier pour les développeurs d'AI. Entré en 1967, il fut le leader de Ferrari mais ne pris part qu'à une seule course. Ferrari ne participait pas à celle de Kyalami…la première course de la saison. A Monaco, Bandini se qualifia fort bien en seconde position mais, on le sait, disparut tragiquement en course. Donc comment estimer ses paramètres dans son cas ? Lee Bowden détermina les performances de Lorenzo Bandini en qualif' et en course à partir des moyennes des années 1964, 1965, et 1966. Les valeurs obtenues furent : Bandini’s Historical Performance 1964 To 1966 A partir de ces estimations, les valeurs de « hype » et « qualifying » sont respectivement de 0.961 et 1.250. ET A PROPOS DES AUTRES PILOTES D'ORIGINE (PAPYRUS) ? Le fichier « driver.ini » original de Papyrus contient des pilotes différents de ceux que nous avons utilisés ici. Au lieu de Anderson, Ligier, Spence et Stewart, Papyrus choisit Beltoise, Ginther, Ickx et Scarfiotti. Dans ce tutorial, Lee Bowden a choisi de suivre les recommandations de David Wright's, ces pilotes étant plus représentatifs de l'historique réel. Cependant pour ceux qui préfèreraient un ou plusieurs autres pilotes d'origine Papyrus, voici leurs réglages. Leurs performances sont ajustées aux voitures qu'ils pilotent dans GPL (qui ne sont pas nécessairement celles conduites en réalité). Par exemple, Beltoise pilote une BRM dans GPL, alors qu'il pilota en majorité sa Matra qui n'est pas modélisée dans GPL. Comme pour Bandini, Lee calcula les performances sur 3 ans pour disposer de données suffisantes. Par exemple, Ginther essaya seulement de se qualifier à Monaco en 1967 et ne prit même pas le départ de la course. Original Driver Performances and Settings #1 Waouahou!! Ce fut un bien long voyage, n'est ce pas ? Nous sommes presque au bout... La partie suivante teste nos nouveaux réglages d'AI pour vérifier que tout fonctionne à merveille ! Et nous verrons aussi qu'il y a ''plus d'une manière de peler un chat''. (littéral) GPL AI T LE FEVRE Page 22 PART IV TESTING THE AI VERSUS « 1967 » HISTORICAL PERFORMANCE Nürburgring – P. Rodriguez (F1) - D. Hobbs (F2) GPL AI T LE FEVRE Page 23 PART IV TESTING THE AI VERSUS HISTORICAL PERFORMANCE (1967) Comme le dit l’adage, « the proof is in the pudding ». Vérifions donc que les réglages préconisés fonctionnent bien...Atteignent- ils les objectifs fixés, à savoir que les performances en qualif' et en course sous GPL représentent bien ce qui s'est passé en réalité durant la saison 1967 ? La table suivante compare les performances relatives en qualif' issues de l'historique 1967 et celles obtenues par GPL sur le circuit de Monza compte tenu des réglages préconisés. Rappel :  le pilote mythique qui se serait qualifié en pole lors de toutes les courses aurait eu une valeur de 1.00.  le paramètre « npt_override » est réglé sur 1.00 Relative Qualifying Performance with Settings #1 Npt_Override = 1.00 On constate que les pilotes atteignent bien la performance désirée à la fois en temps et en position relative de qualification. La moyenne des écarts entre la réalité historique et la performance simulée GPL est inférieure à 0,5%. Par conséquent ces réglages fonctionnent impeccablement pour nos nouveaux pilotes AI. On se souvient que ces nouveaux paramètres d’AI sont dérivés du pilote de référence dont tous les paramètres sont réglés à 1.00. Cependant, même ce pilote de référence pourrait ne pas atteindre le même temps de qualification que le réel pole man de l'époque. Par exemple le pilote de référence se qualifie à Monza en 1'29''78 seconds. En 1967, Jimmy Clark fit la pole en 1'28''50 secondes. L'écart est de plus d'une seconde. Notre « Clark GPL » basé sur les nouveaux réglages est même plus lent encore en 1'30''40. Ceci ne signifie pas que les nouveaux réglages sont mauvais; au contraire ils sont très bons pour atteindre les performances voulues. Ceci signifie juste que nous avons basé nos réglages par rapport au pilote de référence et qu'il n'est pas aussi rapide que le plus rapide pilote réel de Monza. Il se pourrait aussi que la longueur de la piste modélisée dans GPL soit trop longue ou que la performance modélisée de la Lotus ne soit pas optimale. Plus loin, nous verrons 2 autres méthodes pour atteindre des temps de qualif' encore plus proches de la réalité de l'époque. La table qui suit présente cette fois la comparaison des performances en course, toujours à Monza. GPL AI T LE FEVRE Page 24 Relative Race Performance with Settings #1 Npt_override = 1.00 Average Difference : 0.27% Les résultats sont encore meilleurs qu'en qualification puisque l'écart moyen est deux fois plus faible qu'en qualif' (0,27%). Juste pour le fun, Lee a fait un test pour comparer les différentes performances issues de 3 fichiers 'driver.ini' créés par lui-même, Kuratko et David. Les résultats sont calculés en relatif par rapport à Clark qui ressort comme le pole man pour les 3 fichiers. Les résultats de Kuratko et David sont simplement ajustés par un coefficient pour corriger et ramener la perfo de Clark à 0.993 pour tous les trois (ceci ayant été nécessaire car il y avait de légères différences naturellement entre les trois temps de qualif').Soyez ainsi assurés que chaque performance relative est mesurée de la même façon dans cette table. COMPARAISON DES RESULTATS DES 3 TYPES DE REGLAGE Relative Qualifying Performance @ Monza Beaucoup de choses ressortent de cette comparaison. Il est facile de constater que les trois ne sont pas en accord pour tous les pilotes : Kuratko et Lee : désaccord sur Gurney, Stewart, Siffert, Irwin, Bonnier, Anderson et Ligier. David et Lee : désaccord sur Brabham, Hill, Parkes, McLaren et Anderson. GPL AI T LE FEVRE Page 25 A partir de l'agrégation de ces données, on observe que les écarts moyens sont les suivants selon les réglages respectifs : Lee : 0.46% Kuratko : 0.78% David : 0.62%. Lee n'est pas tout à fait satisfait des réglages de Rindt, Stewart, Irwin, et Ligier. Stewart est sous-performant, tandis que Irwin l'est trop. On ne peut mettre ça sur le compte de la performance de la voiture car tous les deux pilotaient une BRM. Il serait possible de « distordre » les réglages de qualification pour mieux correspondre à l'historique réel, mais Lee voulait l'éviter. Lee pense que ses AI fonctionnent bien. Maintenant, il y a deux raisons pour lesquelles les trois « experts » développent des réglages qui produisent différents résultats : L'une est que chacun des trois apprécie différemment l'effet des réglages de chaque AI. Kuratko a expliqué avec force détail comment il trouva ses réglages, mais il n'a pas montré l'évaluation qu'il obtint de l'effet de chacun. David, quant à lui, donne directement son fichier « driver.ini » sans aucune explication de la procédure pour y parvenir. Une autre raison possible des différences enregistrées est que tous les trois ont essayé de faire différemment. Peut-être, Kuratko estime que Stewart était meilleur en qualif' comparé à David et Lee. Et David pense-t-il que Irwin était bien pire que ne l'estiment Kuratko et Lee. Au moins Kuratko explique comment il gère ses réglages. Encore une fois ce n'est pas le cas de David. Lee ne pense pas que tout soit mauvais. Bien sûr, ses AI sont les meilleurs des trois, mais ceci repose sur l'hypothèse que les formules d'appréciation de la performance des pilotes réels soient les plus correctes. OBTENTION DES TEMPS DE QUALIFICATION HISTORIQUES : Comme indiqué avant, les nouveaux paramètres d'AI fonctionnent globalement bien à la fois en qualif' et en course. Cependant le pole man virtuel est plus lent que le pole man réel, historique. D'où l'interrogation : comment accélérer les AI pour qu'ils se qualifient avec des temps plus proches encore de la réalité ? Il y a deux méthodes détaillées ci-après pour y arriver. 1. Npt_override Method Clark AI se qualifie à Monza en 90.40 secondes tandis que Clark réel en 88.50 secondes. Pour améliorer le temps virtuel, on peut réduire le paramètre « npt_override » à environ 0.975. Comme noté plus avant, ne pas laisser à 1.0 le paramètre « npt_override » qui contrôle l'ensemble des AI, cause un souci avec certains pilotes qui se qualifieront relativement mieux qu'ils ne le devraient. Cependant leur performance en course sera préservée. Comme chaque piste est modélisée différemment dans GPL, un réglage « npt_override »valable pour Monza ne fonctionnera pas forcément bien pour toutes les pistes. Après son lot d'expérimentation, Lee a trouvé qu'un « npt_override » de 0.960 était réellement le meilleur réglage possible pour obtenir des temps de qualif' corrects pour toutes les pistes. La table suivante illustre les effets d'une réduction de « npt_override »à 0.960 sur les temps du pole man pour les différentes pistes GPL 1967 Actual versus AI Pole Winner’s Qualification Times AI Settings #1 Npt_override = .960 On constate que ce réglage « npt_override » de 0.960 fonctionne très bien avec les nouveaux AI (setting#1). Ce n'est pas parfait, comme l'indiquent les temps de Spa et Silverstone, mais les temps sont très proches. La modélisation de la piste de Kyalami est incorrecte (trop courte) et il n'y a pas de comparaison possible pour Rouen, non utilisée en 1967. 2. Higher Hype Method La méthode précédente est parfaitement acceptable comme approximation, mais comment jouer sur les paramètres directs des AI pour approcher le temps historique de Clark de 88.50 secondes à Monza avec un « Npt_override » à 1.00 ? Pour cela il faut GPL AI T LE FEVRE Page 26 ajuster à la hausse le facteur « hype » (Exagération). La méthode est simple : il faut ainsi ajuster chaque performance pour atteindre le temps de la pole position réelle. Nous connaissons déjà les performances relatives en qualif' et en course de chaque pilote. Si nous savions comment se qualifie le pilote de référence sur chaque piste, nous pourrions utiliser la moyenne de ses temps pour calculer l'ajustement de performance nécessaire pour chaque pilote. La table qui suit précise pour cela les temps réels des pôles de 1967 et ceux du pilote de référence, utilisant un « npt_override » de 1.00 : 1967 Pole Winner versus Baseline Driver Qualification Times Npt_override=1.00 Ainsi en moyenne le pilote de référence se qualifie 2.72% moins vite que le pole man historique, compte non tenu de Kyalami et Rouen pour les raisons déjà invoquées. Par conséquent, il faut ajuster la performance de qualif' de + 2.72% en moyenne. Ce que nous essayons de faire concerne le pilote le plus rapide, Jim Clark le plus souvent. Or, si nous ajustons Clark, nous devons ajuster chacun d'autant pour qu'il reste dans la même position en temps relatif qu'au début. La formule suivante est donc utilisée pour ajuster la performance de qualif’ : Dans le cas de Jimmy, sa performance originale en qualification était de ''0.993''. Substituée dans la formule, on obtient évidemment : Clark’s Adjusted Qual Perf = 1.0272 Un autre exemple aide à mieux saisir la formule; prenons Denny Hulme. Sa performance originale en qualif' (ajustée compte tenu de sa voiture) est de ''0.986''. Il faut accroître sa performance avant de régler ses paramètres de « hype » et « qualifying ». On divise toujours par la performance de Clark (pilote le plus rapide en référence), par conséquent on obtient la performance ajustée de D. Hulme suivante : Hulme’s Adjusted Qual Perf = 1.0272 x 0.986 / 0.993 = 1.020 On procède suivant le même schéma pour la performance en course. La formule est: La performance en course de Hulme (ajustée de sa voiture) est de ''0.996''. Sa nouvelle performance ajustée devient donc : Hulmes’ Adjusted Race Perf = 1.0272 X .996 / 0.993 = 1.030 La table page suivante fournit alors les nouvelles performances ajustées, intrinsèques aux pilotes, pour s'approcher des temps réels : GPL AI T LE FEVRE Page 27 Par suite, les nouveaux réglages des pilotes (« hype » « qualifying »), déterminés selon le processus précédent sont : Concernant Bandini, « hype » et « qualifying » deviennent 1.000 et 1.250 respectivement. Globalement, ce second set de paramètres AI marche très bien pour toutes les pistes, comme l'indique la table ci-après, avec un « npt_override » de 1.00. 1967 Actual versus AI Pole Winner’s Qualification Times AI Settings #2 Npt_override = 1.00 GPL AI T LE FEVRE Page 28 PART V 1965 MODIFICATION Silverstone – Départ à Quatre de front GPL AI T LE FEVRE Page 29 PART V 1965 MODIFICATION Bien...Maintenant que nous en avons terminé avec la saison 1967, passons à la modification '65. Nous appliquerons les mêmes techniques pour définir les réglages du fichier « driv65.ini » pour rendre les pilotes AI aussi proches que possible des performances réelles de 1965. 1965 CAR PERFORMANCE De même qu'avec les autos 1967, chaque voiture ''1965'' modélisée dans GPL présente ses propres performances. Pour identifier ces performances, la procédure déjà utilisée pour le GPL original de 1967 est reproduite. On commence par faire les réglages à 1.00 des paramètres du pilote de référence. Les différences qui apparaissent alors, mesurent ainsi les différences de performance entre les différentes monoplaces. Le tout est calculé en valeur relative par rapport à la voiture la plus rapide, elle même normée à 1.00. En 1965, des pistes différentes de 1967 servirent de cadre au championnat du monde de F1 : c'est le cas en Afrique du Sud de la piste de « East London », en France de celle de Clermont-Ferrand, circuit de « Charade ». Il n'y a pas eu non plus de Grand Prix du Canada à Mosport. Le graphique suivant présente donc ces performances relatives pour les 10 circuits du championnat 1965. La table qui suit compare quant à elle les performances relatives moyennées sur l'année 1965. La Honda ressort comme largement au dessus du lot. Elle sert de référence (normée à 1.00). Les autres s'expriment donc par rapport à la Honda. Il est aisé de voir les différences de performance de ces autos. La BRM se retrouve juste derrière la Honda, suivie elle même de près par la Ferrari. Les Brabham BT11 et Lotus 33 se situent dans le milieu du peloton, tandis que la Cooper et la Brabham BT7 se tiennent plus en retrait. GPL AI T LE FEVRE Page 30 TESTS OF AI QUALIFICATION PERFORMANCE Lee a suivi la même procédure que celle de l'année 1967 pour déterminer les effets de modifications des paramètres des pilotes AI. Le pilote de référence considéré tient le volant de la Honda à Monza. Par convention dans toutes les tables ou graphiques présentés, des performances relatives plus élevées signifient aussi bien une vitesse plus élevée qu'un temps au tour plus faible. Résultats obtenus : 1965 Relative Qualifying Performance Ce n'est pas vraiment une surprise de constater que les influences des paramètres en termes de performance en qualif' 1965 sont tout à fait similaires à celles déterminées pour 1967. A nouveau, les facteurs « aggression », « alertness », « experience » et « smoothness » ont peu ou pas d'effet sur cette performance. Le paramètre « Hype » est toujours le plus influent, tandis que « quickness » et « qualifying » ont un effet identique mais moindre. TESTS OF AI RACE PERFORMANCE Les résultats de qualif' 1965 étant similaires à ceux de 1967, tester la performance en course n'est pas nécessaire (mêmes effets) Seules des modifications de « hype » seront donc nécessaires et capables d'ajuster cette performance. TESTS OF HYPE VERSUS QUALIFYING ON 1965 QUALIFYING PERFORMANCE D'après les résultats 1967, on sait que modifier uniquement le « hype » suffit à ajuster la perfo en course. Donc nous avons juste à connaître comment faire varier « hype » et « qualifying » pour ajuster la perfo en qualif'. Cette information est disponible grâce à la table ci-dessous : 1965 Qualifying Performance Hype Versus Qualifying Par exemple, avec un « hype » de 1.10, on peut ajuster la performance en qualif' de 103.6% à 109.2% en intervenant de 0.70 à 1.20 sur le paramètre « qualifying » . Avec un « hype » de 0.80, cette performance ne peut varier que de 82.5% à 84.4% de la référence. Il y a d'autant moins de latitude d'ajustement de la perfo en qualif' que le « hype » est réglé bas. QUANTIFYING 1965 HISTORICAL DRIVER PERFORMANCE Comme pour 1967, la performance réelle des coureurs de 1965 doit être quantifiée. Les tableaux de la page suivante récapitulent l'historique de 1965, toujours d'après les mêmes sources que pour 1967 (sites web). GPL AI T LE FEVRE Page 31 1965 Average Gap to Pole Position 1965 Average Grid Position (en %) 1965 Average Race Time 1965 Average Race Time (en % du vainqueur) Finish Position GPL AI T LE FEVRE Page 32 Utilisant les mêmes formules de quantification des perfos qu'en 1967, les performances quantifiées des véritables pilotes sont : 1965 Actual Driver Performance Un seul commentaire : Clark était véritablement imbattable cette année là ! Il a complètement dominé cette saison de F1. Nous devons maintenant ajuster les performances des pilotes pour tenir compte des capacités de leur monture (Cf. Partie III) pour comparer les performances intrinsèques des pilotes. C'est ce que donne la table qui suit : 1965 Driver Performance Adjusted For Car On obtient alors une comparaison des performances des pilotes à iso-performance de voiture (ici, la Honda). Clark ressort encore plus performant (en relatif) car il fut le meilleur alors qu'il ne disposait pas de la voiture la plus rapide. Dan Gurney s'approche de très près de Clark, ce qui conforte la rumeur selon laquelle le père de Jimmy aurait dit à Gurney que son fils le craignait le plus ...un grand hommage de l'un des plus grands pilotes de la Formule 1. GPL AI T LE FEVRE Page 33 Bien que ces réglages donnent des temps de qualif' plus lents que les temps historiques ils peuvent toujours être utiles pour une comparaison relative des performances des pilotes. La table suivante compare ainsi, à Monza, les qualifications selon ces réglages aux véritables performances globales de 1965 1965 Relative Qualifying Performance Npt_Override = 1.00 ACHIEVING HISTORICAL QUALIFYING TIMES OBTENTION DES TEMPS DE QUALIFICATION HISTORIQUES La même procédure que celle menée pour 1967 est suivie pour approcher les temps simulés des temps réels (par ajustement du paramètre « hype »). La table suivante indique les temps du pole man réel de 1965, comparés au pilote de référence, en utilisant un réglage de 1.00 pour le « npt_override » : 1965 Pole Winner Versus Baseline Driver Qualification Times Npt_override=1.00 GPL AI T LE FEVRE Page 34 En moyenne, le pilote de référence se qualifie 1.49% moins vite que le temps historique de la pole. Par conséquent, on doit accroître les performances en moyenne de 1.49%. Ceci est applicable à tous les pilotes (Cf. procédure PARTIE IV). La table suivante indique les performances en qualif' et en course une fois réajustées (voiture et piste corrigées) : 1965 Driver Performance Adjusted For Car And Track A la suite de quoi, on détermine le réglage du « hype » en utilisant la formule de régression ci-après en introduisant la valeur de performance ajustée. Pour 1965, la formule est : Hype = (1.233 * Race Performance) - 0.233. Enfin, on utilise la table « Hype versus Qualification » pour obtenir le réglage du paramètre « qualifying » basé sur la valeur voulue de performance de qualif' ajustée. Alors les nouveaux paramétrages sont : 1965 driv65.ini File Settings GPL AI T LE FEVRE Page 35 Intéressant de noter que bon nombre de pilotes ont un réglage élevé du facteur « qualifying ». Apparemment tous ces pilotes ont donc ''sur-performer'' en qualif' en comparaison de leur performance en course (NDLT: une hypothèse est aussi que la fiabilité des voitures de l'époque nécessitait d'adopter un rythme en course moins soutenu, toutes proportions gardées, pour préserver les chances de rallier l'arrivée). En ce qui concerne les autres paramètres (« aggression », « alertness », et « experience »), nous conserverons les réglages du MOD65 définis par défaut. Que ces valeurs soient ou non correctes, Lee ne sait pas comment elles furent déterminées par l'équipe de la MOD65. Concernant « quickness » et « smoothness », tous les pilotes seront réglés sur 1.00. Globalement ces paramètres AI fonctionnent très bien sur les différentes pistes, comme le montrent les résultats ci-dessous. Se rappeler que ces réglages utilisent un « npt_override » de 1.00, mais que ce paramètre peut aussi être modifié à volonté pour maîtriser globalement la vitesse des AI. 1965 Actual versus AI Pole Winner’s Qualification Times Npt_override = 1.00 Voilà tout pour le MOD65. Mêmes technique et méthode que pour « 1967 » pour en déduire des réglages qui fonctionnent également parfaitement comme il faut ! GPL AI T LE FEVRE Page 36 PART VI 1969 MODIFICATION B. Mc LAREN - BARCELONE GPL AI T LE FEVRE Page 37 PART VI 1969 MODIFICATION Mêmes technique et méthode que précédemment appliquées à la MOD69. Se reporter aux parties antérieures en cas de besoin de description plus précise. Nous reprenons donc ici essentiellement les tableaux de données de Lee. NB: Lee Bowden signale que ce chapitre peut être obsolète vis à vis de la version 2 de MOD69 (non mise à jour). 1969 CAR PERFORMANCE L'équipe de conception du MOD69 a fait un gros travail, introduisant les ailerons sur les monoplaces. Quand on les pilote, il est patent qu'elles diffèrent des versions des années précédentes, tant en accélération / freinage qu'en tenue de route (comportement). D'une certaine façon elles sont plus faciles à conduire, selon Lee, que les voitures de 1965 alors qu'elles disposent d'une puissance supérieure à celles de 1967! Elles sont également plus contrôlables et stables au freinage ainsi qu'en virage. L'aérodynamique c'est quelque chose!! Avant de pouvoir mesurer les performances de chaque monoplace, il nous faut déterminer l'effet des ailerons. Pour cela, Lee a réalisé des comparaisons des temps de qualif' avec le pilote de référence dans la Lotus 49B sur 2 pistes, l'une rapide (MONZA), l'autre lente (MONACO) en réglant l'angle d'incidence des ailerons. Résultats dans la table ci-dessous : Wing Effect On Qualifying Performance Lee fut étonné de constater ces résultats, même s'il avait été prévenu que le réglage d'aileron du joueur avait un effet sur les performances des AI aussi ! Cependant, les résultats de ce test indiquent que GPL utilise vraiment la physique de chaque voiture pour fixer sa performance. Et si c'est le cas pour les ailerons, cela doit aussi l'être pour les autres facteurs des autos tels puissance, maître - couple (section frontale), modifications de suspension, angles de dérives des pneus, etc. Nous savions que GPL utilisait ces facteurs pour déterminer la performance de la voiture du joueur (vous !) mais pas celle des AI ! Chapeau bas donc à Papyrus pour avoir conçu une si remarquable simulation ! Revenons au tableau. Le premier point à noter est qu'une auto de 1969 est plus lente qu'une de 1967 à châssis et moteur similaire. La Lotus 49 de 67, sans ailerons donc, tourne à Monza en 89.35 seconds…soit plus d'une seconde plus vite que la Lotus 49B de 69 à 0° d'aileron ! Ensuite, à Monza toujours, rajouter de l'aileron (de l'incidence) accroît le temps au tour. D'après l'équipe de la MOD69, l'aileron décroche vers 15°. Ces tests montrent qu'au-delà de 15°, il y a toujours plus de traînée et des temps encore moins rapides. Ce résultat est cohérent avec la théorie aérodynamique, qui veut que la traînée croît jusque et au-delà du seuil de décrochage pendant que la déportance s'accroît puis s'effondre dès l'angle de décrochage franchi. L'équipe de MOD69 pense que le meilleur réglage aéro du joueur dépend de la piste choisie, ce qui est le cas dans la réalité. Des pistes à haute vitesse comme Monza nécessitent une incidence faible, disons 5 degrés, tandis qu'à l'inverse, des circuits de basse vitesse comme Monaco conduisent à des réglages de 15 degrés. Chaque piste implique un ajustement optimal. Vous pouvez aussi ajuster les ailerons avant (front) et arrière (rear) séparément pour améliorer la tenue de route, mais ceci dépasse le cadre de ce tutorial Ce qui nous importe, en tant que concepteurs de pilotes AI, est de savoir que le réglage des ailerons affecte énormément la performance des AI, notamment pour les pistes à haute vitesse. On ne peut régler séparément les ailerons des AI et du joueur. Afin de tester les performances de chaque voiture, nous avons du définir un réglage donné; sans quoi, il aurait fallu réaliser différents fichiers « drv69.ini » pour chaque réglage d'aileron ! Après une petite réflexion influencée par une paire de bières, Lee estima qu'un réglage de 10 degrés représentait un bon compromis pour comparer les AI, car c'est finalement un réglage moyen pour la plupart des joueurs. Bien sûr, c'est trop pour Monza et trop peu pour Monaco, mais nous devrons vivre avec ça ! Pour tester alors les performances relatives des autos, le fichier « drv69w.ini » est simplement modifié pour régler à 1.00 les paramètres du pilote de référence de chaque auto (comme d'habitude !). L'aileron est aussi réglé dans le fichier « wg69.ini ». GPL AI T LE FEVRE Page 38 Résultats obtenus pour 1969 : A noter qu'en 1969, certaines pistes furent encore différentes de 1965 ou/et 1967. Kyalami pour le GP d'Afrique du Sud, Clermont-Ferrand pour le GP de France, Montjuich pour le GP d'Espagne. Bien qu'une version de ce circuit ait été développée, elle n'a pas ici été utilisée. Cependant une version béta fut testée (avec l'autorisation de l'équipe MOD69). La Lotus 49B s'avère la plus rapide, mais juste d'un poil ! 1969 Average Car Performance En fait, toutes les voitures animées du même Ford - Cosworth sont très proches en performances. La Ferrari aussi est très proche. Lee fut un peu surpris de la très bonne performance de la Brabham d'autant qu'elle a cette aile avant énorme, mais qui apparemment ne fait pas tellement de différence. Imaginez vous seulement à la place de Jack Brabham ou Jackie Ickx conduisant à 280 km/h avec cet aileron énorme flottant à quelques centimètres du visage...Il n'en fallait pas plus pour que les règles soient changées plus tard dans la saison pour interdire les ailerons hauts. La BRM se situe en retrait des meilleures, tandis que la Lotus 63 est clairement bonne dernière, puisqu'il fut trop difficile de montrer son avantage technologique (Ndlt: 1ère F1 4 roues motrices, lourde et peu appréciée des pilotes de l'époque). GPL AI T LE FEVRE Page 39 TESTS OF AI QUALIFICATION PERFORMANCE Résultats identifiés par le pilote de référence sur Lotus 49B avec 10 degrés d'aileron à Monza. 1969 Relative Qualifying Performance Résultats sans surprises, similaires à ceux de 1965 et 1967. A nouveau, « aggression », « alertness », « experience », et « smoothness » n'ont pas ou peu d'effet. Les tests de performance en course ne sont dès lors pas nécessaires. TESTS OF HYPE VERSUS QUALIFYING ON 1969 QUALIFYING PERFORMANCE 1969 Qualifying Performance: Hype Versus Qualifying QUANTIFYING 1969 HISTORICAL DRIVER PERFORMANCE 1969 Average Grid Position 1969 Average Gap to Pole Position (en %) GPL AI T LE FEVRE Page 40 1969 Average Race Time (en %) 1969 Average Finish Position En commentaire des performances historiques, Jackie Stewart fut premier de classe en course ! En qualif' cependant, Jochen Rindt lui tint tête. La performance de Mario Andretti est estimée sur la base de résultats de course (position) des années ultérieures 1970, 1971 et 1972, puisqu'il ne termina aucune des 3 courses auxquelles il participa en 1969. La performance ajustée (correction de la voiture) montre vraiment que Stewart fut largement le meilleur en course. En fait on s'aperçoit que Stewart fut le meilleur ''performer'' en course des 3 années considérées, 65 67 69, éclipsant même Clark ! 1969 Actual Driver Performance 1969 Driver Performance Adjusted For Car Pour finir, la table qui suit compare les qualif' de Monza utilisant les réglages corrigés en « hype » et « qualifying » (non montrés ici) et leur performance réelle de 1969. GPL AI T LE FEVRE Page 41 1969 Relative Qualifying Performance Npt_Override = 1.00 Globalement les AI 1969 fonctionnent donc bien Le seul écart notable concerne John Miles, mieux qualifié qu'en simulation. La raison en est sa performance en course de 0.904 alors qu'elle est de 0.945 en qualif'. Ce gros écart est difficilement compensable. Comme expliqué en Partie I, il est aisé de réduire la performance de qualif' mais plus difficile de l'améliorer relativement à la performance en course. L'option de Lee est de toujours privilégier la représentativité de la perfo' en course. ACHIEVING HISTORICAL QUALIFYING TIMES La table qui suit indique le temps du pole man réel comparativement au pole man virtuel AI, sous « npt_override » de 1.00. 1969 Pole Winner Versus Baseline Driver Qualification Times Npt_override=1.00 En moyenne, le pilote de référence se qualifie 8.88% moins vite que le pole man historique. Ce qui nécessite ajustement. (Cf. Partie IV pour une description complète). Cette différence de 8.88% est bien plus importante que celles obtenues lors des MOD65 et 67. Les raisons invoquées sont que:  1/ les voitures de MOD69 même sans ailerons sont plus lentes que celles de 1967. Rajouter 10 degrés d'aileron les ralentit encore à cause de la traînée accrue. Lee ne critique pas la MOD69, car c'est plutôt le résultat d'une bonne prise en compte de la physique. Il pense que la même chose se produisit dans la réalité. En y réfléchissant les voitures de 1969 sans ailerons étaient pratiquement les mêmes que celles de 1967 au niveau performances. L'ajout d’ailerons et de pneus plus larges augmenta nettement la traînée ce qui leur fit perdre de la vitesse de pointe, même si les capacités de passage en courbe furent considérablement améliorées. L'effet résultant est que les AI deviennent plus lents, mais vous, en tant que pilote, plus rapide. Lee gagna 2 secondes au Glen dès son second tour d'essais de la MOD69 sur Mac Laren ! Ce qui prouve que les ailerons ont bien aidé...  2/ deux pistes modélisées paraissent suspectes; elles sont peut être plus longues que la réalité (Clermont-Ferrand et Silverstone). La table qui suit indique les performances des pilotes respectifs, ajustées des voitures et des pistes : GPL AI T LE FEVRE Page 42 1969 Driver Performance Adjusted For Car And Track A partir de là, le paramètre « hype » est défini par la régression applicable 1969 : Hype = (1.227 * Race Performance) - 0.224 Enfin, on utilise la table « Hype Versus Qualification » (non montrée) pour définir le réglage « qualifying », d’où : 1969 drv69w.ini File Settings Tous les pilotes ont un « hype » élevé pour compenser les vitesses trop faibles de MOD69. Les paramètres de « aggression », « alertness », et « experience », reprennent les valeurs par défaut de la MOD69. « Quickness » et « smoothness » sont réglés à 1.00 pour tous. Globalement ces nouveaux réglages fonctionnent raisonnablement sur les différentes pistes, le « npt_override » étant à 1.00. 1969 Actual Versus AI Pole Winner’s Qualification Times Npt_override = 1.00 L'écart moyen qui ressort est alors de -0.66% (AI légèrement plus rapides que la réalité, en moyenne). Rappel : ceci ne vaut que pour MOD69 version 1, d'après Lee. GPL AI T LE FEVRE Page 43 PART VII AI CAR RELIABILITY FIABILITE DES MONOPLACES J. ICKX – Nürburgring 67 - 13ième tour GPL AI T LE FEVRE Page 44 PART VII AI CAR RELIABILITY FIABILITE DES MONOPLACES Le comportement des voitures vis à vis de leur fiabilité, gérée par GPL, n'a jusqu'ici pratiquement pas fait l'objet d'analyses. Evidemment certaines voitures sont plus fiables que d'autres. Par exemple la Brabham de 1967 fut extrêmement fiable et ce fut le facteur-clef de la victoire de Denny Hulme au championnat. Au contraire, Jim Clark le perdit en raison du manque de fiabilité des Lotus 49. Les concepteurs de GPL considérèrent important de modéliser cet aspect dans le programme « GPL.exe ». Comme nous le verrons, les fichiers « gpl_ai.ini » et « driver.ini » contiennent des réglages de paramètres qui affectent la fiabilité des autos. Et bien qu'on ne puisse totalement contrôler la fiabilité, il apparaît qu'on peut au moins l'influencer dans une certaine mesure. Cette partie présente donc les recherches de LEE, à sa connaissance réalisées pour la 1ère fois dans cet important domaine. A la différence des essais nécessaires pour identifier l'influence des paramètres sur la performance des pilotes, étudier la fiabilité nécessite beaucoup plus de temps, puisqu'il y a une grande variabilité du nombre et types de défaillances durant une course. A cause de cette variabilité, il faut lancer énormément de courses pour seulement approcher l'effet d'une seule modification des fichiers « gpl_ai.ini »ou de « driver.ini ». Par exemple, il faut 3 ou 4 tests pour avoir une bonne idée de l'effet de paramètres de pilotage tels que « hype » ou « quickness », alors qu'il faut plus de 20 courses rejouées à chaque fois pour apprécier l'effet d'un paramètre sur la fiabilité. D'un point de vue statistique, pas moins de 400 courses rejouées seraient nécessaires pour avoir 95% de confiance en l'effet d'un paramètre à 5% près de la fiabilité réelle ! Clairement, réaliser autant de tests est impossible (NDLT: pour un seul homme*PC). Les analyses menées porteront donc sur beaucoup moins d’essais ! Bien que ceci réduise la confiance des résultats et conclusions, il est tout à fait possible d'en tirer des observations générales et des tendances vis à vis du contrôle de la fiabilité. Dans la plupart des cas, Lee réalisa 20 courses ce qui équivaut à afficher un taux de confiance de 90% pour une précision à 18% près de la fiabilité réelle. Par conséquent, considérons les informations qui suivent comme préliminaires...jusqu'à ce que quelqu'un ait la patience de faire plus et mieux!! Alors, allons y. GPL_AI.INI FILE TESTS La section [Mechanical] du fichier « gpl_ai.ini » contient divers paramètres qui peuvent affecter toutes les monoplaces AI. Ces paramètres définissent la répartition des défaillances ou des problèmes des diverses fonctions de la voiture, telles que moteur, suspension, etc. et définissent aussi l'effet sur le ''cercle de traction'', etc. Etant donné qu'il s'agit de la répartition des probabilités entre ces différents cas de figures possibles, leur somme vaut 100%. On aurait pu supposer que ces valeurs seules régissent la distribution des défaillances de toutes les autos, mais on verra que ce n'est pas entièrement le cas. Voici la liste et la répartition des risques de mauvais fonctionnement : Par exemple, le risque de défaillance des freins représente 1% du total, auquel s'ajoute un risque de 2% d'avoir une déficience des freins (problème qui n'est pas la perte totale de freins). Par conséquent le risque de défaut de fonctionnement du freinage est de 3%. Tout au long de cette Partie VII, on considérera qu'un « dysfonctionnement » est la combinaison de défaillances et de problèmes rencontrés. On doit considérer en effet qu'une défaillance (failure) conduit à l'abandon immédiat ou quasi-immédiat de la course, alors qu'un problème dégrade seulement le comportement ou la performance du véhicule, ce qui permet encore de poursuivre la course plusieurs tours, voire même de la finir, mais plus lentement. La répartition des pourcentages entre les 2 types de risque est à peu près équivalente (50/50). GPL AI T LE FEVRE Page 45 En plus de ces répartitions, le fichier « gpl_ai.ini » contient 2 autres paramètres importants. Ce sont, strictement extraits du dit– fichier, les paramètres suivants : Le premier paramètre (ici abrégé en « m_f_c ») exprime la probabilité pour 10 000 (10-4) d'avoir un dysfonctionnement sur l'intervalle de temps défini par le second paramètre (en abrégé « m_f_i »), par voiture. L'unité de ce dernier paramètre « m_f_i » est en « ticks »; sa valeur indique une durée moyenne de l'intervalle de temps, car il s'agit en fait d'une variable aléatoire (valeur variant aléatoirement autour de cette moyenne). Pendant une course, GPL fait donc périodiquement un état de santé de fonctionnement des autos. Cette périodicité dépend du réglage du « m_f_i ». La valeur de 540 ticks par défaut, conduit à une vérification toutes les 15 secondes en moyenne (36 ticks par secondes), c'est à dire 240 vérifications par heure de fonctionnement, pour chaque voiture. Calculer a priori le nombre induits de dysfonctionnements pour une course n'est en fait pas trivial, car la probabilité de défaillance globale varie avec le nombre de AI encore en course et que la périodicité est aléatoire. Lee a écrit un programme en Visual Basic pour ce faire. Avec les valeurs par défaut, pour une course de 1H 43' à Monza, l'estimation a priori ressort à 3,6 défaillances. Cependant les tests de Lee montrent qu'on en observe plus du double (environ 8 par course). Bref, en synthèse on se rappellera qu'il y a 3 réglages dans le fichier « gpl_ai.ini » pour contrôler la fiabilité de toutes les voitures. Avant d'aller plus loin avec les tests, voyons quelles indications spécifiques donne GPL lors des dysfonctionnements rencontrés. Heureusement, ceux-ci sont listés dans les résultats des courses. Lee réalisa un test avec un réglage arbitraire de 20.00 pour le risque ('chance') de dysfonctionnement de tous les pilotes («fichier « driver.ini ») et de 0.00 pour les risques de dysfonctionnement de « gpl_ai.ini » à l'exception du paramètre soumis au test, réglé quant à lui à 100.00. Ce test permet ainsi de relier les observations de dysfonctionnement aux 13 catégories de défaillances ou de problèmes possibles. Conclusions tirées :  les paramètres 'chance' du fichier « gpl_ai.ini » gèrent le type de dysfonctionnement,  les paramètres 'chance' du fichier gpl_ai.ini » affectent la distribution des dysfonctionnements,  il y a peu ou pas de distinction des dysfonctionnements affichés entre « défaillance » et « problème »  les défaillances 'fuel' ou problème 'fuel' ne génèrent pas d'indication de ce type, à moins que le cas « abandon » soit un dysfonctionnement lié au fuel (mal défini)  il se produit certains effets 'aléatoires', tels des dysfonctionnements de type « suspension » lors des tests liés au paramètre « fuel » ou encore de pannes sèches lors de tests de fuite d'huile, alors que ces risques d'occurrence sont réglés sur 0.00! Maintenant, regardons comment le réglage « mechanical_failure_chance » de « gpl_ai.ini » affecte le nombre de dysfonctionnements au cours d'une course. Pour ce test, tous les réglages de « gpl_ai.ini » sont réglés par défaut sauf en ce qui concerne « mechanical_failure_chance ». Tous les réglages de ''chance'' du fichier « driver.ini » sont à leurs valeurs par défaut. Vingt courses sont rejouées à Monza. Les résultats sont décrits ci-après. GPL AI T LE FEVRE Page 46 Soit encore le taux de dysfonctionnement en fonction du réglage 'chance' : Les conclusions sont que : 1. Le paramètre « mechanical_failure_chance » du fichier « gpl_ai.ini » affecte bien le nombre total de dysfonctionnements. 2. Ce nombre varie pratiquement linéairement en fonction du réglage du paramètre ''chance''. Si vous continuiez les tests avec des réglages au delà de 10, vous verriez que la courbe commence à saturer et tend vers une asymptote. 3. Des accidents se produisent pour tous les niveaux de réglages, même à « zéro ». Ces accidents peuvent être réellement des dysfonctionnements ''déguisés''. 4. Le taux d'accident est pratiquement constant, de l'ordre de 13% par course, indépendamment du réglage de ''chance''. 5. La course de Monza dure environ 1 hr 45 min; des courses plus longues auraient davantage de dysfonctionnements. Une analyse par régression statistique conduit à déterminer le lien suivant entre le paramètre « mechanical_failure_chance » et le taux de dysfonctionnements, accidents inclus : Malfunction Rate = 0.160 + 0.047 * Mechanical_failure_chance (R Squared =.973) Une relation légèrement meilleure est donnée par : Malfunction Rate = 0.130 + 0.071X - 0.002X^2 (R Squared =.977) où X = Mechanical_failure_chance Cette formule montre clairement un taux d'accident de 13% quand X=0 et la saturation quand X excède 10! Puis, Lee fit un test où les réglages de « gpl_ai.ini » étaient à leurs valeurs par défaut, sauf le paramètre « mechanical_ failure_interval » objet de l'analyse. Tous les paramètres 'chance'' du fichier « driver.ini » réglés par défaut. Test répété 20 fois. GPL AI T LE FEVRE Page 47 Conclusions : 1. Le paramètre « mechancial_failure_interval » affecte le nombre de dysfonctionnements. 2. Ce nombre de dysfonctionnements est une fonction non linéaire du réglage de l'intervalle de temps de scrutation. Plus l'intervalle augmente, moins on rencontre de dysfonctionnements. 3. Des accidents se produisent pour tous les niveaux de réglage. 4. Le taux d'accident est pratiquement constant et de 13% quel que soit le réglage. 5. Le résultat vaut pour Monza. Pour des courses de plus longue durée, il y aura davantage de dysfonctionnements. La régression établie par Lee est une très bonne approximation de l'effet du paramètre étudié; elle est de la forme : Malfunction Rate = 1.985 – 0.243Ln(X) (Rsquared= 0.991) où X = Mechanical_Failure_Interval et Ln = Logarithme Népérien. Qu'avons nous appris de plus ? Que nous pouvons ajuster le nombre global de problèmes et de défaillances durant une course pour l'ensemble des autos par le réglage de « mechanical_failure_chance » ou/et « mechanical_failure_interval ». Enfin, durant toute course il peut se produire des accidents, résultats probables de dysfonctionnements cachés. Ce taux est de l'ordre de 13% pour 2 autos par course. C'est tout pour les réglages de « gpl_ai.ini ». Voyons maintenant les réglages du fichier « driver.ini » qui affectent la fiabilité. Heureusement, on peut maîtriser la fiabilité individuelle des voitures, pour correspondre à leurs modèles historiques. DRIVER.INI FILE TESTS Voici un exemple de réglage des paramètres du fichier « driver.ini » qui affectent la fiabilité. Ils sont issus directement des réglages d'origine de 1967 pour la Lotus 49 de Jimmy Clark : Notons que nous n'avons aucune idée de l'unité utilisée pour chaque réglage: des pourcentages? Un nombre de défaillances pour 1000 courses ? ... L'addition de tous les réglages individuels donne un total de plus de 500. Pour l'instant, GPL garde son secret ! Tout d'abord, voyons comment les réglages des fichiers « driver.ini » et « gpl_ai.ini » interagissent vis à vis de la fiabilité des autos. Lee réalisa un test 'tous paramètres de « gpl_ai.ini » par défaut', y compris le réglage « mechanical_ failure_chance ». Il GPL AI T LE FEVRE Page 48 fit alors varier les paramètres 'chance' du fichier « driver.ini » pour vérifier leur effet sur la distribution des dysfonctionnements... (Puis sur leur nombre). Tous ces paramètres 'chance' furent réglés à la même valeur. Résultats: Conclusions tirées: 1. Pas d'effet des paramètres de 'chance' du fichier « driver.ini » sur la répartition des dysfonctionnements. 2. Les pourcentages de dysfonctionnement les plus élevés concernent toujours le moteur, en lien avec le réglage de « gpl_ai.ini ». Il s'avère qu'on ne peut contrôler la distribution des dysfonctionnements. Apparemment, cette distribution dépend du réglage de « gpl_ai.ini » ou du programme « gpl.exe » qui impacte identiquement toutes les monoplaces. Résultat décevant, car Lee espérait une maîtrise individuelle des répartitions de dysfonctionnement par voiture... Ainsi, même le fichier « gpl_ai.ini file » n'apparaît pouvoir contrôler totalement cette répartition, car les problèmes 'moteur' sont toujours plus fréquents que d'après le réglage de « gpl_ai.ini ». C'est le programme « gpl.exe » qui a essentiellement la main sur l'obtention de cette distribution. Alors que pouvons nous faire ? Comme dernier test, Lee régla par défaut « gpl_ai.ini », et fit varier les ''chances'' du « driver.ini » pour vérifier leur effet sur le nombre de dysfonctionnements. Chaque paramètre fut réglé à la même valeur. Quarante (40) courses rejouées pour chaque réglage, sur le circuit de Monza. En tout, plus de 300 courses furent réalisées pour aboutir aux résultats suivants : GPL AI T LE FEVRE Page 49 Conclusions tirées de ce test: 1. Les paramètres 'chance' du « driver.ini » ont un effet sur le nombre de dysfonctionnements de chaque voiture, pour des réglages inférieurs à 20. 2. Les paramètres 'chance' du « driver.ini » n'ont pas d'effet au-delà de 20. En plus de ces conclusions, voici quelques commentaires de ce test. Rappelez vous que certains accidents peuvent être, en fait, des dysfonctionnements cachés. Aussi, notons combien les taux de dysfonctionnement sont aléatoires. Avec seulement 40 tests (courses) pour chaque point, le taux de dysfonctionnement n’est pas totalement lissé. Toutefois Lee estime qu'une tendance se dégage. Lorsque le réglage de 'chance' du « driver.ini » est accru, à partir de zéro, le nombre total de dysfonctionnements, avec ou sans accidents, s'accroît aussi, avec une asymptote vers 42% à partir d'un taux de 28%. Cet effet n'est peut-être vrai qu'avec les réglages par défaut des 'chances' du fichier « gpl_ai.ini ». En d'autres termes, avec un « mechanical_failure_chance » plus élevé le réglage 'chance' du « diver.ini » pourrait conduire au-dessus de 20, à certaines différences. Du côté réglage « bas », on peut atteindre des taux de dysfonctionnement moindres, de 11%, comme indiqué par notre essai précédent du « mechanical_failure_chance ». Lee définit une formule de régression pour des réglages de 'chance' compris entre 0 et 20, vis à vis du taux de dysfonctionnement (y compris accidents). La voici: Malfunction Rate = 0.222 + 0.019X - 0.0004X^2 où X = Driver.ini chance (pour 0 < X < 20) Avec un coefficient de détermination de 0.975, cette formule décrit très correctement la relation entre ces paramètres. Nous ne sommes cependant pas tirés d'affaire...Avec un réglage « mechanical_failure_chance » par défaut de 5.00, nous pouvons seulement faire varier le taux de dysfonctionnement de 22% à 42%. Ceci est clairement insuffisant, comme nous le verrons vis à vis des données historiques. Idéalement, il faudrait pouvoir faire varier ce taux de 0 à 100% ! Toutefois, ceci est impossible. Alors, fixons le « mechanical_failure_chance » à 10.0 pour voir quel en est l'effet. Voici le graphe des résultats de cet essai. La régression excellente (r-squared 0.990) obtenue dans ces conditions, devient alors: Malfunction Rate = 0.11065 + 0.02022X - 0.00011X^2 où X = Driver.ini Chance Comme prévu, utiliser un réglage plus élevé en « mechanical_failure_chance » permet de rendre bien plus efficace l'utilisation des paramètres 'chance' du « driver.ini » jusqu'à des réglages de 50 ou plus. Alors, l'étendue d'ajustement du taux de dysfonctionnement est notoirement plus grande, allant de 11% à 85%. GPL AI T LE FEVRE Page 50 RELIABILITY SETTINGS TEST Essayons un test pour contrôler la fiabilité des [AI] autos, sur la base de nos nouvelles connaissances. Voici un exemple à partir des enregistrements historiques de F1 '1969'. La table montre le pourcentage d'abandons ("Did Not Finish") des 7 monoplaces modélisées par GPL. Les données sont tirées du site « F1 Gamers ». 1969 "Did Not Finish" Percentage Globalement, plus de 48% des voitures qui prirent le départ d'une course en 1969 ne purent la terminer ! On note aussi une grande disparité entre les autos. La Matra MS80 fut très fiable pendant que la McLaren M7 fit un peu moins bien. A l'opposé, les Ferrari 312 et Lotus 63 furent catastrophiques ! Pauvre Chris Amon qui finit seulement l'une des six courses auxquelles il participa en Ferrari. Il n'y a pas beaucoup de chance de remporter un championnat avec une si faible fiabilité... La Lotus 49B, par exemple, eut un taux de dysfonctionnement de 50%. Avec la nouvelle formule de régression, on en déduit un réglage de 0.22 pour le paramètre 'chance' du fichier « drv69w.ini ». En faisant de même pour toutes les voitures, on obtient les réglages indiqués ci-après : 1969 Drv69w.ini File Chance Settings Mechanical_Failure_Chance = 10.0 Notre taux de dysfonctionnement désiré globalement, est dépendant du nombre de voitures de chaque type et de leur taux associé. Pour notre fichier « driver.ini » qui mélange 4 Brabham, 3 BRM, 1 Lotus 63, 3 McLaren, 1 Ferrari, 4 Lotus 49B, et 3 Matra, le taux global, moyenne pondérée des 19 voitures, ressort à 48%...soit par simple coïncidence le même que celui réellement obtenu pour l'ensemble des voitures. Rappelons que tous les tests furent réalisés à Monza. Le Grand Prix prend environ 1h 45mn. Ceci est habituellement la course la plus courte d'une saison de F1, les autres durant plutôt 2 heures. Comme elles sont plus longues, on devrait s'attendre à davantage de défaillances que désiré. La question est donc de savoir si ces nouveaux réglages fonctionnent bien. La table qui suit montre les résultats d'un test de 20 courses à Monza. Comme on peut le constater, ces réglages sont capables de contrôler correctement la fiabilité. Ce n'est pas parfait, ni inattendu compte tenu du nombre limité d'essais réalisés. La Lotus 63 a un taux de défaillances légèrement plus bas que voulu, mais il est plutôt juste pour la plupart des autres bolides. GPL AI T LE FEVRE Page 51 Maintenant que nous disposons d'une méthode efficace pour contrôler la fiabilité, elle peut être utilisée pour en dériver les réglages des F1 de 1967 et 1965. Voici donc les tables qui indiquent les réglages adaptés pour obtenir les taux de défaillances voulus (Malf rate) correspondants aux différentes saisons. Les fichiers « driver.ini » qui accompagnent, en annexe, ce tutorial utilisent ces réglages. Il ne vous reste plus qu'à régler à 10.0 le « mechanical_failure_chance » dans chaque « gpl_ai.ini » pour obtenir des taux de défaillances tout à fait acceptables. GPL AI T LE FEVRE Page 52 SUMMARY Si vous êtes parvenus jusqu'ici, vous aurez appris beaucoup sur la façon dont GPL gère les paramètres d'Intelligence Artificielle du fichier « driver.ini » et comment des changements apportés à ces paramètres affectent à la fois les performances en qualification et en course. Vous avez appris une méthode pour contrôler globalement la vitesse des pilotes AI en utilisant le facteur « npt_override », de telle sorte que vous puissiez effectivement en tant que joueur concourir et gagner des courses. De plus, nous avons vu comment quantifier une performance historique du « monde réel ». Nous avons vu 2 méthodes pour ajuster les paramètres des fichiers « driver.ini » ou « gpl_ai.ini » pour que les pilotes AI réalisent des performances aussi proches que possible de leurs homologues réels. Enfin, nous avons réalisé quelques recherches préliminaires vis à vis de la gestion de la fiabilité des autos gérées par GPL, et avons défini comment la contrôler au mieux. Le point important à retenir est qu'il y a très peu de paramètres qui affectent vraiment la performance brute des pilotes AI. Durant une course, seuls les 2 facteurs « hype » et « quickness » ont un effet. En qualification, s'ajoute seulement le paramètre « qualifying ». Comme on peut ajuster aisément la vitesse en course d'un pilote avec le seul facteur « hype », le paramètre « qualifying » intervient alors pour ajuster la vitesse en qualification. Lee espère que vous aurez trouvé ce tutorial pédagogique et qu'il aura généré encore plus d'intérêt sur la façon d'ajuster les paramètres des pilotes et voitures gérés par GPL (AI), afin de mieux encore représenter le monde réel. Il reste tant de travaux à faire dans ce domaine ! Regardez ainsi de temps en temps la multitude de paramètres présents dans le fichier « gpl_ai.ini ». On pourrait y passer une vie entière à modifier toutes ces choses ! Lee inclut dans le tutorial original, à télécharger sur http://gplpp.com, des fichiers « driver.ini » qui décrivent ces nouveaux réglages AI (2 fichiers ''1967'': un pour la première méthode décrite où « hype » et « qualifying » ne sont pas réajustés sur le temps du super pole man, qui utilise alors un « npt_override » = 0.960; et un second pour la 2ième méthode où « hype » et « qualifying » sont réajustées, qui utilise alors un « npt_override » = 1.00. Un fichier pour chaque année 1965 et 1969 ...ces fichiers utilisent un « npt_override » de 1.00). Vous n'avez plus qu'à ajuster le réglage de « mechanical_failure_chance » à 10.0 dans chaque fichier « gpl_ai.ini » pour obtenir un taux de défaillance réaliste pour chaque voiture. Espérons que ces nouveaux réglages rendront votre expérience de simulation de course sur GPL encore plus sympathique et excitante. Souvenez vous que vous pouvez ajuster le « npt_override » de « gpl_ai.ini » pour accélérer ou ralentir globalement l'ensemble des pilotes autant que nécessaire pour réaliser des courses encore plus enthousiasmantes et avoir une meilleure chance de victoire. De même, ajustez le réglage « mechanical_failure_chance » pour contrôler le nombre d'incidents des voitures. Enfin, vous pouvez signaler toute suggestion, remarque ou commentaire via le site « f1legends.ch » ou par message privé (MP) auprès de « CEVERT », ainsi qu’à LEE BOWDEN directement via l'adresse suivante Lee200@earthlink.net. En espérant que ce voyage vous aura aidé à ouvrir de nouvelles portes de votre simulation favorite Grand Prix Legends, Sincèrement vôtre, Tristan. GPL AI T LE FEVRE Page 53 ANNEXE 1: 1967 AI #1 driver.ini FILE SETTINGS / Npt_Override = .960 ANNEXE 2: 1967 AI #2 driver.ini FILE SETTINGS / Npt_Override = 1.000 GPL AI T LE FEVRE Page 54 ANNEXE 3: 1965 driv65.ini FILE SETTINGS / Npt_Override = 1.000 ANNEXE 4: 1969 drv69w.ini FILE SETTINGS / Npt_Override = 1.000