Map - Revision history

Nyamoru at 23:42, 29 March 2026

2026-03-29T23:42:46Z

← Older revision		Revision as of 19:42, 29 March 2026
Line 1:		Line 1:
	Game levels in Weissblatt are commonly called '''Maps''' while the act of creating a map is called '''Mapping'''. Like with many multiplayer PC games, this terminology is inherited from [[wikipedia:Doom_(1993_video_game)\|Doom]].		Game levels in Weissblatt are commonly called '''Maps''' while the act of creating a map is called '''Mapping'''. Like with many multiplayer PC games, this terminology is inherited from [[wikipedia:Doom_(1993_video_game)\|Doom]].

			This article describes the technical aspect of Weissblatt's map format. If you're looking to get started building maps, visit [[Guide:Map Design]].

			== Map format Basics ==
	Weissblatt supports two different map formats:		Weissblatt supports two different map formats:
			# ''Legacy maps'' (sometimes called ''binary maps'') - This format is inherited from Sonic Robo Blast 2 and is generally advised against when mapping. Weissblatt will no longer develop it an thus a lot of features will be unavailable when using it.
	# ''Legacy maps'' (sometimes called ''binary maps'') - This format is inherited from Sonic Robo Blast 2 and is generally advised against when mapping.
	# ''[https://doomwiki.org/wiki/UDMF UDMF] maps'', upon which Weissblatt is built. UDMF stands for '''U'''niversal '''D'''oom '''M'''ap '''F'''ormat - a text-based map description format developed by the Doom source port community.		# ''[https://doomwiki.org/wiki/UDMF UDMF] maps'', upon which Weissblatt is built. UDMF stands for '''U'''niversal '''D'''oom '''M'''ap '''F'''ormat - a text-based map description format developed by the Doom source port community.
			To fully understand Weissblatt's map formats, you should understand the concepts of how (modern) Doom engines construct their maps in the abstract:
	~~== Map format Basics ==~~
	To fully understand ~~mapping~~, you should understand the concepts of how (modern) Doom engines construct their maps in the abstract:

	=== Sectors, Walls and Linedefs ===		=== Sectors, Walls and Linedefs ===

Nyamoru at 20:00, 19 March 2026

2026-03-19T20:00:03Z

← Older revision		Revision as of 16:00, 19 March 2026
Line 49:		Line 49:

	MOBJs are only spawned at runtime and represent game objects, such as enemies, gems or decorative sprites. MOBJs contain their own Object flags, which are distinct from Thing flags.		MOBJs are only spawned at runtime and represent game objects, such as enemies, gems or decorative sprites. MOBJs contain their own Object flags, which are distinct from Thing flags.

			=== Fracunits ===
			''A fracunit'' is the smallest possible distance in a map. At default scale it corresponds to one texel [pixel on a texture]. In general, Weissblatt assumes a scale of 64 Fracunits per one meter.

	== UDMF Mapping ==		== UDMF Mapping ==

Nyamoru: Additional details on Tagging and Things

2026-03-05T00:38:24Z

Additional details on Tagging and Things

← Older revision		Revision as of 20:38, 4 March 2026
Line 26:		Line 26:

	==== Tagging ====		==== Tagging ====
			''Further Reading: [[:Category:Linedef Type]]''

	Walls, sectors, and Things within a map can be ''tagged'' using an integer number. Depending on the sector effect and Linedef type, Sectors and Linedefs with matching tags may trigger one another, given trigger-dependent conditions, such as one or all players entering a sector or (not) having collected all [[Chakra Shards]] when doing so. Matching tags can also be used for triggers relating to Things.		Walls, sectors, and Things within a map can be ''tagged'' using an integer number. Depending on the sector effect and Linedef type, Sectors and Linedefs with matching tags may trigger one another, given trigger-dependent conditions, such as one or all players entering a sector or (not) having collected all [[Chakra Shards]] when doing so. Matching tags can also be used for triggers relating to Things.

Line 42:		Line 44:

	=== Things and MOBJs ===		=== Things and MOBJs ===
	''~~Full page~~: [[:Category:MOBJ]]''		''Further reading: [[:Category:Thing]] \| [[:Category:MOBJ]]''

	''Things'' are static spawners for game objects placed within sectors. Upon map load, things are initialized and spawn their respective MOBJs. Things can also be given ''parameters'' and ''flags'', which may modify the Thing's behavior. Since Things are only initialized upon map load, this requires some gameplay design considerations when placing enemies such as [https://doomwiki.org/wiki/Monster_closet monster closets].		''Things'' are static spawners for game objects placed within sectors. Upon map load, things are initialized and spawn their respective MOBJs. Things can also be given ''parameters'' and ''flags'', which may modify the Thing's behavior. Since Things are only initialized upon map load, this requires some gameplay design considerations when placing enemies such as [https://doomwiki.org/wiki/Monster_closet monster closets].

Nyamoru: /* Sectors, Walls and Linedefs */

2026-03-05T00:33:24Z

Sectors, Walls and Linedefs

← Older revision		Revision as of 20:33, 4 March 2026
Line 18:		Line 18:
	''Sectors'' are polygons made up of multiple walls through which the player can move. Sectors can be assigned		''Sectors'' are polygons made up of multiple walls through which the player can move. Sectors can be assigned

	* Top and Bottom [[Flat]]		* Top and Bottom [[Flat]] [ceiling/floor texture]
	* Floor and ceiling height		* Floor and ceiling height
	* Light level		* Light level
	* Colored lighting (depending on the map format)		* Colored lighting (depending on the map format)
	* ~~One or multiple~~ ''~~Tags~~''		* A numeric ''Tag'' (multiple for UDMF maps)
	* Various unique effects, such as damage upon touch		* Various unique effects, such as damage upon touch

Nyamoru: UDMF description

2026-03-05T00:29:50Z

UDMF description

← Older revision		Revision as of 20:29, 4 March 2026
Line 4:		Line 4:

	# ''Legacy maps'' (sometimes called ''binary maps'') - This format is inherited from Sonic Robo Blast 2 and is generally advised against when mapping.		# ''Legacy maps'' (sometimes called ''binary maps'') - This format is inherited from Sonic Robo Blast 2 and is generally advised against when mapping.
	# ''[https://doomwiki.org/wiki/UDMF UDMF] maps'', upon which Weissblatt is built.		# ''[https://doomwiki.org/wiki/UDMF UDMF] maps'', upon which Weissblatt is built. UDMF stands for '''U'''niversal '''D'''oom '''M'''ap '''F'''ormat - a text-based map description format developed by the Doom source port community.

	== Map format Basics ==		== Map format Basics ==

Nyamoru: /* Legacy Mapping */

2025-06-07T14:15:54Z

Legacy Mapping

← Older revision		Revision as of 10:15, 7 June 2025
Line 51:		Line 51:
	''[https://doomwiki.org/wiki/UDMF UDMF]'' stands for ''Universal Doom Map Format''. It is a textual map format developed for near-infinite extensibility within modern Doom engine source ports. It is not backwards compatible to older formats.		''[https://doomwiki.org/wiki/UDMF UDMF]'' stands for ''Universal Doom Map Format''. It is a textual map format developed for near-infinite extensibility within modern Doom engine source ports. It is not backwards compatible to older formats.

	~~The main file of a~~ UDMF map ~~is called <code>TEXTMAP</code> and contains. Within~~ a WAD or [[PK3]], ~~it must be followed by a~~ simple marker lump ~~called~~ <code>~~ENDMAP~~</code>. Despite UDMF being a text format, it is not intended to be read or edited manually. Instead it should be parsed by dedicated programs such as Ultimate Zone Builder, SLADE or Weissblatt's game engine.		A UDMF map consists of the following lumps within a WAD or [[PK3]], :

			* <code>MAPxx</code> - A simple marker lump denoting the map number. Required.
			* <code>TEXTMAP</code> contains information on the map geometry (vertices, linedefs, sectors), SIDEDEFs and Things. Despite UDMF being a text format, it is not intended to be read or edited manually. Instead it should be parsed by dedicated programs such as Ultimate Zone Builder, SLADE or Weissblatt's game engine.
			* <code>ZNODES</code> - BSP information generated by [https://doomwiki.org/wiki/ZDBSP ZDBSP] (as it's the only node builder with UDMF support). If missing, many Doom engines expect it to be generated on-the-fly by a ZDBSP instance built into the engine.

			* <code>ENDMAP</code> - a simple marker lump. Required

			=== TEXTMAP specification ===
			Weissblatt supports UDMF <code>TEXTMAP</code>s of namespace <code>weissblatt</code> and <code>srb2</code>.

	== Legacy Mapping ==		== Legacy Mapping ==

Nyamoru: /* Sectors, Walls and Linedefs */

2025-06-07T11:16:41Z

Sectors, Walls and Linedefs

← Older revision		Revision as of 07:16, 7 June 2025
Line 1:		Line 1:
	Game levels in Weissblatt are commonly called '''Maps''' while the act of creating a map is called '''Mapping'''. Like with many multiplayer games, this terminology is inherited from [[wikipedia:Doom_(1993_video_game)\|Doom]].		Game levels in Weissblatt are commonly called '''Maps''' while the act of creating a map is called '''Mapping'''. Like with many multiplayer PC games, this terminology is inherited from [[wikipedia:Doom_(1993_video_game)\|Doom]].

	Weissblatt supports two different map formats:		Weissblatt supports two different map formats:
Line 16:		Line 16:
	Walls can also have multiple ''flags'', which can have effects on movement and rendering such as <code>Peg Midtexture</code> or <code>Impassable</code>.		Walls can also have multiple ''flags'', which can have effects on movement and rendering such as <code>Peg Midtexture</code> or <code>Impassable</code>.

	''Sectors'' polygons made up of multiple walls through which the player can move. Sectors can be assigned ~~a top~~ and ~~bottom~~ [[Flat]]~~, a light~~ level~~, colored~~ lighting (depending on the map format)~~, various~~ unique effects ~~and a tag.~~		''Sectors'' are polygons made up of multiple walls through which the player can move. Sectors can be assigned

			* Top and Bottom [[Flat]]
			* Floor and ceiling height
			* Light level
			* Colored lighting (depending on the map format)
			* One or multiple ''Tags''
			* Various unique effects, such as damage upon touch

	==== Tagging ====		==== Tagging ====

Nyamoru: /* Reserved specialty tags */

2025-06-07T11:08:58Z

Reserved specialty tags

← Older revision		Revision as of 07:08, 7 June 2025
Line 13:		Line 13:

	''Walls'' are lines between two or more vertices on a map. Each wall can either be solid with a single texture assigned to it or it can be a two-sided ''Linedef'' seperating two sectors. Depending on the two sectors' floor and ceiling heights, each Linedef may be assigned a top, middle or bottom texture per-side. Linedefs can also be equipped a ''Type'' which can trigger various effects at runtime.		''Walls'' are lines between two or more vertices on a map. Each wall can either be solid with a single texture assigned to it or it can be a two-sided ''Linedef'' seperating two sectors. Depending on the two sectors' floor and ceiling heights, each Linedef may be assigned a top, middle or bottom texture per-side. Linedefs can also be equipped a ''Type'' which can trigger various effects at runtime.

			Walls can also have multiple ''flags'', which can have effects on movement and rendering such as <code>Peg Midtexture</code> or <code>Impassable</code>.

	''Sectors'' polygons made up of multiple walls through which the player can move. Sectors can be assigned a top and bottom [[Flat]], a light level, colored lighting (depending on the map format), various unique effects and a tag.		''Sectors'' polygons made up of multiple walls through which the player can move. Sectors can be assigned a top and bottom [[Flat]], a light level, colored lighting (depending on the map format), various unique effects and a tag.
Line 20:		Line 22:

	==== Binary Space partitioning ====		==== Binary Space partitioning ====
	Simply put - Doom maps are heavily preprocessed using a so-called ''node builder'' before being included in the game. A modern node builder with UDMF support is [https://doomwiki.org/wiki/ZDBSP ZDBSP] from the ZDoom source port.		Simply put, Doom maps are heavily preprocessed using a so-called ''node builder'' before being included in the game. A modern node builder with UDMF support is [https://doomwiki.org/wiki/ZDBSP ZDBSP] from the ZDoom source port.

	Node builders implement an algorithm called ''Binary Space Partitioning'' or BSP. Through BSP, all map sectors are subdivided into convex shapes and assembled into a binary tree. The game engine can then per-frame traverse the leaves of any given branch of that tree to determine all potentially visible walls.		Node builders implement an algorithm called ''Binary Space Partitioning'' or BSP. Through BSP, all map sectors are subdivided into convex shapes and assembled into a binary tree. The game engine can then per-frame traverse the leaves of any given branch of that tree to determine all potentially visible walls.
Line 35:		Line 37:
	''Full page: [[:Category:MOBJ]]''		''Full page: [[:Category:MOBJ]]''

	''Things'' are game objects placed within ~~a sector~~. ~~Unlike many modern engines~~, things are ~~usually not spawned~~, ~~but~~ are ~~all~~ initialized upon map load~~. This~~ requires some gameplay design considerations such as [https://doomwiki.org/wiki/Monster_closet monster closets].		''Things'' are static spawners for game objects placed within sectors. Upon map load, things are initialized and spawn their respective MOBJs. Things can also be given ''parameters'' and ''flags'', which may modify the Thing's behavior. Since Things are only initialized upon map load, this requires some gameplay design considerations when placing enemies such as [https://doomwiki.org/wiki/Monster_closet monster closets].

	MOBJs ~~implement Things during~~ runtime and ~~may potentially spawn during gameplay~~.		MOBJs are only spawned at runtime and represent game objects, such as enemies, gems or decorative sprites. MOBJs contain their own Object flags, which are distinct from Thing flags.

	== UDMF Mapping ==		== UDMF Mapping ==
Line 121:		Line 123:
	\|		\|
	\|Affect every sector in a map		\|Affect every sector in a map
			\|-
			\|
			\|<code>LE_PARAMWIDTH</code>
			\|
	\|}		\|}

Nyamoru: /* More Legacy Mapping limitations */

2025-06-07T10:55:32Z

More Legacy Mapping limitations

@@ Line 50: / Line 50: @@
 # Each Sector/Linedef/Thing can only be assigned one tag
 # The total amount of possible walls, Linedefs, Sectors, etc. within a map may be limited.
 # <TBA>
 Binary maps are made up of the following lumps:
@@ Line 63: / Line 64: @@
 # <code>SECTORS</code>
 [[Category:Technology]]

Nyamoru: /* UDMF Mapping */

2025-06-07T10:24:31Z

UDMF Mapping

← Older revision		Revision as of 06:24, 7 June 2025
Line 49:		Line 49:
	Like traditional Doom maps, legacy maps are a ''binary map format'', meaning all data is encoded directly into byte structures. This brings some limitations:		Like traditional Doom maps, legacy maps are a ''binary map format'', meaning all data is encoded directly into byte structures. This brings some limitations:

			# Each Sector/Linedef/Thing can only be assigned one tag
			# The total amount of possible walls, Linedefs, Sectors, etc. within a map may be limited.
	# <TBA>		# <TBA>