Zerg-Eco

[MegaVolt]

Bei einem Replay mit Anzeige der Drohnenzahl ist mir aufgefallen, wie viel weniger Arbeiter ein Zerg hat verglichen mit anderen Rassen.

Bisher dachte ich immer, dass ein Zerg eine Basis mehr haben muss als andere Rassen um die geringe Effektivität der Einheiten (vs Psi-Sturm, Reaver, MMs, Vessels) auszugleichen. Aber durch die geringe Drohnenzahl könnte es auch genausogut sein, dass der Zerg mit 3 Exen doch genausoviel Einkommen hat wie der Terra mit 2.

Hat da jemand genaue Zahlen? Also mittleres Einkommen bei einer Exe abhängig von der Arbeiterzahl?

 

[NacktNasenWombi]

Schonmal dran gedacht, dass der zerg evtl das ganze Gas braucht?

 

[IsCream]

Man darf auch nicht vergessen, dass die Zerg durch drohnen Gebäude bauen.

Da geht dann auch ne Drohne flöten und somit is der zerg auch im Nachteil, was eco angeht. Ich gebe zu ich vermute mal, aber: je mehr Exen, desto besser für Zerg, da er schon wenig eco hat. Ecorape an einer exe bei zwei einkommen ist härter als an dreien. Aber das, was Wombi schrieb, stimmt natürlich auch. Zergunits - insbesondere Latetech-units (und ohne die gehts kaum), sind sehr gasintensiv!

 

[WerZerg]

du hast schon recht, meist verdient der zerg mit weniger eco dafür mehr exen etwa das gleiche wie der gegner und kann ihn damit auch schlagen. etwas mehr gas sollts halt schon sein.
schau dir einfach nach dem reps kurz die resourcenstatistik an, oft genug hat der zerg etwa das gleiche verbraucht wie sein gegner.

 

[Muthombo]

mit 3 drohnen erntet man schon mehr als 50 mins/larvenzeit. d.h. für linge braucht man 3 drohnen/hatch, für mutas 6 pro hatch. deutlich mehr wirds erst bei ultras, aber da braucht man eh 1:1 mins:gas.

reinen mineral-überschuss kann man in units nur als linge verwerten. und für 3 zusätzliche erntende drohnen braucht man dann jeweils ne extra hatch. und die ist teurer als ein gate oder ne rax. daher spart man sich meistens lieber gleich die zusätzliche eco und teure baukapazität und greift stattdessen entsprechend früher an.

ein protoss hingegen hat im nexus eh nix anderes zu tun als probes zu bauen. zealots kann man immer gebrauchen, und gates sind billig.

 

[MegaVolt]

Ich war nur sehr beeindruckt, dass der Zerg trotz fast exe und 3hatch build c.a. 1/3 weniger Drohnen hatte als der Protoss. Das ist schon ne Hausnummer.

Was ich mit genauen Zahlen meinte:
Mineralienfeld mit 8 patches. Eine Drohne baut X pro Minute ab. Bis alle 8 Drohnen drauf sind steigt die Fördermenge linear an, d.h. 8 Drohnen bauen dann 8*X ab.
Die 9te ist dann aber nichtmehr ganz so effektiv. Die muss nämlich manchmal warten, weil patches besetzt sind. Also sind das dann nurnoch Y*X mit 8 < Y < 9. Je mehr Drohnen dazukommen, desto geringer steigt die Fördermenge.

Kann jemand diese Zahlen einfüllen bzw gibt es da irgendeine Formel, die hinreichend genau beschreibt, wie viel Mineralieneinkommen man bei wievielen Arbeitern hat?

 

[Muthombo]

da gabs "neulich" mal nen thread, wo es um die optimale probe-anzahl ging:
http://starcraft2.ingame.de/forum/showthread.php?s=&threadid=124264

fazit:
solange sich die probes nicht gegenseitig behindern, amortisiert sich eine neu gebaute probe in weniger als einer minute erntezeit. bei über 3 probes/minblock liegt die zeit schon bei 2-3 minuten usw. 1/8 pylon-kosten sind mit eingerechnet, die bauzeit käme aber noch dazu. bei zerg muss man auch noch berücksichtigen, dass man für jede zusätzliche drohne ne larve opfert.

 

[Sansucal]

megavolt beziehst du dich jetzt auf 1 rep oder auf viele?

 

[MegaVolt]

Original geschrieben von Sansucal
megavolt beziehst du dich jetzt auf 1 rep oder auf viele?

Beliebige ZvT und ZvP bei den GomTV VODs. Dort sieht man immer aktuelle Einheitenzahlen im Zähler rechts unten, anfangs eben die Arbeiter. Eigentlich in jedem Spiel hat der Z deutlich weniger davon als T oder P.

 

[voelkerballtier]

jo da gabs mal ne untersuchung und ich glaub das ergebnis war, dass bis ca 12 sammlern auf 8 patches das einkommen linear steigt und danach langsam der Behinderungseffekt einsetzt. Bei etwa 22-24 sonden ist dann das Einkommen ziemlich an der Sättigung, d.h. neue Sammlern bringen quasi nichts mehr.
D.h. also dass ein Zerg mit 4 Basen und jeweils 12 Sammlern viel mehr Einkommen als ein Protoss mit 2 Basen und jeweils 24 Sammlern hat. Gut möglich, dass das Einkommen des Zerg bei 4 Basen mit jeweils 8 Drohnen ungefähr dem des Protoss mit 2*24 Sonden entspricht. Insofern denke ich schon, dass du mit deiner Vermutung durchaus richtig liegen könntest. Das mehr an Gas kommt da natürlich auch noch dazu.

 

[borlee]

Original geschrieben von Wuselmops
fazit:
solange sich die probes nicht gegenseitig behindern, amortisiert sich eine neu gebaute probe in weniger als einer minute erntezeit. bei über 3 probes/minblock liegt die zeit schon bei 2-3 minuten usw. 1/8 pylon-kosten sind mit eingerechnet, die bauzeit käme aber noch dazu. bei zerg muss man auch noch berücksichtigen, dass man für jede zusätzliche drohne ne larve opfert. [/B]

das bild stimmt doch nich wirklich bei 6 patches wuerden sich doch die ersten 6 probes gleich schnell amotisieren?!!

bin mir nich sicher

 

[MegaVolt]

Das hier beantwortet eigentlich fast alle Fragen:
http://www.yellowchrome.org/1com/sclegacy/final_review.pdf
Danke an Wuselmops, ist aus dem von ihm verlinkten Thread.

Hier sieht man auch (leider nur für 6 patches) in etwa, wie stark der Wanderungseffekt ist bzw. wann die Sättigung eintritt.

2 Basen mit jeweils 6 Arbeitern sind demnach in etwa so effektiv wie eine mit 16.

Original geschrieben von boringfl

das bild stimmt doch nich wirklich bei 6 patches wuerden sich doch die ersten 6 probes gleich schnell amotisieren?!!

bin mir nich sicher

Korrekt. Im Graphen ist wohl eine Fitfunktion zu sehen, die einfach schlecht erstellt wurde. Außerdem gibt es natürlich eine Messungenauigkeit, so dass man (auch in der Tabelle weiter oben) bei den ersten 6 Arbeitern Schwankungen sieht, die natürlich rein zufällig sein müssen. Gleiches gilt für die hinteren Werte, wo manchmal das Mineralieneinkommen mit einem zusätzlichen Arbeiter sinkt - Zufallsschwankungen um den Mittelwert.

 

[Muthombo]

ja, die funktion ist in den randbereichen nicht exakt. ich hab den ertrag mit ner exponentialfunktion gefittet:

aus der ableitung dieser fit-funktion hab ich dann die amortisierungszeit berechnet. korrekterweise hätte man das natürlich stückweise mit unterschiedlichen funktionstypen fitten müssen, aber es ging mir nur um ne grobe größenordnung für die amortisierungszeit.

 

[MegaVolt]

Der Exponentialfit ist schonmal wesentlich besser als der Polynomfit aus dem anderen topic

Genaugenommen müsste man aber für den Exponentialfit den linearen Teil herausrechnen. D.h. nicht die Arbeiterzahl selbst als Variable nehmen sondern (Arbeiterzahl - Patches) und das Grundeinkommen, das die 8 Arbeiter auf den 8 Patches (oder 6/6, ist ja egal) auch abziehen.
Dass der Zusammenhang für die ersten Arbeiter linear ist, ist ja bekannt

Bei deinem Exponentialfit sieht man imho recht deutlich, dass aufgrund des fälschlicherweise eingerechneten linearen Teils die Vorhersage für große Arbeiterzahlen falsch (systematisch überschätzt) ist. Eine Projektion der Formel auf Zahlen über 20 Arbeiter ist somit nicht zulässig.

 

[Muthombo]

ein summand im exponenten würde einfach vom vorfaktor A1 (freier fitparameter) aufgefangen. dasselbe gilt für das grundeinkommen (y0). das würde also unterm strich nichts am ergebnis ändern.

wenn man es genauer machen wollte, bräuchte man noch mehr werte im oberen bereich. ich vermute mal, dass der verlauf dort einfach nicht mehr exponentiell ist, sondern wegen dem polonaisen-effekt stärker abflacht.

aber der "arbeitspunkt" ist ja praktisch immer im bereich 0-3 probes/patch.

 

[MegaVolt]

Jain, ganz so meinte ich das nicht. Für die ersten 6 Datenpunkte kennen wir ja die Formel: m(p) = const. * p. D.h. der Exponentialfit sollte erst ab dem 7ten patch einsetzen, sonst wird der Fit durch den linearen Bereich ungenauer.

 

[sinusx]

Original geschrieben von MegaVolt
Der Exponentialfit ist schonmal wesentlich besser als der Polynomfit aus dem anderen topic

Ich würde da aus heutiger Sicht (7. Semester) auch anders rangehen, hatte mich damals für diese Geschichte hier angemeldet. ~10/2006
Witzig, dass die Pics noch online sind, die hatte nen Kumpel auf seinen Webspace gelegt, weil ich noch keinen hatte.

Wenn du Lust hast, dann nimm doch mal selbst paar Werte auf, vllt auf realistischeren Maps und besserer Genauigkeit. Ist ja ein interessantes Thema.

 

[Muthombo]

Original geschrieben von MegaVolt
Jain, ganz so meinte ich das nicht. Für die ersten 6 Datenpunkte kennen wir ja die Formel: m(p) = const. * p. D.h. der Exponentialfit sollte erst ab dem 7ten patch einsetzen, sonst wird der Fit durch den linearen Bereich ungenauer.

achso. ja, das meinte ich auch mit:

korrekterweise hätte man das natürlich stückweise mit unterschiedlichen funktionstypen fitten müssen

und ob die messreihe wirklich schon in der vollständigen sättigung angekommen ist, wie das die letzten 4 werte auf den ersten blick vermuten lassen, ist noch die frage. die fehlerbalken (wurzel aus anzahl der fuhren) und starken schwankungen in anderen bereichen deuten eher darauf hin, dass es auch zufall sein kann, dass die 4 letzten werte so nahe beieinander liegen.