for fun, i thought i’d just convert this so that it is relevant to mapping.

Identify your conflict. Without a conflict, there is no story to tell. Two of your characters (at least) want different things and only one can get what he or she wants.

Make sure there is always somewhere to go.  The player should always have a clear goal in mind, even if it’s just ‘there’s a monster, go shoot it’ or ‘i’ve never been here before, let’s look around’.

Think of a triangle. Your story should take the shape of a lopsided triangle. It starts on the left corner, which is your first paragraph; it progresses in a long, sloping line to the apex of the triangle, which is the climax of the story; it then falls quickly to the right corner, which is the last paragraph of your story. This will give you an idea of how many plot points you need before the climax and how many afterward.

The map should become progressively more difficult as time wears on.  Likewise, weapons and ammo as well as armor should become more powerful as the challenge becomes higher.

Give the main character obstacles and encouragement. It must be difficult but not impossible to obtain the goal. Remember that other characters are terrific sources of both obstacles and encouragement.

Gvery once in a while, give the player a little something extra, both in monsters and items.  a mega-health or shambler in otherwise normal combat areas.

Put the gun on the mantle. A writing aphorism states that if one character will shoot another at the end of a play, the audience needs to see the gun on the mantle at the beginning of the play. Fill in your story with the details needed to make the climax inevitable.

If you’re going to put in keys or other barriers, make sure the player actually sees those barriers first, before unlocking them.  The only exception to this would be if you had multiple routes to the same goal.

Make the reader nervous. Just before the climax of the story, it must seem that all is lost for the main character before some last-minute action turns things around and brings on the climax of the story.

This one’s easy:  try to scare the player.  Place monsters in places the player might not look automatically or force them to fight monsters from more difficult angles.  Alternatively, lull the player into complacency and then shake them up.

Wrap things up. After the climax, make sure there are no loose ends, no unresolved plot points that would leave the reader unsatisfied.

It’s advisable to make the map in such a way that it’s possible to get 100% kills and secrets even after you’ve gotten to the end.

…just so i wrote something on this blog in 2011. :P

I don’t know if there are better options out there, but I enjoy doing this kind of thing so I didn’t really check all that hard.

It’s not terribly difficult to use, just fill in some text boxes and it spits out QC code for monster frame macros.  Things like stand, walk, run…  It doesn’t create anything like the main monster function or setting up .th_xxxx links…  I suppose I might do that if it bothers me enough.

[Download from Quaddicted]

Note that this is a visual basic program, so you’ll need the microsoft VB runtimes.
More detailed instructions are in the readme inside the zip archive.

Additions in 1.0.3:

-Automatically copies .lit file into output folder.
-Automatically copies .pts file into output folder.

[Download from Quaddicted]

Axe

the SG is exactly half as powerful as the SSG.  that actually surprised me at first glance, as i always felt the SSG had an edge on the SG.  obviously, if we’re talking pure burst potential, then yes, the SSG edges out, but over a sustained fight (and assuming close range), the SSG is only twice as powerful.

edit:  the above was incorrect, apparently because i can’t count. 9_9

the SSG deals 28 damage per shell, vs the SG’s 24 damage per shell, giving it more efficiency.  Note that to the Doom2 SSG, which is nearly 3x more as powerful as the Doom2 SG has a more noticeable difference in efficiency.

even with the correction above, however, if you are looking purely at ammo balance, then the Quake shotguns are easier to account for.  quake’s shotguns only differ a small amount in ammo consumption vs damage whereas in Doom, a player favouring the SSG might start to accrue excess ammo over SG players.

obviously, different weapons are different and the Doom SSG pays for it’s ammo efficiency with an even wider spread than Quake’s SSG making it very situational.

for pure damage potential, aside from the LG, the SNG is the highest dps weapon available, topping even the GL and RL.  It’s fast projectile speed and 100% accuracy making it pretty much the go-to weapon for nearly any situation, ammo permitting.

lately, i’ve felt that the SNG could fully replace the NG when picked up.  They accomplish the exact same role and neither has different damage/ammo rates.  The NG deals 9 damage per nail, the SNG deals 9 damage per nail.  Only the SNG does it faster.  There is absolutely no reason to use the NG after picking up the SNG because the only thing that happens is you kill slower, which is never desirable.  the only possible reason i can imagine is you have trouble aiming; missed shots would cost less ammo.

the LG, of course, is absolutely ridiculous at 300 dps.  Shamblers have 600 hp:  it would take a whole 2 seconds to down one.

i do like that iD included a room clearing weapon without making it stupidly overpowered like Doom’s BFG.  i just wish that it had more utility to it rather than just sheer damage output.

if the lightning bolt was able to pass through enemies to deal damage to the ones behind it, it would make the weapon more of a strategic choice.  you could still use it on high hp monsters like shamblers and vores, but if you saw a group of knights or hknights, it would be a viable tactic to try to line them up for a good lightning blast.  even if successive lightning hits reduced damage by 50% or something such that: first target: 30 damage, second target 15 damage, third target 7 damage, fourth target 0 damage it would still be quite useful.

the LG->water discharge is an interesting mechanic, of course, but one that’s never exploited.  i suspect it’s because of the binary nature of the mechanic:  you either don’t discharge into water and live or you do and flat out die (the sole exception is if you have a very small amount of cells, but then it doesn’t matter because the explosive damage is negligeable anyway).  even if the player has the pentagram, you still loose all of your cells which is a sacrifice that is hard to justify:  there’s no guarantee that the discharge explosion will kill all targets as they have to not only be near enough but in LOS of you.

if the LG water discharge instead only consumed 15-30 cells, created an explosion about the power of a rocket centered on you BUT only dealt ~30-50 damage to you, it might be a choice the player is willing to make.  the damage wouldn’t outright kill you, but it’s not something you’d want to try without armor.

also notable is that the GL has an edge in damage, assuming you hit the target 100% of the time.  the only problem with the GL is that it deals damage differently (and in a less reliable way) than the RL.

the RL first applies random damage between 100 to 120 to the target that is hit and then creates explosive damage while ignoring the first target.

the GL simply creates an explosion around the grenade, irregardless of the target it hits (assuming it did).  what this means is that larger monsters like ogres and shamblers (ignoring shambler 50% damage reduction on explosives) may receive less than 100 minimum damage, even if they are direct hits.  this actually created a bug with quoth’s vermis and grenades.  because the vermis’ bounding box is so large, it was possible for grenades to hit it in such a way as to not deal any damage at all.  this probably made vermis combat a lot harder depending on how you aimed.

I’ve updated my ne_q1spCompilingGui with a couple of new features:

Additions in 1.0.2:

-Supports skip tools

First, specify the tool’s filename in the Folder Setup dialog. In the main dialog, you can check the box “SKIP” next to the QBSP checkbox. The skip tool will run right after QBSP.

-Supports pointfile copying and renaming.

Once your map has been compiled and generated a
.pts file, you can choose File->Pointfile (Ctrl+P). This copies the newly generated .pts file back to the source folder so you can load it up in your editor.

Check the radio button in the Folder Setup dialog to choose between .lin or .pts extensions. .lin is for GTKRadiant which does not load .pts files.

[Download from Quaddicted]

Yeah, that was lame.  But this map isn’t.  What we have here is a failu– ok, I don’t know why I’m quoting films.

What we have here is a solid map combining q1met and medieval textures.  This map looks like it would feel right at home in quake’s second episode, only it would outshine all the stock maps due to it’s clean brushwork and overall polish.  From a technical standpoint, this is probably Trinca’s best map.

The theme is consistent throughout.  Trims are used heavily to good effect which is what makes this map look so polished.  I can’t recall seeing a single misaligned texture.  Well, I guess I’m not counting the weird ‘operating table’ texture which was used as a wall decoration when it’s clearly meant to be used on a horizontal surface.  There are tools and a magnifying glass (??) sitting on it which make it look stupid when it is used on a wall.

Lighting is well done if maybe dark in some areas.  I can forgive this as I’m still using a CRT monitor when most have LCDs and LCDs tend to be brighter with less contrast.  For example, I had built the first half of ne_tower with an LCD display and when I brought it onto my CRT, I couldn’t see anything at all.  I ended up feeding a global command line to brighten everything up again and then everyone said it was too bright. o.o;;

Anyway, there are no unsourced lights here.  Everything has an emitter with nice spotlights alleviating the texture tiling.  My one complaint is that the yellow spotlight texture doesn’t use any fullbrights which makes it look dull.  I checked out stock quake, and it turns out that is how the original texture was like, so it’s hard to fault Trinca in this case.  I would have liked if he had replaced the yellow pixels with fullbright yellow though.  Same goes for those blue strip lights.  I guess I only noticed this because I ran in to the same problem with one of Kell’s metal textures where I had to redo it to use fullbrights.

Gameplay is smooth without any insane fights or annoying ambushes.  That’s not to say there aren’t any ambushes or close calls, but that Trinca exercised restraint this time around.  Gameplay is much more balanced than some of his earlier maps and he even provided a quad for the ending which caps the whole map off with a bang.  I suppose if you don’t take full advantage of the quad, the end may be quite difficult. Certainly not impossible but surely not as fun.

The map follows a linear route but allows a bit of freedom as you can pick up weapons in a slightly different order.  On the other hand, if you don’t pick up the weapons in the correct order, you can be under-gunned in successive areas and you’ll have to back-track anyway.  Because of it’s compact nature, I never got lost after picking up the two keys.  I always knew how to get to the correct key door.  Some locked bars open up as well to speed things up.

Texture choice, as noted above is a mixture of medieval blocks, wizard floor tiles and metal.  In some ways, it makes me feel that this is how quake’s ep2 would have been like if the iD mappers had more time on their hands and more advanced mapping tools and compilers.

This map is decidedly unambitious.  It’s sad that that word has negative connotations because in this case it’s the restraint that is this map’s strength.  It’s not trying to be the next big thing, it’s trying to be a solid, well built map that is fun, and it succeeds quite handily at that.

I guess it’s too early for my other blog post to have influenced the outcome here, but this is exactly the sort of thing I was talking about.

Thanks, Trinca. :P

Direct download from Quaddicted
Release Thread on func_msgboard

for reference,

vector    VEC_HULL_MIN = '-16 -16 -24';
vector    VEC_HULL_MAX = '16 16 32';

vector    VEC_HULL2_MIN = '-32 -32 -24';
vector    VEC_HULL2_MAX = '32 32 64';

the first set of vectors is for hull1.  these are your small monsters like knights and zombies.  hull2, the second set of vectors is your ogres and shamblers.

if left to it’s own devices, quake has a funny way of handling collision for bounding boxes (hence forth, bbox) that have dimensions larger than the standard HULL2 size.

if for example, you created a new size:

vector    VEC_HULL3_MIN = '-128 -128 -24';
vector    VEC_HULL3_MAX = '128 128 64';

when quake is deciding where this new large monster will collide with the world, it will first default to hull2 in the bsp (i can only assume that somewhere in the source code, there’s an “if size is small, else just use hull2″ somewhere).  but it will only collide against the first VEC_HULL2 units starting at your VEC_HULL3_MIN.

that is to say, only the coordinates from -128 -128 -24 to -64 -64 64.  this means that in some cases, your VEC_HULL3 sized monster will appear to be colliding correctly with the world, and at other times it will dip half way into the wall.

so how to get around this?

we know that no matter what bbox size, one monster will never walk inside another one.  the shambler on shub niggurath’s island in end.bsp can’t walk through shub herself even though she has a gigantic bbox.

so what are the properties needed to make use of this?  from testing, it seems as long as an entities .solid is SOLID_BBOX, this is enough.

NOTE that it MUST be a SOLID_BBOX, and not a SOLID_BSP, because a SOLID_BSP, while an entity, still uses HULL1/2 collision.

so what does this really mean?  essentially, we have to ‘trace’ the walls of any area we want to have larger bbox monsters moving around in with box entities.

obviously though, that’s not enough.  if we left it that way, the player would bump into those box entities as well as other monsters.

so, we shall have to do some hackery to get around that.

first we should create our collision entities.

void () func_clipModel_on =
{
	if (self.state == 0 ) //off, turn on
	{
		self.state = 1;
		setorigin( self, self.origin - '8000 8000 8000' );
	}
};

void () func_clipModel_off =
{
	if (self.state == 1 ) //on, turn off
	{
		self.state = 0;
		setorigin( self, self.origin + '8000 8000 8000' );
	}
};

void() func_clipModel =
{
	self.movetype = MOVETYPE_FLY;
	setmodel (self, self.model);
	setsize (self, self.mins, self.maxs);
	setorigin (self, self.origin);

	self.solid = SOLID_BBOX;
	self.model = string_null;

	self.state = 0; //always initially off.
	setorigin( self, self.origin + '8000 8000 8000' );

};

you may recognize this is originally how hipnotic created their func_togglewalls.

the main differences here are they work in reverse (are always initially off) and are not SOLID_BSP.  if you care, you could also modify this code so you don’t need to use brush models but just specify a mangle but that’s outside the scope of this post.

note that MOVETYPE_FLY is used.  to be honest, i’m not sure why it’s not MOVETYPE_NONE, and i can’t think of why it can’t be that.  just don’t use MOVETYPE_STEP, TOSS, BOUNCE… or it will fall to the ground.

there’s also two functions that were added, func_clipModel_on and func_clipModel_off.  i used the same method hipnotic did to toggle the walls on and off because i didn’t care to find a better way.  it works and there’s no need to change it.  note that these functions don’t just toggle.

ok, so that fluff is out of the way.  here’s the actual interesting stuff.

what you want to do is co-opt your movetogoal and walkmove functions so that these func_clipModels are only solid while you’re performing the built in function, and non-solid the rest of the time.

but you don’t want these to be solid for EVERY movetogoal call, since the small monsters don’t need it.

i opted for two things.

1.  only large monsters should use the special code

2. each large monster should only use it’s own set of func_clipModels and not other large monster’s set.

i tie a monster to it’s clipModels via ‘clipModel’->’targetname’ fields first.

next, all monsters use a wrapper movement function that passes the actual move function (ai_run, ai_charge, etc).

keep in mind, however, that this technique can easily be used for monster-only clip.

Rawwrrr…

So, Rogue were really nice and left a usable base frame inside the dragon mdl which made re-rigging it a breeze.

it’s a shame that the ‘hands’ on the dragon are not modeled, but just part of the skin, so articulating them is impossible.  still, the wings were belt well such that using them for ‘gestures’ and also walking should be easy.

i was always so disappointed with this monster.  i mean, it’s the end boss for the entire expansion and all it ever did was follow a preset path.  it doesn’t even fire all that often.  in fact, i probably died more often to the random earthquakes throwing me into the lava than this guy.

hopefully some new animations and the large bbox hack will breathe some new life into this guy.  it would be interesting to script it so it could interact with the world geometry a bit.  landing on ledges/roofs (like in the harry potter movie).  something theatrical, befitting of an end boss.

i initially played this map pack a few months ago, back when it first was released but never finished it (i got to the second map and hit a gameplay snag and gave up).

then sock started playing q1sp releases and i was reminded of this when he dropped his comment concerning this map.

so i decided to give this another go.

the first thing about these maps is that they are huge.  in both gross size and gameplay length.  i got a big surprised when i got to, what i thought was, the end of the first map (roman1) and found there was a whole other area with a visually distinctive theme.  a very pleasant surprise indeed.

tronyn has a very unique take on all the texture themes he chose to use.  some texture choices are questionable (q3′s block3b floor tex used as a brick wall) but not so bad that they are show stoppers.

a lot of the areas remind me of the rome levels in jericho.  very bloody but fairly wide-open and very cool.

gameplay is another story, unfortunately.  skill settings are way off (as per usual with tronyn’s maps– sorry man).  the readme is misleading as it just uses the skill descriptions that was in the 1997 quake manual.  easy is about what modern players consider normal.  normal is what modern players considering hard, and hard doesn’t even bear thinking on.  oh, if that’s not enough, nightmare is (apparently) even harder and hell (new skill level) features respawning monsters and other fun things of that nature. -_-;

i honestly can’t see anyone playing on nightmare without either playing super conservatively or exploiting AI shortfalls and geometry.  i suppose hell skill would have to be played like a speedrun since the monsters would endlessly respawn, unlike your ammo.

so, that said, after my first try on normal skill (this is the skill level i always use to play maps), i sucked it up and chose easy.  (incidentally, i got killed twice in the start map, once when i jumped into the blood looking for secrets and another time from the exploding barrels that i thought might have something in them, so you can see the kind of mood the map was setting, lol)

on easy, the maps are quite fun with some hectic fights but all doable with plenty of ammo and lots of weapon choices.  there are enough cells and nails once you get passed the first map, so that you rarely have to use shotguns and if you somehow do run out, you get the grenade launcher and rocket launcher not too long after as well.

there are a number of custom weapon in this mod but things are kept from becoming confusing by actually replacing weaker versions with their stronger counterparts.  for example, the SNG replaces the NG, the laser rifle replaces the laser gun, the chainsaw replaces the axe…

i remember being hesistant when kell was outlining how he wanted the warhammer to work in quoth.  ‘you want it to replace the axe?’ i thought.  it ended up working really well and does so again here.  the important thing here is that the weapon that is replacing the old one should not have any drawbacks the original one didn’t have.  for example, replacing the shotgun with the super shotgun would be inappropriate because the super shotgun has some serious disadvantages and fulfills a different role.

the most useful ones i’ve found were the laser gun (and later the laser rifle).  there are tons of cells, enough even to splurge and use the lightning gun for it’s higher damage rate from time to time.

the changes that allow melee weapons to kill zombies makes them a viable choice now.  i used the chainsaw quite a bit actually, and it’s very satisfying (although very noisy).

there are a couple of poor routes and item placements.  in particular, the silver key is hidden almost like a secret in the first level and is not required until much later.  you can play for a good 10 minutes before needing to open a silver key door while the key itself is available almost from the get-go.  what ends up happening is you are following one route and come to a complete dead-end with no idea where to go and you have to just search around for the silver key until you find it.

the second map has a similar problem.  near the start, you have to press 5 lionhead buttons to progress, but one of those buttons is up in an area i initially thought was a secret (it’s the ledge where the vore is in the building that has the green marble demon face from doom on the ground level).  i found it after much frustration by walking into a dark corner and finding a hidden lift (it was under the ground and not visible, and there are no items there to entice you to go there).

a final hiccup has to do with the final battle.  it’s very challenging but fun.  you fight a spell casting necromancer who can teleport around (indeed, the model is from hexen 2, and the AI is very similar to it as well) and he can resurrect dead monsters.  a very fun fight over all with a lot of movement and action.

the problem arises when you kill the necromancer.  as his parting gift to you, he summons a cyberdemon.  the cyberdemon uses typical AI that it is known for from Doom, but he also retains his insanely high health.  to make matters worse, it also starts a second monster spawner similar to Doom2′s level 30 end boss.  at this point, ammo is low and, although some ammo is spawned in to help, it isn’t really enough.

the weapon of choice, the thing you’ve been saving ammo up for the whole pak– the ice crossbow (fuck if i’m going to try to type out that ridiculous name) has a very poor rapport with the cyberdemon.  specifically, unless the ice arrow kills the target, there is very little feedback on whether you hit your target or not.  essentially, the ice arrow passes right through the cyberdemon (as it’s supposed to– the ice arrow can kill multiple monsters in a line) without letting me know if i’ve hit it or not.  not even any particles or a sprite.

ammo isn’t the only problem.  the ground is very uneven in this area.  there’s a pentacle built out of brushes embedded in the ground.  it’s very easy to get snagged on it.

essentially, the second phase of the boss battle would have been much more fun with a lot more ammo and proper clipping over the terrain (or turning the pentagram into a func_illusionary).

in the end, i cheated with god mode and chainsawed the cyberdemon to death.

something i appreciated a lot was the invisibility in roman2.  i wish i would see the ring more often in a situation where it matters instead of just tossing it out as a consolation prize in a secret.  indeed, i’d like to see some modifications to the ring.  maybe something like:

-picking up the ring causes all monsters actively chasing you to forget you

-attacking will awaken monsters, but only as long as you continue to attack.  not attacking for (arbitrary) 5 seconds causes them to forget you.

an implementation like this where the ring isn’t just an all or nothing could lead to some interesting fights.

anyway, the raft ride in roman2 is cool.  a little nuts, but not insta-death (at least, not on skill0 o.o). and all 3 maps have an excellent sense of place.  most of them are really just one gigantic area with structures built into it.  it must have been absolute hell to vis, but pays off by giving a lot of scenery to look at to produce a parallax effect with world geometry.  it makes everything very impressive.

so, in the end, we have one of those maps that should definitely be played although not quite a classic.

be wary of skill levels and don’t feel ashamed to pick easy mode!

ARWOP – Direct Download from Quaddicted

Release thread on func_msgboard

this type of thing should be done in the engine, of course, by using some kind of local coordinate system that is based on a child’s parent, but whatever.

this is qc, so it’s haxored in as best i could.  this means that it’s not usable in quite a few situations, namely for moving other movers around.

all bsp movers like doors and buttons store both the start and end points of their movements in .pos1 and .pos2 vectors.  this means that you would need to update these as well.  and then you’d have to account for exceptions like if the child is moving when the parent starts to move (or write locking functions to disallow child movement).

i found it best to limit myself to things like torches, triggers and some custom entities that don’t move (like guis and non-moving rotaters).

first, let’s figure out how we want to do this.

i elected to use two strings, .bind and .bindName (similar to target and targetname).  you could use bind -> targetname, but there may be situations where this could cause trouble (i encountered some).  better to create all knew fields and avoid that entirely.

essentially, what you’re going to want to do is set the origin of the children each frame to maintain their offset with the parent.

this can be done easily by writing a small bit of code into startFrame.  you can create a haxor .string field called ‘isParentMoving’ or somesuch, and search for matches with the string “TRUE” (which we will set later).  after that, just set the origin to the parent’s + the offset:

local    entity    childEntity, _parent;
local    vector    offset, childVec;

childEntity = find(world, isParentMoving, "TRUE");
while(childEntity != world)
{
    if (childEntity.bindParent == world) //this will set up bindParent for any that aren't.
         childEntity.bindParent = find(world, bindName, childEntity.bind);        

    _parent = childEntity.bindParent;
    offset = childEntity.bindOffset;

    childVec = _parent.origin + offset;
    childVec = childVec + (_parent.velocity * frametime); //project forward in time for next frame to maintain correct position
    setorigin(childEntity, childVec);    

    childEntity = find(childEntity, isParentMoving, "TRUE");
}

note that there’s an if check for .bindParent.  if it’s not set, we set it to the parent entity and this will save us from doing an extra search next frame to find the parent again.

as you can see, we need an “offset”, a vector between the child and parent.  we can do this easily because the SUB_CalcMove function is the only one used for movement, so everything passes through there that moves.

if (self.bindName)
{
     bindChild = find(world, bind, self.bindName);
     while (bindChild != world)
     {
          bindChild.isParentMoving = "TRUE";
          bindChild.bindOffset = bindChild.origin - self.origin;

          bindChild = find(bindChild, bind, self.bindName);
     }
}

because we used bindName instead of targetname, it’s really easy to check if an entity has children or not.

remember, this will be the parent who is calling this function, so we need to loop through all the children, set the offsets and also set the isParentMoving string so it will be found by the bit of code in startFrame.

i briefly toyed with the idea of creating a queue out of entities so that you could drop children entities into the queue that needed to have their origins updated, but found that i was too lazy to write data structures and just left it up to the find() function.

btw, don’t forget to turn off the entity updates in SUB_CalcMoveDone:

if (self.bindName)
{
     bindChild = find(world, bind, self.bindName);
     while (bindChild != world)
     {
          bindChild.isParentMoving = "FALSE";

          setorigin(bindChild, self.origin + bindChild.bindOffset);
          bindChild.velocity = '0 0 0';

          bindChild = find(bindChild, bind, self.bindName);
     }
}

you may be wondering:  it’d be easier to just set velocity!  let the engine handle the movement.

the problem is that if you have entities bound that are MOVETYPE_NONE, velocity settings will not have any effect.

also, for MOVETYPE_PUSH entities, they will only move if their .nextthink is set to other than 0.  Some MOVETYPE_PUSH entities may be (and probably are) using their nextthinks for something else, so cheap hacking in a nextthink may create problems with those entities.

better to just setorigin() and be done with it.  note, however, child bsp models will not push the player, so he may become stuck if a child moves into the player via the parent.