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.