Googles QuickDraw Component auf GitHub

Was das Repository ist — und was nicht

Das Projekt ist eine Web Component auf Polymer/Lit-Basis, mit der sich einzelne Quick-Draw-Doodles in eine Seite einbetten lassen. Der Anspruch ist bewusst klein: Ein Element wie <quick-draw category="apple"> lädt eine Zeichnung und malt sie auf ein Canvas.

Was es nicht ist, wird oft missverstanden: Es ist weder eine Open-Source-Fassung des Spiels noch enthält es den Klassifikator. Es gibt keinen Trainingscode und kein Modell. Wer nach der Erkennung sucht, findet sie hier nicht — die veröffentlichte Seite von Quick, Draw! umfasst die Daten und Werkzeuge zu ihrer Darstellung, nicht das Netz, das im Originalspiel rät.

Quelle: googlecreativelab/quickdraw-component.

Die Component: Strichdaten im Browser

Die Komponente kennt Eigenschaften für Kategorie, Index, Strichfarbe und -breite, Abmessungen und einen Animationsmodus. Intern zeichnet sie auf ein canvas. Die Daten liegen als getrennte X- und Y-Punktlisten je Strich vor; kommen Zeitwerte hinzu, lässt sich die Zeichnung in ihrer ursprünglichen Bewegung abspielen.

<quick-draw
  category="apple"
  key="API_KEY"
  animate>
</quick-draw>

Der eigentliche Erkenntniswert liegt in dem, was hier sichtbar wird: Eine Quick-Draw-Zeichnung ist kein Bild, sondern eine Folge von Bewegungen. Sie lässt sich abspielen wie eine Aufnahme. Genau diese Doppelnatur macht den Datensatz sowohl für Sequenzmodelle als auch für Bildklassifikation brauchbar — der Vergleich RNN gegen CNN geht dem nach.

Die API-Schicht

Zum Repository gehört ein Express-Dienst, der einzelne Zeichnungen ausliefert — die Anzahl der Doodles einer Kategorie, eine bestimmte oder eine zufällige Zeichnung:

GET /drawing/:category/count
GET /drawing/:category?id=random&isAnimated=false

Unterschieden wird zwischen vereinfachten und rohen, zeitbehafteten Daten. Für Animationen braucht es die rohe Variante mit Zeitstempeln; für eine statische Darstellung genügt die vereinfachte.

Self-Hosting: der Hinweis, den man ernst nehmen sollte

Die README rät ausdrücklich davon ab, für ernsthafte Projekte auf den Demo-Endpunkt zu bauen. Das ist keine Formalie: Ein archiviertes Repository bedeutet, dass niemand mehr für die Verfügbarkeit einhält. Wer die Komponente heute einsetzt, sollte die Doodle-Dateien in ein eigenes Storage-Bucket kopieren und die API selbst betreiben.

Zwei weitere Punkte kommen mit dem Alter des Projekts. Polymer gilt inzwischen als Altlast — in einem neuen Projekt würde man die wenigen nötigen Zeilen Canvas-Code direkt schreiben, statt eine Framework-Abhängigkeit dieses Alters aufzunehmen. Und der API-Zugriff verlangt einen Schlüssel, was für eine rein clientseitige Einbindung unbequem ist, weil er dabei zwangsläufig öffentlich wird.

Warum DrawLa die Wiedergabe selbst gebaut hat

Der Bezug ist enger, als es zunächst wirkt: DrawLas Bots tun im Kern dasselbe wie diese Komponente — sie spielen eine echte Quick-Draw-Aufzeichnung Strich für Strich ab. Nur eben nicht im Browser, sondern auf dem Server.

Der Unterschied ist entscheidend. Eine Browser-Komponente malt eine fertige Zeichnung hin. Ein Bot dagegen muss Teil des Spiels sein: Sein Zeichenfortschritt geht als stroke_update an alle Mitspieler, damit sie ihm live zusehen, und wird laufend derselben Erkennung vorgelegt wie eine menschliche Zeichnung. Der Bot kann also auch nicht erkannt werden und die Runde verlieren.

Das ist der Grund, warum die Wiedergabe bei uns serverseitig liegt: Sie muss an den Rundenzustand gekoppelt sein, an das Tempo der Runde und an dieselbe Bewertung, die für Menschen gilt. Eine Anzeigekomponente kann das nicht leisten — sie ist für einen anderen Zweck gebaut.

Wann sich der Blick trotzdem lohnt

Für alles, was Quick-Draw-Daten zeigen statt auswerten soll, ist das Repository weiterhin die naheliegende Vorlage: Illustrationen auf Webseiten, Platzhalterbilder, Datenexploration. Die Kombination aus Storage-Dateien, ausliefernder API und Canvas-Wiedergabe im Frontend ist eine saubere, einfache Architektur.

Wer dagegen selbst erkennen will, findet hier nichts — die andere Richtung beschreibt QuickDraw mit PyTorch: Striche in ein Bild normalisieren und ein CNN darauf trainieren. Die Datengrundlage für beide Wege erklärt der Quick-Draw-Datensatz.