News | Forum | People | FAQ | Links | Search | Register | Log in
New Q1SP: Ne_ruins
Here's my QExpo map!

Stuck atop frozen mountain peaks known as the Fingers of the Gods, your only way out lies in using the Altar of Storms to open a gateway and escape. You will need an ancient Rune to activate the Altar, conveniently held deep below ground in a buried city...

One lonely screenshot

This is a two map mod for Quake. (This is NOT a quoth map. DO NOT use quoth).

Engine Requirements

This mod requires a FitzQuake variant as some parts are completely unplayable without fog interpolation. If you just hate FitzQuake variants, then you will need to turn off fog from the console whenever you can't see.

Installation

unzip the pak0.pak file into a directory of your choosing, eg: /quake/ne_ruins

Running

run quake with: -zone 2048 -heapsize 192000 -game ne_ruins

Make sure 'max_edicts' (in the console) is set to AT LEAST 4096. 8192 to be safe. Failure to set this may result in the map crashing the engine. The pak0.pak contains a config file 'ne_setup.cfg' which should take care of this on it's own.

When using a fitzquake variant, make sure sv_protocol is set to 666 (or whatever your variant requires, 999 for RMQ I believe), otherwise you'll probably get invisible items or other oddities when recording demos (wink). I could not include a default protocol setting in config files because each engine has it's own protocol number.

Playing

Once the engine starts, select your skill level in the console by typing 'skill #' (Replace # with a number, 0, 1, 2, 3; for easy, normal, hard, nightmare.) Select 'New Game' from the menu.

if you want to record demos, you can use the "quicksave, disconnect, record, quickload" trick to record demos mid-map.

Additional notes

This mod includes an autosave feature. Every once in a while, you will see the message 'Saved to ne_autosave.sav'. You can press 'F8' to reload to that point and pressing attack or jump when dead will automatically load the autosave instead of restarting the map.
HOWEVER, if you quit the game and wish to load your autosaved game later, you will need to type 'load ne_autosave' into the console instead of pressing F8. F8 will function correctly AFTER the map has been loaded from the console.

Finally, I recommend playing with gl_texturemode 3 to disable bilinear filtering! :D

Download .zip (47mb)
Download .7z (37mb)
First | Previous | Next | Last
 
If the vase had used a common visual clue of red dots

this. usually the argument is realism. :P
i was really on the fence about it when i implemented the grey particles. there was some big discussion about this here or on i3d at the time.
otoh, blood sort of indicates you SHOULD damage it. the vases are somewhat optional, providing only 25 armor after many coins. like a non-secret secret.
and the large vases most definitely are not meant to be shot. :P
i guess the real problem with vases is that there is nothing like it in stock quake.
when you see something moving, you shoot it. if you see something on the ground, you pick it up.
there were no decorative yet destroyables beyond barrels which only showed up in tech maps and had an animating texture.

this is serious business. ^_^; 
Visual Language 
If the visual language is missing from Q1 about breakable objects then something else could be done instead. Maybe use a 'cracking' sound clue?

I suppose the ideal solution would be a damaged skin. I've got no idea if Q1 can support them or if QC can switch to a damaged skin based on health, maybe it could be possible?

I can see hiding a monster in the vase is cool, like a jack in the box type surprise but when the surprise is lethal at close range it feels unfair. Something like that should offer clues, otherwise it is just random. Like someone finding out if they shoot a certain wall texture an ogre falls from the ceiling on their head. Could be funny! :P 
 
Vases were blueish no ? Then particles of same color as the vase, simulates bits of vase chipping off there you have slight realism + indication of something different happening as its not usual white/grey particles. 
In Quake Extras 
Destructable objects that aren't monsters emit yellow (vaguely like sparks) particles. 
Particle Colors 
I went back and forth with this on rubicon2 ... for a long time Floyd had yellow blood (to resemble sparks.) But then I thought, why do shootable buttons bleed then? Should I make them emit sparks too? And then I realized, if I'm changing how shootable buttons work to make Floyd make sense, that must mean there is already a convention in place (all damageable things bleed, even non-organing things) so I changed floyds back to red blood. 
 
I actually hate bleeding funcs. You get more than enough visual feedback when they move or change textures.
And yes you could make breakable models change skin on damage too.
Even worse if you play with proper blood particles instead of dots.

Breakables don't bleed anywhere.

On a sidenote RMQ's lazer prodicing ogange particles hitting brushwork was... sigh. 
 
I don't think different colours is a problem providing it's introduced to the player. I like replacing shootable buttons with things to blow up, but you need the player to know it's they're doing something right and I agree it is weird when random objects bleed :p

Best solution would be a multiple colours thing where you set up patterns. You just have to make sure a negative is always gray so a different colour should become a sign of 'ah, I shoot this'. 
 
I can't remember if Quoth Breakables can trigger things when they die, but I put triggers over them to shoot anyway because I want the hit indication. 
 
I'm with metl on this one - the blood is an obvious cue to the player that they've just hit something and now they can expect a result. It's one of the conventions of the original game.

Of course, if you're happy to stray from the conventions of the original game then you can do whatever you want; otherwise - use blood. 
However... 
I like ZQF's suggestion that grey = fail and bright color = success, which allows different bright colors for different object types.

But I would also like shootable buttons to play a "success" sound that's more obvious than the subtle hydraulic hiss or soft click that they normally play (which is often lost due to the louder weapon sound anyway.) Usually the button triggers a nearby door or machine, and that object is moving and making noise, but it's not always on screen and not always audible.

I also felt it was a (minor) design flaw that rockets don't give damage feedback, so for example I spent way too long firing rockets at Chthon the first time, assuming that it was working. When I ran out and switched to nails, suddenly --- "Aha." (And now that I think of it, Shub gives misleading feedback too. Though you can kill her and crash the game with direct damage, it's not part of the design.) 
 
Yeah, another option since weapon fx can make such indications difficult (seeing a bunch of sparks/blood through a rocket explosion) is a couple of lines around the crosshair or something that blink when damage is caused (like Battlefield), or sounds, but again sounds can be missed in the same way as game fx. 
Just Played 
holy shit!

Before I write my thoughts about the gameplay, I have a quick question though - Did you do all the terrain by hand in radiant? Or do you have some way of exporting it from a modelling app...?

I remember when i did marcher's terrain entirely in the map editor and afterwards I said "never again". Your terrain is an order of magnitude more ambitious so i'm curious as to your method ^_^ 
Kinn 
pretty sure it was hand made. 
 
yeah it was hand made. by far the longest part of making that map. :P
i remember when i was about 1/3 of the way in, thinking "fuck, why did i want to do this again?"
if you're bored, type:
notarget
sv_friction 0
developer 5

to activate ski mode, then use impulse 103, 104 and 105 to teleport to the different peaks and ski down.
ski mode is the only reason i stayed sane. 
God Damn 
Never a more patient man has graced Quake's hallowed halls as you, necros.

That ski mode is hilarious - I think my current record is around 1500 units/s off of slope 2, and I'm sure I was airborne for at least half the journey :} 
 
turning up sv_maxvelocity helps too, because it'll cap you at 2000.
it'd be pretty awesome to use the bsp2 format and make a super huge slope map for something like that slide mod, which i still think is awesome.

how did you do your terrain?

for me it helped a lot to sort of build the whole thing at once.
when you do something that takes so long, you've got to be able to really see it coming together or you're gonna loose interest.
i built all the highest peaks first and then expanded them all outwards simultaneously so that i could see the shape of the terrain very early. 
 
There is that old terragen thingie that makes brush trisoup from a 2d hightmap. Then you load it in a map editor that lets you drag verts on multiply brushes at once and change w/e you need manually. Not that hard to do.
But then qbsp shits on you with collision problems and you spend 10x time fixing than you spent making it. 
Triangles 
how did you do your terrain?
I did it all in quad prisms first (and occasionally higher sided prisms) to get a nice polyflow, and a rough height pass (imagine all the prisms differing in height by jagged steps) then when that was all done I chopped them all into tris and lowered/raised the verts as appropriate to get smooth height variation. Final tweaks like "turning edges" were a pain in the arse as you can imagine :}

There is that old terragen thingie that makes brush trisoup from a 2d hightmap problem with that is that the heightmap is based on a regular grid, which is really ugly - i need my nice polyflow :}

To be honest, I might have a go at banging out some melscript that takes a bunch of triangles from maya and projects them up (or down) to turn them into tri prisms, and then spits out a quake .map file. Shouldn't be too hard to do... (another thing to add to my ever growing list of shit :) 
 
To be honest, I might have a go at banging out some melscript that takes a bunch of triangles from maya and projects them up (or down) to turn them into tri prisms, and then spits out a quake .map file. Shouldn't be too hard to do... (another thing to add to my ever growing list of shit :)

dude... if you did this... my god, it would be amazing.

i really wish there was a way to extrude a triangle to create a brush this way.

but... if you do decide to, would it be possible to have it work for more than just maya? maybe support ASE for full compatibility? 
Well 
I'm sure it would be a similar amount of work to write a maxscript version, although I don't have max, and have never done any scripting in it before. 
One Of My Beefs 
with quake and terrain though rears its head when it comes to the issue of placing architecture in the terrain. I've been taught that letting brushes arbitrarily intersect each other is bad for quake, which lead me to carefully tessellate my tri-soup terrain around any architectural elements to avoid intersection, which feels precise yet at the same time messy and annoying to do (it feels inefficient as it means you use more triangle brushes). I did it like this in marcher (when a 12-sided stone column butts into the terrain, the terrain triangles all perfectly meet up to each side of the column.

Now though, I'm thinking this is annoying to do and might put me off making areas where architecture melds with terrain. I think also, my OCD had a large part in me doing it like that.

Considering how quake chops up faces into ugly shit anyway, even in a pure tri-soup with no intersection - would it really matter if I just let random architecture intersect the terrain? How did you approach it necros? 
 
Something that reads an OBJ file of triangles and spits out a MAP file of extruded brushes should be dead simple. Just saying. :) 
 
"I've been taught that letting brushes arbitrarily intersect each other is bad for quake"

This has never been explained in a way that would convince me it as true. QBSP chops up the world and removes any inter-penetrating geometry. That's what it does. So how do intersecting brushes cause problems? 
 
Generated terrain is only ugly if you use large grid. And even then its really easy to adjust it the editor to your liking, making it as irregular as you want. Big timesaver.

Willem: precision problems that cause collision errors. Never experienced falling through irregular angled geometry?

There are several model-to-map progs and scripts, but none that I'v tried output geometry that is friendly to shitty quake compilers. Again precision loss, gaps, edges don't match, collision errors.

Q3map2 solves all the problems. But I know that quake mappers are too afraid of technology advancements. 
 
I've experienced that but I've never found that manually aligning brushes is a magic fix. As often as not, making them intersect MORE will fix it.

And why the hostility towards Quake mappers? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.