Linedef ordering suggests Doom creation history

[Sludge]

I wrote a program that visualizes Doom maps based on the ordering of the linedefs in the level. They go ROYGBIV -- where red is the lowest ordered linedef and violet is the highest. I've attached the screenshots of two popular maps.

The order I see suggests the areas that level designers came back to in order to rework. What do you think?

http://imgur.com/a/7xqZS

[Linguica]

Looks cool! Here's a similar project: http://www.doomworld.com/vb/doom-general/66593-drawing-doom-maps-start-to-finish/

[Memfis]

Do the numbers of action triggers (like 1 is open door iirc, 97 is teleport iirc) also correspond to the order they were made in?

[scifista42]

Sludge said:

The order I see suggests the areas that level designers came back to in order to rework. What do you think?

Map editors can renumber linedefs when other ones get deleted, right? If so, the order might be distorted if a lot of areas in the map were heavily altered during development. I don't know how did DoomEd handle renumbering, although someone who looked at its source code would clear it up.

By the way, the other project's .gif visualization is superior to your color based one, indeed.

[Blastfrog]

It's probably not completely accurate, but does give a rough picture. No surprise that the computer room in E1M1 is defined last; it totally replaced the original room sometime between November and the 1.0 release.

Definitely some inaccuracies, as the secret hall with armor bonuses was added in 1.2 and the opening from the computer room to the courtyard was added after 1.9.

[Sludge]

I'm sure it's not perfectly accurate, but it seems plausible. In the Romero Letsplay video, didn't he say the exit rooms were done last? That is the case in both of these.

If someone wanted to verify this, they could look at the NexT Doom editor source and see whether linedefs are inserted, appended, and so forth at creation time. Also, take a look at how that affects the save and load order.

This was a cool byproduct of something I'm doing for the Doom community that I will announce at a later date, so I don't want to spend too much of my (limited) time on it, or I won't get to the cool announcement later.

[boris]

scifista42 said:

Map editors can renumber linedefs when other ones get deleted, right? If so, the order might be distorted if a lot of areas in the map were heavily altered during development. I don't know how did DoomEd handle renumbering, although someone who looked at its source code would clear it up.

They have to renumber them. Their number is not explicit (i.e. they don't have a "index" property or something), but just implicit by their order in the lumps. So if you have a map with 3 sectors and a sidedef is set to belong to sector 4, you'll go out of bounds.
DoomEd doesn't have that problem, because it doesn't reference anything at all. For example sectors only start to exist when the map is compiled from text to binary format. The Doomwiki has a page that explains it in detail: http://doomwiki.org/wiki/DoomEd

[scifista42]

OK, just replace my word "renumber" with "reorder". Let's say that you are editing a map with 200 linedefs in DoomEd (hypothetically). You make many changes to the map, during which you delete random 50 linedefs, then add 100 new linedefs, then save the map. How will the order change? Will the original linedefs come first and the new ones saved after them, or will the new linedefs "fill" temporarily free places of the deleted linedefs, to achieve minimum changes in the ordered position of existing linedefs?

[Fredrik]

I asked Romero years ago (this was on ICQ) in which order he would build the parts of a level, specifically how he achieved the nice nonlinear layouts, and he said that he just pretty much did it in the order you play the level.

[Linguica]

As per usual, let's look at the source:

- delete: sender
{
	int	i;
	worldline_t	line;
[...]
// delete any lines that have both end points selected
	for (i=0 ; i<numlines ; i++)
	{
		if (lines[i].selected < 1)
			continue;
		if ( points[ lines[i].p1 ].selected != 1 ||  points[ lines[i].p2 ].selected != 1 )
			continue;
		line = lines[i];
		line.selected = -1;	// remove the line
		[self changeLine: i to: &line];
	}

My Objective C is nonexistenta little rusty, but looks like it deletes a line by calling a method or something called "changeLine"? So let's look at that:

- changeLine: (int) num to: (worldline_t *)data
{
	if (data->selected != -1)
	{
	[...]
	}
	else
	{
	// drop point refcounts
		[self dropPointRefCount: lines[num].p1];
		[self dropPointRefCount: lines[num].p2];
	}

	return nil;
}

OK, so lines are stored in an array, and when a line is deleted, it... DOESN'T actually delete the line? It just flags it as "hey this line was deleted". OK. And then when the map is saved to disk:

//
// lines
//	
	count = 0;
	for (i=0 ; i<numlines ; i++)
		if (lines[i].selected != -1)
			count++;

	fprintf (file,"\nlines:%d\n", count);
	for (i=0 ; i<numlines ; i++)
		if (lines[i].selected != -1)
			[self writeLine: &lines[i] to: file];

Alright, so DoomED sets up an array for all the linedefs, but while you are editing a file, it never actually deletes a linedef - it just flags it as "deleted". Then when you save the file it just doesn't save the "deleted" linedefs, so when you reload it later, the new array that gets initialized doesn't have them.

So yeah, it looks like DoomED didn't reuse array slots for new lines after old lines got deleted - everything just got added onto the end of the list. Linedef numbering in a DoomED-edited map ought to be perfectly chronological.

[Blastfrog]

That's interesting. It'd be cool to look through the map source files to restore deleted content.

[Jon]

Sodaholic said:

That's interesting. It'd be cool to look through the map source files to restore deleted content.

The deleted lines weren't written out to the map source files. They remained in memory until that particular DoomEd session was closed.

[Blastfrog]

Jon said:

The deleted lines weren't written out to the map source files. They remained in memory until that particular DoomEd session was closed.

Oh. Damn. I should've read it more carefully.