3DGaming.de Network

FORUM »
SUCHE »
 
 3DGAMING

  NEWS
  NEWS SENDEN
  SUCHE
  NEWSLETTER
  NEWS-ARCHIV
  UMFRAGEN

  IMPRESSUM

 IN-HOUSE

  TUTORIALS
  KOLUMNEN
  REVIEWS

 SERVICE

  ADD-ONS
  FREE BOOKS
  TREIBER
  JOBS
  LEVEL EDITORS
  ARTIKEL
  DEMOS
  FILESHARING
  PORTALE

 COMMUNITY

  FORUM
  MAPS
  MAP CONTEST
  CLANS
  FAN-SEITEN
  LINKS
  PLAN FILES
  BYTEFRESSER


 WELTBEWEGEND
Welcher der folgenden Shooter wird deiner Ansicht nach am längsten in der Community überleben?

BF 1942

UT 2003

MOH:AA

3DGaming.de - Q3Radiant Tutorials - Zurück zum INDEX

Details: Was "die perfekte Map" auszeichnet


Die perfekte Map. Sicherlich Geschmackssache - aber so einige Punkte sollten als Richtlinien schon beachtet werden, schliesslich sprechen wir hier von "Perfektionismus". Also - ohne Umschweife, meine Meinung zum Thema:

TECHNISCHE DETAILS

  • Sauber arbeiten: Sauberes Arbeiten ist das wichtigste im Level Editing. Niedrige Compile-Zeiten, keine lästige Suche nach Leaks, höhere Frameraten und besserer Überblick sind der Lohn für ein bisschen Sorgfalt und ein wenig mehr Zeitaufwand.
  • Keine überlappenden Brushes: Bemühe dich dafür zu sorgen, dass möglichst kein Brush in einen anderen hineinragt. Die Funktion "Hollow" beispielsweise liefert sehr unsaubere Ergebnisse - wenn du sie benutzt, solltest du hinterher "aufräumen". Überlappende Brushes wirken sich negativ auf die Compile-Zeiten aus.
  • Framerate im Auge behalten: Durch den Konsolenbefehl "/cg_drawfps 1" erscheint im Spiel rechts oben die aktuelle "Framerate" (Bildwiederholrate). Starte eine der in Quake 3 enthaltenen Maps - am besten eine Mittelgrosse, die den Rechner schon ein wenig fordert. Dann stell die Auflösung so lange höher bzw. niedriger, bis du in dieser Map Frameraten erreichst, die man allgemein als untere Spielbarkeitsgrenze bezeichnet (50-60fps). Die Map, die du dir bastelst, sollte nur so detailreich sein, dass du an keiner Stelle diese Framerate deutlich unterschreitest.
  • Leaks: Maps in allen bisherigen Quake-Engines müssen und mussten in sich geschlossene Gebilde sein. Quasi eine Kiste, aus der nirgendwo Wasser herauslaufen könnte. Wer in seiner Map irgendwann auf einen Punkt trifft, wo die Frameraten plötzlich auf 5fps abfallen, der kann sich fast sicher sein, dass sich in seinem Blickfeld ein extrem unvorteilhaft (kaputt-)manipulierter Brush befindet.
  • Klare Strukturen: Wer komplexe Gebilde aus Brushes konstruieren will, der sollte sich vorher Gedanken über die sinnvollste Struktur machen. Das spart Brushes & Polygone und ist hinterher sicher auch leichter zu verändern. Wer früher mit Bauklötzen gespielt hat ist klar im Vorteil. ;o)
  • Caulk: Vielleicht der sinnvollste Bestandteil des "Common"-Textursets ist der "Caulk"-Shader. Seine Benutzung allerdings setzt Perfektionismus vorraus - Wer es auf's Äusserste treiben möchte, der: a.) setzt diesen Shader auf Oberflächen, die hinter Curves liegen und somit unsichtbar sind (sorgt für einen sauberen, flickerfreien Übergang zwischen Brush und Curve); b.) setzt diesen Shader auf alle Oberflächen, die unter keinen Umständen jemals vom Spieler gesehen werden können (Brushseiten, die vollständig von einem anderen Brush verdeckt sind etc.). Warum? Nun, Oberflächen mit dieser Textur werden beim Compilen ignoriert, unter keinen Umständen in der Engine als Polygone gerendert - hinter Curves kann man sich "Caulk" als eine Art Leim vorstellen, der sauber zwischen Rundung und ebener Brush-Oberfläche abschliesst.
  • Shader: Welch wunderbares Feature in der Quake 3-Engine, aber Vorsicht! Übermässiger Einsatz von Shadern in einer Szene kann die Framerate tiefer nach unten ziehen als die lieb sein sollte. Grafikkarten unter der TNT2-Klasse gehen da schnell in die Knie, da die teilweise mehr als 4 "Animations-Phasen" oder auch Metallic-Effekte diesen ernormen zusätzlichen Rechenaufwand abverlangen - in jedem gerenderten Frame auf's Neue.
  • Visibility: Die Quake 3-Engine rendert im Idealfall immer nur das, was der Spieler von seinem momentanen Aufenthaltsort aus potentiell sehen könnte. Alles andere ist für diesen Moment nicht relevant und belastet somit weder Grafikkarte noch Prozessor und Speicher. Das geschickte Setzen von Trennwänden oder 90-Grad-Biegungen in Gängen sorgt dafür, dass in sich geschlossene Areas entstehen. Befindet sich der Spieler mitten in einer solchen Area, wird der Rechner nicht unnötig mit dem Rendern dessen, was sich hinter der nächsten Ecke befindet belastet.
  • Area Portals: Wer seine Map mit "FullVis" compilet hat und das Visibility-Prinzip versteht, der ist schonmal ganz gut gewappnet. Weiteres Schmankerl zur Vermeidung des Renderns unnötiger Polygone ist das Setzen von "Area Portals". Wer in seiner Map eine automatisch öffnende Tür benutzt, der kann (die Türöffnung abdeckend aber innerhalb des Tür-Brushes) durch das Setzen eines "Area Portals" verhindern, dass das was hinter der Tür liegt gerendert wird, solange diese verschlossen ist. Geschickt angewandt kann diese Funktion sehr hilfreich sein.
  • Clipping: Kleinere hervorstehende Ecken und alle Punkte, die die freie Bewegung des Players unvorteilhaft und unnötigerweise beeinflussen, sollten geclippt werden, damit sie kein Hindernis mehr darstellen aber optisch immer noch vorhanden bleiben können.
  • Detail Brushes: Die Markierung kleinerer Brushes als "Detail Brushes" beschleunigt den Vis-/ Kompilierungs-Prozess enorm. Alle kleineren Brush-Gebilde, die niemals wirklich als sinnvolle Sichtblockade funktionieren würden (So wie Geländer, Fenstersimse, Säulen etc.), sollten mit dieser Eigenschaft versehen werden, damit sie beim Vising ignoriert werden.


OPTISCHE ASPEKTE & GAMEPLAY

  • Thematisch verwandte Texturen: Der Designer sollte sich bemühen, optisch verwandte Texturen zu benutzen. Die Textursets "Gothic" und "Base" zu kombinieren ist zwar nicht unmöglich aber dennoch sehr schwierig und mit Vorsicht zu geniessen. Schliesslich ist das Ziel doch auch die Entstehung einer glaubwürdigen Szene. Adrian Carmack's phantastische Totenköpfe können neben einem animierten Monitor schnell lächerlich wirken.
  • Flow: Der Spieler sollte die Möglichkeit haben, die Map-Struktur schnell zu durchschauen. Er sollte sich in der Map schnell und komfortabel bewegen können, ohne ständig an kleinen Ecken hängen zu bleiben.
  • Ebenen: Nur in bestimmten, seltenen Fällen sind Maps, die sich kostant auf dem gleichen Höhenlevel bewegen interessant. Treppen, Jump-Pads, Brücken, Panorama - das alles sind gerngesehene Elemente, solange der "Flow" nicht darunter leidet.
  • Grössenverhältnisse: Nichts ist schlimmer, als 3 Monate an einer phantastisch aussehenden, riesigen Map gebastelt zu haben, nur um dann nach dem Compilen des .aas-Files und dem Spielen mit Bots feststellen zu müssen, dass die Architektur die Player Models daneben wie Zwerge wirken lässt. Testet die Map früh mit Bots und achtet auf realistische Verhältnisse (beispielsweise auch bei einer Tür oder der Deckenhöhe) - setz dir einen Standard.
  • Waffen & Items: Was nützt es, wenn du zwar alle verfügbaren Waffen quer im Level verteilst, hinterher aber doch jeder mit dem Rocket Launcher durch die Gegend rennen kann, weil genug davon + Munition in der Gegend rumliegt. Überleg dir gut, wie deine Map hinterher gespielt werden soll und richte dich danach. Der Einsatz der BFG beispielsweise kann das Gameplay in einer ansonsten guten Map völlig zerstören. Geschickte Plazierung von Health Power-Ups kann die Lebensdauer der Spieler erhöhen und das Match interessanter machen.
  • Licht: Mehrere kleine, vielleicht farbige Lichtquellen schaffen schönere und mitunter realitischere Szenen, als eine Lichtquelle mit sehr starker Leuchtkraft. Zudem sollten Lichter ohne erkennbare Quelle (Leuchter, Spotlights etc.) idealerweise vermieden werden.
  • Spawn-Punkte: Die Zahl der "info_player_deatchmatch"- und anderer Entities ist nicht begrenzt. Sorge für sinnvolle und für ausreichend viele Spawn-Punkte. Niemand hat auf Dauer Spass, wenn er immer wieder in einem Pulk von kämpfenden Gegnern spawnt und direkt wieder das Zeitliche segnet.


Wie man die obengenannten Ziele erreicht, werden zukünftige Tutorials demonstrieren. Wer bis dahin Fragen hat, kann sich in unserem Forum austoben - Antwort garantiert.


» Q3Radiant Tutorial Index



Q3Radiant Tutorials © 2002 3DGaming.de
Autor: Alexander "LEXI" Golubowitsch.



20.09.2017
16:45


Q3R TUTORIALS

  Installation
  Weitere Tools
  Handbücher

 Grundlagen:
  Episode 1
  Episode 2
  Episode 3
  Episode 4
  Episode 5
  Episode 6
  Episode 7
  Episode 8
  Episode 9

 Details:
  Anatomie 1
  Anatomie 2
  Details 1
  Details 2

 Interviews:
  R. A. Duffy

 Forum:
  Q3 Mapping


Diese Webseite einem Freund empfehlen !


 DISCLAIMER
Hinweis: Der Inhalt der verlinkten Seiten wird nicht überprüft und so kann der Betreiber dieser Homepage nicht dafür - wie in dem Urteil vom 12.5.98 des LG Hamburg festgelegt - verantwortlich gemacht werden.


 

 LEXI
 KELLNER
 SELCUK
  3DGAMING.DE
© 2000-2011 3DGaming.de - IMPRESSUM - Wir übernehmen keine Verantwortung für die Inhalte der Web-Seiten, auf die wir verweisen. Alle auf dieser Webseite genannten Warenzeichen und Marken sind Eigentum der jeweiligen Besitzer. Die hier geäusserten Meinungen entsprechen nicht notwendigerweise der Meinung der Arbeitgeber der Autoren. 800x600 bei 16bit Farbtiefe ist die niedrigste unterstützte Auflösung. Internet Explorer 5.x und Netscape Navigator 4.x+ empfohlen.