CoreWars - Page 1

Si je dis CoreWars, est-ce que quelqu'un ici connaît ?

Pour ceux qui ne le connaissent pas, c'est un jeu où on simule une mémoire d'ordinateur,
dans laquelle il y a des programmes. Chaque programme essaie de planter, écraser, exploser
les autres tout en survivant. Celui qui reste gagne.

Les programmes sont écrits dans un langage simili-assembleur, mais beaucoup plus réduit et avec très peu
d'instructions, tellement qu'il semble au début impressionant comme tout assembleur, mais se maîtrise vite
en fait.

Ca fait un jeu très marrant, genre guerre de virus, un jeu pour codeurs.
Et on en apprend tous les jours, on voit qu'un des programmes les plus efficaces,
le Imp, est sans doute le plus facile et le plus simple !

j'ai entendu parler et ca pourrait etre assez amusant ;
il va y en avoir un?

Ben, je regarde les gens que ça intéresse, s'il y en a assez, je me lance.

il y en a au moins un

Je crois que je vais le faire. Pas très long, méga-amusant si je le fais bien...

Tu veux faire la VM et l'assembleur?

Oui, en fait c'est pas vraiment un assembleur, c'est un code très simple, le
genre qui passe très bien en langage interprété à codebyte.

Donc voui, il faut faire une VM. Et je vais me lancer. Tiens, et puis je vais essayer maintenant de commencer sous TIGCC/VTI.

Je connais. J'avais envie de le faire, mais sur pc
Mais le programme qui traduit de l'assembleur au bytecode, ça s'appelle un assembleur quand même.
Si tu ne fais que la VM, ça ne sert à rien, vu qu'on ne pourra pas faire de 'vaisseaux'.
Si l'assembleur est sur pc, ça perd beaucoup d'intérêt même si ça peut être intéressant.
Avec un assembleur on calc, ça peut être vraiment sympa.


Sinon tu m'as l'air de connaître des types de stratégie pour les 'vaisseaux', tu pourrais m'en dire plus?

BiHi > Ah je comprends. Ben bien sûr que l'assembleur serait on-calc, le RedCode est un langage très très simple,
ça se fait sans aucun problème. (J'ai cependant eu des merdes avec un autre langage de script que j'ai fait, le
FPScript, et ça a planté, donc il se pourrait que l'assembleur et/ou la VM soient faits en Basic au début.)

Rassurez-vous, le RedCode et le programme sont bien assez simples pour que ça tourne correctement en Basic.
Et même si c'était lent, ça serait pas plus mal, le 68000 est suffisament puissant pour vous expédier une
partie complexe en moins d'une seconde si c'est compilé.

Je me demande bien pour l'interface utilisateur du jeu.
A votre avis, que devrait-elle montrer, et quand ?

Moi, je pencherais pour montrer à la fin de chaque tour (exéc d'une instruction par chaque programme)
l'état du programme, c'est à dire l'instruction où il est ou celle qu'il va exécuter, et ses variables si les
utilisateurs le veulent.

Qu'en pensez-vous ?

Civilisation avec des programmes en guise de tribus... Où une commande prendrait tant de RAM (éq. Or). Où on lancerait une mise à jour qui ferait découvrir de nouvelles commandes.

Vas-y, on te soutient !

Euh c'est clair que pour l'affichage, je ne sais pas très bien.
Mais tu comptes faire la VM et l'interpréteur (tu vas interpréter au lieu d'assembler) en basic?
Si c'est assez rapide, pourquoi pas. Mais c'est quand même plus propre un asm que pleins de fichiers en basic, et puis tu vas sûrement utiliser des librairies, enfin ça serait mieux un fichier asm.

Non, je ne sais pas encore.
Je pourrais interpréter avec flib -> fonctions textes, ce qui serait plus simple,
ou assembler en bytecode, plus rapide, rendant la VM rapidement convertible en C.

Pour la version Basic, je ferai le plus rapide des deux. Mais je compte à terme faire
une version C, c'est plus sérieux.

Et puis, peut-être qu'il n'y aura même pas de VM en Basic. Après tout, c'est assez simple si j'assemble.
Mais l'assembleur sera fait en Basic certainement. L'assemblage ne sera pas long pour autant car
le nombre d'opcodes est très faible.

Et puis t'inquiètes pas pour plein de fichiers Basic, je suis très très propre de ce côté là.
Tout d'abord, un assembleur ou un interpréteur n'a besoin que d'un fichier, et comme je
fais du Flib, je fais un groupe s'il y en a besoin de plusieurs.

Ca ferait 4 fichiers à tout casser (flib, flib2, le prog et le groupe)
Et ça encore, j'ai bien dit qu'un assembleur ou un interpréteur peut se faire en un seul prog Basic.
De plus flib n'est pas nécessaire pour un assembleur.
Donc 2 fichiers: le prog + flib2.

lol un coreware en basic+flib. Va falloir être patient

Autre chose, en faveur du Basic pour la VM cette fois:

la portabilité. Bien sûr, si je le fais en C, je peux faire une verison 89 (j'ai une 92+)
mais hélas, je vais beaucoup plus m'emmerder. En Basic, c'est bien plus
facile, et si je décide de faire les dialogues en boites de dialogue,
y'a carrément plus besoin d'adaptation.

Si il y a une différence entre 92+ et 89 au niveau des boîtes de dialogue.

[Edit: sinon tu veux pas me parler des stratégies possibles des vaisseaux? (si tu sais quelque chose là-dessus...)]

Niveau portabilité, je te recommenderais plutôt le C qui te permet en plus de faire une version PC

Si il y a une différence entre 92+ et 89 au niveau des boîtes de dialogue.

Dans la police employée. Au niveau du Basic, la seule différence c'est que la TI-92+ peut mettre
moins de caractères que la TI-89 car elle n'essaie jamais d'utiliser la petite police.

C'est pour ça que pas mal de progs Basic pour 89 font une erreur Dimension sur les dialogues quand on les met sur
92+.

Mais là, ça marchera sans problème puisque je le ferais avant tout pour 92+ (on se demande pk )
et qu'au moment de le paser sur 89 les dialogues passent très bien? Côté portabilité, en Basic
c'est méga-facile.

Edit: sinon tu veux pas me parler des stratégies possibles des vaisseaux? (si tu sais quelque chose là-dessus...)]

Euh, pour ça il faudra que tu voie toi-même. Leurs possibilités viennent directement de celles du RedCode,
bien sûr.

La plupart du temps, il peuvent se scinder en plusieurs processus, ont un espace propre pour leurs variables
et tentent de se bousiller en écrasant les données des autres par exemple.

Exemple; le Imp:

mov 0,1

(une seule ligne !!!)

Il va copier l'instruction 0 à partir de l'actuelle (donc cette instruction, l'Imp lui-même) à
l'emplacement d'instruction suivant. Ainsi, il se copie en fait indéfiniment d'espace en espace,
écrabouillant le reste des progs.

Comme la VM exécute à chaque fois une instruction d'un programme, puis une d'un autre etc pour faire
une exécution assez simultanée, tout programme touché par un Imp contient son code et va commencer à copier
l'instruction du Imp: les programmes touchés par un Imp se mettent eux-mêmes à faire exactement
comme s'ils étaient des Imp, ils sont transformés. Ca fait le prog genre agent Smith.

C'est génial, hein ?

Après, on peut faire des tonnes de stratégies, des progs plus gros essayent par exemple de détecter les
autres progs et de se défendre contre eux.

Pollux > Mais ça existe déjà.

Ué on doit pas avoir le même code (ce que tu appelles le RedCode)
Tu pourrais mettre la liste des instructions et opcodes associés?

OK. Alors quel est l'intérêt de le faire on-calc, puisque a priori on va confronter des programmes venant d'internet, donc la plate-forme la plus logique serait le PC ?

La référence complète est là: http://www.sci.fi/~iltzu/corewar/guide.html

(Edit: toute le guide, pas que la partie sur les tests)

Tu peux ainsi constater qu'il n'y a que 19 instructions, rendant cela faisable même en Basic.

Mais attention, Basic != nul. C'est vraiment un jeu super.
Et une fois les port effectué, les joueurs TI trouveront plein de sites sur CoreWars,
pour trouver des nouvelles idées de progs, en télécharger...

Ben ça dépend. Je connais pas du tout le principe mais si ça peut tourner en basic, pourquoi pas.

Bon, sens de l'honneur oblige, je vais essayer de faire ça en C.
Mais c'est capable de tourner en Basic.

Le jeu a les avantages d'être un défi (comment détecter un Imp ?)
et de faire joliment réfléchir (au final, autant que sur du code asm pur, ou pour
ceux qui connaissent pas, sur un algol chaud)

Et puis, chacun se bricole son propre programme.
Bon je commence à bucher ça sérieusement, je vais commencer le coding d'une VM.
(Il faudra donc un assembleur plus tard, mais comme je suis sûr de pouvoir le faire,
ne serait-ce qu'en Basic, je me préoccupe de la VM d'abord, parceque ça me plaît plus)

Faudrait que je lise les regles, à partir du moment ou c'est faisable en basic, j'essayerais peut-être pendant mes heures de cours perdues :]

./22 pour les règles.
Ca va pas être si facile que ça à programmer, mais en C ça ira.

Mouais. Pas super engageant comme lecture pour un truc censé être un test
Je vais plutot suivre l'évolution du topic #pasqueçaafoutre#

Vertyos > Euh je me suis gouré, j'ai inclus le label dedans alors que je voulais désigner la page,
pas spécialement cette partie sur les tests.
J'édite.

Nan mais en fait j'ai même pas lu, c'est une grosse page de texte bien moche en anglais, pas mon genre de lecture favorite, donc j'ai fermé sans même regarder
Disons que quand je recherche un truc précis j'ai pas trop le choix, mais là si

OK. Donc le topic ne te motive pas assez pour que tu te fasses chier à lire la doc ENG ?
T'as bien raison.