simple fact:

http://morebeefequalsbettertaste.ytmnd.com/

Hunted had its first playtest on Sunday. We poppin' cherries off! HAAAAH! Poppin' cherries off! HAAAAH! Poppin' cherries off! HAAAAH! Poppin' cherries off! HAAAAH!

That's gonna be the Ying Yang Twins' next platinum-sellin' single. Just watch. Wait, what happened? I'm over here now.

For the past few weeks, Jesse and I have been on mission of sorts to finally get a playable hunted committed to FF's SVN so we can finally get started with some "real" hunted playtesting. We were tryin' to get the playable hunted committed last week, but we failed. This week, however, we just almost/kinda/sorta failed. Wait, what?

I downplay it like that because even though we managed to commit an updated and playable hunted for Sunday's playtest, we "almost/kinda/sorta failed" by continuing to neglect the escape area. And because of that, I woke up on Sunday before the playtest with a feeling of guilt like, "Why did we waste time yesterday by retexturing areas and working on semi-finished areas...when there isn't even an escape area yet and we haven't even started the lua scripting."

We didn't completely waste time on Saturday, though. We finally added info_ff_teamspawns (which I think is a worthless entity, because info_ff_script should be able to act like a spawn point...but I guess that's for another wonderful dev lua discussion), info_ff_scripts for health and armor kits, and the 2 holes on the corner of the ruins that overlook the warehouse ramp and field.

But even though we did some useful stuff on Saturday, we still didn't make the escape area...which means we should have completely failed for the second week in a row.

There were only a couple of hours before the playtest, so there wasn't enough time to make an actual escape area and recompile hunted...because hunted takes a couple of hours to compile. In hindsight, there actually was enough time due to the playtest being a little delayed, but the keyword there is "hindsight." So instead of making the whole escape area along with a trigger_ff_script for the escape's brush-based trigger and other brushwork that would require a full recompile, point entities were used so hunted could be recompiled with -onlyents.

A new concept that Jesse and I want to go with for the escape area is using a portal instead of a normal door like in the old TFC hunted. So the buttons that used to open a door would open a portal instead. Right now, this portal is only using a point_camera and a scaled down version of HL2's models/effects/portalrift.mdl...along with not using _rt_Camera for the portal material's basetexture, because FF supports multiple render targets for multiple monitors watching multiple orgies all at the same time. Very cool stuff, but it's not perfect for the desired portal effect Jesse and I want.

What Jesse and I really want to have is an escape portal that basically looks like the portals in Prey and Portal, so you actually see through the portal like you're looking through a window. That way the lame low resolution point_camera portals can be murdered in their sleep.

Anyways, by using point entities and -onlyents, a playable hunted was committed for Sunday's playtest. But Jesse...missed out on all that Sunday fun. Hahahahah, he missed hunted's first playtest. Everyone point at the queer and laugh.

Here's the extra goodness, though. My "mouse3" button is my "Push to talk key" in Ventrilo...and it just so happens that for me, "mouse3" is bound to "jpeg" in FF. So every time I talked to the team on Vendrilldo, I also took a screenshot. Which means...I took a lot of screenshots, and here are some of them...

Note: because these were essentially "accidental" screenshots, they were all taken at jpeg_qualilty's default setting of 90. Also, the HUD is being reworked right now, so I cropped the current HUD out of the screenshots. And the sniper rifle view model isn't in-game yet, so I cropped it out as well. Annnnnd I also cropped out other incomplete things, like the escape area...or lack thereof. I'm leaving the one screenshot that shows the sniper with missing textures, though (09)...just because.






O&A PARTY ROCK!

I've been optimising stuff for the last few days, so I thought I'd post a bit about it. A lot of level designers already know this stuff, so I'm just posting it more of a "what the hell are they playing at over at FF towers" kind of fashion.

So, here's a bit about "the process", as I like to call it. The process is an ongoing process. It isn't a fun process. If you want your map to run quickly and vis to chomp through it like nobody's business, then you must adhere to the process. Basically, this means keeping your world geometry as boxy and orthogonal as possible. Every part of the map that is not concerned with visibility should be func_detailed or changed into a prop. At a very basic level, the bsp map format uses each polygon face to 'cut up' the world. This happens recursively until it cannot be split up any more. Why is this important? Well, you want to keep the 'cutting up' of the map controlled. Too much splitting = lots of leaves = slow, both to compile and to play. A level designer generally wants to control this splitting and use it where necessary, but omit it where it's not. We have a decent amount of control, but of course it's not possible to get everything as we want it. It makes more sense to spend time on the important things, too. Try and get the largest returns in speed for your investment. Also, while gnashing your teeth, remember that it will cut your compile times down significantly. I optimised push and vis went from four minutes to one minute. With the bases flipped, this will likely translate into something like a ten minute saving per compile. Now, push is fairly simple; imagine how much time you can save with larger maps.

In many cases, geometry is not serving any actual purpose when it comes to vis-blocking. If you've made a tin hut on the top of a building roof, it will probably be advantageous to make it a func_detail. The reason being is that the hut will cut up the world and it won't actually aid the engine in blocking off any kind of useful stuff in terms of visibility. Furthermore, in many cases, it may be quicker to actually render something than to have to partition it off, particularly if it's an odd shape. Ever compile something and get the rather abstract-sounding "Leaf portal saw into leaf" warning? That's vis yelping because the map needs to be optimised.

I find staying on a 32 unit grid helps a lot when it comes to keeping things tight and fast. Nearly every curve, corner, strut, girder, column is a func_detail or a prop. If a room is circular then, if possible, I will tend to create it as a box, then create func_details for the curves. If the back side of the curve is not viewable to the player, then you can simply merge the vertices to form a point. The nodraw texture should always be applied to the hidden faces of func_details since the func_detail doesn't visblock. Same deal for any world geometry that is completely obscured behind the func_detail. The same goes for geometry hidden by displacements. If you have the time and you feel it is effective, go nuts.

Here's some pictures of push from hammer with various things turned on/off so you can get a feel for what I'm talkin' 'bout. I'm going from everything on and progressively turning everything off; you can see how the detail strips away to leave what vis actually has to deal with -- the vis compexity is a fraction of what is on display.

Click the thumbnails for a larger picture.

Yard -- everything on:


No 3d skybox geometry:


No displacements:


No props:


No func_details & func_ brushes:


Other stuff. The shell of the main corridor (this could be optimised still further, but it's already nice and fast, so I'm not going to spend more time on it):


The side warehouse with everything on:


The side warehouse stripped down to world brushes:



In other news, I've been optimising away and creating some LOD models for my props in the past few days. All I have to say is "Jeez" because the SDK and tools aren't making this much fun. I created everything as described by the valve wiki, yet I've had nothing but problems. This culminated in my props compiling perfectly (no errors, no warnings) and the LOD functioning perfectly in HLMV and Hammer, yet ALWAYS displaying the LOD1 model at all distances ingame.

So, I've wasted umpteen hours on this and there'll no doubt be a simple but esoteric problem. It seems half of my dev journals involve complaining about the SDK so I probably sound ungrateful and embittered, but it is a huge problem for me when I spend time on stuff that could be better spent elsewhere. I resent spending time resolving problems when there is no error message to guide me! I also had a collision model problem with a rubbish skip prop. The collision model would refuse to work. It finally worked after re-trying about a million times, but I'm not quite sure why. *gnashes teeth*

In addition to this problem, Hammer has now started picking up our SVN working copy resources. This results in duplicates for every sound, model, material and other resource type showing up twice in Hammer. Want to search for a model? Two will show up. Want a brick texture? They'll all show up twice. It's really, really annoying. Mirv has been able to knock up a script to eliminate this problem with our materials, but everything else is still affected by the problem. I've emailed valve, but received no reply as of yet. Other mod developers are suffering from the same problem, so I hope they fix it soon.

I would like to thank Thom Yorke and The New York Dolls for easing me through this particularly frustrating period of time.

In .. more... other news, the testing tonight (Sunday) went pretty well. Hunted is looking rather nice and the player models look very solid. Rebo finally fixed the bounding boxes for the models, so you can now throw players around properly with explosive weapons; a long-standing bug had prevented this working correctly in the past. Watching player models die & fly always gets a laugh out of me, especially when they slam brutally against a wall, spraying blood against the surface. :D

Our LUA is being overhauled once more, with Mulch, Olah and the trepids putting in a lot of work. The trepids are more knowledgeable than the rest of us mortals when it comes to entities and the TFC entity system in general, so they've been doing a lot of probing, debating, complaining and saying "can our LUA do this and if not, why not?" There've been a few tensions here and there, but ultimately we're getting a better LUA system for mappers to use, so it's all good.

Beta Ramblings

As you eagle-eyed chaps may well have noticed, we're aiming to have the mod in a beta state very soon (August 2006). I thought I'd clear up a few things in this dev journal. The beta will not be open. Why? Well, we have a dev team that is 20+ odd strong, and we just need some further gamers to add to this so we can make sure the basics are right, people aren't crashing, we've not made any ridiculous oversights and, most importantly, we're not getting 1000 people all reporting the same bugs many times over. It makes more sense from our point of view, both in terms of distribution and practicality, to make the beta closed to begin with. Please do not email us or ask on the forums for beta testing slots. We will be making an announcement or asking people directly. Will we be making people sign NDAs like other mods? Uh, I doubt it. We'll probably just say "hey man, you're a beta tester and we'd prefer it if you didn't go posting stuff, thanks" and then hope that will suffice.

Once things are a bit more refined and polished, then we'll likely open things up somewhat. By open up, I mean either expand the closed beta to a bigger number of people, or just change things so that it's an open beta and anyone can participate. This stage will also likely see the introduction of some gamers with no TF experience so we can see how the TF outsider fares. How long will this take? It's hard to say. Most of us haven't done this sort of thing before, so this is a learning experience and the curve is fairly steep. Some features may not make the (initial) beta, but will definitely will be making an appearance in future revisions.

The major things we've yet to work out are who gets in on the beta and how we're going to distribute it. We've got some ideas on this, but we've yet to decide for sure.

Mapping Ramblings

I've been working hard on shoring up push and we almost released some screens for the last media release, but I wasn't happy with a few things so we held it back for a bit. The cap point is nearly done and I'm just doing a final detail pass in addition to tweaking the fog / skybox at the moment. The spawn rooms are in etc. The hardest thing I had to do, which was quite some feat, was connect up the roofing. In push, like hunted, the whole map is one continuous area. Each building connects to the next area and the map continues instead of being like separate, isolated arenas. This was a total and utter pain in the arse to implement as it means careful visibility management (praise be to hint brushes) and lots of func detailing etc.

Framerates are high and I'm very satisfied with the overall build quality. I'm going to finish up in the next few days and then turn my attention back to bases. Ideally I'd have finished this a week or so ago, but I always tend to find that hammering the last few nails in takes the longest :P

Hello, it’s next Thursday. Well it is while I'm writing it, but by the time this is approved it might not be.

I suppose I’ll write a bit about our play test again because they’re pretty interesting. We played 2fort and dustbowl again and a good time was had by all (presumably).

One thing that’s always quite fun in a play test is trying out new things that have been added to the game. On Saturday in our 13-player dustbowl game I spent most of it playing with the new spy sabotage skill, and (unlike many things initially) it worked pretty well right off the bat.

Still, the big bug crush marches on and gradually all the issues are being ironed out. Recently I added the client-side code for the Lua-controlled dynamic HUD, once this is integrated into Lua it should allow mappers to display their own timers, persistent messages or onscreen icons for their maps.

DrEvil has been doing plenty of work on his bots recently and has brought on 2 new people to help write all the bot scripts for the maps. Bot scripts?

For example, in openfire the script is responsible for marking the flag as unavailable until the lasers are taken down, or in cz2 each checkpoint is disabled for each team at certain times based on the cap status. The availability of detpack goals, capture points, flags, defense points, etc.. all are scriptable.

That’s what he says, and who am I to argue (they’re his bots). This is all good news anyway since this was one of the main areas left to sort in the mod.

Now the main thing is to get the entity system sorted. Mulchman has been doing a lot of work on it recently along with Olah. It’s gradually shaping up, now in it’s 3rd iteration I think. There’s plenty more that could be said about it but that’s something for another journal.

Alright well that’s almost it for this journal.

The spy sabotage! Ah yeah, as I was saying, this was a lot of fun in our play test. Before I go on, I should say that this is going to be subject to change (tweaking, removing altogether, depending on the game balance). So what’s the spy sabotage?

Go spy, disguise as the same team as an engineer and you are able to sabotage his buildables. Strut up to a sentry gun or a dispenser and point your crosshair at it while stationary. After about 3 seconds (there’s a handy on-screen timer) you’ve sabotaged it. Well done.

Sabotaged sentry guns have reduced accuracy and sabotaged dispensers will reduce the armour class of players who take dispensed ammo ammo from them. This lasts for 2 minutes before wearing off.

For those 2 minutes the spy also has a remote link to the buildable (accessible through the spy menu). He can use this to detonate the enemy dispenser or set the sentry gun to attack its own team for 10 seconds (after which it’s no longer sabotaged, even if there was still a minute left of its normal sabotage time).

This is a lot of fun. On dustbowl I went on a mission to sabotage as many sentry guns as possible. I don’t think the enemy team had got the memo about this feature since I’d regularly stroll up to an enemy sentry gun while their engineer just chilled out watching me (this was usually decs). A few seconds later the voice comms (we use Ventrilo for playtests) would be full of surprised voices asking what on earth decs was doing with all the teamkilling.

Good times.