-division- AdministrationProgrammingMap DesignMedia & ArtGameplay MechanicsWebPublic RelationsBeta Activities   -developer- 4estAfterShockBlisTerBlunkkaChemical BurnCircuitousCrackerjackcraigwebCrazycarldecsDefragDexterDospaceatElmoFooley CooleyFriedBunnyFryGuyGhrothIhmhiInnesKermitL0kiMirvin_MonkeyMrBeefyMulchmanNezumiomegaPheroPonreboreduxSchtoofaSh4xsqueek.trepid_jessetrepid_jonVornz0rt[AE] 82694  

As discussed in a recent dev journal, a client-only bugfix patch (version 2.46.1) has been released using our new auto-updater. You should be prompted to update next time you load the game. Let me know if you have any trouble using it.

Here is the changelog (which can also be found on our changelogs page):

Bug Fixes

• Fixed a bug that made the team menu disappear if you joined a server and toggled the scoreboard while still looking at the MOTD
  
• Fixed cloak screen effect being drawn while in a slowfield instead of while cloaked
  
• Reverted cl_ragdolltime fix because it caused unexcepted problems; removed the cl_ragdolltime cvar temporarily
  
• Fixed first-person spectator view going insane if the player you're spectating dies while concussed

Also, for anyone that needs or just prefers it, here is an .exe installer for 2.46.1 (to patch from 2.46 to 2.46.1):

• http://www.fortress-forever.com/files/246/FF_2.46.1_Patch.exe

Just wanted to write a quick little journal about some bugs found in 2.46 and what we plan to do about them. These are all client-side changes and therefore we are planning to release a client-only hotfix (2.46.1) using our newly implemented auto-updater as soon as we get all the bugs squashed.

• Bug: If you join a server and toggle the scoreboard before closing the MOTD, the team menu doesn't show up when you close the MOTD.
  Status: Fixed
  
  
• Bug: While in a slowfield, the cloak screen effect gets incorrectly applied. While cloaked, the cloak screen effect is not applied.
  Status: Fixed
  
  
• Bug: While first-person spectating someone that dies while concussed, your view goes absolutely insane in between them dying and them respawning.
  Status: Working on a fix
  

In addition, the fixed cl_ragdolltime cvar has caused a few new bugs (CL_CopyExistingEntity errors and "cl_ragdolltime 0" spawning floating player models in the center of the map). Unfortunately, the fix for the CL_CopyExistingEntity errors is rather involved and will require some fairly significant changes in how ragdolls are handled. Therefore, we will rollback the cl_ragdolltime "fix" that was put in 2.46 (and temporarily remove the cvar since it will no longer work) and work on a more robust fix for the next patch.

If you are aware of any other bugs in 2.46, let us know.

As KubeDawg suggested, since we probably won't get Steamworks support, including our own auto-updater would be nice. I've been looking into doing just that over the past few days and might have found something that could work. Here is a quick test of a dummy update:



This is using wyUpdate, a free, open-source auto-updater. However, the program used to create the actual updates (the development team side of things) is not free. Each license is $86, which we might need only 1 of, but I'm not sure yet.

For now, I'll continue looking to see if there are other options, but I just wanted to share that it definitely seems possible.

In 2.44, there is a server crash related to laser grenades. We have found the cause (thanks to the cake and Trailer) and fixed it for next patch, but in the meantime here is a .zip containing only the fixed server .dll:

2.44 Server Hotfix

Server owners should update their servers with this.

This Christmas, don't spend time with your family, play FF! They might accuse you of having no holiday spirit, until you show them these new Xmas-mode model replacements:





Download the installer here.

This will allow you to select from a list of model replacements:

• Christmas tree flag
  
• Candy cane crowbar
  
• Gift-wrapped detpack
  
• Snowglobe EMP grenade
  
• Ornament conc grenade
  

The installer should be pointed to your FortressForever folder. All default models are put into backup folders, so you can use the uninstaller to replace them.

Is that all? I might be able to make a few more of these before the holiday hits, so make a request! I'd like to change as many grenades and items as possible.

If all goes well, patch 2.44 will be released in the next week or so. In the meantime, you can preview the changelog here:

2.44 Changelog

Note: Some things are potentially subject to change (removed/tweaked/added) before release.

I thought I'd try something out. I'm going to talk about an idea that we tried for a while in the beta but ultimately scrapped, why we ending up removing it, and what we replaced it with.

One thing that we try to do is look at every mechanic in the game and form some sort of consensus on it with regards to the following questions: Is it good for the game? Does it need to be replaced or removed? If so, what is worth keeping about it? And other questions along those lines.

In this process, some mechanics stand out in terms of needing replacement. One such mechanic was the soldier's nail grenade, which stood out because, essentially, the correct use of it was spam. There was no depth, no interactivity, and no skill involved both in its use and its avoidance. This is a huge problem, because it means that it's not fun to play against, kills that were netted from it didn't feel earned, and therefore it would primarily cause frustration. This is a post from a thread on the beta forums about it:

Originally posted by squeek.1. The nail pattern isn't interactive. To avoid damage you just can't go near it.
2. The explosion at the end is only effective against people that accidentally run into it. Running through a nailgren is a gamble; sometimes it explodes, sometimes it doesn't, and it's not dependent on anything the soldier is/was doing (when he threw it he never could have predicted [even with wallhacks] that you'd go there at that specific time, he was just guessing).

So, we went about thinking of replacements. There are a few criteria for class-specific grenades: that it conforms with or strengthens the role of the class and/or that it creates a deep moment-to-moment choice about which type of grenade to prime (the Medic choosing between frags and concs is a good example of this type of depth).

Our first idea was called the vert grenade. It converted horizontal momentum into vertical momentum; in other words, it slowed people down and popped them up in the air. This works quite well with the soldier because it creates an opportunity for a rocket airshot, buys time for reloading, creates an easy rocket shot when they land, or creates an easy opportunity for getting a few shotgun blasts in.


the vert grenade in all its glory

This was all well and good. It was interactive, it created some amount of depth in grenade choice, and it conformed with the role of the soldier. But, it was not as thrilling in practice. The huge, glaring problem was that it was really, really difficult to use because of the 4 second grenade timer. Elmo summed it up well in a post on the dev forums:

Originally posted by Elmo[If you think,] "Someone should be coming around the corner soon, it's been a while. I'll prime a vert gren"

With the vert grenade, the effect is so quick that the chance of getting someone with it in this way is very low. (it's wasted)

[If you think,] "Aha a victim, I'll prime a vert gren *primed*"

The chances are that they will avoid you (wasted) or frequently the fight is over in under 4 seconds (wasted).

So to make this grenade work (as it is now) you either have to....

• increase the duration of the effect in the hope it will get someone (likely that you didn't intend to hit)
  
• OR
  
• Reduce the timer so that you can hit the intended person before the fight is over.
  

Neither are good solutions...

Say you primed it AND you actually hit them - woo about fucking time....

Most maps have a low-ish roof, especially in CTF around choke points that a soldier would be defending. I DO NOT believe maps should be made FOR vert grens, we need to make a gren that can be used in multiple spaces and surroundings.

With low approval by beta members and playtests with the vert grenade not feeling quite right, we decided to try something else. That something else ended up being the laser grenade.


an early/alternate version of the laser grenade with nails for arms

The original idea, suggested by caesium, was for a grenade similar to the original nail grenade but with defined arms. After some discussion, we settled on an idea that we could work with and got to coding it. Both nails and lasers were tried, but we ended up going with lasers because the nail version was simply too expensive. Lasers had the added bonus of being really simple to team-color, among other small benefits.

Luckily, the laser grenade worked as well in practice as we thought it would in theory. It solved all of the problems with the nail grenade while retaining the nail grenade's area denial ability. Removing the explosion at the end solves the nail grenade's need-for-spam/luck. Making the arms of the laser grenade dodgable creates a level of interactivity that the nail grenade could never have dreamed of attaining. It conforms with the soldiers role and was fun to use and play against. It ticked all the boxes and after extensive testing we decided it was worthy of inclusion in patch 2.42.

Finally, to sum up:

Originally posted by squeek.The laser grenade is similar to the nail grenade, but also entirely different. It does damage in an area, making people want to avoid it. But, the damage is dodgable if you behave in a certain manner. This creates an interesting dynamic, because if there is no one around, you can dodge the damage fairly easily (meaning spamming is less effective, and damage from it always feels deserved [you failed to dodge it well]); but, if there is someone around (say the soldier that threw the grenade), your movement as you dodge the damage becomes MUCH more predictable, making it easier for the soldier to hit you. Once you get into that loop, there is a lot of depth and interactivity (avoiding damage makes me easier to hit with rockets, should I take some damage from the laser grenade? should I hang back and wait? etc...) All are viable and potentially logical choices, dependent on both the situation and the actions of each player. That is what we are looking for.

Anything can be made effective. We want to try to make our mechanics effective, interactive, deep, and fun wherever possible (and jump roping laser grenades is rather fun :)).

And so that's that. Let me know on the forums if you'd like to see more of this type of dev journal.

P.S. Be on the look out for a hefty laser grenade damage increase in patch 2.44 (coming soon!).

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.

Allow me to shed some light on how dev maps are being developed behind the scenes, especially the ones with new gameplay types. One of these maps, ff_impact, is in the final phase so I will use it as an example. To give this process a name we’ll simply call it the PDT approach. Not all dev maps are developed exactly like this, but especially for new gametype maps we’re trying to follow this process as it seems to work well and gives us a guidline to track progress etc.

Prototype phase

At the start, there is typically a request for a certain type of gameplay from one of the devs or the mapper himself. The idea is discussed and tweaked by the devs in terms of moulding it into a map. In the case of ff_impact, Aftershock launched the idea for a new gametype combining CTF elements with AVD elements. After 2.0 it was realized that full 2-way CTF wasn’t ideal for pubs as it wasn’t intuitive for new players to use dm (i.e. the straight obvious thing to do) to reach 2 objectives (defending your flag + getting the enemy flag). So it was discussed to simplify this by dividing the 2 objectives into alternating rounds where you only had to complete one objective: one round you are the defenders, one round you are the attackers. Now we were threading into the realm of AVD. But at the same time we wanted to try to implement elements of 1-way OvD reverse-CTF where it’s not over once you cap the flag. This is more forgiving; the defenders can allow to let some attackers slip through and cap. It is more viable for defenders to “hold on” to front line defensive positions. And the front lines can be “filled up” in case of higher player numbers, so that maps are equally fun for low and high playernumbers. Lastly, the map had to be linear and obvious enough to not give any confusion, or so that dm-ing new players contribute automatically to the objective. We hope this will somewhat bridge the gap between clanned play and pub play.

It resulted into a new gametype: ADZ (Attack/Defend the zone). In this zone, the attackers score points for entering the zone and for remaining in the zone. Different possibilities are possible within this concept, and Green Mushy has multiple of them in different stages of completion. In ff_impact we chose for 4 flag capture points within this zone, automatically reverting when no attackers are in the zone for a certain timeframe, and giving bonus points if all 4 are captured. After capping, the attackers can choose to stay in the zone to get additional points, but an auto-health-drain makes sure the defenders don’t have to chase a lone capper.



So after these basics have been laid out, Pon started to make the lua and I started to orange-map this flag room and the different areas leading up to it. The advantages to orange mapping are:

• You hold no sentimental value to any geometry, so you have no problem getting rid of stuff if it doesn’t work.
  
• It’s very fast to do since you use very basic shapes and textures, and thus fast to change.
  

The prototype was beta tested and changed multiple times as we discussed what worked and what didn’t in terms of striking the balance between simplicity for new players and fun/challenging elements for experienced people.

Some of the things we implemented:

• Both the main attack route and the alternative attack route are always clearly visible, they are only distinguishable because of the height difference.
  
• Entrances are brightly lit so that players are subconsciously attracted to them.
  
• Functional elements such as resupply bags and ladders are very obviously visible by lighting them with consequent colours.
  
• The areas provide for good defensive setups which will require teamwork from the attackers to bring down.
  
• Defensive stances will shift dynamically from area to area and the success of this shift will depend on good defender comms. Not only backward but the defenders can also push back the attackers and claim back forward areas.
  

After lots of iterations and test sessions, we were happy with the basic layout and the map was ready to go the next phase.

Detailing phase

I then proceeded to convert this orange map into a “real” map. Now you can really turn those basic shapes into detailed architectural elements and texture it accordingly. What I did for ff_impact was browse through the model database and found a use for some models which I liked and incorporated them. I had an idea for 2 non-existing models so I requested them to our modelers and after some iterations between my goal and their prototypes, PF and Carl did a great job modeling and skinning them.



I chose or made the map textures fitting with the models and the general theme and then lighted the map to make the architecture and details stand out (along with the functional lighting as described earlier), striking a balance between “atmospheric” darkness for non-functional areas, and clear bright lighting for gameplay-important areas.





The challenge in this phase is the fact that layered details, which give detailed depth to a map, are actually the enemy of clear gameplay visibility, so the goal is to “conceal” the busy detailed areas by using unobvious colours in dark area’s. Also the use of consequent distinctive colour schemes and brightness for floors and walls goes sometimes against the general matching of textures, but is to be preferred in terms of gameplay visibility for a fast game like FF.

Tweaking phase

This is all something that had to be tested and tweaked in beta tests. In these tests we verified that the detailing phase didn’t disrupt the final, tested orange map too much in terms of clear and smooth gameplay. Also all the lua functionalities are tested and some little tweaks like the scoring of points etc can be adapted and tested. We feel it’s now ready to be shipped with 2.2 and will learn from the community how it plays and what we can still improve towards 3.0.

With 2.2 coming very soon, enjoy the new ADZ gametype and stay tuned for different variations following.

Hey squeek! They work just fine.

If you're one of those sites that is cool enough to not only have an affiliate reel, but to also have (or want) Fortress Forever to be a part of it, we ask that you use this image, if you're not already:



Many thanks.

For the code impaired:

<a href="http://www.fortress-forever.com" target="_blank"><img src="http://www.fortress-forever.com/fflink.gif" alt="Fortress Forever" /></a>

You're also welcome to download the button and host it on your own site if you'd prefer.