BCC17 KI-Contest - Themendiskussion
Übersicht
Sonstiges Smalltalk
BIG BUG |
 Do, Mai 15, 2008 20:57Antworten mit Zitat 
|
|
|---|---|---|
|
Um ehrlich zu sein verstehe ich es wirklich nicht.
Wie Silver_Knee und Mahe schon sagten ist es quasi wie ein Live-Include. Nur der Rest der Posts von Silver_Knee ist leider schlicht und ergreifen falsch. Da der Syntax-Check sowieso auch vom Script aus erfolgt kann jeder Editor verwendet werden, z.B. auch BlitzMax. Es wird also keiner ausgeschlossen, sondern im Gegenteil kann sich sogar jeder bei gleichen Chancen beteiligen, egal welche Version er benutzt. Außerdem ist jede KI komplett abgekapselt, daher kann es nicht zu Überschneidungen von globalen Variablen kommen und der sicht- und änderbare Bereich ist genau definiert. Man hat also alle Vorteile eines Includes wie generell viel einfacher(in KI-Entwicklung speziell beim Testen, Rahmen-Entwicklung, Bedienung/Abwicklung), Robustheit und Geschwindigkeit/Echtzeitverarbeitung, aber keinen der Nachteile. Das einzige Gegenargument dass dass man vielleicht noch gelten lassen könnte, ist dass BriskVM BlitzBasic-Syntax ist und sich BlitzMaxler damit minimal umstellen müssten. Andererseits ist es dadurch aber auch wieder gerechter, da gleiche Voraussetzungen für alle herrschen. Bedenkt bitte auch, dass bei einer netzwerkbasierten Lösung die Ausscheidung natürlich nur LOKAL statt finden wird, da sonst mehr von der Netzwerkverbindung als von der KI abhängt! Sorry, aber was und vor allem wie hier manche schreiben klingt mehr nach unseren griechischen Freund Korinthos Kakis als nach einer sauberen Argumentation. --- Und es gibt keine Regeln, wie eine BlitzCompo genau auszusehen hat. Bloss weil man es immer auf eine Weise gemacht hat, muss man nicht so fortfahren, obwohl es offensichtlich auch andere und in diesem Fall sogar einen besseren Ansatz gibt(siehe 3 Absätze weiter oben, bzgl. Vorteile von Include gegen Netzwerk) Da aber natürlich möglichst viele User Spaß an der Sache haben sollen hole ich mir ja gerade die Meinungen ein, aber man wird es nie allen Recht machen können. Auch wenn ich finde, dass das gut in den BCC passt, habe ich das Ganze jetzt trotzdem einfach mal in KI-Contest umbenannt . Der BCC17 dürfte halt dann vom Gewinner des KI-Contests abgehalten werden. --- Damit wir hier uns aber nicht schwarz diskutieren und um das Thema voranzutreiben habe ich jetzt einen Zeitplan aufgestellt: An diesem Wochenende wird das Konzept festgezurrt, ggf. wird es noch eine Abstimmung geben. Danach werden die nötigen Vorbereitungen getroffen(Rahmenprogramm). Ich plane den Contest dann an nächstem Wochenende zu beginnen(ka. ob Fr/Sa/So, halt so früh wie möglich) Wer also neben der BriskVM-Diskussion noch Vorschläge hat oder etwas zu bestehenden Vorschlägen sagen möchte sollte das bitte jetzt tun. |
||
|
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
||
|
BladeRunnerModerator |
Do, Mai 15, 2008 21:03 Antworten mit Zitat
|
|---|---|---|
|
Meine 2Ct: Ich war wegen der BriskVM-Sache auch erstmal skeptisch, da ich auch das "Blitz" im BCC im Vordergrund sah. Schaut man jedoch näher hin halte ich es für eine faire und runde Sache, ab von einem Wehrmutstropfen: Als Bmaxler muss man sich zurück in die BB-Syntax finden, und das hat ein paar Fallstricke.
Von der Ausführbarkeit als solches ist es jedoch eine Überlegung wert. |
||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
BIG BUG |
Fr, Mai 16, 2008 9:35 Antworten mit Zitat
|
|
|---|---|---|
|
Auch wenn ich persönlich nach wie vor die Brisk-Lösung präferiere wird der Contest jetzt auf Netzwerkbasis ablaufen.
Dafür bedanken könnt ihr Euch hauptsächlich bei Noobody der wie manch anderer hier nicht nur einfach rumgemeckert hat, sondern Initiative gezeigt hat indem er sich einfach bei mir per PM gemeldet hatte und gleich an einer Lösung gearbeitet hat. Der zweite Grund ist, dass es für keine der beiden Lösungen Erfahrungswerte gibt, aber man ja mit irgendwas anfangen muss. Bin dann mal gespannt ob von den Brisk-Gegnern jetzt dann doch ein paar beim Contest mitmachen würden oder hier nur um das Meckerns Willen gepostet wurde. 
Daher bitte ich noch um Meinungen und Vorschläge zum Thema an sich. Für den Anfang halte ich die Shooter-Lösung nach wie vor für keine schlechte Wahl. Ich stelle mir das Ganze so vor, dass man immer die Positionen aller Gegner kennt, die herumfliegenden Schüsse sind aber nur in einem bestimmten Sichtfeld bekannt. Ansonsten denke ich bei der 4-Richtungen-Lösung kommt mehr Taktik auf und es können auch Leute mitmachen, die mit Trigometrie auf Kriegsfuß stehen. Was denkt ihr? |
||
|
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
||
|
DAK |
Fr, Mai 16, 2008 11:38 Antworten mit Zitat
|
|---|---|---|
|
joa, klingt gut... wie schauts mit schussgeschwindigkeit im vergleich zu fahrgeschwindigkeit aus?
kennen die Bots die ganze map? |
||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
|
Silver_Knee |
Fr, Mai 16, 2008 13:25 Antworten mit Zitat
|
|---|---|---|
|
fein die gegner sind trotzdem frei drehbar?
|
||
|
Noobody |
Fr, Mai 16, 2008 16:07 Antworten mit Zitat
|
|---|---|---|
|
Theoretisch sind sie frei drehbar, da sowohl bei der Schussberechnung als auch bei der Spielerdrehung alle 360° in Betracht gezogen werden (nur muss dann beim Grafikteil des Servers noch ein wenig rumgemurkst werden, um das darzustellen).
Das mit dem Sichtradius, in dem Gegner/Schüsse sichtbar sind, ist so eine Sache. Schliesslich wird nur etwas übetragen, wenn ein Spieler schiesst, der Rest muss jeder Client lokal berechnen (wie es grundsätzlich auch sein sollte bei Netzwerkspielen). Würde man die Methode mit dem Sichtradius wählen, so müsste der Server überprüfen, ob der Spieler/Schuss im Sichtfeld liegt und dann die Position übertragen, was bei vielen Schüssen und mehreren Clients dem Server das Genick bricht. Die Map wird ausserdem am Anfang übertragen, dass heisst, dass jeder Bot die ganze Map kennt. Könnte man auch abändern, wenn das gewünscht wird. Die Schussgeschwindigkeit ist frei änderbar (Konstanten <3), das muss dan vor allem BIG BUG entscheiden. Wenn BIG BUG sich dazu entscheidet, die Codes zu nehmen, dann werde ich hier noch eine kleine Dokumentation zu den Netzwerknachrichten posten. |
||
| Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun | ||
BIG BUG |
Fr, Mai 16, 2008 19:52 Antworten mit Zitat
|
|
|---|---|---|
|
Wollte auf folgendes Spiel in einer abgeänderten Version verwenden(siehe auch allererster Post):
http://www.mein-murks.de/software/speeder.zip Man kann sich also unabhängig von der Bewegungsrichtung komplett 360° drehen aber halt in 90° Schritten. Die Schüsse sollte man vielleicht noch schneller machen, dass die Schüsse sich auch gegenseitig Treffen können wollte ich auch gerne behalten. Was mir an freier Drehung nämlich nicht so gefällt ist, dass man im Prinzip jeden Gegner beschießen kann, falls die Luftlinie frei ist. Durch das Vier-Richtungsprinzip muss man sich erst in Position bringen. Dadurch ist eine defensive Haltung generell vorteilhaft, aber Punkte gibts ja nur für Abschüsse, was ein aggressives Vorgehen notwendig macht. Am Besten ist also eine Mischung aus beiden. Außerdem kann die Map so sehr einfach gehalten werden, was die Programmierung erleichtert.(leere Map wäre sogar auch denkbar). Dachte hier an sowas: 
Weiss ist Wand Rot sind Startpunkte Bin aber natürlich nach wie vor für Vorschläge offen. |
||
|
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
||
|
ChaosCoder |
Fr, Mai 16, 2008 20:10 Antworten mit Zitat
|
|---|---|---|
|
Naja, ich finde ne Tilemap immernoch besser => anständiges pathfinding und einen bot zu schreiben der sich z.B. immer in deckung bringt ist damit auch viel einfacher als es bei einer freien pixel zu pixel kollision wäre...
90° ist ja dann auch okay, wie ich es schonmal in nem früheren post angemerkt habe. und frei drehbar ist ein muss!
|
||
|
Projekte: Geolaria | aNemy
Webseite: chaosspace.de |
||
|
Geeecko |
Sa, Mai 17, 2008 10:33 Antworten mit Zitat
|
|---|---|---|
|
Tipp für die Netzwerklösung:
Ich würde das Protokoll ähnlich wie das OSCAR Protokoll machen. Also ungefähr so: +------------------------------+ |...........CHANNEL ID..........| .Auf welchem Channel bearbeitet werden soll. Channel 1 ist z.b. für Login +------------------------------+ |.........PAKET ANZAHL........| .Wieviel Pakete übertragen werden. (So lassen sich mehrere Informationen übertragen) +------------------------------+ ################### #####PAKET 1########## .Hier werden die ganzen Pakete dran gehangen #+------------------------------+# #|...........PAKET TYP.............|# .Welcher PaketTyp es ist. z.b. 1 für Login Name #+------------------------------+# #|.............VALUE.................|# .Inhalt des Paketes. Kann alles sein, ob string oder INT Float... #+------------------------------+# #################### Bei PaketTyp: 1 Kann z.b. mehrere Bedeutungen haben. Das kommt dann aber auf die Channel ID an. Wenn channel ID auf "login" (1) steht, bedeutet Packer TYP 1 Login Name. Ist Channel ID auf "Move" (2) gestellt, bedeutet Packet TYP 1 z.b. X Position. Es lassen sich belibig viele Pakete anhängen. Muss aber in der PaketAnzahl gesendet werden, wie viele Pakete vorhanden sind. Was haltet ihr davon? Edit: Nochmal ordentlich: +------------------------------+ |...........CHANNEL ID..........| +------------------------------+ |.........PAKET ANZAHL........| +------------------------------+ ################### #####PAKET 1########## #+------------------------------+# #|...........PAKET TYP.............|# #+------------------------------+# #|.............VALUE.................|# #+------------------------------+# #################### |
||
|
|
Silver_Knee |
Sa, Mai 17, 2008 11:17 Antworten mit Zitat
|
|---|---|---|
|
Ich mach eigendlich immer schon:
Channel <Byte> Information <Alles mögliche> Je nach Channel variiert die anzahl der ausgelesenen Bytes und auch deren Bedeutung... 0 heißt dann login: Information wäre dann: Int für die länge des Namens und darauf folgend der Name... oder 1 Für gehe und als Information ein Byte mit 1,2,3,4 für die Richtung.... |
||
BIG BUG |
Sa, Mai 17, 2008 12:51 Antworten mit Zitat
|
|
|---|---|---|
|
@Chaos: Die Map ist natürlich schon als Tilemap abgebildet. Das Ganze sollte nur den Aufbau beschreiben, den ich mir vorstelle.
Die Map wird als rechteckige Tilemap abgebildet, wobei immer nur ein komplettes Tile entweder Mauer oder frei ist. Schrägen oder so gibt es also nicht. Zusätzlich vielleicht auch als Type, so dass sich der Entwickler selbst raussuchen kann, was ihm besser gefällt. Die Schüsse und die Spieler stelle ich alle auf Kreis-Kollision um, so dass es einfach 2 Konstanten gibt, die jeweils den Radius des Spieler und den Radius des Schusses beinhalten. Hatte 2 Spielmodus vorgesehen: 1. Deathmatch mit mehreren KIs mit Zeitablauf. Wird man abgeschossen, wird man einfach nach kurzer Auszeit wieder respawned. 2. Last-Team-Standing. Hier kämpfen immer nur zwei KIs, jede steuert aber ein Team aus 3 oder 4 Raumschiffen. Respawns gibt es nicht. Auch hier gibt es einen Zeitablauf, falls zwei "Camper-KIs" aufeinander treffen. Bei Zeitablauf gewinnt die KI die besser dasteht. Also mehr Player übrig hat oder bei gleicher Anzahl in Summe weniger beschädigt ist. Ein Sieg gibt 3 Punkte, ein Unentschieden 1 Punkt. Der technische Ablauf sieht so aus, dass die KI für jedes gesteuerte Raumschiff aufgerufen wird. D.h. eine DeathMatch-KI kann theoretisch ohne Änderungen auch ein Last-Team-Standing spielen. Zumindest das Angreifen der Teamkameraden sollte man hier aber verhindern
Die KI hat immer den kompletten Status aller Gegner zur Verfügung, also auch wer wie stark beschädigt ist und wieviele Kills/Deaths hat. Ebenso ist bekannt, wieviel Zeit noch bis zum Ende der Runde verbleibt. Ob man diese Informationen berücksichtigt bleibt aber einem selbst überlassen. Der Aufruf der KI erfolgt in bestimmten Intervallen z.B. alle 4 Verabeitungszyklen in denen diese mit neuen Positionen/Informationen, etc. versorgt wird. Pro Intervall kann auch nur eine Antwort zurückgegeben werden, die die Steuerkommandos enthält. Die Ki wird also durch das Rahmenprogramm "getriggert". Ist die KI-Verarbeitung durch, so erfolgt ein Delay, um das System zu entlasten. Die ganze Netzwerkgeschichte läuft im Hintergrund, so dass der Entwickler davon nicht viel mitkriegt, außer halt, dass er zum Testen den Server öffnen muss. Das Client-Framework wird als Include/Modul fertig bereitgestellt und enthält die komplette Netzwerkkommunikation. Eine Grafikausgabe erfolgt nur im Rahmenprogramm. Auch wenn ich euer Interesse gut finde, brauchen wir zum Netzwerk im Moment nicht zu diskutieren, denn das muss ja "nur" funktionieren. Ich werde aber natürlich über den aktuellen Stand der Entwicklungen informieren und ggf. Vorabtests bereit stellen, so dass hier natürlich noch Einwände gebracht werden können. |
||
|
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
||
|
Vincent |
Do, Mai 22, 2008 11:44 Antworten mit Zitat
|
|---|---|---|
|
Hallo !
Das gesammte Spiel muss in Spielrunden ablaufen. Jeder Bot bekommt seine Anweisungen für die nächste Runde ( Drehen, Laufen, Schiessen, .. evtl Schauen ). Wenn alle Anweisungen fertig gesendet und berechnet wurden, wird die Spielrunde ausgeführt. Die Ergebnisse der Spielrunde ( Hinderniskollisionen, erhaltener/ausgeteilter Schaden, ... evtl gesehene Gegner ) werden mitgeteilt, gespeichert und für die nächste Spielrunde ausgewertet. Da kling alles sehr statisch, wird aber durch die Schnelligkeit der Rechner sehr dynamisch und actionreich ablaufen können. Zudem kann man durch das Rundensystem klarer planen. |
||
| Gott ist nicht mit uns ... weil er mit Idioten keine Gnade kennt ! | ||
|
|
Silver_Knee |
Do, Mai 22, 2008 12:36 Antworten mit Zitat
|
|---|---|---|
| Runden wären auch für TCP besser... dann brauch sich keiner mit der Unsicherheit des UD-Protokolls rumschlagen und kann sich mehr auf die Intelligente KI konzentrieren | ||
BIG BUG |
Do, Mai 22, 2008 13:15 Antworten mit Zitat
|
|
|---|---|---|
|
Jo, da ja jede KI mit den aktuellen Daten getriggert wird und darauf genau eine Antwort sendet(welche alle durchzuführenden Aktionen enthält) ist das ganze ja rundenähnlich. Allerdings wollte ich nicht warten bis jede KI "ihren Zug" getätigt hat, sondern das Spiel läuft in der Zeit parallel weiter. So hat eine schnelle KI quasi Echtzeitverbuchung, eine langsame halt dann 1 oder 2 Zyklen "Verspätung"(wobei es wahrscheinlich sowieso nicht ganz einfach ist eine so langsame KI zu schreiben ).
|
||
|
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
||
Übersicht
Sonstiges Smalltalk
Powered by phpBB © 2001 - 2006, phpBB Group