Changing Spawn Rooms on an Individual Basis

Discussion in 'Mapping Questions & Discussion' started by LoftyTheMetroid, Jul 2, 2009.

  1. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    Hi, all! I'm pretty sure my other thread was overlooked due to its length, so I'll try to keep this one short... >.>

    I'm still learning about how to fully utilize TF2 entities, so I'm not sure if this is possible: Can I change the spawn room a player spawns at on an individual, player-by-player basis?

    For example, one player on RED crosses a certain threshold trigger on one end of the map, and will now spawn near that end of the map. On the opposite end of the map, another RED player does the same. When either dies, he or she respawns at his or her respective side of the map.

    Everything I've looked at so far seems to only allow for team-wide spawn room changes, and that doesn't work for my new map type. I need to make some rather significant alterations if that's the case.

    BTW, I'm nearing completion on Control Point A sometime within the next few days. After that, just B, C, and the Hill before my first Alpha release! XD
     
  2. pitto

    pitto L3: Member

    Messages:
    109
    Positive Ratings:
    73
    Hmm, sounds interesting, I don't think it is possible though
    (TF2 is a team based game, hence valve caters for spawning teams together, not individual players at certain points)

    I guess you could make spawn points that are disabled, and when the players walk through a trigger this enables them, however it is random which spawn position the player is spawned at (chosen from the active/enabled spawn positions)
     
  3. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    I feared as much, and figured that would be the justification (that TF2 is a team-based game).

    In that case, I think I'll convert my outlying spawn rooms into simple "class-change" rooms (with health cabinets), and will ignore any fears I have about map traversal downtime until the alpha release. At that point, if it proves to be an issue, I'll simply add "wind tunnels" or something to move players around.
     
  4. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    It's actually possible through teleportation. Everyone spawns in a teleport room, and have teleport triggers filtered by entity name, and then you name players with triggers in the different zones.

    But how complicated it is depends on how many factors can change where the player "spawns". If you could outline the whole list of cases (spawn here when X, spawn there when Y, no longer spawn here after Z, etc) I could help you out.
     
  5. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    It should be fairly simple:

    The initial spawn room acts as more of a central hub, with the remaining three control points of the map lying in regions that are extended from the central hub. The three regions are all connected to one another and have their own respective spawn rooms, so it makes spawning at the central location redundant beyond the initial spawn.*

    Once a player crosses the threshold into an adjoining region, he or she becomes tied to that region's respective spawn room, and will never respawn in the central hub again. If a player tied to one of the outlying spawn rooms moves to another region of the map and crosses its threshold, then the player is now tied to that specific region and its respective spawn room and removes all spawning ties with the previous region.

    Basically, beyond the initial spawn, a player is only ever tied to one of three spawn rooms at any one time, depending on his or her last crossed threshold.

    (I have ideas for a more complicated spawning system to encourage certain attacking behaviors, but I don't even want to even consider that unless extended playtesting would prove it necessary.)

    *I want to include this initial, neutral hub for both thematic and strategic reasons. This way the team begins together, and can divide up as necessary to distribute their forces among the three regions.
     
  6. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    Ok, that sounds simple to do, the only thing you didn't clarify was if these people should stop spawning at a given location after they lose the CP. (I presume these locations are related to CPs?)
     
  7. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    Actually, that's related to the more complicated spawning system I mentioned... XD

    No, at the moment, control of a CP has no implications on being tied to a spawn room. (And yes, each of the three regions centers around one of CPs A, B, or C.) This isn't an attack/defend map, nor does control of all three CPs result in a victory.

    Just to clear up any further issues, I'll outline the basic map gameplay and other spawning system I envisioned. Read it only if you're interested or if you think it would clear things up:

    -------------

    The map is a mixture of King of the Hill, CP, and Rock-Paper-Scissors. In the center of the map, located far above the initial spawn rooms, is the Hill. Standing on the Hill accumulates points for your team, a factor which is multiplied times the number of players standing on the Hill and the number of CPs A, B, and C under your team's control. Surpassing a certain point threshold results in victory.

    When a CP is captured, in addition to giving your team a multiplier on the Hill, it brings several paths under your team's control. These include a route to the Hill, and a route to the CP you currently "beat". These paths are A-->B, B-->C, and C-->A.

    What I mean is that, by taking one of these paths, your team will arrive at a more advantageous position in the following region, making assault and capture easier. However, the cyclic nature of these points means that the other team is doing the same to the CP furthest behind you. As a result, teams are constantly revolving around all three regions, trying to gain more than they lose. All the while, small teams of players will need to occasionally be sent to the Hill to accumulate points.

    My main concern is spreading teams thin across the three points, as well as the downtime it would take players to reach one of the three regions from the central hub. As such, I considered limiting visitable CPs to two per team.

    For example:
    - RED controls A and C. BLU controls B.
    - BLU cannot attack A, because A is "behind" B. BLU can only attack C. Thus, defensive BLU players are at B, offensive at C.
    - RED can only attack B, as that's the only point left. A needs no defense, as C is under RED control. Thus, defensive RED players are at C, offensive at B.
    - As a result, any BLU (and possibly RED) player that was tied to A during RED's capture of it should have his or her respawn default back to the central hub. Being tied to respawn A at this point in the match shouldn't be possible.

    For situations where one team controls all three CPs, any player from any team can be tied to any of the three spawns.

    This setup would give teams a little bit more direction and would ensure a balanced cross between the regions. (After all, 5-CP maps only concern themselves with two CPs at a time anyway, so the two would play the same mechanically.)

    However, it is also more complicated and may confuse players as to why they can't visit certain points. Traveling downtime and thinned teams may not even prove to be an issue, so such a spawning system may be unnecessary.
     
  8. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    Okay, so I think I have the teleport thing figured out, but I'd be very appreciative if someone could verify what I have going. (FTR, I'm initially going with the simple spawning system, not the complex one.)

    1) Players of each team spawn in separate and empty spawn rooms. These two spawn rooms are separate from the rest of the map.
    2) Each spawn room is completely covered in sixteen different trigger_teleport brush entities, each one tied to a separate player. Players are identified by their corresponding filter_activator_name entities, one of which is uniquely tied to each one of the trigger_teleport entities.
    3) Upon spawning, a player is immediately teleported to his or her corresponding info_teleport_destination entity. Info_teleport_destination entities are set when a player crosses a trigger brush threshold designating a new region of the map.

    Is this right? Also, is there an in-game means of referencing individual players (like blu_player_01)? Or will I have to do some complex finagling to properly track each player and his or her respective teleport, as well as alter his or her teleport destinations at the trigger brushes?

    Also also, I haven't tested it yet, but... are teleports instantaneous? It would look awkward for a player to briefly see a "teleport room" before actually "spawning", and would probably be more trouble than it's worth if true.

    Thanks!
     
  9. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    Oh, sorry... I meant to write up some instructions but seem to have forgotten about it. It's a little late tonight though, I'll do it tomorrow.
     
  10. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    Ok, you were in the right direction but on the wrong path. You need a trigger_teleport for each zone not for each player, and yes, it is instant.

    What you do is name the player's entity, just like any other entity can have a name. Have a trigger_multiple covering each zone that sends:
    Column 1 Column 2 Column 3 Column 4
    OnStartTouch !activator AddOutput targetname zone_X_death

    Where X is A, B or C.

    Then set up a filter_activator_name for each of those names, and use them on three trigger_teleport in the spawn room. Then create a filter_multi that includes all three other filters, and set the negation key. Use this filter for the fourth trigger_teleport that will send people to the initial spawn.

    That's the basics of it, however if CPs change hands then you'll have people teleporting into the wrong places. So you may need to rename those people directly on point loss. For example if B is lost you would need to do:
    Column 1 Column 2 Column 3 Column 4
    OnEndCap zone_B_death AddOutput targetname zone_C_death

    To "forward" anyone marked for B and set them to spawn at C instead.
    What all you need to do in this regard depends on your exact dynamics, whether or not you have seperate triggers/names for each team, and more.

    Lastly, if you just target an info_teleport_destination, everyone will pile onto the same point. You can use an info_landmark reference for the teleport, but then all your spawn rooms have to face the same direction (because the player's view angle will be retained through the teleport), since you don't want people facing the back wall of spawn.
     
    • Thanks Thanks x 1
  11. TracerDX

    TracerDX L3: Member

    Messages:
    127
    Positive Ratings:
    25
    I love you ABS. :laugh: I had no clue you could even do something like that, and it helped me with a totally unrelated problem.
     
  12. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    Well, first, having to have all my spawn rooms face the same direction would be a problem for my map. The three CPs are arranged like the points of an equilateral triangle, each facing outward from the center (with the initial spawn rooms being in the center of the triangle). Each region is rotated sixty degrees from the previous one, as are the spawn rooms. I just don't think I could come up with a universal spawn setup that could be used at each point and still appear natural. Is there a possible workaround for this?

    (BTW, this is why I originally thought having an info_teleport_destination tied to each individual player would be necessary. The spawn location at each region wouldn't be randomized, but at least they wouldn't pile on one another.)

    And while I'm still trying to get the hang of entities, might I ask you two quick questions...?

    1) I couldn't find anything related to player entities on the Source SDK website (at least, for multiplayer/TF2). Exactly where can I find the entities in Hammer and name them?

    2) The website also didn't cover anything regarding the AddOutput function I so often see in entities. Could you briefly explain what this means:

    Is there some sort of syntax behind it? Do I actually use "targetname" as a variable or something? Is zone_X_death a built-in variable? (I couldn't find anything on zone death...)

    The other stuff I'll figure out later...
     
  13. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    There is no way around the alignment issue if you use a landmark, and trying to do individual teleports for each people would be beyond insane.

    You don't actually name the player entities in Hammer, that's what the trigger does. Whenever it is touched, the entity responsible for doing so (the !activator, a special variable) has it's targetname key overwritten by the AddOutput function (it can both add outputs, and add/change keys). zone_X_death is just a name, it doesn't mean anything in particular, it's just what I used when I built a slightly different version of this system.

    Also, the syntax for AddOutput is explained in the entry for it on every entity on the VDC.
     
    Last edited: Jul 6, 2009
  14. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    Aww, damn it. :(

    I've got a couple other workarounds in mind already, but individual respawns would have been ideal. I'll condense some elements and just wait until the alpha to see if it's really a problem in the first place.

    Thanks for the help anyways, though, I think I'll probably be able to use this information in the future! :D

    Oh, and for the AddOutput syntax, this is all that I could find on the VDC:

    Unlike most other inputs, there's no link with more information. I didn't know, for example, what could be used for a <key>, or what <parameter> values are available to me, as well as what the whole thing is generally used for. That's what I was trying to figure out, but I couldn't find any pages or tutorials on it. I guess I just won't mess with it...
     
  15. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    <key> refers to an entity key, aka property. It's the terms you see if you turn off Smart Edit in Hammer.

    <parameter> means the same thing as it does in the actual Outputs tab of the properties. AddOutput doesn't DO something, it add another output to the entity you are targetting, and that long string are all the available options outputs use.
     
  16. LoftyTheMetroid

    LoftyTheMetroid L1: Registered

    Messages:
    16
    Positive Ratings:
    0
    Okay, so I've been thinking about this for the past couple days, and I thought I came up with a solution to my problem. However, when I implemented it using a test map, I just spawned normally. However, that may be due more to my inexperience with Hammer, so maybe someone could tell me if this is possible or not, and what I may be doing wrong...?

    -----

    First, I begin the map like A Boojum Snark suggested; a trigger_multiple covers the entry to a zone that renames a player to "zone_A_death".

    However, back at the respawn, I implemented a respawn-wide trigger_multiple that uses a filter_activator_name to find players named "zone_A_death". After OnStartTouch is fired, the trigger_multiple gives a logic_case a PickRandomShuffle input.

    The logic_case has (for the purposes of the test) four cases, one for each spawn in Zone A. When PickRandomShuffle is called, the following is executed:

    Column 1 Column 2 Column 3 Column 4
    OnCase# !activator AddOutput targetname zone_A_death_#


    # is a number from 1-4. As far as my understanding goes, this renames a player from zone_A_death to zone_A_death_#, a more specific name that ties this player to a specific, numbered spawn.

    Also overlapping the spawn room are four trigger_teleporter entities, each one tied to a different filter_activator_name that filters for zone_A_death_#. The teleporters each teleport their respective players to their appropriate info_teleport_destinations.

    Overlapping the Zone A respawn room is another trigger_multiple that resets all players names back to "zone_A_death". In addition, players cannot enter the initial spawn room without crossing a trigger_multiple threshold that changes their names to "zone_initial_death".

    -----

    Any thoughts on why this wouldn't work? (Perhaps I'm misunderstanding one of the entities, or something from A Boojum Snark's post...)

    Also, if it makes any difference, all of the filters had "zone_A_death" in red text, which doesn't sound good... >.>

    EDIT: And if this doesn't work, I'm just going to have all players spawn in the central hub spawn no matter what. I'll just make sure to tighten up the level design. The more I think about it, the less I think I absolutely need this spawn system. (Although, it would still be nice...)
     
    Last edited: Jul 8, 2009
  17. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,527
    Sounds like that would work if you really want to do it... that's just a crapton of entities to work with. Also the red text is normal, that just means Hammer doesn't recognize it, which is true, because entities named that don't exist in Hammer.