Hey everyone,

I want to try something. I'm going to stream myself working on FF every day from 7pm PST to 8pm PST. I'll do it for at least a week and we'll see how it goes.

What I'll be working on:

• Getting 2.42 ready for release
  
• Coding new features, fixing bugs, etc
  
• Balancing/tweaking existing features
  
• Testing new maps
  
• Finishing training and adding it to the game
  
• Perhaps streaming beta tests
  

The exact specifics will change from day to day.

Why I'm streaming:

• I think it'll be enjoyable
  
• To involve the community more in FF's development
  
• To give you guys a behind-the-scenes look at FF's development
  
• To get immediate feedback from the community on what I'm doing
  
• To provide a direct route for suggesting features and maybe seeing them implemented/tested
  

I'll be doing a test run tonight at 7pm PST (in a few minutes). I hope you'll tune in.

The stream can be found at:
http://www.justin.tv/ffdev

There is a criminally underused entity in FF map making: the trigger_ff_clip. Although, its rarity is forgivable because it has never really been implemented correctly. Since FF's initial release, trigger_ff_clip could not block players and their hitscan bullets separately, which meant that players of one team could potentially stand behind it, invincible, while shooting enemies outside of it.


What's that thing?
Well, hlstriker changed all that. He dove into the trace/collision code and got a few very notable things done: fixed the long-standing trigger_ff_clip inconsistency, and added teammate soft-clipping. Since then, I have added some more capabilities to trigger_ff_clip. It can now optionally block players, bullets, grenades, projectiles, buildables, buildable weapons, backpacks, flags (info_ff_scripts), and spawn turrets. Also, In doing so, I fixed a few bugs and made SGs/spawnturrets tracking a bit more consistent; they both will now correctly lock on to anything they can shoot at (playerclip brushes have always caused weird behavior).

So, now to the real reason behind this dev journal: how to use the new trigger_ff_clip that'll be released with 2.42.

A trigger_ff_clip entity is made by tying a world brush to an entity (Ctrl+T) and selecting trigger_ff_clip as the class. You then give it a name and Lua code handles the rest. The texture of the trigger_ff_clip can be anything that normally works on world brushes; it behaves like any other entity-tied brush (func_brush, for example). I have included a few standard clip brush definitions in base_teamplay.lua (almost every map uses base_teamplay). They should serve most general purposes.

Name your trigger_ff_clip one of the following to use these standard clip brushes (case matters, so make sure your entity names are all lowercase):

clip_blue - clips everything except blue players (blue team "owns" the clip brush)
clip_red - clips everything except red players (red team "owns" the clip brush)
clip_yellow - clips everything except yellow players (yellow team "owns" the clip brush)
clip_green - clips everything except green players (green team "owns" the clip brush)
block_buildables - blocks buildables and buildable weapons
block_buildablepathing - blocks buildables but not buildable weapons
block_buildableweapons - blocks buildable weapons but not buildables
block_spawnturrets - blocks spawnturrets (turrets can't see or shoot through this)
block_nonplayers - blocks everything except players
block_backpacks - blocks backpacks
block_flags - blocks info_ff_script entities (flags are info_ff_scripts)

If you're more adventurous or need something more specific, here are all the clip flags available. Note that the generic clip flags (kClipPlayers, kClipGrenades, etc) are aliases for their ByTeam counterparts. This is to make the new system backwards compatible so that no current maps using trigger_ff_clip need to be reconfigured. Also, kClipInfoScriptByTeam is not implemented.

ClipFlags
Corresponds to a trigger_ff_clip flag

ClipFlags.kClipTeamBlue
ClipFlags.kClipTeamRed
ClipFlags.kClipTeamYellow
ClipFlags.kClipTeamGreen
ClipFlags.kClipAllPlayers
ClipFlags.kClipAllGrenades
ClipFlags.kClipAllProjectiles
ClipFlags.kClipAllBullets
ClipFlags.kClipAllBuildables
ClipFlags.kClipAllBuildableWeapons
ClipFlags.kClipAllBackpacks
ClipFlags.kClipAllInfoScripts
ClipFlags.kClipAllSpawnTurrets
ClipFlags.kClipAllNonPlayers
ClipFlags.kClipPlayersByTeam or ClipFlags.kClipPlayers
ClipFlags.kClipGrenadesByTeam or ClipFlags.kClipGrenades
ClipFlags.kClipProjectilesByTeam or ClipFlags.kClipProjectiles
ClipFlags.kClipBulletsByTeam or ClipFlags.kClipBullets
ClipFlags.kClipBuildablesByTeam or ClipFlags.kClipBuildables
ClipFlags.kClipBuildableWeaponsByTeam or ClipFlags.kClipBuildableWeapons
ClipFlags.kClipBackpacksByTeam or ClipFlags.kClipBackpacks
ClipFlags.kClipSpawnTurretsByTeam or ClipFlags.kClipSpawnTurrets
ClipFlags.kClipNonPlayersByTeam or ClipFlags.kClipNonPlayers

You define a trigger_ff_clip like so:

clip_example = trigger_ff_clip:new({ clipflags = {

ClipFlags.kClipPlayersByTeam, ClipFlags.kClipTeamRed, 

ClipFlags.kClipTeamYellow, ClipFlags.kClipTeamGreen, 

ClipFlags.kClipAllNonPlayers} })

The team clip flags apply to any and all ByTeam flags added to the trigger_ff_clip. If no team clipflags are included, ByTeam flags will block all teams.

Hopefully these new trigger_ff_clips will both be helpful in protecting respawns and open up the possibility for weird and unique maps (invincible SG spots? constantly changing clip brushes? a ceiling detpack-only drop-point? spawnturret dodging skill maps?).

Just to show you guys that we aren't exactly idle.

Check out pF's kick ass texture set!

There's a lot we'd like to do with FF. I'm going to give you guys some examples of excellent ideas that have been posted in the beta and dev forums.



HUD Customizations
What if you never look at the map time? Perhaps you don't even both with looking at your armor count - you just care about your health. Maybe you want your armor and health to be on the right side above your ammo count. Maybe you want it to be below your ammo count.

We'd love to have a customizable HUD to a degree that hasn't really been seen in any game yet. You could drag around the individual elements of the HUD and place them where you'd feel comfortable. This would also, of course, support custom HUDs that the user can put in so they can really pimp out their own personal copy of Fortress Forever. Speaking of customizations...



HUD Refinements / Additions
That bar over the disguise area when the Spy disguises is one of many things we would like to do to improve the HUD. The short list:

• Cloak Cooldown Timer - You know that whole "You cannot cloak so soon!" message? A simple little bar or something that shows the cloak recharge time.
  
• Spy Disguised Weapon - A little-known feature that we'd like to make more obvious. If you have the nailgun out and you're disguised as a Soldier, it will show the Soldier's RPG. If you have the knife out, it shows the crowbar, and so on. You should be able to see what weapon your disguise is showing on the HUD.
  
• Detpack Countdown Timer - Shows the time until your planted detpack goes off.
  
• Sabotage Countdown Timer - Shows the time until your sabotage(s) run out. If you have multiple sabotages, it shows multiple timers - up to a limit. Basically, it would show the same icons as the Engy's SG and dispenser, perhaps like this:
  
  • ICON - Sabotaged Buildable Location - Time Left
  
  
• Jump Pad Timer - How much time you have left before your jump pad goes kaplooie.
  
• Navigational Refinements - A lot of newbies get lost. We've been discussing some kind of entity-based waypoint system where its easier for newbies to navigate a map - basically the objective icon on crack.
  
• Team-Colored HUD Improvements - The Team-Colored HUD works decently at best - the text can be difficult to read with some colors and its a bit buggy. We'd like to make it look more professional and less buggy overall.

Customization Management
Replacing standard files is so 1998.

Right now, if you wanted to use a custom model you would have to replace the existing ones. Rather than do this, we'd like to set up a menu where you could select from a variety of models.

Instead of all of the models being put in one folder, there would be a variety of folders divided by purpose and class. For example, a few of the main folders would be Weapons, Grenades, and Classes. The Weapons folder would have subfolders for every weapon - Crowbar, Single Shotgun, etc.

Moreover, if you change a weapon it also replaces it globally in the current version of Fortress Forever. This means if you have a custom crowbar, every class that has a crowbar would have that custom model. Aside from being able to just pick from different models, you would be able to set each model by class - so your Scout could have a giant fish crowbar and your Soldier could have a lightsaber crowbar.



Background Image
Pretty much the same thing as above. Right now, to replace it you would have to replace a certain file in your FF directory. I don't see why you shouldn't have a drop-down menu where you can pick from whichever one you'd like to use.

Converting images to textures is also a bit of a hassle for the average user, so if it could use .jpgs that'd be sweet as well, wouldn't it?



Multi-language support
The Source engine actually supports multiple languages. We have a project in our forums to get some translation work going, and implementing it would be relatively trivial.

But while we can swap out text messages (like "You have the flag!"), swapping out other stuff in-game would be a bit more problematic. For instance, the signs in the game are textures (like the ones that say "Flag Room") wouldn't be affected by the language change.

One idea is to make different versions of the textures - one for every language we support. When you choose Spanish, it switches out Flag Room sign texture with one that says "Flag Room" in Spanish.



Melee Hit Detection
Melee Weapons in Source are spotty at best - they're basically a one pixel dot that you have to hit the target with.

The first improvement we'd like to make is to just have the crowbar, medkit, etc. work better. One idea that has gained favor is that a melee swing is actually an explosion (or series of small explosions) in regards to the code - if an enemy is hit with the explosion, it does damage to them. This would make it easier to hit with melee (and we may reduce damage as a result).

From there, we'd like to work on giving each class their own melee weapon (something many people have assumed that we'd like to do, it's obvious) and have them be unique in their own way. Right now, these are our melee weapons:

• Crowbar - The Scout, Sniper, Soldier, Demoman, HWGuy, and Pyro currently have this weapon. Your standard melee "do damage" weapon.
  
• Medkit - The Medic's melee weapon. It heals allies up to maximum health in one shot and can overheal allies. It also infects enemies with a poison that kills them slowly and can only be cured by other Medics.
  
• Knife - Does twice the melee damage of the crowbar. A backstab is an instant kill on any class, regardless of their health or armor.
  
• Spanner (Wrench) - Reloads/repairs Sentry Guns and Dispensers and it can restore teammate's armor (at the cost of cells). Otherwise, it does the same melee damage as the Crowbar.
  
• Umbrella - The Civilian's melee weapon. I think it does the same damage as the Crowbar, but I'm not quite sure. For all intents and purposes it's a crowbar clone.

So there's our melee weapons. We have 6 classes sharing the same melee weapon and we'd like to change that in the future. For instance, one suggestion was that a class had a melee weapon that gave a conc effect when you hit someone. Another suggestion was a weapon that could reflect projectiles/grenades - if someone shot a rocket at you and you timed it right, you could bounce it back at them. Most of them would just be "Damage dealers", but we can deal damage in different ways. The crowbar could be the standard quick taps like it is now. Perhaps the HW Guy could have a huge, slow, melee weapon that does damage in a wide, sweeping arc. Stuff like that!



Orange Box Stuff
We made a lot of modifications to the Source Engine. Our current build of the Orange Box broke a lot of the stuff that our coders have written over the years and we're going to probably have to rebuild a few things. That's a problem, but the bigger obstacle is the all the cool stuff we'd like to do with Orange Box - global stats (finally!), achievements (a possibility), integrating community stuff (your Steam icon & info), and tons of other stuff that trepid_jon is so excited about that he's having seizures in his computer chair.



Conclusion... FF needs YOUR help!
Why am I telling you guys all this stuff?

One (small) reason is that I wanted to give you guys insight on the kinds of ideas and plans we have floating around in the dev forums. Some of this stuff is solid, some of it is experimental, and some of it we haven't decided on yet. We'd love to get to work on it.

Sadly, we only have a couple of coders at our disposal. A lot of the stuff holding up more frequent patches is coding work. FF needs more coders.

If you or someone you know is skilled with coding in Source SDK and you can provide a few examples of your work, we'd probably bring you on board to help out! Any interested parties can send an e-mail to ihmhi [AT} fortress-forever {DOT] com.

I thought it was high time that I wrote out one o' these dev jernal thingies.

Being the P.R. guy can really suck sometimes. My job is poorly defined, but the basics of it are to work with community involvement, try to keep the front page fresh, and try to work out deals to get the game into the headlines. Basically, I have to keep FF in the spotlight and keep the community involved and interested in playing.

This means my job as a dev is probably one of the most ambiguous and difficult to gauge success on. Why are more people playing - is it because of a video we released, word of mouth, or just a fluke? And if it was something we DID do, how can we repeat it for future success?

The most aggravating thing of all is all the stuff I've seen. Every dev and tester has seen what amounts to probably half a dozen or so maps in the works and on their way ready to release for some future patch, but it would sort of ruin the surprise to tell you all about it. But what the hey, I can bring out some info on what *is* in the works without revealing too much.

= - = - = - = - = - = - = - = - = - = - = - =

Team Hunted:
Each side has a civvy and is trying to take out the opposing civvy while protecting their own. It's sorta like CTF, but the flag can run around and beat you with an umbrella.

Point... holding?
Point capture? Holding? Er, uh, basically there's a cap point that you just have to physically touch. There are 2-3 variants of this in various stages of completition with maps scaled for 8 players all the way up to maps scaled where you could play comfortably with a full server. This gameplay style (and the variants) is Green Mushy's love child and it will probably serve to be a fun but basic style of gameplay.

Reverse Flagrun-ish?
Yeah, this is hard to do without giving away map names, and I sure as Hell can't describe the gameplay accurately in a few words. A variant of the above, everyone on one team tries to capture one of four points located at one area. While the points are still contested, a timer is counting down. The timer runs out, and the cap points are reset to uncaptured. Conversely, if all four points are captured, well - the offense scores some.

= - = - = - = - = - = - = - = - = - = - = - =

Please remember that I can't honestly say when any of the playstyles above will come out - they will out when they will out. They might also change a little or a lot from how I've described them here - everything is subject to balance testing and tweaking.

There are other ideas being worked out by mappers all the time in various stages of completion. The ones I've mentioned here are the ones that are being worked on the most and have the most promise for being fun.

A lot of our newer maps make use of round timers, either in halves or the more popular quarters. So an OvD map might have the Blue team playing Offense for 10 minutes and then Defense for 10 minutes - or it might be Offense for 5, Defense for 5, Offense for 5, Defense for 5. This style of switching up O and D has survived months of playtesting and has proved to be a great balancing factor in the game. Having a strong offense won't count for much if you don't have a good defense as well when the Defense half or quarter comes up.

Another shift that has been happening behind the scenes is trying to move away from the standard CTF play of the olden QTF and TFC days. We are by no means abandoning CTF wholesale, nor are we going to be changing existing maps irreversibly - rather, we're trying to have a shift towards OvD. Maps can still be CTF and OvD at the same time - for example, sections of a base could be closed off, and the defender's base would be completely open. Using the round system explained above, each team could dedicate themselves wholly to offense or defense. We've learned a lot from the pickup community, and we believe that this sort of gameplay style will be succesful even on small servers.

But hey, let's say you like standard CTF and don't want to play the OvD sort. Good news - another thing we've been developing is the ability to have multiple Luas for one map. This way, people could say, play Team Deathmatch on 2fort without any concern about flags, or play OvD CTF on Dropdown if there's only a few people on the server. It'd be really cool if this switch could be made while the game is live, but that's something that would probably be implemented far, far down the road - if we could figure out how to do it at all.

I've tried to give you guys some clues as to how things are going, but please remember that we are constantly shortstaffed. We could always use more programmers, mappers, texture artists - if you think you can make a worthwhile contribution to the game, then speak up! If we can use you, we sure as Hell will be glad to put your ass to work.

I hope you've all appreciate this edition of "Ihmhi tries to tell you guys about what the Hell we're working on without revealing too much". Stay tuned for next time, which is whenever the Hell I can think up something interesting to write.

In the meantime, keep your eyes open. 2.2 is nearing completion (how soon until it's done, I can't say). We have some interesting things in the pipeline for both the game and the P.R. front, and we're all very excited to reveal the surprises we have in store.