Difference between revisions of "Spawn points"

From Armagetron
m (Spawm points moved to Spawn points)
m (tried to wikify this a bit...)
Line 1: Line 1:
Need to investigate:
+
'''Need to investigate'''
--------
+
<blockquote>3) Respawn points can be identified by an attribute. For
[quote]3) Respawn points can be identified by an attribute. For
 
 
example respawning inside a fortress zone is pretty dangerous as
 
example respawning inside a fortress zone is pretty dangerous as
 
it's usually crowed, so the designer might add "respawn points"
 
it's usually crowed, so the designer might add "respawn points"
for each team farther away from it.[/quote]
+
for each team farther away from it.</blockquote>
 +
 
 
Point take, I'll investigate methods to specify if a specific
 
Point take, I'll investigate methods to specify if a specific
 
Spanw is for "game start only" "respawn only" or both.
 
Spanw is for "game start only" "respawn only" or both.
--------
 
  
Controling the spawn points from the map:
+
==Controling the spawn points from the map==
  
 
joda.bot, tell me if you understand properly and if you agree with
 
joda.bot, tell me if you understand properly and if you agree with
Line 27: Line 26:
 
the moment, this is only used in the context of Zones.
 
the moment, this is only used in the context of Zones.
  
Association:
+
==Association:==
 
A team should be associated at least one teamId. A player should
 
A team should be associated at least one teamId. A player should
 
be associated at least one playerId. Should this be impossible to
 
be associated at least one playerId. Should this be impossible to
Line 54: Line 53:
 
assigning multiple id's to the same grabber.
 
assigning multiple id's to the same grabber.
  
Spawning:
+
==Spawning==
 
Members of the same team should be placed on spawn points of the
 
Members of the same team should be placed on spawn points of the
 
same teamId. Should a team has more members than available spawn
 
same teamId. Should a team has more members than available spawn
Line 71: Line 70:
 
controled by an external factor.
 
controled by an external factor.
  
Items:
+
==Items==
 
Items such as Zones can be linked to a teamId and a playerId. If
 
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
 
an Item links to a teamId or a playerId, such id MUST be defined
Line 83: Line 82:
 
all the members of a team are dead.
 
all the members of a team are dead.
  
Syntax in the map:
+
==Syntax in the map==
  
 
A team element may contain player elements and spawn elements.
 
A team element may contain player elements and spawn elements.
Line 96: Line 95:
 
with attribute. Need to pick one.  
 
with attribute. Need to pick one.  
  
<team teamid="1">
+
<team teamid="1">
      <spawn .../>
+
      <spawn .../>
      <spawn .../>
+
      <spawn .../>
      <spawn .../>
+
      <spawn .../>
</team>
+
</team>
<team teamid="A">
+
<team teamid="A">
      <player playerid="Joe">
+
      <player playerid="Joe">
      <spawn ... />
+
      <spawn ... />
      <spawn ... />
+
      <spawn ... />
      </player>
+
      </player>
      <player playerid="lemon">
+
      <player playerid="lemon">
      <spawn .../>
+
      <spawn .../>
      <spawn .../>
+
      <spawn .../>
      </player>
+
      </player>
      <spawn .../>
+
      <spawn .../>
      <spawn .../>
+
      <spawn .../>
</team>
+
</team>
<player playerid="5">
+
<player playerid="5">
<spawn .../>
+
<spawn .../>
<spawn .../>
+
<spawn .../>
</player>
+
</player>
<player playerid="boat">
+
<player playerid="boat">
<spawn .../>
+
<spawn .../>
<spawn .../>
+
<spawn .../>
</player>
+
</player>
<spawn .../>
+
<spawn .../>
<spawn .../>
+
<spawn .../>
<spawn .../>
+
<spawn .../>
 
+
vs
+
vs
 
+
<spawn ... teamId="3" playerId="6"/>
+
<spawn ... teamId="3" playerId="6"/>
<spawn ... teamId="3" />
+
<spawn ... teamId="3" />
<spawn ... playerId="7"/>
+
<spawn ... playerId="7"/>
<spawn ... teamId="1"/>
+
<spawn ... teamId="1"/>
<spawn ... teamId="1"/>
+
<spawn ... teamId="1"/>
<spawn ... teamId="1"/>
+
<spawn ... teamId="1"/>
<spawn ... teamId="A"/>
+
<spawn ... teamId="A"/>
<spawn ... teamId="A" playerId="Joe"/>
+
<spawn ... teamId="A" playerId="Joe"/>
<spawn ... teamId="A" playerId="Joe"/>
+
<spawn ... teamId="A" playerId="Joe"/>
<spawn ... teamId="A" playerId="lemon"/>
+
<spawn ... teamId="A" playerId="lemon"/>
<spawn ... teamId="A" playerId="lemon"/>
+
<spawn ... teamId="A" playerId="lemon"/>
<spawn ... teamId="A" />
+
<spawn ... teamId="A" />
<spawn ... teamId="A" />
+
<spawn ... teamId="A" />
<spawn ... playerid="5"/>
+
<spawn ... playerid="5"/>
<spawn ... playerid="5"/>
+
<spawn ... playerid="5"/>
<spawn ... playerid="boat"/>
+
<spawn ... playerid="boat"/>
<spawn ... playerid="boat"/>
+
<spawn ... playerid="boat"/>
<spawn .../>
+
<spawn .../>
<spawn .../>
+
<spawn .../>
<spawn .../>
+
<spawn .../>

Revision as of 16:48, 22 June 2006

Need to investigate

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.

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

joda.bot, 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>
      <player playerid="lemon">
	      <spawn .../>
	      <spawn .../>
      </player>
      <spawn .../>
      <spawn .../>
</team>
<player playerid="5">
	<spawn .../>
	<spawn .../>
</player>
<player playerid="boat">
	<spawn .../>
	<spawn .../>
</player>
<spawn .../>
<spawn .../>
<spawn .../>

vs

<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 .../>