M-Budget Sommer-Wettbewerb mit Elo-Rating

Im M-Budget Sommer-Wettbewerb werden die Gewinner nicht direkt über die Anzahl der abgegebenen Stimmen, sondern durch das sogenannte Elo-Rating mit der Elo-Zahl R ermittelt.

Es handelt sich dabei um ein Wertungssystem, bei welchem Schachspielern aufgrund statistischer Auswertung ihrer bisherigen Turnierergebnisse eine sogenannte Elo-Zahl zugeordnet wird, die ihre Spielstärke widerspiegelt und Prognosen über ihre Erfolgsaussichten gegen andere Spieler zulässt. Das Konzept wurde 1960 vom ungarischen Physiker Arpad Elo für den US-amerikanischen Schachverband entwickelt.

Der Elo-Algorithmus sorgt für Fairness und motiviert die Community

Im Gewinnspiel treten jeweils zwei M-Budget-Sujets gegeneinander an. Die Community entscheidet anschliessend, welches Sujet origineller ist.

Die Anzahl der Votings ist nicht ersichtlich und die Sujets können nicht über die Anzahl abgegebener Votings miteinander verglichen werden. Ausgegeben wird nur der Rang. Mit der Elo-Zahl ist gewährleistet, dass selbst ein in der letzten Spielwoche hochgeladenes Sujet noch die Möglichkeit hat, den Hauptpreis zu gewinnen.

Da alle Spieler bzw. Sujets mit einem identischen initialen Elo-Rang, aber nicht zum gleichen Zeitpunkt starten, führt dies im Verlauf eines Spiel zu einer immer ungerechteren Rangliste. Um dem entgegenzuwirken, ist der initiale Wert neuer Sujets erst einmal provisorisch. Bis zur fünften Voting-Runde befindet sich zudem jedes neue Sujet fix auf dem letzten Platz. Ab der fünften Voting-Runde erhält das Sujet dann erstmals seinen auf der provisorischen Elo-Zahl basierenden Rang.

Der provisorische Elo-Score wird im Verlauf der ersten 20 Voting-Runden ermittelt. Dazu wird der Durchschnitt aus der Elo-Zahl aller gespielten Gegner – sowie +400 bei Sieg bzw. -400 bei Niederlage – gegen ein Sujet mit bereits ermitteltem Score bzw. +/-200 Punkte bei Gegnern mit provisorischer Elo-Zahl errechnet. Nach den ersten 20 Runden greift dann die eigentliche Elo-Formel.

Beispiel: Angenommen, 20 Sujets sind bereits seit einiger Zeit im Rennen und von diesen 20 gewinnen mehrheitlich immer die selben fünf Sujets, so würde ein neues Sujets mit einem Initialwert von 1’200 im Vergleich zu den weniger häufig gespielten übrigen 15 Sujets vergleichsweise hoch in der Rangliste landen. In unserem Beispiel wäre dies im “schlimmsten” Fall Platz 6, obwohl das neue Sujets noch gar nie gespielt worden ist.

Elo-Formel konkret

Gewinnt ein höher klassiertes Sujet mit einer hohen Spielstärke, das heisst Elo-Zahl, gegen ein niedriger klassiertes Sujet mit einer tiefen Elo-Zahl, erhält es, nach einer logistischen Formel berechnet, eine gewisse Anzahl Punkte, in diesem Fall nur wenige Punkte. Dazu wird zunächst die Gewinnwahrscheinlichkeit als erwarteter Punktestand des Sujets errechnet:

EA: Erwarteter Punktestand für Foto A, RA: bisherige Elo-Zahl von Foto A, RB: bisherige Elo-Zahl von Foto B

Die Anpassung der neuen ELO-Zahl R’für Foto A wird dann wie folgt vorgenommen:

k: 20,  SA :1 bei Sieg oder 0 bei Niederlage von Foto A

Je höher der K-Wert (Koeffizient zur Berechnung des Entwicklungsstands), desto stärker wirken sich neu erzielte Ergebnisse aus. Das “Gewinner-Sujet” erhält somit bei Sieg vom “Verlierer-Sujet” seine zu erwarteten Punkte. Würde folglich ein schwach klassiertes Sujet gegen ein spielstarkes Sujet gewinnen, so würde es ziemlich viele Punkte erhalten, da die Gewinnerwartung beim besser klassierten Sujet um einiges höher liegt.

Auswahl der Spielerpaare und weitere technische Hürden

Wenn weniger als 30 M-Budget-Sujets im System sind, ist das Spiel zu Ende spielbar. Damit ist gewährleistet, dass “gespielte Paare” nur einmal gespielt werden. Bei zehn hochgeladenen Sujets ergeben sich somit insgesamt 45 Spielrunden (n*(n-1))/2.

Die Kontrahenten eines gespielten Sujets werden in einem Array gespeichert. Aus einem weiteren Array von spielbaren Sujets, also Sujets, die noch nicht gegen alle anderen angetreten sind, erfolgt die Zufallsauswahl der möglichen noch verfügbaren Konkurrenten.

Sobald mehr als 30 Sujets online sind, erfolgt die Paar-Auswahl immer und über alle Sujets zufällig und das Spiel ist endlos. Bei vielen Fotos würde die Anzahl der möglichen Paarkombinationen zu gross werden (n=1000, Anzahl Spiele=499500).

Als Massnahme gegen “automatisierte Tricksereien” muss beim Voting einmal pro Session zudem die Hürde “Google reCAPTCHA” genommen werden.

Mit ‚high speed‘ im Einsatz

Nachdem er am M-Budget-Skiweekend in Laax zu Hochform aufgelaufen ist, darf der legendäre M-Budget Fotobuzzer an den Openairs natürlich nicht fehlen.

Die Openair-Buzzerfotos werden in einem Seafile-Verzeichnis auf einem lokalen Rechner gespeichert. Seafile ist Open-Source, der Seafile-Client synchronisiert die Fotos bei vorhandener Internetverbindung automatisch mit dem Seafile-Server. Mit einem automatisierten Script werden die Buzzerfotos alle fünf Minuten vom Seafile-Server abgeholt und direkt in die Fotobuzzer-Galerie auf der M-Budget Seite importiert.

Aus technischer Sicht galt es für den M-Budget-Festivalsommer einige spannende Hürden zu meistern. Ab sofort heisst es jetzt aber wieder Bahn frei für kreative Geister!

Zu gewinnen gibt es 60 × 2 exklusive Festival-Packages für die beliebtesten Schweizer Openairs (St. Gallen, Frauenfeld, Gurtenfestival, Paléo Festival Nyon, Heitere und Gampel). Im Package enthalten sind Festivalpass für alle Festivaltage, Übernachtung im exklusiven M-Budget-Camp, Verpflegungsgutscheine für die M-Budget-Zone und coole Überraschungs-Goodies. Nach Abschluss der Ticket-Runde ist aber noch keineswegs Schluss: Bis Ende August kann weiter um den Hauptpreis sowie zehn Kreativpreise gespielt werden. Zusätzliche Gewinnchancen auf einen von 70 Sofortpreisen winken beim täglichen Voting. Das Voting um die Festivaltickets endet bereits am 14. Juni 2016!

Los geht’s auf m-budget.migros.ch/!

 

Technology Stack
Standards: HTML5, LESS, JavaScript, PHP, JAVA
Components: Magnolia CMS, Symfony2, Bootstrap, Jquery
Software: Eclipse, PhpStorm

Digital Consulting & Realisierung
Jean-Pierre König (Senior Software Engineer, Gesamtverantwortung)
Stefanie Giese (Scrum Master)
Simon Schneeberger (Software Engineer)
Kerstin Wischy (UX Consulting, Interaction Design)

 

Weiterführende Informationen:

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *