Ich stimme da MQ im Prinzip zu.
Das Problem an diesem Contest ist, dass die Teilnehmer zu viele Freiheiten beim erstellen der Roboter haben.

Wenn das ganze ein wahrer "KI"-Contest werden soll, sollten eigentlich alle Aktionen der Roboter vorprogrammiert sein und der Teilnehmer muss nur noch eine Prozedur schreiben, mit der die Aktionen zum Zeitpunkt t ausgewählt werden.

Und selbst wenn man darüber hinaus auch noch flexible Aktionen erlauben will, so sollte doch zumindest die Kollisionsabfrage festgelegt werden oder generell die Art, wie die Roboter getroffen werden.

Denn ansonsten kann man schon alleine bei der Kollisionsabfrage ziemlich viel rumcheaten, z.B. eine Treffer-Abfrage mit Pixel-Coordinaten um das eigentliche Event herum.

Und Schluss endlich wird es ein Theater werden, die ganzen Roboter gegeneinander tatsächlich antreten zu lassen.
Denn so wie ich das lese, müssen die Roboter nichtmal die richten Event IDs haben, sondern der Organisator will das entsprechend anpassen.
An jenen Organisator: Ist dir klar, was für ein Aufwand das sein kann?
Theoretisch kann man beliebig oft im Event Skript Werte von anderen Events abfragen und das müsste alles angepasst werden.

Also das mindestes was meiner Meinung nach so ein Contest brauch, ist ein Muster-Projekt, dass die Teilnehmer dann erweitern können, wo alles, was vorrausgesetzt wird, bereits implementiert ist. Das Minimum dafür ist:
- Kollisionsabfrage.
- HP-Änderung-Funktionen der Roboter (am besten direkt von der Kollisionsabfrage aus aufgerufen und nicht vom Skript des Teilnehmers...)
- Wann der Kampf beendet wird.

Der Teilnehmer sollte eigentlich nur folgendes implementieren:
- Wie sich der Roboter bewegt.
- Wie der Roboter seine Schüss abschießt und wie diese herumfliegen

Da die Regeln ja schon jetzt einige einschränkungen bei den Schussbahnen machen, würde ich gerade diese einfach vorprogrammiren.
Alles was der Spieler dann machen müsste, wäre an einer Stelle im Skript ein paar Werte setzen (Flugrichtung, Geschossart usw.) und dann einfach einen Switch anzusetzen, damit das Event AUTOMATISCH (so wie vorgegeben) vom Roboter fliegt wie es soll...

Also insgesammt gefällt mir die Idee für den Contest schon, aber so wie er hier gestellt ist, wird er
1. Kaum Teilnehmer finden, da viel zu viel kram selber implementiert werden muss, was lange dauert.
2. im Endeffekt daran scheitern, das zuviel unterschiedlicher Code synchronisiert werden muss, da es viel zu wenig einschränkungen gibt und keine Vorlage.

Also ich würde am ehesten einen Neuanfang vorschlagen. So ein Contest muss besser vorgeplant sein.

Aber selbst wenn man eine gute und einfach bedienbare Vorlage anbietet, wird es schwer, genug Teilnehmer zu finden. Ich denke zwar schon, dass es mehr als 2 sein werden, aber dennoch. Und im Endeffekt ist auch die Frage, wer das ganze durchzieht.

@V-King: Nein, es würde nicht ewig lange dauern, so eine KI zu basteln, sofern es keine Super-KI ist. Du übertreibst da etwas, imho.
Und nein: Ein Kampf zwischen zwei KIs sollte, abgesehen von den Fehlern wegen der Incompatibilität, keinen relativ modernen (3-5 Jahre alten) Rechner in die Knie zwingen, sofern elementare Grundregeln, wie das einhalten einiger Wartepausen in Schleifen, beachtet werden und die Teilnehmer nicht auf die Idee kommen, irgendwelche tollen A*-Algorithmen und der gleichen mit dem Maker umzusetzen (aber wer sowas drauf hat, kann es auch performant hinbekommen)
Und nein: Ich kann keine Performance-Wunder auf dem rm2k schaffen.
Das Ballspiel würde auf besagten 400 MHz Rechner stocken. Sehr.

C ya

Lachsen