BRutal EXtinction International Tournament (vanilla special effects map) — 1.0 released!

This is pretty cool. 

Some low-hanging visual improvements are (obviously) misalignments*, but also perhaps having the nukage top out at the highest step, leaving a lip.

Most of the action unfolds quite fluidly. At the end, however, there is a dead period after the rocket launcher becomes accessible; and that one manc is an anticlimactic closer regardless of which lens one views the gameplay through (combat, staging, pacing, etc.). 

*I wonder how easy in WadC to define a function that can be used to stretch vertical-seam textures to their appropriate line width. With a 91-long linedef and 64-wide seam, the simplest case would be splitting the linedef in two and changing the alignment of the new rightmost linedef to (seam - new length), or (64 - 45) = 19. A triple split (as with BRWINDOW, a texture that tiles conveniently for it) might involve linedef lengths of 30-31-30 and alignments of 0, mid, and high -- where high = (seam - new length), or 34, and mid is perhaps high//2. If this is possible, using WadC for extensive 'alignment play' in large areas would certainly be easier than doing it by hand. 

4 hours ago, rdwpa said:

This is pretty cool. 

Thanks!

4 hours ago, rdwpa said:

 

Some low-hanging visual improvements are (obviously) misalignments*, but also perhaps having the nukage top out at the highest step, leaving a lip.

I'll experiment with that; effectively just removing the last stage of flooding?

4 hours ago, rdwpa said:

 

Most of the action unfolds quite fluidly. At the end, however, there is a dead period after the rocket launcher becomes accessible; and that one manc is an anticlimactic closer regardless of which lens one views the gameplay through (combat, staging, pacing, etc.). 

Yes indeed. I originally wanted a longer endgame but I'm still battling VPO in the main area. At the very least I will reduce the timer so that last door opens more quickly. But that rocket launcher really needs more fodder... I might just have to have that last room be some means of moving to an entirely new area (I did have an elevator in there at one point to put the player much lower) so the VPO budget upstairs doesn't get worse.

4 hours ago, rdwpa said:

*I wonder how easy in WadC to define a function that can be used to stretch vertical-seam textures to their appropriate line width. With a 91-long linedef and 64-wide seam, the simplest case would be splitting the linedef in two and changing the alignment of the new rightmost linedef to (seam - new length), or (64 - 45) = 19. A triple split (as with BRWINDOW, a texture that tiles conveniently for it) might involve linedef lengths of 30-31-30 and alignments of 0, mid, and high -- where high = (seam - new length), or 34, and mid is perhaps high//2. If this is possible, using WadC for extensive 'alignment play' in large areas would certainly be easier than doing it by hand. 

It is possible, but subject to encoding information about textures and good tiling/repeat/split-points into wadc functions.  I have done something similar-ish elsewhere: I have a function that draws a corridor of arbitrary length. And so long as that length is ≥ 128, then it adds some ceiling detailing (a light fixture every 128 units, conduit between them, etc)

one of my never-explored ideas was to try to computationally find good texture split/tile points by running edge detection on them.

"DIE DIE DIE" that is from the new DOOM movie right? ;)

21 hours ago, Jon said:

Thanks!

I'll experiment with that; effectively just removing the last stage of flooding?

Exactly (preferably with the penultimate step changing to nukage anyway, despite staying place). 

21 hours ago, Jon said:

It is possible, but subject to encoding information about textures and good tiling/repeat/split-points into wadc functions.  I have done something similar-ish elsewhere: I have a function that draws a corridor of arbitrary length. And so long as that length is ≥ 128, then it adds some ceiling detailing (a light fixture every 128 units, conduit between them, etc)

 

one of my never-explored ideas was to try to computationally find good texture split/tile points by running edge detection on them.

Neat. Even if tiling length needs to be added as an argument, that is convenient. 

That sure is an acronym

Awesome map!

A way you could throw in more monsters, is teleporting them in using the same conveyor belt you are using right now. Just make very small rooms, with the exact size of the monster, throw a teleporter line right in front of the center of the monster (1 unit or so), add a door with a little bit of space behind it and open it via the conveyor belt. Almost instant teleport on demand! Okay, maybe not exactly instant, but it always happens exactly at the same time so you can fiddle around with the timing beforehand.

(i used the word exact 3 times)

You did not make that acronym. I refuse to believe you made it work. 

21 hours ago, NaZa said:

You did not make that acronym. I refuse to believe you made it work. 

 I hope you enjoy the sequel, Fear And RAGE

Cool map!

On 5/17/2019 at 12:10 PM, Jon said:

one of my never-explored ideas was to try to computationally find good texture split/tile points by running edge detection on them.

I used to maintain a 10,000+ texture database, where I manually set not only texture groups, but also left, right, top, and bottom counts and offsets for textures that tiled.

This provided me the following information:

• For a given texture, I knew which other textures were made of the same material (and would look good in the same room/on the same wall).
• I knew which textures would seamlessly tile against a given texture.

Like for red bricks: I knew that the bricks were 3 across, and 8 up and down, so I join other textures with red bricks in the same pattern (3x8). The goal of all of this was to provide a "skinning" procedure to a map editor. Without having to find appropriate textures, and without worrying about offsets, I could simply switch to Marble. Or Green bricks. Or, even, Rock Formation 3. The program would find all possible texture groups that contained all of the needed elements for this particular room, and it would add these groups to a dropdown box.

It was very cool - you could re-skin a level in seconds, and it looked good, without having to do anything! But, it sucked too - that's back when my port had to load this 250+Mb data-aware texture set every time it started...

I finally ditched that approach. But, I'm wondering if you could benefit from my data setup, for new level generation. Basically, you choose your texture style, and draw the lines, and this algorithm chooses the textures and sets the offsets appropriately. I suppose I could also automate the creation of multi-patch custom textures for switches. What really makes it all work is that dataset, combined with lots of patches that tile well horizontally, vertically, or both. Or course, brick textures have multiple ways to tile, making them especially useful.

I like the edge-detection idea! To think that I could have used that, instead of visually matching 10,000² combinations... What a painful experience that was.

I built a lot of specialized tools like this, over the years, to compensate for not being artistically-inclined :) I'm hoping to share some of this tech one day, if I can make it presentable.

After a long delay, RC2: https://jmtd.net/tmp/brexit-rc2.zip

I had been playing with a totally new area but lacked inspiration for it so, cut back to the original arena.

It's out, at least 1.0 is. A paragraph about it here https://jmtd.net/doom/#index2h2

and uploaded to idgames

and I'll attach it to the first post of this thread

skill1 is broken, I ran out of time to fix that. Enjoy!

Seemed to work in EE. Also it's nice to see these kind of demonstrations, scripting in vanilla is neat.