Difference between revisions of "Tutorials/Mapping Old"
(→Testing maps in-game: rewrite some DevHC words since he is unreachable for relicensing)
|Line 388:||Line 388:|
==Testing maps in-game==
==Testing maps in-game==
For testing purposes, it is most convenient to place your compiled <code>.bsp</code> file in the <code>main/maps/</code> subdirectory of the [[Running_the_game#Data_locations|data location]] appropriate to your system. Once you have done that, you can load your map with either the <code>devmap</code> or <code>map</code> commands after setting <code>sv_pure</code> to 0. The former allows using
For testing purposes, it is most convenient to place your compiled <code>.bsp</code> file in the <code>main/maps/</code> subdirectory of the [[Running_the_game#Data_locations|data location]] appropriate to your system. Once you have done that, you can load your map with either the <code>devmap</code> or <code>map</code> commands after setting <code>sv_pure</code> to 0. The former allows using commands ("cheats") that make it easier to test. Additional commands are discussed on the [[testing]] page.
==Testing maps publicly==
==Testing maps publicly==
Revision as of 14:57, 22 January 2018
- 1 Overview
- 2 Acquiring the game pack
- 3 Tutorials
- 4 Design mentality
- 5 Understanding Radiant
- 6 Using Radiant
- 7 Entities
- 8 Size Guidelines
- 9 New Features
- 10 Testing maps in-game
- 11 Testing maps publicly
- 12 Packaging maps for distribution
- 13 Resources
Map geometry is created using either a conventional modeling program (such as Blender) or with some variant of Radiant. Do note that if you intend on using Blender, you will need to use Radiant to perform a few final steps. This is discussed further below.
Radiant is the name used to refer to id Software's map editing tools from Quake 3 onwards.
- QuakeEd — Developed internally at id and used to create maps for Quake. Written for NextStep.
- QE4 — Developed internally at id and used to create maps for Quake II.
- QERadiant — A fork of the released QE4 source code by Robert Duffy.
- Q3Radiant — id Software's fork of QERadiant used to create maps for Quake III. Windows-only.
- GtkRadiant — A port of Q3Radiant using the Gtk+ GUI toolkit, making it cross-platform (available to Linux and Mac OS X). Development stalled after 1.5 for a number of years, but has resumed with the recent release of version 1.6, which (for now) removes support for a number of games, including Tremulous.
- NetRadiant — A fork of GtkRadiant (?) by Alientrap, developers of the former (FOSS) Nexuiz project. The project page for this fork is currently down, but builds are still available from noted Tremulous mapper Ingar's site. The Xonotic project is currently maintaining NetRadiant; source code is available from their site and is also viewable.
- DarkRadiant — A fork of GtkRadiant with the aim to improve the user interface and primarily intended to support Doom 3.
- MacRadiant — A port of GtkRadiant to Mac OS X.
Map editor comparison matrix
This table provides a comparison of all modern map editing tools available.
|Program||Supported OSes||Last stable release|
|Mac OS X||Windows||Linux|
|NetRadiant (Ingar's builds)||10.5, 10.63||Yes||Yes||2011/03/09|
|DarkRadiant||No||Yes (32 and 64-bit)||Yes1||2012/07/16 (v1.7.2)|
|MacRadiant||Yes2 (Intel & PPC)||No||No||Unknown (v1.4 and v1.5)|
- Binary packages are not yet available (but have been promised by the developer).
- Problems have been reported with Snow Leopard and Leopard, though there are workarounds. See the download page for more information.
- Binaries are for Intel systems only. Requires that X11 be installed. Users of 10.7 can get this from the XQuartz project.
Using other than Radiant to create maps
There are a handful of alternatives to Radiant for creating maps.
Note that these programs are not currently recommended for use.
- Milkshape 3D is an open source modeling program that reportedly has the ability to export in the
- Qoole is an editor for Quake 1 and 2 maps.
- TrenchBroom is an editor for Quake 1 maps. The author has stated that they intend on adding support for Quake 3 in the future. TrenchBroom is notable in that it is not a derivative of Radiant and has an entirely unique UI.
Gmax is a free variant of a very early version of 3ds Max, roughly similar to version 3 or 4. As it was intended to create mod content for games, it has a more restrictive license agreement than a licensed copy of 3ds Max. Those games which are supported by Gmax require the installation of the appropriate game pack; there exists a game pack for Quake 3 that might make it possible to use Gmax to create maps for Unvanquished. Do note that the legality of using Gmax to create content for games other than Quake 3 has been questioned in the past.
While geometry other than triangles may be used during map creation, the map compilation tools can only handle brush geometry; as of now, the
.map exporter for Blender can only convert polygonal geometry (triangles) to brushes, and as such it would be pointless to use anything else during the construction of a map except as a placeholder.
A comprehensive guide of using Blender to create map geometry ready for Radiant and the compilation tools is available from katsbits.
Acquiring the game pack
To use any version of Radiant to create maps for Unvanquished, you will need to download the associated game pack. Note that game packs for NetRadiant and GtkRadiant differ in format, and as such cannot be used for both applications without modification.
GtkRadiant 1.4 & 1.5
Versions 1.4 and 1.5 of GtkRadiant included the game pack for Tremulous, which can currently be used to develop for Unvanquished.
Version 1.6 does not include the game pack. You must either extract the game pack from Tremulous or acquire it from SVN:
$ cd /path/to/GtkRadiant/installs $ svn co http://svn.icculus.org/gtkradiant-gamepacks/TremulousPack/trunk/
Place the game pack in the
GtkRadiant 1.6 can read game packs from the
~/.radiant/1.6.2 directory. Place the contents of the extracted archive there.
This section is oriented towards those with less experience mapping.
There are many potential pitfalls of map creation. Possibly the easiest to fall into is spending too little time on design and spending too much time on map details before even having a working base design. There is an adage that applies well here: "Weeks of effort will save hours of planning." Before you begin creating, do not concern yourself so much with visual elements but the physical layout of the map.
A good strategy is to use placeholder textures (such as those containing only text labels to identify what each finished surface should be, such as "cement wall" or "window") and very basic geometry at first, then playtest with as many people as possible as much as possible to evaluate gameplay, making adjustments to the basic level geometry as necessary; the emphasis during this phase of development is making many small iterations to get feedback as fast as possible. Only when gameplay seems stable would you then begin adding details.
When designing a map, consider the following:
- What can players use to help themselves navigate the map? What would make a good landmark or how can different areas of the map be differentiated visually?
- Is the map partitioned well visibly? Are there any areas that may cause poor performance?
- Are corridors large enough to facilitate combat?
- Does the map provide other good locations to build in aside the defaults?
- Is the map biased towards one side or another?
This section is oriented at those who are new to Radiant who have not used other, similar mapping tools such as those for Enemy Territory: Quake Wars, Call of Duty, Valve's Hammer editor, and UnrealEd.
The process for creating a map in Radiant is significantly different than conventional polygonal modeling; instead of meshes, Radiant uses brushes to define the space in which the player may occupy. The fact that all brushes enclose a volume (unlike a mesh, which does not necessarily have to) and the way in which brushes are used to construct a map is referred to as constructive solid geometry. Essentially, because brushes by definition enclose a volume, they are said to be solid, and may be combined in ways to produce more complex geometry. For example, a cut in one brush may be made by subtracting the volume enclosed by another brush from it.
Those who have used UnrealEd may be familiar with the idea that the entire world begins as a solid volume. The player naturally cannot move in a solid, so before you can create rooms of a level, you must subtract from that initial filled volume to create a void. From there, that void can be filled with brushes that create walls and ceilings and floors (or rocky mountains and terrain if you please; all brushes are created equal and may be used for any purpose). This constitutes a level.
Radiant, however, models the world as a void, so no initial subtraction is necessary. Rather, brushes must be added to create a level sealed from the void; any gap allowing access into the void, however small, is called a leak and will prevent you from successfully compiling your map.
Note that brush coordinates are quantized, which essentially means that they must be aligned to a grid. Also, faces must constitute a plane, so it can be difficult to move the vertices of a face into position as Radiant will only allow new vertex positions that satisfy this requirement, while at the same time restricting positions to those that are on the grid.
Shortcuts for different versions of Radiant are the same unless otherwise noted.
Selecting brush geometry
- Press and hold Shift and click objects to select them (or deselect them if they are already selected).
- With nothing selected, press and hold Shift and click and drag to select multiple objects at once in a rectangle.
Editing brush geometry
- Click and drag to create a new brush.
- With a brush selected, click and drag the mouse cursor to change the size of the selected brushes.
- Press Esc to deslect everything.
- Right-click in a 2d viewport to access the entity placement context menu. See "Entities" for a discussion of what these are for and what is available.
A target relationship can be established between two entities by selecting them, then pressing CtrlK.
Changing viewport layout
To change the layout of the viewports:
- Go to Edit → Preferences… or press P.
- In the preferences dialog, select "Layout" (under "Interface") from the left panel.
- Select your desired view layout.
Note that to see this change in effect requires restarting Radiant.
- Scroll using the mouse wheel to dolly the camera forward or back.
- Right-click on the viewport to look around. Using the mouse wheel to dolly the camera works while in this mode.
- Press A to move the camera up and D to move the camera down. Note that this moves in finer increments when in free look mode.
- Right-click and drag to move the views around.
- Press Ins to zoom out and Del to zoom in.
- Change the view with the toolbar button:
For a listing of all entities, please see the full article.
The term entity with regard to Quake games and derivatives (which Unvanquished counts itself among) refers to any of a class of things:
- Players (including those controlled by AI; i.e., "bots")
- Static models
Note that some entities are not tangible, and although all entities have a position, not all entities appear where they are placed or are even positionally dependent at all. These other entities are:
- Camera positions (for spectators)
- Light flares
- Harmful areas
- Target positions
- Map information
As a mapper, you have control over the starting location of entities. Some entities, of course, move, and you have no control as to where they might go.
At a minimum, you must place the following entities:
info_player_start— The initial position of the spectator camera.
info_alien_intermission— The location of the camera for the Aliens' team while they are waiting to spawn.
info_human_intermission— The location of the camera for the Humans' team while they are waiting to spawn.
Without these entities, although you will be able to compile your map, you will not be able to load it in the game; an error will be displayed.
Note that if you do not also place an Overmind (
team_alien_overmind), any alien buildings you have placed will explode after a short amount of time. The same will occur for human buildings if you do not place a Reactor (
|Format||Static?||Animated?||Best suited for|
|ASCII Scene Export||
PicoTerrain is a format evidently invented by ydnar back in the early 2000s. The only information on the format is in a thread on the Splash Damage forums. It uses two image files and a small text configuration file.
Note that 32qu is approximately 1m.
Player sizes, in quake units (qu):
Players will need an opening at least 1qu wider to fit through (possibly 2qu). In addition, player bounding boxes do not rotate, which means diagonal corridors need to be wider. (Set
1 while in-game to see.)
Doorways should be a minimum of 128×128qu. Corridors should be a minimum of 196qu wide, although it is possible to use a mix of 196qu and 128qu (see Niveus for an example), and at most 512qu wide. Do not create corridors more than 1280qu long without plenty of cover. Currently, large open areas and underwater areas are very human biased.
Alien bases need cover to hide things behind, the entrances should be 128×128qu and should not be easily visible from outside other entrances.
You may be interested in the list of engine features.
- If you would like to support bots on your map, you must generate a navigation mesh.
- Additional shader functions (e.g., normal mapping) have been added; please see the XReal shader manual for more information.
This applies only to the modern (GL3) renderer.
- Add a light entity.
- Add the key "noradiosity" to the light, and set the value to "1".
Testing maps in-game
For testing purposes, it is most convenient to place your compiled
.bsp file in the
main/maps/ subdirectory of the data location appropriate to your system. Once you have done that, you can load your map with either the
map commands after setting
sv_pure to 0. The former allows using special commands made for developpers ("cheats") that make it easier to test. Additional commands are discussed on the testing page.
Testing maps publicly
You might consider announcing the release of your map by creating a new thread on the Map Releases subforum. On that forum is also a helpful guide to offering constructive criticism, which doubles as a checklist of things for map makers to consider about their creation.
Packaging maps for distribution
If you want to distribute your map to the world (either for testing or as a final release), you'll have to create a package. Such packages may be distributed automatically via the server download feature or other means.
- Official homepage (Note: some links are outdated)
- Additional Documentation
- Shader Manual
- Source Code
- Quake 3 Shader Manual — Contains information not present in the XReal shader manual.
- XReal Shader Manual — Contains information on new shaders added with XReal.
- Excerpts from The Hows and Whys of Level Design — includes information on gameplay and lighting.
- Multiplayer Level Design In-Depth:
Tutorial Sites & Communities
- Custom Map Maker's Wiki
- Xonotic mapping resources
- Useful mapping links thread on Tremulous forums
- Netradiant mapping video tutorial series — Aimed at maping for AlienArena, but much of the information is the same.
- Tremulous Mapping Guide by Ingar and Jex. Very complete.