Pollux a écrit :
Mouais, y a des défauts, notamment (pour le cas d'une IA en C) :
- obligé de tout sauvegarder dans des variables globales du TIOS, c'est un gros problème surtout si ces variables globales contiennent des pointeurs (l'adresse du programme peut changer d'un appel sur l'autre), donc il faut faire des grosses routines d'import/export...
A quoi sert de garder l'adresse des programmes appelés ?
A chaque demi-coup, le programme de l'IA qui doit jouer est lancé, s'execute, puis s'achève normalement en indiquant le résultat de ses réflexions dans un format compréhensible par tout programme, à savoir les variables TI.
- API hyper-compliquée pour des raisons que j'ai du mal à comprendre... (pk l'IA devrait avoir qqch à faire du type de calc ??? pk l'IA doit être prévenue du résultat ??? pk demander son nom à l'IA ?)
1/ Comme chaque IA disposant, en bonus du seul calcul du coup à jouer, d'une petite zone graphique où elle est libre d'afficher ce qu'elle veut (ne serait-ce que des infos de debug), il vaut mieux qu'elle sache la taille et la position de cette zone, laquelle dépend de la taille de l'écran, et donc de la calculatrice.
2/ Chaque IA est prévenue du résultat final de la partie qu'elle vient de jouer afin qu'elle puisse réagir en conséquence pour ses futures parties.
Si j'empêchais cela, j'interdirais du même coup toute les IA auto-évolutives (Réseaux de Neurones Formels + Algorithmes Génétiques par exemple).
Et pour les autres IA, tant pis, elles n'ont qu'à pas tenir compte du résultat si elles n'en n'ont pas envie : l'arbitre propose, les IA disposent.
3/ A la fin d'une partie, l'arbitre affiche à destination de l'humain qui attend derrière sa calculatrice le résultat.
Et plutôt que d'annoncer un laconique 'Joueur 1 vainqueur', je préfère ajouter un nom.
Ainsi, lors de la grande compétition finale lancée par ce topic, on saura beaucoup plus facilement le résultat du match entre EthanIA et Pollux4 (ou tout autre nom que tu choisira pour ton IA), sans avoir à se prendre la tête de se souvenir à chaque partie qui est le joueur 1 et qui est le joueur 2.
Comme pour le premier point, c'est un bonus pour rendre plus convivial les matchs.
Plus l'arbitre disposera de ce genre de détails pouvant être utiles, plus il sera complet, sans avoir à rajouter quelques lignes de code chaque fois que l'on s'aperçoit qu'une petite feature serait pratique.
Evidemment, je ne prétends pas avoir inclus toutes les features pouvant être utiles, mais j'ai tenté de m'en approcher en programmant toutes celles auxquelles j'ai pensé.
[cite]Il suffirait de faire simplement :
void ia_init();
int ia_getmove();
void ia_setmove(int);[/pre]
Par exemple une solution serait de passer par le chargement à la demande des libs par PreOS, il suffirait de faire arbitre("prog1","prog2"), avec prog1 et prog2 se présentant sous la forme de libs dynamiques contenant ces 3 fonctions...
Le jour où tout le monde ici saura faire des librairies dynamiques, on en reparlera
...
Ca exclut évidemment les IA en Basic, mais bon de toute façon c pas très réaliste de vouloir faire un truc en TI-Basic qui joue mieux que s'il jouait au hasard ^^
Ho l'autre, hé ! Même pas vrai d'abord !
Mon IA marche très bien, d'abord
!
Non mais c'est quoi cette discrimination envers le TI-Basic ?
C'est comme ceux qui critiquent le fait que je ne programme sur x86 qu'en Asm alors qu'ils trouvent que c'est un
vieux langage pourri 
...
@++
)
!
...
...
