Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Zylinderkatze

I used to be hip in 98. What happened? [editing]

Recommended Posts

CEOofAEP said:
I'd... probably eventually become an expert at DOOM FLATS from looking at the floor so much ^^;

LOL

So what, would you say, is the main reason to go "Vanilla" (Chocolate)? I mean- besides a die-hard love for the old days, keeping things real, et cetera? As far as I see it, it's the most sure-fire way to make sure it'll later on run on all ports, correct?

It'll run on anything, and even someone who's more casual or totally clueless about add-ons will be able to load it up by reading the readme or help file which comes with the game they bought, without needing to get extra stuff. Another reason is because the lack of extra features keeps the game playing in a classic and consistent manner. Some people want to see new things added to the game and say things like "whoo, we can finally jump in DOOM," while others start an engine or join a server with free look and jumping and say "if I wanted to play Quake I'd be firing up my QuakeWorld client." As you saw above, some of us record and share demos, too. One advantage of "vanilla" levels is that they can be recorded under the original game behavior, making a recording made 8 years ago pretty much comparable to one made today. Source ports make changes to add features, alter the way the engine behaves in subtle ways, and make all the demos recorded with (even their own) earlier versions obsolete. This kills sharing, comparisons and continuity. So, aside from universality, one chooses between versatility and new options or consistency in play. Some people stick to one or the other rather faithfully, others do a bit of both from time to time.

I do find the ability to exceed former engine limitiations somewhat tempting, even if it was a challenge back then (there it is again) to try and stay within them. Does Chocolate Doom lift those limits, too? or does it stay true to the original in this case, too? Visplanes, etc?

Chocolate doesn't. In fact, it was made precisely to retain the old limits in a portable manner. At one point it was getting awkward to play or test in true vanilla mode because the DOS executable doesn't work fine outside of DOS or Windows 9x, as it needs to access sound directly from the sound card, which newer Windows does not approve. Sound "works" but causes system lag. And also because the other option, Doom95, relies on a VXD (virtual extended driver) file for mouse input, and that is not supported by newer windows. Nowadays Chocolate Doom and DOSBox have solved this.

There are (level testing) options for raising the limits while keeping everything else in place. One is PrBoom and its more regularly updated offshoot, PrBoom+, that have the compatibility modes we talked about, optionally making the game behave just like the original except as far as limits are concerned (or else demos would go out of synch.) The PrBoom+ programmer is also a talented reverse engineer, and he hacked the DOS executable to raise the limits. With his Doom+ patch, the visplane limit is raised to 1024 (instead of the usual 128.) That means levels that are up to 8 times as complex, in the (hacked) DOS executable.

In addition, there's an "in between" option people also use. The source port Boom by TeamTNT was the first source port to become particularly popular. It introduced a series of extensions without changing the behavior of the game too much. It was also quickly discontinued after its release, yet remained popular. This has granted it a certain degree of consistency through the years, and many more modern source ports, especially the currently maintained ones, have adopted its feature set (with PrBoom even supporting its demos).

Oh- I've seen "bigger" skies in levels, even "back then" (argh)... I think that is achieved by replacing the SKY1 with a bigger version of "octal multiple" dimensions? like 512x128, etc?

The texture (the entry in TEXTUREx) is given bigger dimensions, either 512x128 or 1024x128. The latter would make one 360° sky. In this case you normally apply 2 or 4 256x128 patches to make that sky. I think wider patches will not work, except in some source ports. The Final DOOM IWADs have multi-patch skies.

Share this post


Link to post

Just a question... I hope someone can help: in PrBoom+, it seems that the settings for "Doom Compatiblity" are (almost) all default set to "No".

For example, "Use exactly Doom's LineDef Trigger model" is set to "No".

Do I change all values to "Yes" manually in the Settings- or would these be affected automatically if I start the game with a parameter... I think, Super Jamie, you mentioned "-complevel" set to "2"?

...would I still have to override values or would they be set appropriately for the "session" with the command line call?

Just want to make sure I'm not missing anything. I'd try out a few more things myself right now (started skimming the "usage.txt"-file that came with PrBoom+) but I need to head to bed- it's 2am. lol.

So feel free to answer but if you think I am getting too carefree and lazy, I'll just read into it myself tomorrow =)

Good night!

Share this post


Link to post
CEOofAEP said:

or would these be affected automatically if I start the game with a parameter... I think, Super Jamie, you mentioned "-complevel" set to "2"?

Correct.

The Boom port made several bugfixes and behaviour changes to the Doom sourcecode, the other ports that incorporate PrBoom probably have a few as well.

However one of the main aims of the Boom port is to retain demo compatibility and behaviours with the original executables, which is achieved via "compatibility levels". Just setting all to "Yes" will not necessarily evoke Vanilla-style behaviour, indeed there are three accepted "versions" of Vanilla Doom:
- Doom Registered v1.9 and Doom 2 v1.9 (complevel 2)
- Ultimate Doom with Lost Soul fixes (complevel 3)
- Final Doom with some codepointer channges (complevel 4)

You'll find other references in the PrBoom documentation, most notably complevel 9 which is compatibility with Boom v2.02 (the last official release by TeamTNT) and considered the standard for playing "boom-compatible" maps.

Changing individual compatibility settings in the menu will result in a different game behaviour, and break demos if you wish them to play back with the original EXEs or at a specific complevel.

Share this post


Link to post
Super Jamie said:

- Doom Registered v1.9 and Doom 2 v1.9 (complevel 2)

Ah yes.

I was almost "happy" too see a "hint of HOM" (sounds like a perfume) in one of my levels... the kind where you see a very narrow bit of vertical "debris" in the distance. Like there's a wall, far away, that's going from the top of the screen to the bottom instead of sticking to it's surrounding floor and ceiling heights...

I think that's one of the things that PrBoom+ would "filter out" if it wasn't behaving like Doom v1.9 - right? I don't think I saw it before, when testing in Eternity (while not telling it to behave compatible in any way)... but I made some changes to that level since then so I don't know for sure.

BTW- what exactly causes that error? I always assumed (and think I read somewhere) that the Doom engine does that when there are too many lines in view behind each other... or such?

I need to get back into the actual names of "stuff and things" in the Doom level editing environment so you people don't flinch every time you read my posts =D I used to be fluent ^^;

(screenshot follows when I get home - just thought I'd "post ahead")

Share this post


Link to post
CEOofAEP said:

Ah yes.

I was almost "happy" too see a "hint of HOM" (sounds like a perfume) in one of my levels... the kind where you see a very narrow bit of vertical "debris" in the distance. Like there's a wall, far away, that's going from the top of the screen to the bottom instead of sticking to it's surrounding floor and ceiling heights...

I think that's one of the things that PrBoom+ would "filter out" if it wasn't behaving like Doom v1.9 - right? I don't think I saw it before, when testing in Eternity (while not telling it to behave compatible in any way)... but I made some changes to that level since then so I don't know for sure.

BTW- what exactly causes that error? I always assumed (and think I read somewhere) that the Doom engine does that when there are too many lines in view behind each other... or such?

I need to get back into the actual names of "stuff and things" in the Doom level editing environment so you people don't flinch every time you read my posts =D I used to be fluent ^^;

(screenshot follows when I get home - just thought I'd "post ahead")


I think what you described there is actually a "slime trail", which is caused by an inaccuracy in the nodes built for your level, where a seg split doesn't precisely match up with the linedef the segs are created from, generally due to the line being at an odd angle and due to Doom's standard nodes format only being able to define segs and whatnot at exact whole-number vertex points, not decimals. (Segs are lines created by your nodebuilder by splitting up sidedefs into smaller pieces.) Some source ports deal with slime trails better than others.

HOM, on the other hand, is caused by either a missing texture (of course) or, in vanilla Doom, more than 256 segs being in your view at once. In vanilla, there's a hard limit of 256 "drawsegs", and if there are still any more segs that are supposed to be drawn onscreen after that, you'll just see HOM where they were supposed to go. To my knowledge, the only modern source port that you'll still experience HOM from the original drawsegs limit is Chocolate Doom, which intentionally emulates the limitations and bugs of the vanilla exe.

Share this post


Link to post

CEOofAEP said:
I think that's one of the things that PrBoom+ would "filter out" if it wasn't behaving like Doom v1.9 - right? I don't think I saw it before, when testing in Eternity (while not telling it to behave compatible in any way)... but I made some changes to that level since then so I don't know for sure.

In PrBoom+ the compatibility mode has little effect on visuals, so they probably appeared after the changes you made.

Share this post


Link to post

Guys... you guys =]

I keep repeating myself but seriously... thank you for sharing your collective, accumulated knowledge and experience with me =)

My E1M1 is polished and carefully "up-detailed" now, still dealing with a bonus room, though- but that should be done soon... then I'm off to E1M2. Almost done! lol. Well not really- but working on it.

btw here's the screenshot I mentioned:



I already undid the changes (but didn't check again since then). If it still happens, I'll also push some vertexes around and see what happens =)

Share this post


Link to post

Some slime trails are produced by poor node builders. Perhaps you're already using it, but one good choice is ZenNode v1.2.1.

Share this post


Link to post
myk said:

Some slime trails are produced by poor node builders. Perhaps you're already using it, but one good choice is ZenNode v1.2.1.

Thanks- yea I'm using exactly that. It's "built in" (included with) Doom Builder 2.

It's version 1.2.1 but I had it set to "fast" setting for level testing (the default of Doom Builder 2, it seems) which does not build the reject...map(?). I switched it to "Normal" now.

The error is gone now but I don't know if it's because I undid the changes or the changed BSP-settings. but at least it's working now =)

Share this post


Link to post

The reject is a structure used to optimize monsters' line-of-sight calculations by using a pre-built table that essentially says "sector A can be seen from sectors B and C, but can't be seen from sector D". It's generally considered somewhere unnecessary nowadays on modern computers, though I suppose it could still be somewhat helpful on gigantic maps. It shouldn't have any effect on slime trails or other rendering issues, though.

Share this post


Link to post

The "ZenNode - Fast (no reject)" profile is more optimized for performance than accuracy and this is not limited to just the reject map. I just put (no reject) in the profile title so that you know you won't have a reject map (some sourceports can't handle this).

The optimizations for "ZenNode - Fast (no reject)" are:

-n3 -nq -rz
I don't know from the top of my head what these do, I looked into this when I made the profiles, but forgot. Google it yourself :P

Share this post


Link to post

CodeImp said:
The "ZenNode - Fast (no reject)" profile is more optimized for performance than accuracy and this is not limited to just the reject map. I just put (no reject) in the profile title so that you know you won't have a reject map (some sourceports can't handle this).

The node builder settings should best automatically depend on the configuration choice. Can't that be done? The commands could appear somewhere in each port or game configuration file, applying by default the settings convenient for the base engine. A few people might get an idea that their Doom, Boom or whatever maps don't work properly from what it says in the node builder settings dialogue, but others won't understand. Different engine types need different settings. All that is pretty obscure and should be handled in a safe manner. Besides, when a mapper switches from one configuration to another because he'll be making maps that suit a different port, he shouldn't normally have to manually alter the node builder settings.

By the way, -rz creates a REJECT, but fills it with zeros instead of optimizing values. That works with any engine. I'm guessing an empty REJECT is made by using -r-, as it does nothing to the REJECT lump, making an empty one if there was nothing there in the first place. Using that 0-byte REJECT was introduced by ZDoom, if I am not mistaken, and then some other "advanced" ports followed suit. In all others it will cause issues, especially to recorded demos.

Share this post


Link to post
CodeImp said:

-n3 -nq -rz

# -n3 - Uses a simple SEGS based metric to reduce the number of SEGS split and balance the left and right group of SEGS, but only examines the first 30 SEGS at each step.
# -nq - Stop the progress indications from being displayed as ZenNode works. If you're really concerned about speed, use this option.
# -rz - Insert a 0-filled REJECT. Useful while you're developing your map and don't want to wait for a full REJECT to be built.

Oh a modern PC building nodes never really takes that long, not even on huge maps which have like ~55k linedefs.

I use

-bc -n2
# -bc - Compress the BLOCKMAP.
# -n2 - Uses a simple SEGS based metric in combination with a similar metric based on SECTORS to reduce the number of SEGS and SECTORS split and balance the left and right group of SEGS/SECTORS.

ZenNode homepage here: http://www.mrousseau.org/programs/ZenNode/README.html

Share this post


Link to post

I'll try those settings but the error is actually gone now that I "undid" those changes (they looked odd anyways ^^)

Which brings me to my current problem...

My morbid love for detail.

Back in the day, I often used semi-simple architecture and somewhat alignment-tolerant, "forgiving" textures in order to achive a nice, consistent overall appearance without any ugly misalignments to distract the player...

But now... with instant preview of the changes I'm making (especially to textures and their alignment), I'm getting carried away. I am now making all the things I always wanted to but was too reluctant to do because of the immense work that would be involved.

If you looked at my E2M1 you might notice that I stil *did* put in a healthy(?) amount of diversity, nevertheless (for my own taste)... even though it meant hours (and hours and hours...) of aligning and going back and forth between DEU, BSP and DOOM.

But now I am actually going slightly overboard. I mean- not GOTHIC-overboard or "prove of concept"-overboard... but I did catch myself adding things like notches and beams in places, just because I feel like "there could be more detail there", without them being necessary (or *looking* necessary).

I'll publish my E1M1 in a "before-and-after", when it's "done enough" if you're interested =)

Maybe you can tell me what I could do better. Some of it still feels a bit "fake", if you know what I mean. Like the creator of the WAD tried too hard...

Wait- that's me! v_v

Share this post


Link to post

A high level of structural detail is nothing to be ashamed of if you enjoy designing it, it's handled in such a way that it doesn't negatively impact the gameplay, and it contributes to rather than clutters the map's appearance. Of course, those things are not always necessarily true, and it's definitely possible to screw them up if you're not careful or miss some important points. If you're unsure, posting map betas for gameplay testing and screenshots for structural advice can always be beneficial. :)

Share this post


Link to post

CEOofAEP said:
Maybe you can tell me what I could do better. Some of it still feels a bit "fake", if you know what I mean. Like the creator of the WAD tried too hard...

Well, just experiment. You've been flooded with new possibilities so you might want to try them. Personally, I like relatively lower detail because it's easier to rework if you change your mind about big things like the layout, lets you more or less complete different designs in less time because of the focus on a larger scale, works well combined with lots of action and high game speed, and looks fine even on the lower resolutions of the original executable, but that's a choice I've made with time and I have passed through different stages...

Share this post


Link to post
myk said:

Well, just experiment. You've been flooded with new possibilities so you might want to try them. Personally, I like relatively lower detail because it's easier to rework if you change your mind about big things like the layout, lets you more or less complete different designs in less time because of the focus on a larger scale, works well combined with lots of action and high game speed, and looks fine even on the lower resolutions of the original executable, but that's a choice I've made with time and I have passed through different stages...

This is definitely true, and as a result I've made some of my smaller maps (such as my Claustrophobia 1024 contribution, "Nova Scotia Robots") by building a completely butt-ugly layout first, using a misaligned placeholder texture everywhere with no thought given to detail, texturing, or lighting until I'm completely satisfied with the layout flow and gameplay of the map.

With larger maps I have a harder time getting myself to do this, and usually end up detailing as I go. When I have a map in progress, I usually have only a very vague idea of what the remaining parts left to be built are going to be like, and as new ideas gradually come to me over the course of the map's development I improvise as best as I can around what's already built. It does sometimes result in wasted work, but I find it exceedingly difficult to work continuously on a large map without focusing on the visual and architectural design of it. >_<

If at all possible, do as I say, not as I do, and perfect your layouts first ;)

Share this post


Link to post

Indeed! Don't let detailing get in the way =)

For me, it's often that I have an idea (or several) that I want to go with... usually I scribble it out on paper the way I want it to look in... "3D", long before I actually end up using it. This can be anything from a concept of how to make a nifty-looking pillar- to a whole building complex.

Then at some point when I make a level that would benefit from some such idea, I work it into the map =)

But in this case, detailing doesn't so much get in the way of laying out the map, really- since the *layout* of my maps is generally done (the whole episode was pretty much complete in 1996).

There's 2 exceptions- I am dissatisfied with the way my E1M2 turned out (it's mostly just a long canyon without too much of a "whoa!" in it. Or even a "hm.", for that matter). And my E1M6 (an underground base dedicated to the idea of its layout changing alot as you run through it)... is crap. lol.

Those are the ones I want to redo, in the case of E1M6 probably from scratch.

But yea- the others are done, concetually- and are going through "brush-up" at the moment. Which takes longer than I thought, even with "cutting edge tools". Hehe.

Maybe I'm just slow ^^;

Here's a before and after of a part of E1M1:


(the "before", also "before texture alignment" ^^)


(the current "after")

Like I said: before Doom Builder, I was a bit too cautius about what textures I'd use, since I'd have to align them all perfectly in order to allow myself to ever publish them ^^ ...but now, the level of diversity I use might be a bit "much" (in this case, brown, grey AND cement in the same view)...

...what do you guys think?

Share this post


Link to post

I don't think there's necessarily a problem with using a wide diversity of textures, but colors are something that it generally helps to maintain a theme with (if not for the entire map, then at least for individual areas). By this I don't mean just "highlight" colors like if you have blue and orange lights and computers, but also "base" colors which in Doom are typically different sorts of tans, browns, greens, and grays.

There's no hard-and-fast rules for it, really, but...for example, if I have tan tiles on the floor, I'll try to match them with a similarly-colored trim along the ceiling, or a strip of a matching color along the walls, or some other sort of tan highlights cut into the upper walls to provide some visual balance and "reprise" the floor. (I hesitated to reuse the word "highlight" here in a different context than I did a few sentences ago; hopefully my meaning was still clear.)

The overall lines and shape of a map (I mean the "lines" of the structures you see when you're looking at it and implied lines between them, not the actual linedefs in an editor) also go a long way towards making it look either cluttered or sleek. While a high level of detail in a map can exacerbate problems with a messy style of design, it's possible to go for a high level of structural detail while still looking sleek and clean.

Some of this is stuff I'm having trouble really explaining well, but the autoalign abuse (part 1, part 2) on the CEMENT textures leads to somewhat of a lack of coherency and structural believability, due to the discrepancy between the shapes of walls you've used CEMENT on and the vertical/horizontal outlines of the panels and bars in the texture itself.

In general the structures in that screenshot feel a bit random and unconvincing to me. I think in this case you would be right in saying you may have used too many textures, though the way they're used also contributes to it. In my own mapping I've come to barely use support textures to separate different materials at all, instead layering them around each other as solid-looking 3D materials. A random map screenshot that might help show what I'm talking about, or not.

For example, rather than having a somewhat random strip of GRAYBIG and STONE on one wall, you could potentially have a STONE trim along the bottoms or tops of the walls, and/or expand out the strip of STONE you currently have into a medium/large-ish \_/ shape coming out from the wall to look like some sort of support pillar built into it. Place a couple more of the same thing at appropriate locations on the other walls of the structure and it's not random anymore; it visually makes sense now!

You could then *combine* that with some sort of trim for added structural detail, perhaps even a 96-tall floor trim that only comes out around the pillars instead of following the entire shape of the structure there, continuing the brown96 from the main walls. This is possibly a bit much for a floor trim's height; I picked 96 units tall so that the top of the trim would match up with the outlines on the brown96 texture. Changing some ceiling heights and y-alignments around so that this same match-up can be done without requiring quite such a tall trim (64 or 32 units might be better) would probably work out better, and would serve the purpose of visually continuing the brown96 concrete underneath the gray stone supports.

Alternately (or, even, in addition to the brown96 trim around the pillars) some sort of BROWN1 or BROWNPIP (basically the same material anyway, just in different shapes and sizes) trim along the lower walls could help balance the BROWNPIP along part of the ceiling.

It'd also be helpful if the couple of small metal supports along part of the ceiling could be extended out to actually connect across two structures, possibly adding some more of them at appropriate locations in the same room (and, from there, possibly in other rooms where appropriate) to make them a recurring theme rather than an isolated instance. :)

In general, detail like trims and supports work best when they appear logically connected to something and are built and textured to complement each other and the rest of the scene visually, rather than just being there for the sake of being there.

There's also no light sources that I see; in addition to making things a bit more realistic in regard to how you're able to see anything in there, some well-placed lights can be a great highlight to increase visual contrast in a scene that's looking drab or dull. These could be placed on the stone supports if you put those in, or along the walls in between them, or on the ceiling of a large trim/overhang, or the ceiling of the main room....or the outer walls of the room....or wherever they look appropriate, really. I usually use 255 brightness for lights unless I intentionally want a couple of them to be dull or flickery; anything too much lower and their purpose of adding visual contrast to the scene is lost.

A lot of this is stuff that I'm still slowly trying to figure out how to translate from behavior into words to be able to explain it, so I'm sorry if I've been a bit vague with some of it.

Note that I'm honestly not trying to be a know-it-all here or act like I know better than everyone, even though I realize I often might sound like it. I'm just trying to dispense some advice based on what I've found in my own personal experience mapping. Feel free to take it or leave it, or find other strategies that work better for you :)

Share this post


Link to post

Don't tile vertically the CEM* and BROWN* textures, they're really not designed for that. If you want to use them on a tall wall, pull an Icon Of Sin Trick* to have them not tile, with different textures above and/or below. (* The IOST is of course named after the solution designed by Id Software to display a huge 3x3 texture mosaic on what's conceptually a single wall.)

Share this post


Link to post

Thank you thank you :3

*bows to esselfortium*

I get what you're saying- thank you for putting my "vague impression of my own shortcomings" into a somewhat concise, written form ^_^

This means Gez, too =)

The level is meant to look / feel like you're raiding an offshore oil rig to open a gate and advance towards the coast... it's split into 2 areas, one is "below the rig" (as seen in the screenshot taken in Doom Builder 2) and one is on top of it... of course all with 1996 technology, so there's no real feeling of continuity but instead you use a teleport to get to the top.

I mainly just wanted to show what I meant by the whole earlier rant about "still having to get a hang of how to add detail in a believable fashion"... I know it still needs work- so I definitely appreciate the pointers.

I'll most likely get rid of the cement again- it's... visually disturbing, the way I'm using it. I agree. I'll find a way to use accents and highlights appropriately to create eye-candy... instead of doing a "there's still room left!"-random-detail-flooding =D

EDIT>>>
The pillar / support that's right above the center crosshair in the second screenshot is kind of a last-minute addition... the BROWNPIP "block" above it "felt" unsupported, kind of- like it wouldn't physically feel comfortable where it is, unless supported- so I experimented with the idea of a support for it.

That one support now looks lonely. It also kind of blends in (too much) with the BROWN96 it "grows out of". My whole color concept (or lack thereof) definitely needs more thought. I mean- it's not totally crappy (at least I hope it's not) but it could look much better. I might just revert it all to a much heavier use of greys, with an occasional ickwall highlight and more supports, in a contrasting color. I already have a few ideas. I am also currently looking into photos of actual oil rigs... I did that in 1996- but not anymore, since then.

The building in the "on top of the rig" part are grey (the biggest one), one is BROWNGRN, "bonus" structure there is SHAWN... it doesn't blend in with the rest (obviously)- but I didn't want it to =) ...the platform itself it brown (FLOOR7_x) but the storage tanks
use the CEMENT variety of textures. I might revise that, too.

*sigh*

The more I think about what the level *could* look like, the more I am considering to vastly remodel the top area, too... actual oil rigs have much more height-variation in them and mine just looks like someone put a few buildings on top of a platform.

Which is, basically, what I did ^^;
<<<EDIT

Also: There shall be light! (there already are some lightsources but *this* angle of view on the level is obviously somewhat dark, agreed)

I still need to get a balanced feeling for what my maps *should* and *could* look like (now that it's easier to enhance my maps)... and refrain from just thinking about what might be possible to be added (now that it's easier to mess my maps up).

Mainly, this screenshot is just the "most visually cluttered" example I have of my current (re-)styling foray... and I thought I should throw it at you now before I travel too far into the wrong direction and it's too late to turn back ^_^

Then again, of course, these levels are mine- they shouldn't look like they're by esselfortium... but common sense and style are something I'll gladly learn from him- and everyone else willing and able to teach =)

So thank you all for your input, yet again... I'll put it to action toda~ ...tomorrow =D
EDIT: "Now tomorrow is today!" ^^

*end babbling*

Share this post


Link to post

Hi.

I'm Tolwyn.
You might remember me from President Carter's administration.


You might not know me from Adam.

But... rumour has it... I've been around. And around... then I was around again.


Doombuilder 1 and Doombuilder 2 are great editors. Get both. It's okay. Use both. They both have strengths and weaknesses.

Get XWE and SlumpED. Believe me, they both have strengths AND weaknesses.

Use:

Prboom+
GZDoom
Zdoom
Chocolate Doom
Doomsday (Jdoom)
SkullTag

And maybe a few others to work on/with. You will find one or two that you PERSONALLY like, and all that you should test with, and some that you will design specifically for.

You're going to pick this up fast. It's easy. Even the slopes in GZdoom (I've seen levels that are just frickin' amazing) are easy to understand. You are in my generation. We've used Waded, DETH, etc. Hi. How are ya doin?


Do a couple practice wads. Don't be like me. I release work about every 3 years, but just have fun. It's still a freakin' blast.

Share this post


Link to post

Tolwyn! Thank you.

Yes, you are right. I don't know you. hehe. No but seriously- thank you for your input- I am looking forward to "eradicating that flaw" (of not knowing you ^^)

I am actually quite interested in SkullTag and would quite likely be digging into it right now if I didn't still have my 1996 maps to retouch and bring up to par. I even had some ideas of how a sort of "capture the flag"-ish gameplay would've been possible through level design, back in 1996 (based on keys and lifts, moving platforms and such) but never got around to actually test that idea. It looked good on paper, though. lol.

The ideas I said I had for my Oil Rig (E1M1) level are working out nicely so far, if I may say so myself- but there's still alot of work to do, since I am going to go with what I suspected I'd eventually do: Remodel the entire "upper level" of the map, as well. *sigh*

I don't know how long that will take, though- I am beginning to realize why I never published my maps in 1996... I never seem to be fully satisfied with what I do. lol.

Wish me luck.

Share this post


Link to post

Hrm. I find that it's harder to retouch and remodel the existing levels that it'd probably be to make new ones. But I'm not giving up... yet =)

Any tips on what *you* usually do to overcome this... sort of... "author's block"?

I'm determined to get them done in the order in which they appear in the episode- but that keeps me kind of stuck at my E1M1, still. Maybe I should just skip ahead or write something new instead, so my creativity doesn't keep hitting that wall of not knowing where to go with the level =D

I'm still not entirely sure if I should remodel the "upper area" of that oil rig (E1M1) ...it'd look cooler and I already have a few ideas- but it wouldn't be the "real thing" anymore- not the original architecture that I came up with in 1996. hm.

Either way, I am likely going to publish the "before" and "after", once I am done... and not only the "after" =)

Just letting you know I'm not dead yet ^^

Share this post


Link to post
CEOofAEP said:

Any tips on what *you* usually do to overcome this... sort of... "author's block"?

When working with an idea that's turned into a flawed layout, I'll usually have a few goes at fixing it then just delete it altogether, or at least crop it out of the map and put it into scraps for later. No use "polishing a turd" so to speak.

When unable to think of new areas, I'll go look at screenshots from other games or play other Doom maps. When I find an area I like, I make a basic re-creation and as I integrate it into the flow it somehow magically changes itself into a new unique area.

Share this post


Link to post

Bump! *hides*

Super Jamie said:

When working with an idea that's turned into a flawed layout, I'll usually have a few goes at fixing it then just delete it altogether (...)

Thanks for your insight... I was close to doing that (binning) but then finally came up with some ideas on how to improve the design and layout to make it look more realistic =) It's close to binning most of the level, though. lol.

I even gathered some reference images on how "actual" offshore Rigs look like but was reluctant / found myself unable to come up with a way to put those images to action... but it feels like the wall I was running into... uhm... is finally not impassible anymore xDD

So this weekend will be a architecture-a-thon. I hope I can fulfil my own expectations ^_^

Share this post


Link to post

I just wanted to thank all of you (again) for your (ongoing) support and your hints and pointers about what engine to use for the results I want to achieve ^_^

I feel like I am well enough prepared for what lies ahead of me now. *bows*

When I wrote this comment, I had started to write yet again on what progress I made over the weekend (etc) but I presume you guys aren't really all that interested =D

For those of you who *are* interested, I recommend a specialist on mental misfunctions. Ehrm. I mean... I started a WIP-Account and will eventually get around to posting there.


Only one more thing (for now):

How do you usually pin down (level) ideas?

I got to the point / state of mind that I was at, 15 years ago... where I'd almost constantly be scribbling little ideas and mock-up structures / rooms / consoles / etc. in pseudo-3D on pieces of paper ^^;

When I am at the PC at the time, I nowadays *sometimes* write a small level that incorporates the idea... but even these days I still find it easier to draw / scribble it at first (the way I want it to look) and then get around to using it eventually / working out how to make it possible in (vanilla) DOOM ^^;

How do you guys do it?

How often do you just write levels "as you go", room by room? If you ever do that at all?

I find that the levels that one writes just for the sake of writing them (without a specific idea in mind) often turn out a bit bland / boring. I mean- even if you manage to make them *look* good, they don't *feel* good. You know?

I've seen this discussion before somewhere on here- about what best editing techniques to deploy- that it's recommended to lay out the general structure of the level first and then add detail later...

...but that doesn't really apply to me right now, since I am almost entirely just retouching the levels I already have.

I'm just curious if you guys have some sort of "common approach" of sorts- if you don't mind sharing =)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×