 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Great job. All my feedback is basically nitpicking. The gug skin doesn't quite meet with my taste, and same for the new grunt and enforcer skins. Bob doesn't fit in, IMO, but his crash animation rocks. All the other monsters are pretty thematically accurate and fun. Red777 and ne_marb are great; red777 is super marvy cool. Including e1m1quoth was nice.
I'm really, really eager to see Kell's next project. the newfound chapters:
http://forums.cgsociety.org/showthread.php?t=281268 I'll make this quick, because I have to go use the bath right now (yes, I stink).
I really liked the vermis test map where there is a two-tiered platform surrounding a pit. However, I do agree that it could use some extra tactics (yes, like an old school shooter!) to make it more interesting. In fact, I love how so many (predominantly Japanese) games put a lot of attention into boss monsters to make them interesting to fight. I hate 95% of FPS game boss monsters, because they are just the same stupid shit. It's either figure out some kind of crap puzzle, or just shoot it a lot whilst it performs the same crappy attack over and over. To overgeneralise, boss monsters in western games tend to look like an afterthought, whilst those in Japanese games look more like they have had a lot of time and effort put into them. The only FPS I can think of with good bosses is Metroid Prime. That's it. Seriously. (Painkillers were ok I suppose) However, I do agree that it could use some extra tactics to make it more interesting.
Understood. With our monsters, we tend to stick to the Q1 simplicity whereby monsters have 1 ranged + 1 melee attack. It's not an absolute of course; vores are so range-oriented they have no melee, and the knights' greatest weakness is that they must reach melee to make any attack at all. ( note that the fiends' leap is their equivelant of a ranged attack ) The Vermis is mostly there as a one-step up from Chthon and Shub. At least the vermis has a melee attack, and an unusual one at that. Both its attacks are such that they can be more influenced by map design than Chthon's hotrocks. It also isn't limited by a one-trick kill method that wouldn't stand up to repeated appearances. That's pretty much it. Crafting a sophisticated boss is not out of the question, but does demand a lot of focus and testing. The servitor races would not permit me to elaborate on such development, but we have done more than consider the possibility. Ther vermis was intended to be the capstone combat to chapters. I still consider the vermis one of the most successful projects by necros and I; it took only 6 days from concept to completion, and another two days for external playtesting. The sort of boss you're describing was well beyond the time we had in the midst of the chapters project. It was amazing when it snatched and tossed you the first time (and when it did that to a fiend later too :P).
It's probably map design and playtesting that would have to be done carefully here. Ie, not permanent cover that makes the gameplay just corner-wanking. Quoth is awesome, you have both done a fantastic job of making all the new stuff feel fresh yet very at home in the Quake environment. I am currently making a large map for Quoth (it's taken over from my more important portfolio boosting hldm2, because it's way more fun*) and although Quoth has a lot of awesome stuff, I am greedy and want more. Feel free to ignore me of course, but here are some suggestions:
exploding wall code PLEASE! As I mentioned before somewhere, I have some modified Zer code which is very flexible and works well. We can currently use killtargetted func_walls, but it's not ideal. extra shooters I want to be able to fire cthon lava balls, and other monster missiles from shooters and have them aim at players (targetting within a specific angle threshold and perhaps varying targets in coop) or specific targets. It would also be nice to have them fire at set intervals, semi randomly, if the player is in sight/range or only on trigger. For my map, I only need the cthon lava ball, and I am going to try the hack in the "teaching an old progs.dat new tricks" thread, but a specific shooter would be nice. gug modifications I really like the gugs, but their eathquake attack really pisses me off. Even though it doesn't do a lot of damage, it just feels unfair. You might not like the idea of mapper configureable monster behaviour, but I would like the ability to set range, frequency and timing of the attack, as well as having flags for whether the gug does it only when he has seen the player within the last 30 seconds (i.e. the player could be hiding somewhere, or could have gone somewhere else in the map). Setting the frequency timer to 0 should disable the attack completely. Having said that, I like the idea of the earthquake attack, it's just that at the moment it feels a bit cheap. In addition, it would be nice to have an extra target that gugs can fire when they use their attack, as I would like to have scenery that breaks when they are using their attack. bob as player helper drone I mentioned this earlier on in the thread, as I actually though bob was intended to be a player helper drone powerup when I saw the pic. Although I am not personally making a base map, I think it would be fun to allow bob to work as a player helper. In addition to having a separate player helper bob skin, he should have a power up animation for when the player finds and activates him, along with a power down anim for times when he might not be able to come with the player (trigger toggles power on/power off). *HUGE RANT WARNING. Hammer is a total pile of shit. How Valve actually made it worse to use since 1.6 is beyond me. Aside from the easier to use camera controls and accelerated 3d view, the more recent changes to the interface are annoying (double click on a brush to get to visgroups...) and some of the HL2 specific stuff is so shit I can't understand how it has been made the way it has (displacement editing with an airbush only, stitching depends on brushes rather than displacement vertices...) Crashes MORE than wc1.6. Takes ages to load compared to WC 1.6, requires Steam, and HL2 takes forever to load. Why the fuck have the modelling tools not evolved AT ALL since wc1.6? What the hell is with that? Making maps with it is not much fun basically. I used to think WC was better than Radiant. However, Radiant has been hugely improved over the past 5 years or so, yet WC is almost the fucking same. WC editing is fine for simple games, such as Q1/2 (still using 1.6), but it is pretty hopeless as a tool for modern games imho. I forgot to add that the explosion hack seems to be a bit broken in quoth. The sound wasn't playing back earlier. I know there is a triggerable sound entity, but that's another ent, and more hassle to set up.
Since the explosion is a hack, maybe you could add some of the more useful hacks in as proper entities? (explosion basically). I was working on a Quoth
Let me guess... You want the hordespawn, eh? :D i just want to add some monster... if possible i whould like to add in this big map i�m making now! it feat very nice some of the monster�s :)
Don't forget to add the Quoth pack nt the tmpQuark directory where the map are compiled.. it's usefull to be able to launch correctly the map with all Quoth pack feature included...
exploding wall code:
what do you want for this, exactly? i mean, if a bmodel disappears when triggered or when killtargetted, is there a difference? :P or do you want some kind of rubble spawning? can you describe what the modified zer code does? i suppose rubble spawning wouldn't be a bad idea. could probably get away with only using one precache, and having multiple rubble models in different frames with different skins. But then how do you make rubble to match different textures? have a billion skins for any possible texture colour on top of having different skins for the different rubble frames? we'd have to look into this. kell has mentioned wall breaking stuff though, so there's a good chance. about extra shooters, (even auto aiming ones) that shouldn't be too hard to do. about the gug though, i'll be honest with you and say he's working pretty much as intended. there is only one thing though, as we never considered that the player might be able to run from a gug and not get back to kill it. having the earthquake attack eventually time out and stop being used might be a good idea for those occasions. possibly even making it toggleable via a trigger, but we'd have to test something like that. kell and i discussed configurable monster behaviour a fair bit, and we like to stay away from that as much as possible because we want behaviour to be obvious, and consistent, but your suggestion has merit. amusingly, we have discussed the possibility of having the gug be able to earthquake at specific times and trigger off targets to break walls down and such. on bob... well, for this i'm really not sure... Ai tends to break down into tears when it's forced to do anything 'non-standard' (remember the helper monsters in hipnotic? :P) if something like this were made, it would be something general that all monsters could use, i think. again, we'll have to discuss this, as i can sort of see where you're going with this, and the possibilities it might produce, but it seems to be moving a fair bit away from the quake 'feel' as helpers aren't really what quake is about. one thing i definatly want to do, though, is some proper logic stuff. if:or/and... pissed me off that i had to build all those stupid lightning + door tricks in marb. :\ i will be honest with you here and say that i'm not sure when any of these changes can be made. kell and i aren't actively working on quoth at the moment. I wasn't sure if you were still working on stuff, sicne Kell mentioned something about a new boss monster earlier.
Anyway, the exploding wall code... I can email it to you in a couple of days. It's potentially buggy because I wrote it, but I never noticed any problems. Here is a list of features: health: amount of damage to take rubble: amount of rubble to spawn on destruction various damage methods: either explode by trigger or taking damage. Optionally toggle one hit kill only, which causes the walls health to reset if it is not destroyed in one hit (i.e. for explosive/quad ssg only destruction) BBOX or BSP clipping: either use a regular bounding box for clipping (as in Zer) or use BSP clipping (same as doors, plats etc.) so the players or monsters can walk on it. styles: built in styles include brick, metal, wood and gib (maybe another I forgot) , but use 2 models I think. This could be modified into one model using three different frames easily enough I guess, but I don't know how to edit q1 models. Each style has it's own sounds. In addition, styles can be overridden and any models or sounds can be used. e.g. set model1/model2 an/or noise1/noise2 (explode and gib bounce sounds) for custom effects, such as spawning gib explosions using quakeguy heads :) Also, I think the force of the damage to the wall affects the velocity (maybe just speed) of spawned gibs. There might be a few more options for it, but I don't have the code to hand, so I can't check right now. Regarding the helper monsters in Scourge, I rather liked them. It was fun to have a Shambler spawn and do half my work for me :) The horn sound that summoned them was cool too if I remember it correctly. The early mod cujo was quite fun also, as was the axe of persuasion. As for the Gug stuff, what you are considering is pretty much all I need really. I want the gugs to stop earthquaking after they haven't seen the player in a while, because I wanted to put one near the start of the level, when the player can't kill it. My current idea is to just put it well out of range, but I don't know exactly what the layout will be yet. By the way, I don't particularly want the following features for my map, but they could be cool to have included in Quoth (for subsequent maps) if you have time. Basically pox extras. Some of the coolest mods I have ever seen for Quake, yet nobody has actually used them in a map afaik. The main features are flowing water, advanced trains, and water that can be attached to func_trains (and behaves exactly as you would expect it to behave). There are some particle features that are quite interesting, although I'm not sure of a practical use for them, although the weather and dripping effects are quite nice. Even if you don't want to include them, they are certainly worth a look. http://developer.chaoticbox.com/quake.php some neat things there
another thing i've wanted to do is be able to bind movers to other movers like in d3 (ie: have a button and door follow a lift). i think that was mentioned for the func_switch ent, but it would be cooler if it worked with all movers. probably not for rotaters though, since rotation in quake sucks already. for breakable walls, sure, send over the bit of code (the email i have listed in my profile should work). It's potentially buggy because I wrote it, but I never noticed any problems. that's fine, it should feel right at home alongside my own stuff. XD also, i'm still not entirely convinced helper monsters is a good idea. i tend to think of it as a gimick, tbh. maybe if it was in a limited capacity... ie: the helper lives for 30 seconds, like a quad or pent, then dies after that time is up. anyway, i'm not in the habit of promising anything, esp. at this point since we're on break. :P kell and i are (usually) open to suggestions so feel free to post anything else. no promises though. ;) kell and i are (usually) open to suggestions so feel free to post anything else.
I'm eating a salad right now, and I'm ready to move on to the main course: Gauntdrop! i suppose rubble spawning wouldn't be a bad idea. could probably get away with only using one precache, and having multiple rubble models in different frames with different skins. But then how do you make rubble to match different textures? have a billion skins for any possible texture colour on top of having different skins for the different rubble frames?
Medal of Honor had a system where you actually made rubble out of brushes, placed it roughly in the right spot inside the intact wall, and then gave it an info_null to fly towards when triggered. The intact wall model would vanish, and the rubble would all appear in place, fly outwards and bounce around. Of course it used a lot of edicts, but it gave total control for size, shape, texture, and number of rubble pieces used. ...and use up one precache slot for each and every piece of bsp model rubble. ;)
i'm not saying it's not cool looking, or that it wouldn't work well, of course. but it would only be feasible if you had a string of small maps where you could afford to chunk out quite a few precache slots. (since bmodels and model precaches take up the same slots, of which there are only 128, i believe). normal quake without any monsters or items already loads up a fair bit (about 20 or so), a typical map might have 60 or so doors, plats, trains, triggers. Then monsters and weapons come in, another 30 or so. (at least 2 (usually 3) models per monster, body model and head, plus any projectile models) the main reason something wouldn't be added is that it would end up using yet more precache slots. They're very low as it is, and in a typical map, you wouldn't even be able to place a monster of every type. a last thing to take into account would be that bsp models wouldn't have proper collision. If a mapper made the pieces too big it would clip into brushwork, and if it was too small, it would float over the ground (unless they were set to have 0 size, in which case, anything larger than the chest gib model wouldn't look very good). most probably, the MoH engine was modified to support more model precaches, or parts where explosions took place with that method of rubble were short areas where they could change map to get back those precaches. i've never played the game, so i wouldn't know how it was done. Just wondering, because fitzquake just shits on every other engine imho. I am using FQ as the main engine for my current map, which should end up being pretty enormous by the time it is finished. I would really like to know how many ents etc. I can throw in.
Didn't know that brushmodels used precaches either. I presume triggers use only edicts, right? I think you made some more textures for quoth, right? Have they been released separately, or should I just rip them from the relevant maps?
Also, out of curiosty, who users hammer (pre HL2) for Q1 edting? I find wc1.6 nicer, despite the fact it doesn't have an accelerated 3d view and suffers from a weird problem where it sometimes confuses texture names with a _# extension. It's generally a lot more straigtforward to map with and tends to crash less (when it matters, 1.6 always crashes on shutdown after a long period of mapping). The title really says it all. When quake loads the BSP, it precaches every bmodel in it automatically, before the QC gets a look in. So each trigger also counts towards the limit, which I'm pretty sure is 256, not 128. Still not that much. Now, it does seem a bit of a waste using up all these model precaches on models that are never seen. One way you can work around this is with a hack.
You can use the same bmodel for multiple entities in a map. So if you had several triggers that were all the same size(or could get away with being the same size), then you could make a dummy one of them in the standard brush based way, but centred on the origin. Then look at the entity data for the map to find out what modelindex it has, and at the same time delete this dummy entity. Finally make some point entities with model *thatmodelindex and all the properties of the trigger they replace. Because the dummy one was centred at the origin, you put the point entity where you want the trigger to be centred. Nice idea in theory, but almost certainly a pain to actually do in a real map. At best, you'd want to test it in an engine that can handle more models, and then just reduce it down below the limit using this trick once it's finished. Even so, not fun to do. Perhaps a better solution would be to fix the QC that requires a model for a trigger. The model is largely a waste in the QC anyway. All it does is set the bounding box of the trigger to that of the model, collisions with the model don't happen at all. This is why all triggers are cuboids, regardless of how you build them in editor. So I'm gonna go away and see if there's a way to make triggers without a model, I've got an idea, but I suspect it's a little more involved than what I have in mind. If I find a way I'll post it here. There's me talking up the difficulty of a four line modification to the code. Oh well. Open subs.QC. Find the function InitTrigger. Replace the line
[q]setmodel (self, self.model); // set size and link into world[/q] with [q] if(!self.model) setsize(self, self.pos1, self.pos2); else setmodel (self, self.model); // set size and link into world [/q] Then you can make any trigger a point entity simply by filling out the minimum and maximum points of the trigger in pos1 and pos2 instead of giving it a model. pos1 and pos2 should be the absolute world coordinates, not relative to the entity. Not tested this extensively, but I can't see it going wrong. Have fun!
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |