• Content count

  • Joined

  • Last visited


About kb1

  • Rank
    Ask me about my source port

Recent Profile Visitors

974 profile views
  1. I actually always liked custom monsters that had less health than the originals, filling in any holes in the bestiary in that direction. Otherwise, the stock weapons become, by extension, less powerful, and you need to beef them up. And that makes the original monsters, by exension, less powerful. It's an endless cycle. But, adding less-powerful monsters doesn't suffer from this issue. (And, you get to pick off monsters quicker too!) Win-win.
  2. The levels hold up fine. I can play them, almost exactly as I did 24 years ago. They were great then, so, of course they still are. They didn't change - you changed. Does each new pizza have to be cheesier? Is Led Zeppelin IV not as badass as it ever was? Does your junk have to continue to grow to stay a man? Needing to constantly have more and more to be satisfied looks a lot like addiction. I play pwads too, and I play the iwads, and I enjoy all of them for what they are, without having pick apart the original stuff. They took what they had, and did their very best, and that is what shows to me. It's actually kinda rude to say otherwise, but, yeah, each to his own, I guess.
  3. Apparently, you weren't around, checking out bleeding-edge software in 1993. Cause my jaw dropped when I saw the 2 imps on the ledge in the zig-zag room of E1M1. The levels represent the absolute best possible, within the very limited spec they had to work with. We're talking about 386's running at 40 mHz, in machines with 2Mb RAM (yes, Mb), an even slower ISA bus, ridiculously slow video RAM, and slow hard drives. For the game to use more than 640K memory, yet still be able to read from the HDD required that they use sketchy compilers with DOS extenders that allowed the machine to switch in and out of protected mode at runtime. The map editor was the first of its kind, probably being constantly updated. The engine itself was constantly updated, meaning all the map tools had to follow suit. And, don't forget the time schedule - they had to produce all of this very quickly, starting out with no assets. Everything that went into the project was made from scratch. Geniuses? Of course! And, above all else, the maps are fun. They're not overly detailed, or difficult, but it's still fun to blast through an episode. It's easy to look back and criticize, with our multi-gigahertz, multi-gigabyte monster PCs with dedicated 3d video poly-processing workhorses. But, remember, games like Doom are what drove the creation of that hardware. John Carmack himself played a big role in shaping the functionality of those video cards. Will you call those those legendary PWAD levels "shit", in 10 years, when much better levels get produced? "What have you done for me lately? Oooh Oooh Oooh Oooh Yeah"...
  4. The other question is: How do you know that the monster you're shooting at is an original map-placed, non-resurrected monster? A floating "boss health" bar above monsters could be modified to show if a monster is a respawn or not - might be a cool option. In KBDoom, resurrected monsters can be made translucent, which does essentially the same thing. But I was never very happy with it: The translucent part should be the monster's "soul", and should float up (or down :), which leaves you with the original look, accomplishing nothing. Maybe a "pale" color-remapper drawer could make the skin clammy looking, suggesting a resurrected monster. That would be more engaging than a floating bar, which diminishes immersion.
  5. It would be very easy to manipulate prndindex, or have an array of prndindex[] values, by setting the start index and a wraparound factor (mod), so that each action works the same, every X times. For example, on shotgun blast X, you get the same pattern as you did during shotgun blast X-4. This would give you 4 different blasts (for the sake of pseudo-randomness, or boredom elimination), yet be predictably deterministic. A separate formula could be used for each type of randomness, even without modifying each calculation that uses P_Random(). A table-driven approach could be implemented. But, here's the issue with a non-PRNG Doom: When you add a pseudo-randomness factor to a game like Doom, you get something else "for free": The randomness completes the lack of a proper physics engine. It accounts for the lack of proper collision detection. What if your bullet hits the imp's arm? This should cause minimal damage, vs. him being shot in the chest. What if a gust of wind affects a long-distance shot? The randomness actually simulates some real-world complications in a very simple way. In the 70's/80's video games, if an alien missile hits you dead center, or just grazes the side of your ship, you're dead - game over, no matter how direct the hit. Knowing that it takes 2 pistol shots to kill a shotgun guy might actually create a fun game, no doubt. But, depending on how long you play with that dynamic, you'd become so good that you wouldn't even have to look - you'd just fire twice, and move on, knowing that the enemy is dead. Again, it could create a new level of elitism, a new level of Doom mastery. So, on one hand, I do think non-random damage could actually be fun, as a new, specific way to play Doom. On the other hand, you would lose that extra simulated realism that fills in the missing checks in collision detection, steadiness of the firing hand, the effects of fatigue, sweatiness and greasiness of the hand, unsteady stance while running across uneven floors, heavy cross winds, and a million other factors affecting the ability to aim. Adding some randomness goes far towards including consideration for all those factors, without actually having to test for them during every shot. Also, the randomness forces you to look: "Is it dead yet?" This is a dangerous look at times, so it adds a tenseness and a bit of fear, contributing to the feel of the game. And, I think this is valid for all game modes.
  6. It's a cool idea, but only if the player can figure out what needs to be done, and if the gun and ammo are guaranteed to be available at the right time. Otherwise it's an impassible trap requiring noclip, all the while with the player cussing your mapping skills... Don't get me wrong - I don't want to discourage the idea. It must be done carefully, that's all. Also, it'd be nice if the map had some sort of obvious mechanic/gimmick that explain why you must do this extraordinary action to proceed. A standard-looking switch might not cut it. But a hole in some technology, with some electronics/sparks in it might be suggestive enough, and cool enough, to let the player know what must be done. Does that make sense?
  7. Virginia Beach, Virginia, USA. If you're 30 minutes south of Richmond, you're probably 30 minutes north of me. LAN Coop session!
  8. Sounds like some fun maps are on their way!
  9. Yeah, Doom II feels like a rush job in so many ways. I hate to think that they were just having too much fun playing Doom to do justice to Doom II. I imagine their map tools were probably kinda sketchy, without the years of refinement, and countless thousands of people thinking about it, like we do. Also, it's hard to remember just how slow those old computers were - node/reject building, and just starting the game took a long time. But, knowing what a hit Doom was, it seems like they could have produced something that looks a little better. Abstract design only goes so far for me. Ironically, my favorite Doom II map is a map that was around before the first Doom...
  10. It's one of my favorite IWAD maps. It's cool, because, as soon as you start to move, no matter which way you go, you've got monsters coming after you from everywhere. Very tough pistol start map (for me, anyway). A fun fact: MAP10 was around in the Doom Alpha days, and was skipped entirely for Doom, and revamped for Doom II.
  11. Using longer names can affect readability in columnar lists. Imagine a launcher that shows Filename, Date/Time, Author, Type, Map count, and, maybe a thumbnail of INTERPIC, or the first map, all on one line. A 256-character filename would have to be wrapped to multiple lines to be able to be read. It sounds picky, but it would present a slight issue. Another issue is the internal conversion of long filenames to 8.3 format, when the OS supports it, on FAT file systems (like you might find on a USB thumbdrive). You know, the conversion of "Long Named Doom WAD.wad" -> "LONGNA~1.WAD". Most people think this is a perfect 1:1 conversion that can cause no problems, but that's not the case. The 8.3 names can become duplicated when moving/copying multiple folders, causing files to get overwritten erroneously is some cases. It's somewhat rare, but it's happened to me more than once. (I'm not necessarily against using the long names - I'm just presenting some counter examples).
  12. Something like this is very likely. We know that they had imp and demon images in Doom Alpha 0.2, so it's reasonable that they animated them before the caco. We also know from videos that the real sounds were added very late in development, as they were using Wolfenstein sounds for the longest time. It could also just be an evolution of how they chose to handle sounds. My guess is that they added monsters as they needed them for levels (and as they were drawn: drawing all those frames was probably the most lengthy task of all), and, once added, very little adjustment was done. I think they were having too much fun playing the game, to devote much time to tweaking health, radius, speed, etc. We know they totally botched height, for example. It's probably very lucky that we ended up with something as balanced as it is :) Good questions for Romero!
  13. The CG can be decent for picking off lost souls vs. the rocket launcher, especially in situations where there's lot's of tight decor that might catch your rocket (oops). And, as mentioned before, it's great for long distance, and practically required through bars. I agree that the CG is awfully fun against the former humans, and also cacos and pain elementals, limited in number (to avoid the desire to switch to a more powerful weapon). Finally, the CG can trigger far away switches (as can pistol/shotguns). Some tricky wall trigger scheme could be made to require the count and speed of the CG, as a convoluted way to require it (why you'd want to, I don't know: destroy all the computers to temporarily disable the forcefield long enough to jump through - heh.)
  14. Please correct me if I'm wrong: I think the only time something undesirable/weird happens is when a texture name is defined more than once. In that case, the definition that the engine will use is unpredictable, as it is based on how the texture lookup function (TextureNumForName) is written in the port being used.
  15. Heh heh. Yes, criticize, but do it gently. You know, the Golden Rule: Do onto others as you'd have them do onto you. It's not difficult to be civil, and it's free. Otherwise, it's just beating someone down, because you can get away with it. That's how I see it, anyway. Worst of all, it's demoralizing, and can adversely affect motivation. Which, again, serves no one. I know where you're coming from, but "bug" is too harsh a term. Vanilla Doom was built to render 27 levels: the IWAD levels. Period. Yes, they built the WAD system, as a result of seeing what people accomplished with Wolfenstein, and realizing how difficult those mods must have been. Yes, they did want people to be able to create mods. But, id was on a tight schedule, so they built exactly what was needed to play their 3 episodes. We may see it as a bug, but, to id, using the multi-patch texture on a 2s wall is simply unsupported. They didn't need it, so they didn't build it. They did, however, give us the code, to add whatever functionality we wanted. I mentioned Medusa to suggest that, no matter how optimized the engine is, using invalid resources (or poorly-written scripts) can bring it to its knees. Specifically for Brutal Doom, it may be that what Sgt. Mark is trying to do with his scripts will slow down the engine, no matter how well they are written. Then again, the slowdowns may be due to poorly-written script. Again, I have not studied the scripts. However, on a scale of 1 to 10, I don't think anyone can claim a Crap factor of 10. (or 1). Some cool things are being done in Brutal Doom, and I don't think anyone can really argue that point, no matter how much they despise the mod. And, I believe this should be taken into account when criticizing (or praising) the mod. I am not excusing any of Sgt. Mark's behavior, or his actions. But I believe that anytime you're getting ready to say something that has the potential to hurt someone's feelings, extra care should be taken, and extra thought should be considered. Empathy should be employed, if you're capable of feeling it. Feel free to praise. Feel free to criticize. Just be fair and kind about it. I am proud of Doomworld, for having a community that does criticize and praise kindly and fairly, most of the time. Many forums do not. I support this notion. That's all.