Spawn points

Revision as of 15:21, 22 June 2006 by Philippeqc (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Need to investigate:

[quote]3) Respawn points can be identified by an attribute. For example respawning inside a fortress zone is pretty dangerous as it's usually crowed, so the designer might add "respawn points" for each team farther away from it.[/quote] Point take, I'll investigate methods to specify if a specific Spanw is for "game start only" "respawn only" or both.

Controling the spawn points from the map:, tell me if you understand properly and if you agree with that stuff.

2 new "fields" have to be introduced to properly control spawn points. A teamId and a personId. They are independant series, ie: teamId="3" is not refering to the same 3 as personId="3".

the id's have 2 tasks. First, they associate spawn points that are equaly owned. 2 or more spawn points sharing an identical id of the same type can be used by the same owner, and only that owner. Second, they associate players and teams with certain game elements. If a game element has an id reference to a personId or a teamId, it is considered to be owned by said team or person. At the moment, this is only used in the context of Zones.

Association: A team should be associated at least one teamId. A player should be associated at least one playerId. Should this be impossible to furfill, the behavior the behavior for teams and players that did not received their respective id's is undefined.

The map can link a playerId to a teamId. A playerId is not required to be linked to a teamId. A teamId can have multiple playerId linked to it. Assigning the same playerId to multiple teamId is not allowed, and a map showing this behavior will be automatically rejected.

A team associated to a specific teamId will take ownership of all the items with said teamId. A teamId can be owned at most by a single team. A team can grab multiple teamId. While it is recommended to do this only when it is possible to balance the teamId's equally among all teams, there are no restrictions on it. When multiple teamId's are grabbed by the same team, they are considered to operate under the same teamId for logic purpose. Items that have a teamId that is not grabbed by any team are considered not to have any teamId, ie. to be common items. Players grabs playerId in the same fashion.

There are no requirement on the method used to assign a teamId to a team, or a playerId to a player, be it for the first id, or when assigning multiple id's to the same grabber.

Spawning: Members of the same team should be placed on spawn points of the same teamId. Should a team has more members than available spawn points, two options are possible. First, the wingman configuration could be used to distribute them. Second, the excess members of the team can be placed on spawn points that aren't associated to any team. This decision need to be controlled by an external factor.

A player can be placed on any spawn point that it owns. A player cannot be placed on a spawn point owned by another player. Should a player re-spawn during the game, two alternatives are possible. First, the player is respawned at the same position that it was at game start. Second, if other spawn points are possible, a new one is selected by an undetermined method. If no other spawn points are available, the old one is reused. This need to be controled by an external factor.

Items: Items such as Zones can be linked to a teamId and a playerId. If an Item links to a teamId or a playerId, such id MUST be defined as part of the map. Maps not respecting this will be automatically rejected. Such linking affect the behavior of the Item, and can be specific of the type of Item.

(Uncertain: an Item can be linked to multiple playerId or teamId?)

Items keep their owner through the match, even if the player or all the members of a team are dead.

Syntax in the map:

A team element may contain player elements and spawn elements. A player element may contain spawn elements. The id's need not to follow any rule other than to be unique in their own series.

(Uncertain: need to confirm for the id's)

Two different ways to write the XML. One with hierarchy, one flat with attribute. Need to pick one.

<team teamid="1">

     <spawn .../>
     <spawn .../>
     <spawn .../>

</team> <team teamid="A">

     <player playerid="Joe">

<spawn ... /> <spawn ... />

     <player playerid="lemon">

<spawn .../> <spawn .../>

     <spawn .../>
     <spawn .../>

</team> <player playerid="5"> <spawn .../> <spawn .../> </player> <player playerid="boat"> <spawn .../> <spawn .../> </player> <spawn .../> <spawn .../> <spawn .../>


<spawn ... teamId="3" playerId="6"/> <spawn ... teamId="3" /> <spawn ... playerId="7"/> <spawn ... teamId="1"/> <spawn ... teamId="1"/> <spawn ... teamId="1"/> <spawn ... teamId="A"/> <spawn ... teamId="A" playerId="Joe"/> <spawn ... teamId="A" playerId="Joe"/> <spawn ... teamId="A" playerId="lemon"/> <spawn ... teamId="A" playerId="lemon"/> <spawn ... teamId="A" /> <spawn ... teamId="A" /> <spawn ... playerid="5"/> <spawn ... playerid="5"/> <spawn ... playerid="boat"/> <spawn ... playerid="boat"/> <spawn .../> <spawn .../> <spawn .../>