Select Page

Game: Team Fortress 2

Platforms: PC

Tools Used: Valve Hammer Editor

Production Time: 2 months (2008)

Team Size: Personal Project

Role: Level Design, Gameplay Design

DYNAMITE

Back when Team Fortress 2 was new, there were only a handful of game modes. One of which we are used to today, Payload, was not in the game at the time of making this map. Therefore, I took it upon myself to make one called Escort.

I started on the new gamemode Escort about a year after the release of Team Fortress 2. As an avid player of everything that the game had to offer, I felt like a new gamemode with a completely different objective would not only fit the game but also give me a good challenge.

The idea was to make a gamemode where the attacking team had to push a cart full with dynamite to the end of the map, into the enemy base and blow it up.

I also wanted to experiment with more features such as different paths that are random each time and having obstacles that the attackers had to clear out.

To the left is the approach from BLU base toward the crossroad that initially split into three different paths where the first path when starting the map was always randomized.

On the right is a video of one of the early prototypes of the new gamemode Escort.

As seen in the video, the path is always randomized between three in total and depending on which path is active I set it up so that everything visual, such as blocking off entrances and arrows for both BLU and RED team, were properly updated to lead the player in the right direction.

Later on when released and tested, the map had two routes which were completely randomized on every playthrough and other new elements such as obstacles which the attacking team had to open up to make the Payload progress further.

With the ‘final’ release of Dynamite, I had made some changes so that the right path is always the first one to be active, then the left.

I also had playtests that focused on the obstacles on each path, such as the one to the left where, before the bridge, the attacking team had to push a button on the other side to open up the barrier.

I opted to keep these obstacles in because they added an interesting dynamic where the attacking team goes from protecting and pushing the cart to themselves having to go to the enemy side to remove the obstacle, then back and continue pushing the cart.

I felt like this also allowed both teams to really try and coordinate in different ways with different classes to even send some ahead to open the way early.

On the right is the obstacle for the second path, this time taking place in a shipping yard of sorts and just like the other area, have several ways of the attacking team to reach the other side and open up the path.

With this homemade Payload system, there are no visible checkpoints for the players, but I did add them eventually such as the obstacles, to save the progress of the attackers.

After reaching a checkpoint, the attacking team and the defending team will have a new spawnroom which will push the defending team back and allow the attacking team to put even more pressure onto the defending team.

LOGIC

1. On the left is a filter specifically for the payload cart that the attacking team has to move.
On the right is the automatic logic that fires when the map is loaded, it contains outputs which tells the game rules on how to setup the current match running while handling post processing values and picking which round to start.

2. All of the following are text based logic which will tell all of the players what is happening with the payload, if it is moving, if there is an obstacle or if it is nearing the enemy base.

3. These are two default control point entities, normally used to be captured by standing near them, but they are used to make a custom HUD for the Escort gamemode, showing checkpoints and exactly where the payload is.

4. The two white boxes are entities that control the control point rounds and are used to help indicate things on the custom HUD. The logic case in the middle handles which round is picked by the automatic logic and fires proper outputs depending on which one is picked.

1. Both of these are filter entities to help handle who is actually inside the radius of the payload and thus make it stop or move.

2. This pair consist of an entity handling the math by counting off of the triggers around the payload and then outputting this to the logic case that contains several outputs. Depending on the value given, it has several different cases which in turn control the next set of logic relays, firing the one that is equal to the players in range of the payload.

3. All of the logic relays pictured play part in controlling the speed of the payload. They receive an input from the previously mentioned logic case and sends the correct speed to the payload. This allows the payload to move at a different speed depending on how many are in range or even completely stop if a defending player is in range.

4. This group contains several different entities, the orange boxes are triggers for the defending and attacking team, the small red box is the actual ‘train‘ that runs on the track with the minecart and dynamite box model parented to it. I took to liberty to add a big blue arrow and a light to help players more easily identify where the payload is.

Post-Mortem

This personal project really allowed me to do more scripting and prototyping of a new game mode using existing entities and have it thoroughly playtested throughout the process. It also gave me the chance to play around with breaking the standard design for levels made for the game, bringing a completely new gameplay experience for players to enjoy.