Hallo, ich habe folgendes Problem:
Ich habe eine CS Map gemacht, die sehr groß geworden ist. Ich habe sie mit den ZHLT Compilern kompiliert und eine wesentliche Verbesserung im Vergleich zum Hammer Compiler festgestellt. Die Map selbst ist ein Nachbei eines alten NES Adventures. Mein Problem nun: Dadurch, dass die Map so groß ist, braucht man viele Leute, die darauf spielen können. Ich teste die Map immer mit Bots und am Anfang hatte ich (verwendete viele ambient_generics und doors) nur bis ca. 5 gegen 5 ruckelfrei spielen können. Jetzt, nachdem ich fast alle ambient generics rausgestrichen habe, kann ich ca bis 10 gegen 10 großteils ruckelfrei spielen. Ich habe einen großen Raum im Spiel, in dem, wenn sich die Spieler dort treffen, sowieso die Performance-Hölle los ist, aber dagegen wird man wohl nichts machen können oder?

Meine Frage nun: Wie spare ich effizient Performance ein, sodass möglichst viele Leute spielen können? Ich schreibe hier noch eine Liste mit Entities, die ich verwendet habe

* func_ladder (sicher mehr als 10, könnte 2-3 entbehren)
* light (aufgrund der großen map sehr viele, aber nicht so viele als dass es iwo eine Überbelichtung gäbe)
* ambient_generic (6)
* func_button (6-8)
* func_breakable (15)
* func_door_rotating (10-15)
* func_train (1)
* path_corner (4)
* func_bomb_target (2)
* cycler_sprite (1)
* Startpunkte (mehr als 16 für jedes Team, wobei hier sowieso viele überflüssig sind, aber ich nicht weiß, ob die so zum Performance-Fressen beitragen wie der Rest)

Die ambient_generics würde ich gerne behalten, da sie sehr gut zur Stimmung des Spiels beitragen.
Meistens kommt es nur zu Ruckelein bei Schusswechseln, bei denen mehr als 5 Spieler sich gleichzeitig irgendwo treffen.

Ich bin dankbar für jede Art von Tipps!

Poste mal ein Bild von dem großen Raum. Würde nämlich schätzen, dass dieser mit die Hauptverantwortung trägt.

Ich wuerde mal sagen, du suchst den Schuldigen an falscher Stelle. Die paar Entities (<100) werden wohl kaum die Performance in den Keller ziehen.
Das einzige was kosten koennte, waeren die Lights falls dort massiv auf Appearances (Flackern, etc.) gesetzt wird. TexLights sehen uebrigens in fast allen Faellen wesentlich besser aus als normale Punktlichter.
"Grosser Raum" und "Nachbau" klingt stark nach Engine-Vergewaltigung durch fehlende VIS-Blocker wodurch sich staendig sehr viel Geometrie im PVS (Potentially Visible Set) befindet und dadurch natuerlich die Performance leidet. Ohne aber wenigstens mal ein Bild der Map gesehen zu haben laesst sich da nur schwer eine Aussage treffen.

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Je nachdem ob die Map unter freiem Himmel ist, kannst du auch einfach nen light_environment setzen. Das sieht 1. 100x besser aus und ist 2. kinderleicht!

http://www.fpsbanana.com/maps/132911
http://www.fpsbanana.com/maps/134201
http://www.fpsbanana.com/maps/107942

Hier ein Screenshot des großen Raumes mit einem Bot als Vergleichsgröße

http://img227.imageshack.us/img227/7114/bild1lf.jpg

Ich kann auch die Map selber hosten, falls sich jemand diese genauer ansehen will.

@kainstuk:
Der Teil, der unter freiem Himmel ist, wird mit einem light_environment belichtet.

Ich hoffe doch mal schwer die Kronleuchter, Baeume und die Treppe sind func_walls.

There is nothing wrong with high standards. It's your problem that you don't meet them.
If you think it's simple, then you have misunderstood the problem.
When a customer says "nothing has changed", assume they're lying.

Jap, sind sie

Lad die Map mal hoch, der Raum sollte an sich gar kein Problem darstellen, da gibt es weit aus größere Räume. Gehe von unsauberer Arbeit aus, siehe auch Bluthunds Post.

Compiled oder rmf datei?

Ruhig die .rmf Datei.

hier die datei:
http://www.4shared.com/file/u_anaCC6/map1.html

Hab jetzt einen kurzen Blick drüber geworfen:

- sehr unsauberes Arbeiten, Brushes überlappen sich teilweise mehrfach, ragen durch andere durch usw.
- Brushes mit der sky-Texture müssen diese, afaik, quasi auf allen Seiten haben und keine anderen Texturen
- viele unschöne Brushes sind keine func_wall's und zerschneiden viele Stelle
- kaum vis-blocker

Kann dir die beiden (guten) Artikel ans Herz legen:
http://www.thewall.de/content/half-life:tutorials:r_speeds
http://www.thewall.de/content/half-life:tutorials:hint-brushes

- Brushes mit der sky-Texture müssen diese, afaik, quasi auf allen Seiten haben und keine anderen Texturen
- viele unschöne Brushes sind keine func_wall's und zerschneiden viele Stelle
- kaum vis-blocker

Kann dir die beiden (guten) Artikel ans Herz legen:
http://www.thewall.de/content/half-life:tutorials:r_speeds
http://www.thewall.de/content/half-life:tutorials:hint-brushes
OK Danke, werd ich machen.

- sehr unsauberes Arbeiten, Brushes überlappen sich teilweise mehrfach, ragen durch andere durch usw.

Das hingegen wäre mir neu ..

Na, wenn dir das neu ist, dann einige Beispiele, ich könnte lange so weitermachen:

Unsauberes Arbeiten + kein func_wall:

Unsauberes Arbeiten + nicht am Grid:

Unsauberes Arbeiten + Tür im Nirgendwo:

Alle markierten Brushes sind keine func_walls (ich hab die Wand zwecks Bild entfernt), die Treppe ist ein Graus:

Ich denke mir so was ja nicht aus ;)

OK verstehe ^^
zu Bild1 und 4 hätte ich eine Frage: ab wann ist es empfehlenswert Brushes zu einem func_wall zusammenzufügen?
Bild Nr2: könntest mir bitte die Koordinaten sagen, finde das nirgendwo, würde es gerne ausbessern.
Bild3: Ja die Tur hatte ich immer als Vorlage für andere Türen und in der Zwischenzeit immer außerhalb der Map gelagert, hab wohl vergessen die zu löschen.

Bzgl unsauberes inanderstapeln von Brushes: Manchmal hatte ich ein Leak angezeigt wo ich keines finden konnte und habe durch Brushes ineinanderstecken dann das Leak eingegrenzt und halt lieber so belassen als dass ich ein Leak habe. Ist das Ineinanderstapeln wirklich so schlimm?

Danke für deine Mühen, finde ich toll! :)

Zu deinen Fragen:
Im Artikel über r_speeds (http://www.thewall.de/content/half-life:tutorials:r_speeds) kannst du vieles nachlesen. Zum Beispiel, ab wann ein Brush besser ein func_wall sein sollte, bzw. wann nicht (Punkt: Verwendung von func_walls). Besonders der Punkt "Wichtige Hinweise" und die darauf folgenden Trricks zur Poly-Reduktion sind recht effektiv. Zu den überlappenden und angrenzenden Brushes ist der Punkt "Spezielle Bauweise aneinanderstoßender Brushes" interessant (auch im r_speed Artikel).

Die Koordinaten kann ich dir gerade nicht sagen, es war eine Stelle im Außengebiet, Felswand/Sand.

Lieber sauber Arbeiten und Leaks immer vermeiden, als unschön die Leaks mit wirren Brushes versuchen zu beschränken, geht meistens nach hinten los ;)

Zu der Treppe:

Ich bau meine Treppen meistens so, kommt eben ein bisschen drauf an, wie der Raum aufgebaut ist (rot ist func_wall):

Großes Dankeschön Raziel, deine Tipps haben die Performance-Probleme meiner Map um Einiges geschmälert. Das einzige bei dem du falsch lagst, war der Sky. Die Blöcke verursachten, nachdem ich sie auf allen Seiten mit Skytexturen einfärbte, ein viel zu helles Nachtbild.
Der func_wall Tipp hat echt sehr viel gebracht, bei mir wurden scheinbar wirklich extrem viele Flächen unnötig zerschnitten. Kann mittlerweile problemlos 16 on 16 spielen, danke! :)

so jetzt darfst du uns die map mal präsentieren wenn sie fertig ist :)

Hilfestellung nach dem Vorbild TheWall: "Lies die Tutorials, Kacknoob wolololo" -Agamemnon-Hellmapper

Ähm, das mit der Skytextur kommt von den Einstellungen deines light_environment.

bla.. ich hab sowieso keine Ahnung ^^

de_italienvillage -> Beta-Phase.. bis jetzt nicht darüber hinausgekommen.