Vorstellung Projekt Podball - Futuristisches Ballspiel, Programmierwettbewerb

scrontch

Hallo,
Danke für dein Interesse am Spiel!
In den letzten Wochen ist die Entwicklung wieder etwas eingeschlafen, da es bisher auf wenig Interesse gestoßen ist. Aber Interesse motiviert! Deshalb werd ich mir deine sehr konstruktiven Kommentare zu Herzen nehmen wo es geht.

wubsnack schrieb:

Die Doku um einen Lua-bot zu schreiben scheint mir leider noch nicht sehr vollständig. Für so ein Programmier-spiel ist das doch eigentlich mit das wichtigste.
http://sourceforge.net/p/podball/wiki/PodballModLua/
zB steht da nur function getTeamActions(world) aber nicht was genau diese Funktion denn return'en kann. Oder auch "wie kann ich denn die Position vom Ball erfahren?"
Der lea.lua Demobot erklärt manches aber ein richtiger Ersatz für eine Doku ist es leider nicht.

Stimme zu. Die Lua-Sache ist ganz neu. Erst grad vor ein paar Wochen fertig geworden.
Da muss ich was die Doku angeht noch nachbessern. Wobei es klar der Sinn des Lea Demobots ist als Tutorial zu fungieren.

wubsnack schrieb:

Vorschlag: Die Variablen/Funktionen die Podball bereit stellt in einen eigenen Table packen. Also zB podball.matchSettingsParam und podball.getTeamActions
Beim lesen von scripts (zB lea.lua) ist sonst nicht gut ersichtlich welche Variable/Funktion vom script selbst kommt und was vom "Hostprogramm" stammt.

Verstehe ich nicht ganz. Ah, du meinst quasi als eine Art "namespace".
Also dich stört das gameSettings, matchSettings usw global definiert sind?
Ok, stimmt. Aber das ist dann ja Sache des Scripts, oder?

wubsnack schrieb:

Konstanten wie das hier:
-- Constants for convenience
local NO_TEAM = -1
local OUR_TEAM = 0
local OTHER_TEAM = 1
local ACTION_NOTHING = 0
local ACTION_MOVE = 1
local ACTION_SHOOT = 2
sollten imo auch vom Spiel "gestellt" werden und nicht per Bot selbst definiert werden müssen.
Also podball.ACTION_SHOOT etc

Ok. Aber ich würde die Definition troztdem noch im Script lassen.
Das Interface zum Hostprogramm besteht halt nur aus dem numerische Wert. Die Bezeichner muss das Script selbst definieren.
Ich werd aber definitiv Lea anpassen in diesem Sinn anpassen.

wubsnack schrieb:

Bei anderen programmier-die-KI-Spielen fand ich es immer sehr schade wenn es kaum Möglichkeiten zum "debuggen" gab.
zB schon eine malePunktAufSpielfeld (x, y) Funktion wäre nützlich. Ich glaube sonst kann es doch recht frustig werden, so ganz "blind", weil es doch sehr viel um Koordinaten uä geht.
Zum Beispiel um die Soll-Positionen der Pods zu kontrollieren wäre es doch schön wenn man sich aufmalen könnte ob zB das hier so aussieht wie man es sich vorgestellt hat:
for i=1,gameSettings.NPODS do
 FIELD_POSITIONS[i] = vector(-math.cos(i*2*math.pi/gameSettings.NPODS)*0.28,
 math.sin(i*2*math.pi/gameSettings.NPODS)*0.22)
end
3b) step-by-step könnte nützlich sein

3c) Mit print ("bla") kann man zumindest ein bischen debuggen. Aber beide Bots spammen in das gleiche Konsolenfenster, vielleicht ein eigenes Fenster pro Team.

Vollkommen einverstanden. Manche Sachen sind aber relativ "teuer" zu machen, so dass ich bei meiner eingeschränkt zur Verfügung stehenden Zeit da eine Auswahl treffen muss. Aber ich werd mal schauen was ich machen kann.
(Natürlich darf mir auch gern jeder selbst Patches einreichen die ich dann gerne aufnehm. ,) )

scrontch

Als Motivation für dich und andere:
Nachdem ihr den eingebauten "dummy" Bot besiegt habt (dürfte nicht allzu schwer sein) warten noch zwei weitere Bots auf euch, die nicht offiziell Teil des Projekts sind.
Schwierigkeitsklasse "gut" und "verdammt gut"

wubsnack

Ok. Aber ich würde die Definition troztdem noch im Script lassen.
Das Interface zum Hostprogramm besteht halt nur aus dem numerische Wert. Die Bezeichner muss das Script selbst definieren.

Was ich meinte:
Im Moment muss sich jedes Script sowas einfügen:

local ACTION_NOTHING = 0
local ACTION_MOVE = 1
local ACTION_SHOOT = 2

(oder halt direkt Zahlen verwenden)

Aber für diese Konstanten könnte es ja auch ein constants geben.
constants.ACTION_MOVE, constants.ACTION_SHOOT usw ähnlich wie es zB schon gameSettings.NPODS gibt.

Vorteil von so einem "namespace Table" ist dass man reingucken kann, zB so:

for key,value in pairs(t) do 
  print(key,value)
end

Bzw für verschachelte Tables: https://gist.github.com/stuby/5445834#file-rprint-lua
Mit rprint (constants) könnte man dann alle "values und keys" die im constants table enthalten sind, anzeigen lassen.
ergibt zB für world:
http://pastebin.com/N4aRGnXx
Finde ich ganz nützlich um zu gucken was für Konstanten/Variablen/Funktionen es überhaupt gibt. (zB ball.status und den score habe ich so entdeckt)
Aber soooo wichtig ist es dann auch nicht und habe eigentlich auch nicht so richtig Ahnung davon

-world.ball.owningpod und world.ball.owningteam:
Wenn der Spieler den Ball wegschiesst wird das nicht reseted?
Also world.ball.owningpod ist immer die Nummer vom Spieler der den Ball zuletzt hatte - auch wenn er ihn nicht mehr hat.
Das fand ich erst etwas seltsam (erschien buggy) aber dann gesehen dass es noch world.ball.status gibt um zu gucken ob der Ball frei oder "getragen" ist.

-Die SpielerIndexes im Lua gehen 1 bis 1 to NPODS, im Spiel sind die Nummer aber 0 bis NPODS-1, bischen verwirrend.
Wenn man es ändert passt es aber für die C++ Bots nicht mehr...?

Mein erster Versuch:
www.youtube.com/watch?v=_rAzLDn3UXY
(mit Tipfehler, darum rennen auch mal alle an die Wand)

Danach etwas besser, Klumpentaktik mit Torwart und Vorwärtsgewussel:
www.youtube.com/watch?v=tG7mHW9sIKQ
Code: http://pastebin.com/JKraVHj7
Das war einfach nur ausprobieren, darum ist es so ein Chaos.
Irgendwie hab ich gestern nicht geschafft die Funktionen aus vector.lua zu benutzen, weiss aber nicht mehr woran es lag.
Oben kann man noch local debugSpam = true setzen, wenn man den möchte.

Finde das Spiel echt gut gelungen.
Vor allem das man es schnell neustarten kann ist praktisch.
War erst skeptisch aber war dann doch leichter als gedacht den Einstieg zu finden.
Ein Wettbewerb wäre echt cool
Wo gibts denn die zwei anderen Bots?

scrontch

wubsnack schrieb:

Was ich meinte:
Im Moment muss sich jedes Script sowas einfügen:
local ACTION_NOTHING = 0
local ACTION_MOVE = 1
local ACTION_SHOOT = 2
(oder halt direkt Zahlen verwenden)

Aber für diese Konstanten könnte es ja auch ein constants geben.
constants.ACTION_MOVE, constants.ACTION_SHOOT usw ähnlich wie es zB schon gameSettings.NPODS gibt.

Hmm, Ok, aber ich würde das irgendwie besser als ein "require" von Lua Seite her sehen.

wubsnack schrieb:

Vorteil von so einem "namespace Table" ist dass man reingucken kann, zB so:
for key,value in pairs(t) do 
  print(key,value)
end

Ja, also den namespace Table werd ich auf jeden Fall in Lea machen.

wubsnack schrieb:

Bzw für verschachelte Tables: https://gist.github.com/stuby/5445834#file-rprint-lua
Mit rprint (constants) könnte man dann alle "values und keys" die im constants table enthalten sind, anzeigen lassen.
ergibt zB für world:
http://pastebin.com/N4aRGnXx
Finde ich ganz nützlich um zu gucken was für Konstanten/Variablen/Funktionen es überhaupt gibt. (zB ball.status und den score habe ich so entdeckt)
Aber soooo wichtig ist es dann auch nicht und habe eigentlich auch nicht so richtig Ahnung davon

Ja, wobei wie gesagt, das ist ja jetzt bloß als Doku-Ersatz.
Man kann auch in http://sourceforge.net/p/podball/code/ci/default/tree/src/podball/podtypes.h
reingucken. Da stehen auch alle Varaiblen drin die es so gibt. Mit knapper Erklärung.

wubsnack schrieb:

-world.ball.owningpod und world.ball.owningteam:
Wenn der Spieler den Ball wegschiesst wird das nicht reseted?
Also world.ball.owningpod ist immer die Nummer vom Spieler der den Ball zuletzt hatte - auch wenn er ihn nicht mehr hat.
Das fand ich erst etwas seltsam (erschien buggy) aber dann gesehen dass es noch world.ball.status gibt um zu gucken ob der Ball frei oder "getragen" ist.

Ja, genau.
podtypes.h sagt dazu:

UINT   owningpod;   // [0..NPODS-1], undefined if owningteam==OWNER_NOBODY.

Kann ich aber auch noch klarer machen in der Dok.

wubsnack schrieb:

-Die SpielerIndexes im Lua gehen 1 bis 1 to NPODS, im Spiel sind die Nummer aber 0 bis NPODS-1, bischen verwirrend.
Wenn man es ändert passt es aber für die C++ Bots nicht mehr...?

Ja, das is das Problem der unterschiedlichen Konventionen in C und Lua.
Ich wollte mich da Lua-freundlich geben, deshalb verschieb ich die Indices extra für Lua.
Aber dann is es halt nich mehr so konsistent in der Dok.

wubsnack schrieb:

Mein erster Versuch:
www.youtube.com/watch?v=_rAzLDn3UXY
(mit Tipfehler, darum rennen auch mal alle an die Wand)

*lol*
Die life-Kommentare sind köstlich!

wubsnack schrieb:

Danach etwas besser, Klumpentaktik mit Torwart und Vorwärtsgewussel:
www.youtube.com/watch?v=tG7mHW9sIKQ

Nice! Herzlichen Glückwunsch zum erreichen des ersten Levels.
Jetzt trete gegen den fest eingebauten "dummy" an. Der is (etwas) besser als Lea.

control
    {
      type "dummy"
    }

(Ups, merke grade dass das nich mehr der default in match.info ist wie es eignetlich sein sollte.)

wubsnack schrieb:

Finde das Spiel echt gut gelungen.
Vor allem das man es schnell neustarten kann ist praktisch.
War erst skeptisch aber war dann doch leichter als gedacht den Einstieg zu finden.
Ein Wettbewerb wäre echt cool

Danke! Ja klar, das Ziel ist mal ein Wettbewerb. Da müssten dann aber noch mehr mitmachen. Bis jetzt sind wir drei, davon zwei "Insider" die streng genommen nicht mitmachen dürften, nämlch ich und mein Bruder

wubsnack schrieb:

Wo gibts denn die zwei anderen Bots?

Meinen Bot kann ich dir demnächst mal schicken.
Der andere ist von meinem Bruder und zur Zeit der absolute Champion.
Der wird vorerst noch nicht öffentlich zugänglich gemacht.

wubsnack

Doch, der Dummy ist in der default match.info drin.
(zumindest hier: http://sourceforge.net/projects/podball/files/podball-2014-07-07.zip/download )
Wird auch regelmässig etwa 8:1 besiegt
Der Wub-Knubbel sollte theoretisch leicht zu umspielen sein, bin mal gespannt.
Die Beispiel-Bots sind eigentlich schon immer vorbei, vertüddeln es dann aber mit sinnlosen Doppelpässen statt nach vorne zu spielen.

scrontch

Ah, ok.
Ja, der Dummy war mal besser, hat aber die Umstellung einiger Physik-Konstanten und den Spielmodus auf 8 Spieler nicht gut verkraftet da vieles hardcodiert ist. Mal sehen ob ich die Zeit finde das mal etwas anzupassen.
Dasselbe gilt übrigens auch für meinen eigenen Bot wie ich feststellen musste

wubsnack

Ja, denke gleich-bleibende Spielparameter sind wichtig.

Wollte eben den Code kompilieren, hat leider nicht geklappt:

Bei sourceforge diesen "Snapshot" runtergeladen: http://sourceforge.net/code-snapshots/hg/p/po/podball/code/podball-code-a4cecfdee30c05173ba185d4079d4c00c390a894.zip
In CMakeCache.txt habe ich das hier rauskommentiert weil es den Ordner nicht gab: (dein Bot?)

add_subdirectory (src/strunz)

War mir nicht sicher wie genau das mit den Libs geht darum als prebuilt geladen: fltk-1.3.x-r8627-win-bin.rar und boost_1_55_0.zip
Mit cmake-gui.exe ein ein code::blocks Projekt PODBALL.cbp erschaffen
Wenn ich das nun kompilieren will kommt der Fehler:

error: 'tr1' in namespace 'std' does not name a type

ganzerbuild log: http://pastebin.com/g6MgEvrs
Dazu habe ich dann gegoogelt aber war alles zu verwirrend. Wusste auch nicht ob ich schon vorher irgendwas falsch gemacht hatte oä.

Idee wäre gewesen jeden Tick/Frame die Positionen der Pods+Ball zu speichern so dass man eine animierte .svg Datei erhält.

Habe das dann in Lua probiert, also im Bot:
Naja, so richtig gut geklappt hat es nicht, aber immerhin:
http://filehorst.de/d/bBwHbtvp
(runterladen und dann zB mit Firefox öffnen. (Nicht jeder Browser kann animierte svg anzeigen, IE zB nicht))

Ist das

srand(777);

eigentlich Absicht? Der Zufall wird so ja etwas unzufällig. Cool wäre evtl ein randomseed=4676 in der match.info Config zu haben, dann könnte man das gleiche Spiel nochmal reproduzieren. (und dann im Bot zB die debugging-Ausgabe anschalten)
Wobei das evtl nicht geht wenn in den Lua-bots auch random() benutzt wird..Das müsste ja auch wieder den gleichen Seed benutzen.

scrontch

wubsnack schrieb:

Wollte eben den Code kompilieren, hat leider nicht geklappt [...]

Ja alle Schritte soweit ich das sehen kann richtig.
Ich kompiliere unter VSExpress.
Das Problem kann sehr wahrscheinlich durch jeweils Ersetzen von
#include <memory>
#include <functional>
durch
#include <boost/tr1/memory.hpp>
#include <boost/tr1/functional.hpp>
in allen Dateien unter \LuaCppInterface gelöst werden. (Die Umgekehrte Ersetzung musste ich nämlich für VSExpress machen.)
Das liegt daran das diese Header mit C++11 in die Sprache aufgenommen wurden. Liegt also am Compiler.

wubsnack schrieb:

Idee wäre gewesen jeden Tick/Frame die Positionen der Pods+Ball zu speichern so dass man eine animierte .svg Datei erhält. [...]

Als Youtube-Video für Arme sozusagen?
Also es ist noch auf der Todo-List beim Projekt ein Log und Replayer zu programmieren mit dem man aufgezeichnete Spiele über den gleichen Player nochmal ansehen kann.

wubsnack schrieb:

Ist das
srand(777);
eigentlich Absicht? Der Zufall wird so ja etwas unzufällig. Cool wäre evtl ein randomseed=4676 in der match.info Config zu haben, dann könnte man das gleiche Spiel nochmal reproduzieren. (und dann im Bot zB die debugging-Ausgabe anschalten)
Wobei das evtl nicht geht wenn in den Lua-bots auch random() benutzt wird..Das müsste ja auch wieder den gleichen Seed benutzen.

Ja, wie du richtig vermutet hast ist es Absicht die Engine deterministisch zu halten, d.h. wie Du sagst ein selbes Spiel exakt reproduzieren zu können. (Das ist vor allem beim Debuggen hilfreich, aber auch unter anderen Aspekten)
Aber ich stimme zu, man könnte den Seed auch in die match.info reinnehmen.
Random wird von der Engine nur an einer Stelle benutzt, nämlich für die Richtung beim Einwurf des Balls beim Anstoß, um immer andere Spielverläufe nach jedem Tor zu haben.

wubsnack

Das ersetzen der includes hat teilweise funktioniert, hängt aber trotzdem noch etwas später beim compilieren:

error: there are no arguments to 'static_assert' that depend on a template parameter, so a declaration of 'static_assert' must be available

kompletter Log: http://pastebin.com/TNWPT10s

Die -fpermssive Option ist schon eingeschaltet, so wie hier: http://stackoverflow.com/questions/13024111/fpermissive-option-in-codeblocks-where-do-i-put-that-fpermissive-option

scrontch

Hallo wubsnack,
Schön zu sehen dass Du noch dabei bist!
Hmm, die Kompilier-Probleme sind ärgerlich. Ist wohl doch nicht so platform-neutral wie ich hoffte. sag mir mal dein genauen System/Compiler Setup, vielleicht kann ich das auch mal aufsetzen.
(eventuell sollten wir solche technischen Fragen zum kompilieren aus der Diskussion hier rausnehmen - schreib mir mal eine EMail - Adresse im Profil).

Ansonsten wird dich freuen, dass ich einige deiner Vorschläge umgesetzt habe:
Es gibt jetzt einen single-step Button. Besser gesagt springt damit man immer zum nächsten Zeitschritt, nachdem die Control-Module aufgerufen wurden. Also ideal zum debuggen.
Ausserdem hab ich ein kleines Drawing-Interface implementiert.
Die Module können jetzt zu Debug-Zwecken einfache Formen (Kreise, Linien) auf die Arena malen! (Das muss aber noch Lua verfügbar gemacht werden. Ich arbeite grad dran)
Ich werd ein etnsprechendes Binary-Package demnächst hochladen.

scrontch

Neues Bin-Package für Windows:
http://sourceforge.net/projects/podball/files/podball-2014-07-29.zip/download
Jetzt mit Single-Step-Button und Debug Drawing Interface (auch für Lua).

wubsnack

Hallo
habe momentan nicht so viel Zeit gehabt und nur ein bischen rumgewurschelt ohne zu posten.
Das Debug-malen und single-step ist nützlich
Wenn du willst kannst du meinen Bot in den download/git reinpacken? Er ist zwar nicht sehr "schön" aber immerhin ein Beispielgegner mehr

scrontch

Gerne