Aufgrund eines Anflugs spontaner Hackigkeit und Anfrage eines MUSKEL-Tiers hat die Karo-API ein neues flag:
Unter
http://www.karopapier.de/api/map/list.json?nocode=true
gibt’s jetzt ne Liste aller Karten-Infos allerdings ohne den mapcode. Gedacht, um den Traffic zu reduzieren, wenn man mal alle Karten wissen will.
Wer’s braucht darf’s nutzen 😀
Hab heute beim Rumspielen festgestellt, dass die API in den GameDetails ja um die Positionen (x, y, xv und yv) doffe “ drumrum macht und somit aus den Zahlen einen Text – is ja aber völlig quatsch, und so hab ich das gerade mal behoben. Jetzt kommen also wirklich auch Zahlen über den JSON-Äther
Wäre doch gelacht, wenn man mit etwas mehr Hirnschmalz und Javascript das Spiele-Erstellen nicht besser hinbekommen könnte.
Als erstes gibt’s nun endlich mal nen Knopf für eine zufällig ausgewählte Karte, wobei die Anzahl der ausgewählten Spieler berücksichtigt wird.
Was im letzten Adventskalender 2011 als 24. Türchen auftauchte, nämlich der „Teaser“ unter http://reloaded.karopapier.de/lobby/createGame wurde jetzt, ein Jahr später in etwas anderer Form wahr. (und ist auch noch nicht fertig)
Was aber für die API-Entwickler unter Euch interessant sein könnte is die Tatsache, dass die Spiele per API erstellt und die Antwort vom Server ausgewertet wird. Im Code lässt sich also schauen, welche Anforderungen der API-Call POST /game/add.json hat.
Für die Nutzer unter Euch, denen das einfach egal ist soll die neue Spielerstellung im Laufe der Zeit ultimativ benutzerfreundlich werden und mir schweben auch noch die ein oder anderen Änderung vor, um das Formular besser zu machen – allen voran natürlich eine ordentliche Kartenauswahl, aber auch ein paar nützliche Helferlein, um die Listen zu filtern.
Wer mit zwei Browsern oder ullis KaroApp und dem Browser parallel zieht, kann sich schon mal verfahren. Weil z. B. in der App nich ein alter Spielstand angezeigt wird, während man im Browser schon einen Zug gemacht hat – und jetzt wieder dran kommt.
Da bisher die Züge nur „relativ“, also als Zugvektoren übergeben wurden, konnte das passieren.
Jetzt neu in Karo1 (und schon immer so geplant in Karo2) müssen Zugvektor UND Zielposition übergeben werden. Dadurch kann ich dann auf dem Server prüfen, ob das auch alles zusammenpasst.
Für die „Übergangszeit“ (bis alle Bots und Apps umgeschrieben sind) schick ich die Browser-Benutzer auf die „move2.php“, die genau das gleiche tut wie die move.php, nur mit dem Unterschied, dass sie diese Prüfung durchführt.
Sobald die Herren ulli, quabla und Jody „Bescheid“ sagen, kann ich das ja wieder korrigieren.
Die Tabelle „Mapvotes“ gibt es schon ewig, entstanden aus der Idee, Karten bewerten zu können. Hat sich aber nie was getan.
Und auch das „Starvote“-Modul lag ja schon eine ganze Weile herum.
Nun endlich hab ich die Funktion, Stimmen für Karten abzugeben, in die API eingebaut (gleiche URL, als POST zum setzen und als GET zum lesen) und dann auch gleich noch bissl mit jQuery-Events rumgespielt – und jetzt ist es eingebaut!
Man kann also nun direkt aus der showmap.php heraus Karten bewerten.
(Die API liefert als Response für eine abgegebene Stimme die neuen Bewertungszahlen, so dass man sie gleich verwenden kann und die Abstimmung neu rendern. Ganz praktisch)
Seit gestern kann jetzt übrigens auch Karo2.0 (also auch die API) den „Regeltest“, also erlaubt es, auf Felder zu ziehen, die in dieser Runde noch frei werden.
Ausgelöst aufgrund einer Anfrage von quabla/botrix – hoffen wir mal, dass die App von ulli das auch versteht!?
Aber das bedeutet auch: Nicht mehr lang, und ich kann es für alle und immer frei schalten.
Hab viel mit Backbone.Marionette rumprobiert und gespielt – so ganz 100%ig bin ich noch nicht hinter alle Konzepte gestiegen, aber für die JS-basierte Version von Karo wird es sicherlich ganz gut helfen können.
Mal sehen, wie das dann mit existierenden Teilen interaggieren könnte… Karo1, Karo2 und die JS-Version… da wird’s voll.
Wenn dann jetzt der Editor tut, ist es bald auch mal an der Zeit, das Hochladen und Spielen eigener Karten für alle zu basteln.
Dazu muss ich aber erst mal den alten und neuen Karocode unabhänig von den uralten „Map“-Dateien machen. D.h. der Kartencode muss aus der Datenbank kommen – und zwar überall.
Das wird erst mal der nächste Umbau. Und dann kann ich anfangen zu überlegen, wie wir dem zu erwartenden Kartenwust Herr werden…
Meine Versuche mit backbone.js sind von ersten Erfolgen gekrönt.
Ich habe eine erste Version einer Spielanzeige gebastelt (per JSONP Daten holen, diverse Views, die miteinander interaggieren) – und dann auch angefangen, einen Karteneditor zu bauen.
Dieser basiert auf den Erfahrung der ersten Schritte sowie aber auch dem existierenden, älteren Code zur Kartendarstellung, den ich einfach so mal geschrieben habe.
Ließ sich alles recht schön zusammenfügen, events halten bisher alles ganz ordentlich zusammen (mouse events zum Malen als User, diverse change-events „malen“ dann den Canvas an.
Dann noch was drangebastelt, um existierenden Kartencode über die API zu laden, und schon macht’s Spaß
Zu sehen (stand jetzt, 16.8.2012, hier: http://2.karopapier.de/editor.html)
