Originally posted on Runegame.com by Jean Paul LeBreton
Mirrored for archival purposes
Making New “Arena” Maps
Design
The new Arena gametype offers players a chance to compete in 1on1 or team fighting in specially made Arena environments. The key aim of Arena is to give combatants a completely level playing field in which skill is the deciding factor of battles. Mappers who wish to make Arena maps should consider a few new things when designing them.
General Rules – In Arena, players first spawn into a Neutral area where they choose their weapons. No player can deal damage to any other player in this area. They then proceed to a Queue area, where they can watch the current match in progress and await their turn to fight. Again, no player can deal damage to any other player in this area. When their turn finally comes up, they are teleported into the arena and begin fighting. If they are victorious, they remain in the Arena to fight the next match, their health and weapons replenished. If not, they respawn back in the first Neutral area, where they can grab a new weapon loadout, proceed to the Queue area and try again. It’s of key importance that the only place an Arena player can hurt others and be hurt is the Arena itself.
Which brings us to the first rule of Arena map design.
Arena combatants should be totally free of unwanted spectator interference – in traditional Deathmatch, unless there is a sort of “gentleman’s agreement” or house rules, two players wishing to duel are at the mercy of anyone else on the server...and as we all know, all it takes is one rampaging lamer to break up such endeavors by throwing weapons, using rune powers, or just generally getting in the way and trying to kill everyone else.
Design your Arenas so that the Queue / Spawn area is separated from the actual fighting area. This means that nobody in the Queue area should be able to A) jump down into the arena, B) throw weapons in the arena, C) do anything that might cause unwanted interference to the fighters.
The “invisible walls” commonly employed by mappers to keep players out of inaccessible areas are the order of the day. Specific ways of doing this will be discussed shortly.
Hopefully, though, most people waiting in the Queue area don’t want to mess things up and will be waiting their turn politely… as politely as axe-wielding vikings can wait, that is. Which brings to light the second rule of Arena map design:
Give players in the Queue area a clear view of the fighting action – Depending on the number of players on the Arena server and the size of match the map accommodates, you will almost always have people waiting their turn to fight. While keeping these players away from the fight is important, you also need to allow them to see the current match in progress.
Again, the need for invisible walls that can be seen through - but not traveled through - arises. It’s also worth noting that sometimes, it’s good to:
Keep players in the Queue area otherwise entertained – In particularly large Arena games, players can sometimes find themselves doing a lot of waiting. While Arena fights are always interesting to watch, players in the Queue area might want something else to do.
A little creativity on behalf of the mapper goes a long way in this case… the Arena maps in Halls of Valhalla feature such diversions as music instruments to play, games of skill and luck, severed heads to toss around, and in the case of AR-Bladepit, levers that trigger deadly traps in the fighting area itself!
Something like this does indeed give Queue area waiters a chance to affect the actual fight, killing any combatant unlucky enough to be caught in the swath of the blade traps. This introduces a new element to Arena gameplay that obviously isn’t suited to every type of Arena, but combatants, having waited in the Queue area themselves, will be aware of this threat and on their guard.
Besides, keeping Arena fighters on their toes with tricks and traps is pretty entertaining! It’s worth noting that while a player is waiting in the Queue area, they will never be credited with a kill… thus it’s impossible for a player to rack up any victories by springing such traps on hapless Arena fighters.
Ensure that the fighting Arena is a level playing field for both Challenger and Champion – All other things being equal, the player with the most skill will accumulate the most Arena victories. Your job as a mapper is to ensure that there’s no place in the fighting area where one player can pull some cheap trick or otherwise gain the upper hand.
Placing weapons and especially powerups in the fighting area generally tends to break this sort of balance. However like most other rules, this can be broken to great effect.
AR-TimeToVent spawns in two identical two-handed weapons on either side of the Arena, and this adds a new dimension to gameplay.
It goes without saying that people will have different tastes as far as Arena combat styles go, some will prefer a classic, no-tricks map like AR-Champions and some will enjoy the treacherous challenges offered by maps like AR-WidowMaker.
The common idea behind all these maps is the intent of a fair, structured dueling environment.
Technology
Now I’ll go into detail about how to set up a Rune map for Arena play. This mini-tutorial will assume that you’re familiar with how to build geometry in RuneEd / UnrealEd, divide your map into zones, and place actors within the map.
Arena maps are denoted by their AR prefix. Just as maps with a DM prefix (DM-Thorstadt, for example) will only show up in the Deathmatch map list, if your map has an AR- at the beginning of its filename it will be selectable from the server setup screen as an Arena map.
To make your map an Arena map, you’ll first need to specify Arena as its default gametype. Hit the Load button down at the bottom of the browser and select the Arena.u file. All the Arena-specific actors will now be accessible. Expand Info>GameInfo>RuneGameInfo>RuneMultiPlayer, and select ArenaGameInfo. Crack open Level Properties, select DefaultGameType, and hit Use. That’s the easy part. Now build the map and get it wired for Arena play!
You should design your map from the ground up to have 3 distinct zones, zones which will be moved through in the following order: Spawn, Queue, and Arena. The Spawn area contains standard PlayerStarts, and it’s where players spawn into the map after dying or joining the server.
Nearby, you should place any weapons and shields you want players to be able to equip themselves with. Most Arena maps give players access to all 15 weapons in the game.
Shield selections vary, some maps offer the full range, from the modest GoblinShield to the massive DwarfBattleShield, while other maps simply opt for a single, medium-level shield type with the thinking being that the largest shields take forever to hack through and prolong matches unnecessarily. It’s totally your choice as a mapper.
For all available shields and weapons, you’ll want to set their Inventory>RespawnTime to something very short, like 0.5 seconds, so that players will never have to wait to grab their weapon of choice before heading off to fight.
Within this spawn area, you’ll want to include a standard ZoneInfo, and the only property that needs changing is bNeutralZone, to “True”. This will prevent players from harming each other in the Spawn Area.
After arming themselves in the Spawn Area, the players will move into the Queue Area. It helps if you make the boundary between these areas something readily recognizable to players, some architectural feature like an archway, a magic portal, etc… something that will make the player understand they are entering the Queue area to wait their turn to fight.
Another nice player aid is to offer a visible boundary from within the Queue area, so that the player won’t unknowingly step back across it and lose their place in line. In a few of our maps we used 1-sided translucent sheets, visible only from inside the Queue area.
The Queue area should be a totally distinct zone from the Spawn and Arena areas, sectioned off by invisible zone portal sheets. Within this zone, place a QueueZoneInfo actor. If QueueZoneInfo isn’t available to you in the classes browser, follow the instructions at the beginning of this section to gain access to all the Arena-specific actors. There are no other special properties in the QueueZoneInfo, and it is always considered a NeutralZone.
Finally, you have the fighting area itself.
This should be its own wholly separate zone, with an ArenaZoneInfo actor placed somewhere within it. This is the zone players will be teleported into when it is their turn to fight. New player(s) will spawn in as Challenger, and the victor(s) of previous matches will be teleported into the zone as Champion.
The distinction between Champions and Challengers is important because they spawn in different locations, marked by ArenaStart actors. The ArenaStart actor has a few keys that determine, along with the total number of ArenaStarts in the map, how many combatants the map supports and where these combatants will spawn in when a match begins.
Placing two ArenaStarts in a map, one for the champion and one for the challenger, will mean that the maximum number of fighters will be two… a 1on1 duel map. Placing four will mean the map supports 2on2, six will support a 3on3, and eight a 4on4. XonX matches function like 1on1 matches, with challenger and champion teams instead of individuals.
The last team left standing is declared the winner.
Keep in mind that the maximum match size is something a server admin can set, so if you make a map that supports up to 4on4 players, it can also be used as a 3on3, 2on2, or 1on1 map. However a map only built to accommodate 1on1 matches (i.e. it only has 2 ArenaStarts) will not be able to support matches any larger that 1on1.
Basically a mapper has the final say on the upper limit of supported combatants, and admins can set the limit lower than that figure when they start the server.
There are 3 different variables used to control which ArenaStart a player spawns at. In a 1on1 map, it’s as simple as setting one ArenaStart’s bChampion property to “True”, and another’s bChallenger to “True”. In an XonX map, things get a little more complex. Perhaps this is best explained below showing the properties of a typical 2on2 map’s ArenaStarts:
bChampion:
Champion1 True
Champion2 False
Challenger1 False
Challenger2 False
bChallenger
Champion1 False
Champion2 False
Challenger1 True
Challenger2 False
bChampionTeam
Champion1 False
Champion2 True
Challenger1 False
Challenger2 False
Between the Queue area and the Arena fighting area you should put some sort of transparent block that will bar access but still allow visibility. There are a few ways to do this.
BlockPlayer or BlockAll actors work well, and being actors they create no new geometry and so are all around pretty cheap for network performance and client-end framerate.
In AR-AEternal massive arrays of BlockAll actors keep players from jumping off into the void or worse, down into the Arena itself. However Block actors aren’t always the best choice, as their size is set by their collision height and radius.
You can form straight walls of these collision cylinders, but in some cases, like the banked glass floors of AR-Champions, their shape isn’t ideal. In this case, invisible collision hulls (formed from static semisolid brushes) may work, but they can occasionally cause strange visibility problems.
The best solution we found was to use non-moving PolyObjects with all their surfaces flagged “invisible”… as you will remember PolyObjs are basically Movers that in no way occlude visibility.
So long as the PolyObj is constructed sensibly, this is still a relatively cheap (framerate and netspeed-wise) way of keeping the Arena off limits.
Even if waiting players aren’t able to get into the Arena, it’s often possible for them to be able to throw weapons into it. However there’s a tricky feature built into the ArenaZone actor that prevents this.
Simply leave bBlockWeapons “True” and any weapons thrown into the Arena will be bounced back at the player who threw them, often producing comedic results. If for whatever reason you want players to be able to throw weapons into the Arena, set that property to “False”.
So long as you’re digging around in the ArenaZone’s properties, check out the two other properties: ArenaMatchBeginEvent and ArenaMatchEndEvent. These two guys can be used to trigger all kinds of things upon, respectively, the beginning (combatants spawn and begin fighting) and end (last enemy combatant dies) of an Arena match.
Putting the tag of any sort of other scripting actor in these fields will cause that event to happen, be it a simple text message, a sound player, or an extremely elaborate dispatcher-controlled fireworks display. This is a great opportunity to reward the champions with a cool mini scripted sequence.
So there you have it.
Make the Spawn area a NeutralZone, designate the QueueZone, designate the ArenaZone and properly configure however many ArenaStarts you want in it.
