30/09/2008 @12:32:09 ^13:31:26

HNTR v. ITYTD

I tend to play ridiculous slaughter maps on HNTR. If there are too many monsters around I take too much damage, and die. I'm pretty sure this is something to do with reaction time - I get on better if I speed the guns up a bit*

Anyway recently maps have started appearing that are too hard even on HNTR. I would consider this a bug. Of course the author will say, "drop the skill level down to ITYTD." However, I believe ITYTD is broken. There is no difference between it and HNTR that the map author can affect - the only differences are that (a) you take half damage and (b) your ammunition is doubled.

Now, dropping down from HNTR to ITYTD usually is for the half damage. This makes a surprising amount of difference. Archvile blasts hardly hurt at all. You can even eat a rocket from a cyberdemon, and, instead of it leaving you pretty much dead (if not dead outright) you still have the chance to go "aargh" and run off. Or, to put it another way: every health item you pick up is effectively worth twice what it usually is. Medikits give you 50%. Soulspheres, 200%, and so on.

The problem is with the doubled ammunition. A properly made map will have enough ammunition on any skill level to kill all the monsters. Therefore having double ammunition completely unbalances the map; you have so much ammunition it is effectively almost unlimited, and you can play like a complete idiot and get away with it.

Furthermore, and more irritatingly, every pickup you make is likely to maximise your ammunition, and waste a fair proportion. This is especially the case if you don't have a backpack. If you start the typical level giving you a shotgun and box of shells, they are now worth 40+16 and you can only carry 50. If you accidentally pick up two boxes of shells, that's 30 shells wasted. I find this greatly frustrating.

ITYTD is broken and a map forcing you to play it on that skill is equally broken.

* Not to the extremes of the super weapons patch, which completely unbalances the weapons obviously (the BFG and super shotgun are many times as powerful as anything else) But when I was fairly new to the game I made a patch that sped up the guns a little but still tried to preserve their balance. It worked quite well and back then made UV playable for a keyboard-using newb. Nowadays it works quite well for slaughter maps.

20/09/2008 @10:11:23 ^11:53:57

Entrapment A decent slime-filled techbase map. Rather green. The architecture and lighting is good. It's still a bit disjoint, though. Not too hard, might kill you a couple of times before you beat it, but once you know it you should find it manageable. Worth playing. I just wish the various sections weren't so separate from each other.

Lop3 A single large map. Starts off mostly as a sequence of smallish "rooms" (quotes because they're outdoor areas or caves, but they're still small rooms.) There are lots of traps. Later there are some larger areas, which are an improvement. The texturing is quite messy, in a mid nineties random style, although a common theme is blood, rocks, earth and wood. It's not unplayable, but nothing special and I'm bored of wads made of largely disjoint small areas.

MASTURBATION MAGAZINE 1 Like Kama Sutra, don't let the name put you off, there's only a crude title picture and intermission screen. Unlike Kama Sutra, the maps are fairly mediocre. We have four of them:

It would be worth downloading for map01, if map01 didn't have that bug in it, or for the atmospheric map02, if actually playing map02 wasn't as annoying. As it is though, probably not worth the bother.

08/09/2008 @22:37:16 ^01:33:36

Yeah I haven't felt like writing much recently. In order to fill a silence here's some thoughts on demo compatibility, and PrBoom's complevels. I suppose it could be considered a followup to a previous post.

Demo playback versus total emulation

Compatibility level has two interpretations, which I have dubbed "weak" and "strong":

I believe PrBoom initially defined complevels using the weak interpretation. On the other hand PrBoom-plus greatly favours the strong interpretation.

Recording demos in old formats

The weak interpretation is only concerned with demo playback. A third point on the sliding scale might be:

Achieving 100% recording compatibility with old engines is, I believe, prohibitively difficult. It's not impossible - PrBoom-plus is pretty close - but it comes at a cost. Code becomes full of ugly hacks, is unmaintainable, and is impossible for a casual source reader to follow.

As examples, consider that for doom2.exe you have to worry about array overflows and uninitialised variable problems; or for true boom.exe-compatibility, you have to bring back its friction code, which is so awfully written that Killough ripped it out of MBF despite being fully aware of the consequences.

Two orthogonal compatibility systems

As I said before, allowing recording of old demo formats means you can end up recording broken demos if your emulation is not 100%. These demos might play in PrBoom but fail in the engine that it's supposed to be emulating, or run in an old version but fail in the latest.

If you want to play back such demos you need to tell the engine to emulate a previous version's bad emulation. The current way of doing this in PrBoom-plus is by adding something like "-emulate 2.2.6" on the command line (the actual demos themselves are indistinguishable from real ones recorded in the same format - there's no way to tell a doom2.exe demo wasn't recorded with doom2.exe)

Thus a second, orthogonal, compatibility level system has evolved. You effectively have a matrix of compatibility levels crossed with old version numbers. And with about 17 complevels and a couple of dozen old engine versions, you can imagine the potential number of combinations that have to be handled.

and then there is -doom95 and -exe chex

Non-sync-sensitive compatibility options

Some features in newer engines don't affect demo compatibility.

MBF sky transfers are the obvious (and controversial) example. As a purely cosmetic effect they don't affect demo compatibility at all. So, unless you really, really care about strict compatibility with an old engine executable, you might as well just allow them without any messing about with complevels.

I think it should be left up to the map author - if he is comfortable with using a sky transfer in a Boom map and is aware of the consequences, let him. After all, I would argue those consequences are extremely minor.