Originally posted on Runegame.com by Dave Halsted
Mirrored here for archival purposes
Following are instructions for mappers making maps for the HH Arena and Headball maps, the 2 MOD's included in "Halls Of Valhalla".
General RuneEd:
- Under ActorGenerators, you can now select bRespawn -> FALSE. This allows you to ActorGenerate Inventory class items in deathmatch games without having those items automatically respawn after 30 seconds... as always, though, you can retrigger that ActorGenerator repeatedly.
- The RuneOfStrengthRefill now fills 50% of the player's Berserk-power meter; previously it only added 10% or so and was effectively useless. Now it's very useful for guiding map flow, and doesn't weight the spot where it's placed nearly as much as a normal RuneOfStrength.
NOTE: To be able to place the new Actors associated with Headball and Arena, you'll need to have them loaded up in your RuneEd, and have RuneEd from version 106 or 107 (Halls of Valhalla). Either load up an already-made HB or Arena map first, or go to Classes and "Load" up Arena.u and HeadBall.u
Arena name convention: AR-xxx.run
HeadBall name convention: HB-xxx.run
Make sure you place the correct new GameInfo's (HeadBall or Arena) in the appropriate slot under LevelInfo.
As always, it's critical that you hit "Paths Define" before you're 'done' with your map.
HeadBall Mapping Instructions:
The goals are made as Zones, each with a unique HeadBallZoneInfo that handles the scoring amounts, whether limbs count, etc.
You can have any number of goals, from 1 to dozens. Under the HeadBallZone Properties, you can make the goals team-specific or general use; or you can allow both... limbs are always worth one point, but for every goal you can type in how many points you want a head to be worth (ScoreAmount), as well as how many points you want a head to be worth for a scorer of the 'correct' team (TeamBonusScore, incidentally _not_ added to ScoreAmount in final value).
Naturally, if bTeamOnly is set to true, the generic ScoreAmount entered is irrelevant, and similary you have to have bTeamBonus->TRUE if you want your separate TeamBonusScore to count.
Any time something goes into a HeadBallZone, it's deleted (and scored, when applicable, if it's a head or limb)- if the player jumps in there, the player dies. If you throw a HandAxe in there, it'll get deleted from the world.
One major 'restriction' on these goals/Zones came up in play-testing - I had one which was just a big hoop floating in the air, that you could throw into from either side [i.e. the HeadBallZone was fairly thin]... problem was, with real-world lag, sometimes heads or limbs would just fly through it, not counting - they were passing right through that Zone and with lag hitches the Zone wasn't 'catching' them during the brief instant they were in it.
So the trick is to design your goals so that, if a head is tossed in there, it'll _stay_ there indefinitely, giving the game time to recognize it and score it... think of them like buckets or something - whatever the shape or orientation (floor, wall, etc.), you want that goal to have a dead-end in the back so that things thrown in there stay in there.
All players start with a full, maxed-out health bar, and start with the VikingBroadSword - you can place other weapons and items in the maps as usual, though. Pretty much the only healths we placed were RunesOfHealth, so players could get back up to 100% health quickly - and since everybody's got a full bar to start with, you don't have to worry about the "my health bar is twice yours" problem you get in regular DM.
There is a bRestoreHealth property for each HeadBallZone - if set to TRUE, then players get full health whenever they score in that Zone/'goal'.
Teams - you can have between 2 and 4 teams (Unreal's maximum). Players can choose to play a 4-team map with only 2 or 3 teams if they'd like, but in some cases you may want to cap it (for the one I made, I limited it to 2 teams). You just place down normal PlayerStarts, and then type in the correct team number for each playerstart (0=blue, 3=yellow, I think 2=red and 1=green, though I'm not 100% sure).
The "Paths Define" is really important here, so the game knows the correct place to spawn people in to. For each team, you place a special Pump trigger called a HeadBallPump - at the start of the game, the whole thing is a big neutral area and you can't score points.
A person from each team has to 'log in' by hitting his team's pump (the interface lets players know who hasn't logged in yet)... once that's all set, the game commences.
The in-game scoreboard says if the server has limb-scoring enabled or disabled (server option). It's a gameplay variant - when limb-scoring is disabled, limb-chopping during play is disabled automatically.
Arena Mapping Instructions:
The basic philosophy here is that you spawn the players into a single Zone (set to bNeutralZone->TRUE), where they collect their weapons.
In a second zone, set to the new QueueZone type, is where the game handles the 'line' of players wanting to play. When it's their turn, they're teleported into a third zone, set to the new ArenaZone class type.
The winner(s) stays in the ArenaZone and takes on the next comer with restored health/weapons. At the end of the match, actors are cleared from the Arena for speed purposes - you don't get a bunch of thrown weapons, chopped limbs, and dropped shields piling up round to round.
You can actually have multiple ArenaZones. This was necessary for AR-SmeltingPot, where weapons that landed in the separate ankle-high 'lava' painzone weren't being cleared at the start of each new match.
Making this painzone an ArenaZone also meant the map had 2 ArenaZones, and therefore both are now correctly cleared of weapons after each round - the trick to why this doesn't break this is that the ArenaStarts are properly configured... they're the critical part.
But you _must_ have only one QueueZone.
All Arena maps have to have a single QueueZone. This is where all the queuing is handled for all gametypes (1-on-1, x-on-x, etc.). If you really want 2 or more 'distinct' queuing areas on your map, make sure you cleverly connect them up so that they rebuild as the one QueueZone.
Do not spawn players into the QueueZone - it isn't built to handle that.
ArenaZone Properties:
ArenaMatchBegin/Event are fired off when the match starts and ends, respectively. Good for pomp.
bBlockWeapons - defaults to TRUE, this is a backup check to keep people from throwing weapons from the QueueZone into the ArenaZone.
QueueZone Properties:
No special options here. Just make sure you have one and only one in the map.
Speaking of blocking things... using WarpZones or SkyZoneInfo's to fake 'viewing' windows (i.e. to keep actors/occlusion down in the Arena itself) doesn't work. This is a deep Unreal rendering matter, and won't be changed for Rune.
What happens is clients can see other actors through these WarpZones reliably in on-line play. In other words, after a few seconds you see nothing through them except world geometry. The same applies to InvisibleCollisionHulls. Sucks, but that's the way it is.
So if you want to block the player while giving them a viewing window, three ways work:
1. Make the viewing space geometry such that it can't be walked/crouched through - straight geometry solution.
2. Use PolyObjects as InvisibleCollisionHulls. So long as you set the PolyObject's Advanced property of bHidden->TRUE, it won't appear in the game, yet will block the player. The problem is that PolyObjects are Actors (unlike InvisibleCollisionHulls, which are Unreal geometry), and Actors represent a server load. Use a bunch of these and you risk bogging down the server in real-world play.
3. The third way is to use BlockAlls. Just make sure you set them to Collision->bSweepable->TRUE so that weapons can't be thrown through them [props to JP on that one].
In the ArenaZone, you must place at least 2 ArenaStarts (Under PlayerStart), one for the Champion and one for the Challenger (the winner is respawned in the Champion spot). Make sure one is set to bChampion->TRUE and bChallenger->FALSE and another is set to bChampion->FALSE and bChallenger->TRUE.
If you want to support X-on-X teams (goes up to 4, I believe), you'll need to place extra ArenaStarts for the extra max. # of players. For these extra ArenaStarts, it is not necessary to make either bChampion or bChallenger -> TRUE; i.e. leave them false. Just make sure you select bChampionTeam->TRUE for all the ArenaStarts for the winning team.
To recap, if you wanted to support up to 3-on-3, you'd place 6 ArenaStarts total. For the 'leader' of each side (or the sole combatant in 1-on-1 server scenarios), set one to Champion and one to Challenger.
For the other 4, leave bChampion->FALSE and bChallenger->FALSE, but make sure that 2 of them are set to bChampionTeam->TRUE [the 2 extra spots for the Champion side].
So if you want to restrict your map to 1-on-1 only, just place one ArenaStart for the Champ and one for the Challenger, and nothing else.
