BO = Build Order
Sim City = Durch bestimmte Anordnung von Gebäuden den Weg versperren
Rush = Schneller Angriff welcher verschiedene Ziele verfolgen kann
Fast Exe = Fast Expansion = Schnelle erweiterung seiner Basis durch weitere kleine Basen
Eco = Economy = Einkommen
Micro & Macro = http://de.wikipedia.org/wiki/Micromanagement

Video – Teil 1/2

Video – Teil 2/2

Im folgenden Artikel werden diese und weitere Fragen geklärt. Aber Achtung: Es kommt auch ein wenig Mathematik vor! :p

Ein wenig Grundwissen um die folgenden Überlegungen anzustellen, kann man einer E-Mail von arQon einem Entwickler des CMPA Quake 3 Promode, entnehmen.

and cl_maxpackets give you the ability to send an update every frame or
every 2 frames, 3 frames, or 4 frames (and so-on) which means that the
amount of packets you send is still roughly connected to your frames per
second.

Dieses Zitat aus der E-Mail ist das wesentlichste der ganzen E-Mail. In der E-Mail wird aber noch wesentlich genauer auf diesen Satz eingegangen.

Maxpackets -> Maxfps

Wie wir aus einem anderen Artikel des GameGuides bereits wissen:

• pro FPS maximal 1 Paket
• Maxpackets müssen ein Teiler der FPS sein
• der Teiler muss ein Integer-Wert sein

Weiterführend ist zu sagen, dass der Client (also der PC des Spielers) pro Frame ein Command erstellt. Ein Command enthält Informationen darüber, welche Knöpfe der Spieler gerade drückt, wohin der Spieler gerade schaut (View-Koordinaten), wo der Spieler gerade steht (Positions-Koordinaten) und wie die Maus bewegt wurde. Diese Command-Listen sind circa 20 byte (~0,00002 MB) Groß.

Wenn wir 125 FPS haben, erstellen wir also 125 Commands die Sekunde. Bei 250 Frames-per-Second logischerweise 250 CPS (Commands per Second). Bei 250 FPS wird also alle 4 ms abgefragt was wir gerade machen. Bei 125 FPS alle 8 ms und bei 100 FPS alle 10 ms. Das verdeutlicht, warum wir zum flüssigen Spielen nicht mehr als 125 FPS benötigen, wer erstellt schon mehr als 125 Aktionen in der Sekunde? (Dieser Satz war bezogen auf die ESL-DE Diskussion)

Eigentlich… Ja nun, wieso eigentlich “Eigentlich“? Es gab viele – vor allem “professionelle” – Spieler, die sich beschwert haben, das es bei 125 FPS ruckeliger wäre als bei 250 FPS. Aus eigener Erfahrung kann ich sagen: Ja es stimmt, aber… das liegt meiner Meinung nach größtenteils an der Gewöhnung. Als zweiten Grund habe ich eine Theorie, die ich so nicht 100%ig beweisen kann, welche aber – für mich zumindest – schlüssig und logisch ist. Wie wir wissen wird pro FPS ein Command erstellt. Dreht man sich nun um 180° innerhalb von einer Sekunde, können nur 125° in dieser Sekunde verarbeitet werden, der rest wird interpoliert. Sollte diese Theorie stimmen, muss man sich trotzdem Fragen, ob man wirklich dauerhaft in der Lage ist diese interpolation zu sehen – das bezweifel ich stark -. Ich denke man kann sich sehr gut daran gewöhnen.

Warum verbietet nun aber der deutsche Bereich der ESL FPS > 125? Durch diese Frage kommen wir der Überschrift dieses Abschnitts schon näher, nämlich der Beziehung von Maxpackets und FPS. Wir wissen, dass durch hohe FPS, Beispielsweise 333 FPS, Bugs auftreten. Lautloses gehen ist hier das Stichwort. Auch bei 250 FPS treten Bugs im Movement etc. auf, aber solch hohe FPS in Verbindung mit den richtigen Maxpackets haben enorme – sehr wahrscheinlich unfaire – Vorteile. Um das folgende Rechenbeispiel detailiert verstehen zu können, ist es ratsam den  Kapitel 2.1 Die Maxpackets Artikel gelesen zu haben. Bitte tut dies – falls noch nicht geschehen – bevor ihr weiter lest.

100 FPS -> alle 10 ms ein neuer Frame
125 FPS -> alle 8 ms ein neuer Frame
250 FPS -> alle 4 ms ein neuer Frame

Nun rechnen wir aus in welchen Abständen und mit wievielen Command-Listen ein Paket gesendet wird, in Abhängigkeit der Einstellung von com_maxFPS.

100 FPS / 100 MP

• jedes Paket besteht aus einer Command-Liste, also ein Frame
• jeden Frame wird ein Paket verschickt
• 1 Frame = 10 ms
• alle 10 ms wird ein Paket verschickt. Inhalt: 1 Command-Liste

125 FPS / 63 MP

• jedes Paket besteht aus zwei Command-Listen, also zwei Frames
• alle zwei Frames wird ein Paket gesendet
• 1 Frame = 8 ms; 2 Frames = 16 ms
• alle 16 ms wird ein Paket verschickt. Inhalt: 2 Command-Listen

250 FPS / 84 MP

• jedes Paket besteht aus 3 Command-Listen, also 3 Frames
• alle drei Frames ein Paket
• 1 Frame = 4 ms; 3 Frames = 12 ms
• alle 12 ms wird ein Paket verschickt. Inhalt: 3 Command-Listen

Ich hoffe, dass es bis hierhin verständlich genug ist. Etwaige Fragen können in den Kommentaren gestellt werden. Hierfür benötigt ihr einen Account und müsst eingeloggt sein. Ich / Wir beantworte(n) alle Fragen sehr gerne und so schnell wie möglich!

Das Ergebnis der Beziehung

Um alles auf einen gemeinsamen Nenner zu kommen, habe ich die Zeit auf 240 ms gesetzt, hierbei ergibt sich folgendes Bild:

Für den Abgleich mit dem Server ist es natürlich am besten wenn man die 100/100 nimmt. So wird – zumindest wenn alles Konstant ist (FPS, Leitung usw.) – alles was man macht übertragen. Der Server weiss schnell bescheid (10 ms) über jeden einzelnen FPS. Es sollte genaueres Zielen möglich sein und ebenso keinen Durchschuss geben. Nachteil: Schnelle Reaktionen im ms-Bereich werden schlechter übertragen und Dargestellt.

Wenn man einen Vergleich von 125 FPS und 250 FPS anhand obiger Tabelle ansieht wird relativ schnell deutlich, warum 250 FPS ein unfairer Vorteil sind. Bei 250 FPS ist die Synchronität mit dem Server besser, man meldet dem Server 25% öfter seine Aktionen. Nicht nur, dass man dem Server öfter Aktionen übermittel (Command-Listen), sondern auch wesentlich mehr, nämlich doppelt soviele Aktionen (60 zu 30).

Nun kann man eine Grundsatz-Diskussion darüber führen, ob nicht alle Spieler, die professionell Spielen wollen, Geld investieren müssen um 250 FPS Konstant nutzen zu können oder nicht. Sollange hierbei kein Ergebnis erzielt wird ist die einzig faire Variante die FPS-Obergrenze auf 125 zu setzen.

Und wofür sorgen die sv_FPS?

Die sv_FPS sind im Prinzip das gleiche wie die com_maxFPS. Es funktioniert im Prinzip gleich wie die com_maxFPS. sv_FPS 20 bedeutet also, dass der Server alle 50 ms eine Aktion ausführt. Er arbeitet also alle 50 ms alle ihm geschickten Command-Listen ab, führt diese aus, baut ein Gameworld-Update (Frame) und schickt diesen an den Client. Der Client empfängt also alle 50 ms ein Gameworld-Update (sofern diese den Wert snaps auch auf 20 hat). Ihr seht, es ist alles genauso wie beim Client.

Jetzt könnt ihr euch ausmalen warum sv_FPS 30 wesentlich besser sind. Durch sv_FPS 30 entstehen aber Bugs, da die Coder von Call of Duty 4 viele Werte und Berechnungen auf sv_FPS 20 hardgecoded haben. Dieser Fehler kann nur durch Mods behoben werden.

Wie mache ich was?

FPS-Begrenzung einstellen:
Entweder fügt ihr der Config “seta com_maxFPS XXX” hinzu, wobei XXX für den gewünschten Wert steht oder ihr öffnet die Console (idR. mit dem ^) und gebt dort “com_maxFPS XXX” ein. Natürlich jeweils ohne die Tüttelchen.

Maxpackets einstellen:
Config -> “seta cl_maxpackets XXX”
Console -> “cl_maxpackets XXX”

Die Serverframes:
Die Serverframes werden per Befehl “sv_fps XX” eingestellt. Dieser Befehl kann entweder in die Serverconfig oder in die Startparameter geschrieben werden. Der Befehl muss vor dem Serverstart aktiviert werden, nach dem Serverstart ist er Read-Only und kann nicht mehr geändert werden.

Glossar

• MP = Maxpackets
• FPS = Frames per Second
• SV = Server
• CPS = Commands per Second
• ESL = Electronic Sports League
• ms = milli-sekunden (1 sekunde = 1.000 ms)

Die Maxpackets, als CoD Befehl cl_maxpackets, werden im Allgemeinen wie folgend beschrieben: “..Der Configbefehl cl_maxpackets bestimmt die Anzahl der maximal vom Client verschickten Gameworldupdates pro Sekunde..”. Da dies eine doch sehr oberflächliche Beschreibung ist, werden wir uns in diesem Artikel etwas tiefergehend mit den cl_maxpackets beschäftigen.

Auch wenn die Entwickler immer meinten sie hätten für Call of Duty 2 – und auch für CoD4 – eine neue Enginge entwickelt, basiert diese wohl doch, zumindest zu 95%, auf der Quake3 Engine. Somit sollten wohl auch alle Fakten bezüglich der Quake3 Engine auch auf die Call of Duty 2 Engine zutreffen. Da viele CoD2′ler auch CoD1′ler waren, beschäftigen sich die meisten mit der Maxpacketfrage schon seit mehr als 3 Jahren, oder sogar länger – eben bedingt durch den Bezug auf die Quakeengine.

Direkt zu Beginn ein kleiner Ausschnitt von dem, was der Leadcoder von SID einmal im IRC gesagt hat:

<TwentySeven> well packets at a divisor of your fps
<TwentySeven> 30 is good
<TwentySeven> every “frame” the client generates a command
<TwentySeven> a command is just a list of what buttons you have held down
<TwentySeven> and your viewangles
<TwentySeven> tiny packet like 20 bytes
<TwentySeven> now whatever your maxpackets is
<TwentySeven> is how many of those to send per packet
<TwentySeven> so cl_maxpackets 42 at 125fps
<TwentySeven> is ~ 3 commands per packet
<thnom> So why is it locked now ?
<TwentySeven> because
<TwentySeven> sending 125 packets per second is okay for 1v1 cpma
<TwentySeven> or q3
<TwentySeven> but for 14 player UrT
<thnom> Oh
<TwentySeven> thats 14*125 packets per second
<TwentySeven> essentially a ddos attack

Somit wäre schonmal geklärt, warum sich der Spielraum der Maxpackets nur in dem Bereich von 10-100 dreht. Höhere Maxpackets wuerden zwar nicht gleich zu einer DDoS Attacke des Servers führen, aber zu einer hohen Serverbelastung, somit zu Lag und ausserdem zu wesentlich mehr Traffic.

Das Q3 System habe ich bislang immer so verstanden, dass sowieso nur alle 50ms (bei sv_fps 20 – welches bei CoD2 leider nicht anders geht, ausser mit dem neusten PAM Mod) ein neuer Frame serverseitig berechnet wird und dann an die Clients verteilt wird. Es ist also vollkommen egal, ob von einem Player in den 50ms etwa 6,25 (cl_maxpackets 125/20) oder 1,5 (cl_maxpackets 30/20) Pakete ankommen, die werden sowieso nur in eine Queue gestellt und nacheinander später, wenn wieder ein Server frame generiert wird, weitergereicht und abgearbeitet.

Der zusammenhang von com_maxfps und cl_maxpacket scheint sehr vielen nicht ganz klar zu sein. Vielleicht hilft folgendes einigen bei ihren Connection-Einstellungen. Grundsätlich kann der Client pro Frame maximal ein Paket an den Server schicken.

com_maxfps 100 + cl_maxpacket 100 = 100 verschickte pakete
com_maxfps 76 + cl_maxpacket 100 = 76 verschickte pakete
com_maxfps 76 + cl_maxpacket 76 = 76 verschickte pakete

Natürlich verursachen zu niedrige Maxpackets, wie zum Beispiel 30, einen Kuenstlichen Lag, deshalb ist es gut, dass in den meisten Liegen die Maxpackets auf 60-100 beschränkt sind. Aber nicht nur für die Mitspieler sind zu niedrige Maxpackets fatal, auch für einen selber, denn wenn die Maxpackets falsch eingestellt sind, schickt der Client die generierten Commands mit Verzögerung – da nur jeden 2., 3. oder 4. Frame – an den Server. (Dazu mehr in einem anderen Teil von GameGuide)

Zum Beispiel:
com_maxfps 76 + cl_maxpacket 60 = 38 verschickte pakete

Für 76 FPS gibt es nur die Möglichkeit 76 Maxpackets einzustellen, da in den meisten Turnieren und Co. mindestens 60 Maxpackets gefordert sind. Stellt man nun aber 60 Maxpackets ein, nimmt die Enginge den nächst niedrigeren Wert, also 38 Maxpackets. Dies kommt – wie gesagt – dadurch, dass die Engine als Maxpackets-Divisior nur ganze Zahlen nehmen kann.

Wir sollten nun die Frage klären, welche Maxpackets wir in diesem Bereich waehlen sollten. Wie der Leadcoder schon sagte: “Ein teiler der FPS ist eine gute Wahl”. Wie wir aber auch wissen, es macht keinen alzugroßen Unterschied ob wir 2 Packete oder 6 Packete pro Frame verschicken. Manchmal ist weniger auch mehr, vor allem im Internet, so können wir Lag vermeiden. Der Teiler muss ein Integer-Wert sein. Ein Integer-Wert ist eine ganze Zahl, also 1,2,3..10 etc., nicht 1.2 oder 4.5. Dies beruht auf dem Quellcode der Quake-Engine. Warum dies so ist wird in einem anderen Teil der Serie erklärt.

Meine Empfehlungen:
FPS: 76 / Maxpackets: 76
FPS: 125 / Maxpackets: 63
FPS: 333 / Maxpackets: 84, bzw. 100

76,125,333 sind FPS-Werte bei denen der Strafejump funktioniert.

FPS: 250 / Maxpackets: 84
FPS: 100 / Maxpackets: 100
FPS: 60 / Maxpackets: 60

Ich habe versucht diesen Artikel möglichst niedrig im Niveau zu halten, damit er für jeden verständlich ist. Ich bin absichtlich nicht näher auf Übertragungsprotokolle etc. eingegangen. Sollte hierbei bedarf sein, nutz bitte die Kommentarfunktion.

Als Abschluss: Da sich der Befehl cl_packetdup auch auf die Maxpackets bezieht, folgend noch ein kleiner Hinweis:

<TwentySeven> “CL_packetdup is a multiplier, not a “number of packets to send” so CL_packetdup 0 and 1, both mean only one copy is sent. cl_packetdup 2 means two copies.

Die zwei Bereiche

Die obere Linie bezieht sich auf die Übereinstimmung zwischen Clientframes und Serversnaps:
blau = alle vom Server erzeugten Gameworldupdates werden vom Client verarbeitet
gelb = es werden Gameworldupdates nicht angezeigt, d.h. entweder sollte man den Wert fuer Snaps verringern oder seine Grafiksettings auf mehr fps trimmen.

Die untere Linie bezieht sich auf die eintreffenden Packete der Verbindung :
gruen = Die Verbindung ist ohne Packetverluste, alle Daten vom Server kommen beim Client an.
gelb = Es werden Packete vom Client selbst gedroppt. Maßnahme : “rate” erhöhen.
rot = Es sind Packete auf dem Weg von Server zu Client verlorengegangen, das ist der beruechtigte Packetloss. Maßnahme : Die Variable “cl_packetdup” auf 2 oder hoeher stellen, wenn das nicht hilft, den Server oder den ISP wechseln.

Das Volumen der Linie

Das Volumen der Linie gibt Auskunft über die Verzögerung in ms zum Server, bzw. vom Server. Wenn wir als Beispiel die untere Linie nehmen, wäre es am besten sie wäre Grün und ganz klein unten.

Wie sieht das Lagometer aus?

Aktivierung

“Die Informationen sind ja alle schön und gut, aber wie aktiviere ich nun dieses Ding?” Der Configbefehl für das Lagometer ist “cg_drawLagometer”. Die “1″ hinter diesem Befehl schaltet das Lagometer an und die “0″ deaktivert es wieder.