Es wird langsam peinlich, liebe Devs

WoW Classic WoW Classic – Allgemeines
1

In der ersten Iteration habt ihr den Premadern geradezu den roten Teppich ausgerollt, um Anmeldungen in AV über grosse Gruppen und Servergrenzen hinweg zu ermöglichen, indem ihr ihnen (wieso eigentlich?) die ID des BGs in das sie joinen können gesagt habt.

Das wurde „gefixt“.

Nur leider hat der fix genau gar nichts gebracht, weil ihr es trotzdem (nochmal: warum eigentlich?!?) ermöglicht die Nummern aller derzeit offenen BG IDs einzusehen…in realtime. Daraus eine simple Funktion abzuleiten die sagt wann man sich anmelden kann, ist ein Kinderspiel…

…und genau das ist passiert. Die premades sind wieder unterwegs, und der grossteil der Community hat das nachsehen: Ghost BGs, unlustige Rushspiele, ebenso unlustige Turtletaktik als einzige Reaktion, WSG ist wieder mal am boden, Ehrefarmen ist wieder die Beschäftigung von accountsharern und bots, toxische „premade communities“ schiessen wieder wie Pilze aus dem Boden (oft mit finanziellem Druck um Leute mitzunehmen, siehe engl. Foren).

Was ist los mit euch?
Wer trifft bitte solche Entscheidungen?
Wo ist da basic testing, basic QA?

Die Lösung ist so simpel, es ist gradezu peinlich:

  • Die Clients haben keinen Zugriff auf die ID information oder Anzahl der offenen BGs mehr (zum dritten mal, warum zum Geier haben sie die überhaupt jemals gehabt???!?)
  • Der Server hält einen Pool von mindestens N offenen BG instanzen zu jeder Zeit, jedes launchende BG triggert die sofortige instanzierung eines neuen empty_bg
  • Jede Anmeldung einer Gruppe wird random auf die derzeit wartenden N BGs aufgeteilt, diese Entscheidung wird getroffen nachdem die Gruppe einen invite annimmt.

Und das hab ich, ein einsamer kleiner, nicht in der Games-Branche beschäftiger, Softwareentwickler, nicht innerhalb der letzten 2h durch grossartige Überlegungen ausgetüftelt, sondern in den 70sek in denen ich diesen text getippt hab…komplett ad lib.

Reisst euch endlich zusammen.

Editeditedit:
Sorry für die vielen Edits, aber ich schreib Texte gerne noch fertig nach der ersten Version :wink:

25 Likes
2

Ja, und deswegen ist das alles auch total wertlos, weil du 0 Ahnung davon hast, wie genau das technisch umgesetzt wird und was dabei alles abgewägt werden muss.

Wer es nicht umsetzen muss, kann immer viel fordern.

12 Likes
3

Dieser Logik nach zufolge ist die Einschätzung eines Mathematikers, der berechnet wieviel Tonnen Weizen benötigt werden um eine Stadt mit n Millionen Ew. 1 Woche lang zu versorgen auch wertlos, weil er weder ein Bauer, noch ein Bäcker, noch ein Brotverkäufer ist.

Finden sie den Fehler.

25 Likes
4

Ich muss sagen mega gut gekontert :ok_hand::point_left:t3:
Game Over

9 Likes
5

der fehler war crossrealm bg’s einzuführen.

5 Likes
6

Easy. Erstens hast du nichts berechnet, zweitens hast du, wenn wir bei der Analogie bleiben wollen, keinerlei Daten darüber, wie viel Weizen in wie viel Brot resultiert, oder wie viel Nährwert der Weizen hat, oder wie viel Menschen so essen, oder wie viele Menschen in der Stadt leben. Dir fehlen die ganzen Daten, die du eigentlich bräuchtest, bevor du hier raushaust, dass das alles ja total einfach zu implementieren sein müsste. Und nicht zuletzt: Es kann sein, dass es zwar einfach machbar ist, die Entwickler sich aber trotzdem dazu entschlossen haben, es anders zu machen, weil gewichtige Gründe dafür sprechen.

Und ein kleines Detail: Du klingst nicht klüger, bloß, weil du überall N Kommentare mit N einbaust.

6 Likes
7

Welche Daten brauch ich denn um das bewerten zu können?

Hier gehts um ein simples Binning-Problem. Die Abbildung einer Menge auf mehrere andere Mengen, wobei ich verhindern möchte dass mehr als N% der Ausgangsmenge in jeder einzelnen der Zielmengen landen.

Das ist kein Problem zu dessen Evaluaierung ich irgendwelche „Daten“ benötigen würde, genausowenig wie ich „Daten“ brauche um einen Radix-Sort-Algorithmus zu implementieren. Solche Probleme sind bereits gelöst, die Antworten stehen in Lehrbüchern. Wenn du mir nicht glaubst, geh auf Amazon, gib „Donald Knuth“ in die Suchmaske ein und kauf dir was schönes. Ich wünsche viel Vergnügen beim lesen.

Wesentlich unklüger würde ich wirken, wenn ich Posts die sachliche Argumente enthielten anzweifeln würde, ohne jedwede eigene Argumente anzubringen. Es gilt zwar das prinzip „onus probandi incumbit ei qui dicit non ei qui negat“, aber ich habe meinen onus erbracht :sunglasses:

10 Likes
8

Man kann durchaus einiges abschätzen.
Z.b. ID-Anzeigen. Nope muss man eigentlich nicht anzeigen, kann man rausnehmen. Die Frage ist, ob das noch APIs gibt, die das beachten müssen und wo man zugriff drauf haben muss.
Ok, gehen wir von den schlimmsten Fall aus: Ja, man braucht sie in der LUA-Schnittstelle.
Gut, dann macht man folgendes:
Server sendet eine BG-Server-Id. der Client erstellt eine BG-Server-Id auf BG-Client-Id - Tabelle. Letztere wird zufällig von Client ausgewürfelt. Diese BG-Client-Id wird in der API-Lua-Schnittstelle verwendet.
Immer wenn dann mit den Server kommuniziert werden muss, wird die BG-Client-Id in eine BG-Server-Id umgewandelt und gut ist.
Ergebnis ist, das der Server und Client untereinandern eindeutig reden können und trotzdem hat jeder Client eine völlig andere ID angezeigt. Server muss man hier nicht anpassen - nur der Client braucht eine Änderung. Performance von Server ändert sich nicht.

Aber es gibt durchaus andere Möglichkeiten premades zu verhindern. Serverseitig und zwar beim Matchmaking.
Man muss nur merken, mit wen man abgeschlossene BG gemacht hat.
Wieviel Speicher man wohl braucht? Schauen wir uns mal ein GUID an:

https://wow.gamepedia.com/GUID#Formats

„Player-970-0002FD64“
In der Liste können nur Spieler sein - damit kann das „Player-“-Prefix auslassen.
970 ist die RealmID - Wenn das eine Hexadezimal-Zahl hat, kann man das in 2 Bytes speichern. Die folgenden 8 Ziffern sind in Hexadezimal, also 4 Byte. Damit kann man eine Person mit 6 Bytes erfassen. Man braucht noch einen Zähler, wie oft man mit dieser Person in einen BG war. grob 32.000x sollte ausreichen (kann man ja wöchentlich zurücksetzen), das wären wieder 2 Byte. Man kann pro Eintrag in dieser Liste mit 8 Bytes in besten Fall arbeiten.
Wieviel Speicher bräuchte man wohl: bei 1KB (=1024 Byte) könnte man 128 Personen traken. Bei einen MB (1024 KB) wären das schon 131.072 Personen. Das sollte also mehr als ausreichen. Zumal man die Daten quasi nur eine Woche speicher muss - und dann jede Woche die Tabellen einfach löschen kann.
Jetzt wertet man bei einen abgschlossenen BG aus, wer alles dabei war und zählt die entsprechenden Zähler hoch.
Anschließend sortiert man die Tabelle.
Um Premades zu verhindern muss das Matchmaking nur folgendes Sicherstellen:
Man kann in kein Battleground mit den Top-Ten der bisherigen Mitspieler, wahrscheinlich würde sogar Top-5 reichen. Müsste man ausprobieren.
Damit block das System Premaides sehr effektiv. Sollten mehr als 10 Spieler in dieser Liste mit der gleichen „Punktzahl“ stehen, werden halt die zufällig ersten 10 Spieler genommen.
Anpassung von Client: Keine. BattleGrounds, in die man nicht darf, werden von Server einfach als Voll gemeldet oder gar nicht. Das kennt der Client und kann damit umgehen.

Speicherbedarf? Man könnte es noch vereinfachen. Premades sind immer von gleichen Server? Dann hat man schon eine Reduktion gefunden. Man könnte auch eine Account-ID speichern statt Spielfigur-Id.
1MB sollte wirklich kein Thema sein, das sollte das System handeln können. Notfalls kann man da sicherlich auch auf den Client ausweichen. Das der die 1 MB runterlädt beim starten und später dann die Aktualisierungen hochlädt. Quasi wie ein Inventar, Briefkästen, Freundeslisten, Gildenlisten und was es sonst so gibt. Das blocken könnte auch von Client erfolgen, wenn man die Mitspieler in BG mitgeteilt bekommt. Theoretisch könnte der Client jetzt cheaten, aber das sollte Warden verhindern, oder?

Problem ist: Man müsste sich hinsetzen und es mal entwickeln. Kostet natürlich.

2 Likes
9

Man kann in dem Fall auch etwas viel simpleres machen: Man ändert einfach die API, entfernt zB. die getter function welche auf die Information zugreifen kann.

Die BG ID ist für den client, und sein Interface, keine relevante Information. Der client muss nicht wissen in welches BG er joint. Die einzigen Addons die sich dafür interessieren, und deren Funktion durch den change beeinträchtigt wären, sind genau die, deren Funktionalität man unterbinden möchte.

Und es wäre auch nicht das erste mal dass Blizzard API changes durchführt welche ganze gruppen an Addons zerbröseln.

4 Likes
10

Wie gesagt, das Beispiel ist für den Fall, dass man es nicht kann, weil die Blizzard-Lua-Addons es zwingend brauchen. Man kann es dann immer noch maskieren.
Wenn man es einfach sperren kann - um so besser.

11

Eh, ich rede ja genau von Blizzards eigenem Interface. Es hat keinerlei mehrwert für den Client, oder genauer gesagt, für den presentation layer des clients, die IDs zu kennen. Wozu werden diese Zahlen, oder die Anzahl offener BGs, überhaupt angezeigt?

Und selbst im allerschlimmsten Fall, dass der zugrundeliegende netcode so ungeschickt geschrieben wäre, dass der client dem Server mitteilen müsste welchem BG er joinen will, könnte diese info immer noch in der engine liegen, ohne gegenüber der LUA API exposed zu werden.

Dann könnte man zwar theoretisch immer noch darauf zugreifen, nur dazu müsste man den Speicher des laufenden games lesen, und da würde WARDEN anschlagen :slight_smile:

12

Ne andere ganz blöde Idee:
Bei der Anmeldung bekommt man eine Zufalls-Zahl von 1-1000 zugewiesen. Aktuell scheint das System ja nur von Anmelde-Zeitpunkt etc auszugehen. Gut, würfeln wir halt dazu diese Zufallszahl und der Spieler hätte keine Chance mehr durch gleichzeitiges Klicken was zu erreichen.

13

Hätten all diese Erklärungen oben schon gestanden, hätte ich deutlich positiver reagiert. Ursprünglich stand oben letzten Endes nur „Is easy, macht mal!“.

14

Steigen dadurch die Wartezeiten nicht noch weiter an, da es länger dauert bis ein einzelnes BG voll ist und starten kann?

15

Nur ausserhalb der Stosszeiten. Und es ist besser als die Alternative.

Gerade weil die premades durch ihr permanentes Requeing viele nicht-volle BGs öffnen, kommt es zu den sogenannten „Ghosts“…BGs in denen 5-15 Allys gegen 40 Hordler stehen.

Wenn die Alternative dazu geringfügig längere Wartezeiten sind, dann ist das ein guter Tausch.

2 Likes
16

Bin ganz deiner Meinung,braucht man nichts mehr hinzufügen.

17

Wo es keinen Respekt gibt, da gibt es auch keinen sinnvollen Service. Welchen Service hat Bli$$ard in letzter Zeit abgeliefert?

1 Like
18

Organisiert euch halt ihr Heulsusen sollten wir auch

1 Like
19

Also ich sehe keinen Handlungsbedarf bei Blizzard. Das ursprüngliche Problem war, dass unzählige Schlachtfelder mit weniger als 20 Allianzspielern gestartet wurden, wodurch die Serverressourcen von Blizzard wohl nicht optimal genutzt wurden und die Horde (unfreiwillig) einen unfairen Vorteil beim Ehregewinn bekommen hat, weil jedes dieser BGs mit maximaler Bonusehre gewonnen wurde. Dieses Problem ist mittlerweile behoben.

20

ich denke die einfachste methode wäre, wenn es im anmelde bildschirm ausser „als gruppe anmelden“ und „nächstes verfügbares anmelden“ keine anzeige gäbe. niemand muss angezeigt bekommen, welche bgs offen sind. niemand muss ein bg auswählen können. es gibt das nächste verfügbare und fertig. gruppengrösse ist max 5 mann, das will blizz so. damit sollte das problem sehr schnell behoben sein und ausser einer änderung des anmelde bildschirms ist keinerlei anpassung nötig. oder hab ich da einen denkfehler? (ich bin kein programmierer).

2 Likes