Three more maps in two more wads by Dutch Devil / Morbid Doomer.
Evil Unleashed is the name Doom was going to have before they called it Doom, I think. It's also the name of this map which is for Doom1 and replaces E1M1.
It's one of those maps that's like an entire mission, you know the ones like UAC_DEAD, Outpost 21 etc where you're in a base and you have to clean it out and to exit you need to go off into some other "Hell" section and retrieve an artefact to open the exit? Well it's like that, there's a few pentagram gates and the furthest one has the red key on it.
Architecture and texturing are pretty much spot on; the start is kind of blocky but it's not really a bad thing and the rest of the map is fine. The gameplay is fairly easy although there are are two or three big teleporter traps to contend with. It's more or less a really good map, as you'd expect from Dutch Devil.
The only weird thing about it is the placement of the keys really. It has a weird flow, it seems if you follow the "natural" way to do it you end up running all the way across an empty level, opening the yellow door, pressing a button and running halfway back again through the still-empty map to fetch the blue key. And you can get the red key without knowing what it is for. I don't know if maybe some more of the doors should be locked and the map repopulated via teleporter more often.
Blood Boiler (MAP01) is a techbase. It's kind of a bit disjoint, being a central hub with doors around into different sections, but it's not too bad and you don't notice so much because you're too busy fighting - the battles are nicely staged and quite hard. Although it is a bit top-heavy (the red key section is much easier than the preceeding fights, I found)
Temple of Acheron (MAP02) a green stone castle, like something out of Episode 4 I guess. It's probably the better of the two maps, if only slightly. It's a bit less disjoint but probably just as top-heavy, although for much of the map you need to at least be careful and there is one fight towards the end that can go bad very quickly I've found.
While both maps are more or less completely separate, have completely different themes etc. (and should be played as such) they have their similarities (both have a secret area on a platform in the centre of a damage pool, for instance) Both very good maps, nicely made and textured, and not bad at all to play other than my usual nitpicks.
Finally I must mention the palette replacement. I don't like it. The basic game palette does the usual irritating desaturation of blue and green that we see in so many modern maps already - I could do without it but it's not too aggravating. But then it gets into the redscreen palettes and makes them... blackscreen. So I end up not noticing when I'm taking damage... Never mind what happens when you pick up a berserk box, the screen just goes darker for no reason. Bad idea. Fortunately they're easy to remove from the wad!
I should actually talk about some of these wads I have piling up instead of stupid hacks and the like. Although I want to go on about the incredible regenerating teleporter fog... But first I'll post about the map in which I saw it happen.
Disclaimer: I helped a bit with beta-testing this.
Third in the previous series and exactly what you were expecting if you saw the end of the second one - a lava cavern. It turns out to also have bits of an old fortress embedded in it, charred almost black by the heat.
First a minor digression. Doom is a game. As a player, the goal of this game is to exit a map, with a secondary goal being to get 100% kills and so forth. But it works in reverse, as well. If you are a map designer, your goal is to kill the player. You are playing the same game but from a different point of view.*
Year 23 is a map that's trying very hard to kill you.
Seriously you can't move for traps. You do anything and a door to some infested alcove will fly open, or there'll be a huge flash of light and you're surrounded by teleporter fogs and god only knows what else. Most maps just place monsters and expect them to do the work - this one is just a little (read: a lot) more proactive! I was particularly taken by one part where I was sure this wretched switch was going to teleport something in behind me but then it turned out I was standing on an elevator... The author has said one of his aims was to make a map that's hard even if you play carefully and don't try to crash through it like the hero of an over-the-top 1980s action movie. I think he was successful.
The map's construction is very technically competent, even managing to get away with using conveyor teleporters; usually a bad sign, but most of the common pitfalls have been avoided, and I haven't managed to break them and end up with a monster stuck and unable to teleport yet.
The secrets, which number seven in total, are very well hidden. I only found one to begin with. A couple are even chained (that is the trigger for a secret is inside another one)
The only real issue is one of design; the map is more or less split into five sections, a central dual lava river and four others, each housing a numbered switch. And of course, each section is completely disjoint; more or less cut off from the rest of the map.
Also one complaint I heard and can understand although I don't think it's that bad: since you have to do sections I and II before the main area of the map opens up, it can feel like you're not making any progress after the first section you choose since you have to go do another one that's also balanced to be done from the beginning of the map. I thought it was a bit like a co-op level in a way. You want two players to do each of the first two sections by himself.
Oh and just while I think about it, the fortress/castle parts, textured entirely in a dark grey variant of GSTONE, are a bit monochromatic and, well, drab. I think a few more flecks of red in the walls and some glowy things (like the archvile eyes at one point) would have done some good here.
Oh and and (I keep remembering little nitpicks that no-one else would care about) I'm not sure about teleporting in more ammo every so often. I dunno. Bit cheesy. *flash* here's some monsters *flash* and here's what you use to kill them... I don't know why I suddenly decided to mention that, it's just not very Doom-like I guess.
Anyway overall a very good map, the longest of this series so far (with nearly 600 monsters) and probably, all things considered, the best one. Let's hope the next (I believe a Year 24 is planned) is a little more connected!
* Of course you have to be fair about it, else the player won't come back, and then you've both lost. The goal of a map is to have players die in it; if no players come, the map has inherently lost before it has even begun.
A "speedmap done in three hours" by the author of the excellent Base Ganymede (of which there is now also an episode 2, but I haven't finished it yet.)
I wish I could make maps like this in three hours.
It's basically a cave filled with green slime and various kinds of rocks, although there is a kind of a hell temple off in one part where the plasma gun is hidden. Its layout, architecture, texturing etc. are all fine.
Gameplay gets easier the more you do it, I had the idea from its announcement thread that it was very tight on ammunition so I played far too cautiously to begin with. But it turns out that, while you can't waste ammunition, you don't have to be too stingy.
It has a couple of bugs, especially in the blood temple previously mentioned.
- I started off playing it on a lower skill level in case it was hard, which it isn't really, but it did allow me to notice that the monster teleporters don't go off on lower skills as the teleporter exits don't have the right thing flags
- Also you're meant to get locked in there, by raising up a short wall when the plasma gun is picked up. However there are far more W1 linedefs that raise this wall, than there are W1 linedefs that lower it, so it's quite easy to get stuck in there.
A small map from the author of Techbase 1 (a.k.a Techbase 6.) Made almost entirely with one brown texture, the point of this map is the gameplay, not the looks, and gameplay to challenge the best of players. It was way beyond me, naturally. Still, it does what it sets out to do. Nothing much else to say. Oh it's a low-ammo and cramped conditions kind of difficulty than an unlimited resources and hordes of monsters kind of difficulty.
A rather nice but apparently completely overlooked (at least by me) map01 replacement from a few years ago. Unfortunately I spoiled myself with this one by reading a comment that likened the map to Alien Vendetta map21, and now I can't see anything else. It does really start off like one of Pablo Dictter's overdetailed corridor maps though.
Then you get out into this open area with these huge and quite elaborate metal columns, which look quite stunning. Thanks to whoever it was who posted a screenshot of them that made me download the map, I guess.
Gameplay is quite tight, there's not a great deal of ammunition, and health especially, so even though the monster resistance is relatively light (mostly zombies and imps and the lesser demons) it's quite easy to get yourself into a position you can't recover from. You have to play just defensively enough for it to get just a little bit annoying. Oh well. There are also a couple of monsters that don't wake up and you can't kill them.
Worth playing though.
gifs
Recently I hacked a thing into rboom to take screenshots of every frame of the player view. I don't usually bother posting about rboom stuff because it's not public but this time I have something to show for it. Screenshotting every frame naturally lends itself to making animated gifs.
bugger this (again)
I improved Bugger This a little
- The switches are now (slightly) visible from range, by having a tall, thin column of blood above them. These disappear when pressed.
- Added a more satisfying exit; the map now crushes a boss brain, with all the screaming that entails. Also, the player dies when it explodes.
Funnily enough this led to two compatibility fixes in, of all things, ZDoom. Firstly it was not handling negative thing angles the same way Boom does*, and also, floor crushers didn't hold in place until the thing they are crushing is dead.
Thanks to The Green Herring and gggmork who both managed to record demos beating it on Ultra-Violence. So it's not impossible after all!
The first of these demos led to some interesting messing about, as I will go on to describe.
* although arguably negative thing angles are illegal, indeed you shouldn't use anything not of the form { 45n | n=0..7 }
demo hacking
Suppose you record a demo of a single map where you die and restart a few times. Usually when recording if you die you quit the game and restart the recording. You can't just cut out the good part of the demo after all the deaths and expect it to sync.
What if you can? It turns out it's possible, at least with Boom demos, since the Boom demo format stored the random number seed in the header.
- find the state of the random number generator at the point you want
- find the random number seed that generates this state
- put it in the demo header
- chop out the tics up to the start of the successful run.
It does work! The first part is easy since you can just print it out. Editing a demo is pretty easy as well with a hex editor. The tricky part is finding the right random number generator; I couldn't think of a better way than just brute-forcing it, but there are "only" 2^32 possible values to check and it doesn't take that long to loop over them all.
I can't be bothered to write up the precise technical details. But I'm sure this stuff or something like it could be useful for tool-assisted demo recording, if I can find a way to make it easy to use (yeah right!)
It was Doom's birthday the other day and for once I felt like doing a few things and posting them on Doomworld.
PrBoom patches
I took some screenshots of stuff I've put into PrBoom recently and posted them in the gargantuan screenshots thread.
Ammo empty/full patch posted by another user on the PrBoom mailing lists. Blue numbers mean the weapon is full, brown ones mean it's empty, i.e., can't be fired. That means zero ammo for most weapons, but less than 2 for the super shotgun and less than BFGCELLS for the BFG (in the picture I have BFGCELLS/2 cells)
Backgroundless fullscreen menus so you can still see a demo or whatever running if you open one of Boom's fullscreen menus. An ancient feature request. I've had the patches for almost as long. Now I've made it optional so if you think it makes the game unreadable you can turn backgrounds back on (they default to being on, you have to turn them off yourself)
UTF-8 ENDOOM When you quit the original DOS game it would dump a screenful of data into VGA memory as like a credits screen. PrBoom had this system that translated the screen into ANSI escape sequences to set the colours, but it never worked very well with printing codepage 437 graphics. However on modern linux terminals UTF-8 works well and all of CP437 is a subset of unicode, so I just translated it. I also rewrote the colour handling because it was messy. Other engines will actually pop up a box and draw the thing themselves, but I don't like that because I don't like boxes popping up after I press the quit button!
Bugger This
I modified a sandbox and came up with something I called Bugger This.
It runs on MAP30. The idea is you press 8 tiny switches around the edge of a giant ring of blood 16000 units across. What's stopping you are hundreds of boss brain monster spawners throwing in monsters from the edge of the ring (just in front of where the buttons are, naturally)
The air is rapidly filled with flying spawn cubes and after about a minute or so there will be thousands of monsters charging towards you. It's hilarious. I can't press more than 4 buttons, but that's okay because on lower skill levels that's as many as you need.
It is more or less unplayable but what do you expect, it's a speedmap. Well, sort of. I had the program that made the main part already. I just had to make the extra mechanism that allows you to exit the map, which still took a couple of hours because of Yadex (you know what it's like)
This was for a thread about making a really hard speedmap. The name is inspired by what I imagine people will say when they try to play it, of course.
Personal note (you can ignore this part)
When I was new to the game, having played through it a couple of times, and just getting into its internal workings (around the point of "DEVELOPING AN INTEREST") one thing I tried repeatedly to do was make a giant level full of spawn spots so I could just run around and shoot things until I got bored. I was constantly thwarted, both by crappy wad editors and my own lack of knowledge when trying to write a program to generate the thing; and while I did manage to make a map, it was never even remotely satisfactory. (Of course part of that was due to game engine bugs which have since been fixed.) Anyway time went on and I forgot about it as I found "proper" new levels on the internet, and started working on the game engine itself, and so forth.
Then a few weeks ago when, while messing with friendly monsters, I made a sandbox that was full of spawn spots and monster spawners. As I ran around it I realised I had at last created the perfect spawn spots level. Not only that I could recreate it trivially by tweaking the parameters of the program. Somehow I'd achieved a years-old ambition without even realising it.
Bugger This pretty much is that level I always wanted to create, augmented a bit so you can actually finish it. Not bad eh?
serialisation of floating point data
Yesterday the topic came up of how to store floating point variables in a file or send them over the network so they can be reloaded later, possibly by another machine, possibly with a different architecture, and be exactly the same as when they were stored. This is a general problem, called serialisation.
Consider for example the problem of one human brain, containing a complex image or abstract concept, having to transfer that image or concept into another human brain. This is a serialisation problem, one at which I am very bad... better known as "talking to people".
For integral data types it's easy. You just write the thing as a stream of bytes. The only thing you really have to do is make sure you're reading the bytes in the right order (endianness.) This is a solved problem, go read about network byte order and host byte order for instance.
For floats and doubles it's a bit more complicated though. How do you write out a double and then read it back later, knowing you have the same thing? Here are the outlines of three approaches.
Type punning
Stick the double in a union along with an array of the same size as a double.
union { double d; uint8_t c[sizeof(double)]; } u;
Then you write your double into u.d and loop over the bytes, writing each one out at a time, just like writing out an int32_t or whatever.
Pros Fairly simple. Probably looks like the serialisation code you have already.
Cons Not particularly portable. Assumes floating point data format is the same on both ends. While this is more or less true in modern times it cannot be relied upon. Even if that's a risk you're willing to take you still have to worry about endianness.
Write the double as a string
Convert the double into an array of characters with sprintf. To read it back, use strtod. C99 has a printf format specifier "%a" that seems made for this.
Pros Has the nice bonus that strings are human-readable.
Cons How do you know how much precision to use so you read back exactly the same number as you wrote? The manual page for printf suggests that's what it is for, but of course %a doesn't exist in worlds where C99 support doesn't exist (guess who I mean!)
frexp/ldexp
This is an approach I didn't think of and had to try out myself.
These are two floating point functions (defined in math.h, link with -m). The first decomposes a double into an integer exponent and a normalized fractional mantissa in the interval [½,1). The second puts it back again. Now what?
My naive approach was to multiply the fractional part by INT64_MAX to convert it into an int64_t. Now you have two integers (of sizes 4 and 8 bytes respectively, so you're using up 4 extra bytes per double stored) and these can be serialised using your existing functions for integral data types.
struct fpack {
int32_t exp;
int64_t frac;
};
void serialize(struct fpack *pack, double d)
{
double mantissa = frexp(d, &(pack->exp));
pack->frac = INT64_MAX * mantissa;
}
double unserialize(struct fpack *pack)
{
double mantissa = (double)(pack->frac) / INT64_MAX;
return ldexp(mantissa, pack->exp);
}
I've tested this a bit - get a double, convert it to a struct and back, compare it to the original - and it seems to work for most everything I threw at it (several thousand random strings of digits and a decimal point somewhere) but with the exceptions of infinities, "Not-A-Number" cases etc.
I suspect printf("%a") is doing something like this but a more clever variant. But ultimately it begins by calling frexp.
Conclusion
Strings are probably best, but I like that trick with frexp/ldexp. It just needs more testing and attention to edge cases.
And of course if you want strings but your platform doesn't have printf("%a") you could always pilfer a free implementation that's compatible with your licence.
