http://wiki.armagetronad.org/api.php?action=feedcontributions&user=AndySquirrel&feedformat=atomArmagetron - User contributions [en]2024-03-28T16:33:13ZUser contributionsMediaWiki 1.35.3http://wiki.armagetronad.org/index.php?title=User:AndySquirrel&diff=21444User:AndySquirrel2008-04-14T04:11:34Z<p>AndySquirrel: </p>
<hr />
<div>Does anybody actually read the User pages?<br />
--[[User:AndySquirrel|AndySquirrel]] 21:11, 13 April 2008 (PDT)</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=Map/Config_Rotation&diff=21439Map/Config Rotation2008-04-13T18:35:41Z<p>AndySquirrel: </p>
<hr />
<div>''Tank Program sez'''<br />
<br />
Yesterday morning I comitted some code to CVS (head) that allows for the rotation of maps and or configs through a cycle at the end of a round, match, or not at all. The config items are ROTATION_TYPE, MAP_ROTATION, CONFIG_ROTATION. ROTATION_TYPE is either 0, 1, or 2. 0 is disabled, 1 is round and, 2 is match based rotation. _ROTATION is a semi-colon deliminated list of maps or configs, depending on variable name. So, for MAP_ROTATION,<br />
<br />
<pre><br />
MAP_ROTATION fullpath/name.xml;original/map-1.0.1.xml;<br />
<br />
and then for CONFIG_ROTATION we have<br />
<br />
CONFIG_ROTATION file1.cfg;file2.cfg;<br />
</pre><br />
<br />
Please note in both lists the ending semi-colon, as it is necessary.<br />
<br />
file1.cfg and file2.cfg must be in the config/ directory.</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=Map_Making&diff=21434Map Making2008-04-12T22:22:06Z<p>AndySquirrel: fixed last edit, small rewording</p>
<hr />
<div>Here are some ways to make maps that you can play in Armagetron Advanced.<br />
<br />
== Tutorials ==<br />
<br />
=== [[Making Maps for Beginners|A beginners tutorial]] ===<br />
<br />
This is an alternative tutorial written by kyle and syllabear that's more intended for beginners who haven't dealt with XML before. It basically contains duplicate information as the page below, so for technical matters [[Making Maps by Hand]] should be consulted.<br />
<br />
=== [[Making Maps by Hand|The complete description of the map format]] ===<br />
<br />
This is the only supported way to make maps right now. It is a tutorial that is created by the Map Master himself and hopefully maintained by him (with everyone's help). It is your first and best resource to what exactly goes into a map, how to put it there, and how it works in the game. Even if you choose to use a graphical map maker, you still need to read this, so consider it required reading.<br />
<br />
== Tools and Generators ==<br />
* [[Acme]] — Acme is a currently experimental mostly-doesn't-work graphical map editor that's in Armagetron Advanced's cvs. If you'd like to fool with it, go to this page and read about it, but be warned, it mostly doesn't work.<br />
<br />
* [[ArmaBell's MapEditor]] — ArmaBell's MapEditor is a currently experimental graphical Win32 map editor. If you'd like to fool with it, go to this page and read about it.<br />
<br />
* [http://generalconsumption.org/armagetronad/ellipse-maker/ Ellipse Maker]<br />
* [http://generalconsumption.org/armagetronad/svg2aamap/ SVG2AAMap] — Convert SVG documents to aamaps. See [[http://forums.armagetronad.net/viewtopic.php?t=6311 aaforums:6311]].<br />
<br />
== Viewing Maps ==<br />
<br />
[http://www.generalconsumption.org/armagetron/map-preview/ Map Previewer]<br />
<br />
Nemostultae made a neat little web application that renders a map to a picture right in your browser. When used in conjunction with a text editor, it is a powerful tool to help make maps. In fact, the output of this page is currently considered required information if you want any server administrator to use your map on his server.<br />
<br />
== [[Playing Maps]] ==<br />
<br />
So you've made your killer map, now how do you play it?</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=Map_Making&diff=21433Map Making2008-04-12T22:14:14Z<p>AndySquirrel: Redid the first sentance</p>
<hr />
<div>Here are some ways to make mapsthat you can play in Armagetron Advanced.<br />
<br />
== Tutorials ==<br />
<br />
=== [[Making Maps for Beginners|A beginners tutorial]] ===<br />
<br />
This is an alternative tutorial written by kyle and syllabear that's more intended for beginners who haven't dealt with XML before. It basically contains duplicate information to the page above, so for technical matters [[Making Maps by Hand]] should be consulted.<br />
<br />
=== [[Making Maps by Hand|The complete description of the map format]] ===<br />
<br />
This is the only supported way to make maps right now. It is a tutorial that is created by the Map Master himself and hopefully maintained by him (with everyone's help). It is your first and best resource to what exactly goes into a map, how to put it there, and how it works in the game. Even if you choose to use a graphical map maker, you still need to read this, so consider it required reading.<br />
<br />
== Tools and Generators ==<br />
* [[Acme]] — Acme is a currently experimental mostly-doesn't-work graphical map editor that's in Armagetron Advanced's cvs. If you'd like to fool with it, go to this page and read about it, but be warned, it mostly doesn't work.<br />
<br />
* [[ArmaBell's MapEditor]] — ArmaBell's MapEditor is a currently experimental graphical Win32 map editor. If you'd like to fool with it, go to this page and read about it.<br />
<br />
* [http://generalconsumption.org/armagetronad/ellipse-maker/ Ellipse Maker]<br />
* [http://generalconsumption.org/armagetronad/svg2aamap/ SVG2AAMap] — Convert SVG documents to aamaps. See [[http://forums.armagetronad.net/viewtopic.php?t=6311 aaforums:6311]].<br />
<br />
== Viewing Maps ==<br />
<br />
[http://www.generalconsumption.org/armagetron/map-preview/ Map Previewer]<br />
<br />
Nemostultae made a neat little web application that renders a map to a picture right in your browser. When used in conjunction with a text editor, it is a powerful tool to help make maps. In fact, the output of this page is currently considered required information if you want any server administrator to use your map on his server.<br />
<br />
== [[Playing Maps]] ==<br />
<br />
So you've made your killer map, now how do you play it?</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=International_Tron_World_Cup&diff=21420International Tron World Cup2008-04-09T01:59:11Z<p>AndySquirrel: </p>
<hr />
<div>The tron World Cup is a tournament where all players play for their country, like in the football WorldCup.<br />
It's fortress style, so if you like fortress what are you waiting for to register!!<br />
Every 4 months there is a new edition of the TWC, more info on the [http://lod.bigreddesign.co.uk/twc/ TWC Official Site]</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=Moviepacks&diff=21408Moviepacks2008-04-05T19:50:55Z<p>AndySquirrel: </p>
<hr />
<div>This page will tell you how to create your own moviepacks. See [[Moviepacks list]] for already existing moviepacks. For help installing an already existing moviepack go '''[[Customizing_the_game|here]]'''.<br />
<br />
== Editing and Creating a Moviepack ==<br />
<br />
<br />
== Title ==<br />
*Title.jpeg<br />
<br />
The custom start page before the menu (only works in 2.7 +) (the thunderbolt page when using default textures)<br />
<br />
== Cycle Model ==<br />
*cycle.ase<br />
<br />
The bike model, make one using your favorite 3d modeling system.<br />
<br />
== Cycle Texture ==<br />
*bike.png<br />
<br />
The skin for your bike model. Transperent parts of the image will show the color each player has selected for his bike/wall<br />
<br />
== Player Wall Texture ==<br />
*dir_wall.png<br />
<br />
The skin for player walls. Transperent parts will be invisable in game, White will show the color the player has selected. -note while using colors here is tempting its not recomended as the colors are often distorted in the game.<br />
<br />
== Floor Textures ==<br />
*floor.png<br />
*floor_a.png<br />
*floor_b.png<br />
<br />
Floor.png works like a tile and is tiled across the floor with no variation you can use a small image like 50px50p and tile it or a larger image like 500px500p and stretch it across the entire floor.<br />
<br />
floor_a.png is normally a line just stretched vertically across the floor and floor_b.png the same only stretched horizontaly by combining the two it creates a sharp square grid. There have been people who thought they could use this to create a very sharp unique floor. <br />
<br />
discussion here -http://forums.armagetronad.net/viewtopic.php?t=1708&postdays=0&postorder=asc&start=30<br />
<br />
== Rim(outer)Wall Textures ==<br />
*rim_wall_a.png<br />
*rim_wall_b.png<br />
*rim_wall_c.png<br />
*rim_wall_d.png<br />
<br />
The 4 images are used to make the outer wall make one image and copy it for a look that spans the whole grid or try using 2 patterns for a unique look.<br />
<br />
== Sky ==<br />
*sky.png<br />
<br />
The sky image can help the whole movie pack together in game but not everyone uses a sky so don't depend on it.<br />
<br />
== Settings ==<br />
*Settings.cfg<br />
<br />
Use this to unify the look of your movie pack no matter who uses it<br />
<br />
example<br />
<pre><br />
MOVIEPACK_FLOOR_RED .8 floor color (with moviepack)<br />
MOVIEPACK_FLOOR_GREEN 1 floor color (with moviepack)<br />
MOVIEPACK_FLOOR_BLUE .6 floor color (with moviepack)<br />
<br />
<br />
<br />
MOVIEPACK_WALL_STRETCH 6<br />
<br />
GRID_SIZE_MOVIEPACK 5<br />
</pre><br />
<br />
[[Category:Client Features]]</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=PlayingGettingStarted&diff=21406PlayingGettingStarted2008-04-05T05:51:19Z<p>AndySquirrel: </p>
<hr />
<div>ordronco<br />
{{Sections}} <!-- Template:Sections should be at the top of each section --><br />
<br />
This document attempts to give the minimal set of knowledge required for a player to enjoy the game. <br />
<br />
= Getting ready to play =<br />
Once you start ArmagetronAd, the game will be launched in fullscreen. To be able to follow this document, press "f" to toggle between fullscreen and windowed mode.<br />
<br />
== Select your preferred languages ==<br />
Once the game is started, you will be asked to select your preferred language. Use the right and left arrows to change it. The secondary language is used when a translated text cannot be found in the primary language. Once selected, use the up and down arrows to move to Accept and press return.<br />
<br />
== Hardware detection ==<br />
A screen indicate the 3D hardware found. It us usually properly detected, so feel free to press return to continue. Even if not detected properly, you will still be able to play the game. <br />
You should now be at the main menu, labeled "Armagetron Advance" with the items "Game", "Player Setup", "System Setup", "About" and "Exit Game". Remember this menu, it will be the navigation reference.<br />
<br />
== How to move in the game ==<br />
Before launching into play, here is the minimal keys you will need to know:<br />
*To turn left, press either z, y or w<br />
*To turn right, press x<br />
*While playing, you can always activate the menu by pressing ESC. To stop playing, navigate to "Leave Grid"<br />
*To navigating back to the main menu after leaving the grid, press ESC once more.<br />
Most keyboards in the world, should allow you to use the left most letter on the bottom row of your keyboard to turn left, and the second left most key to turn right.<br />
<br />
== Start playing ==<br />
In its basic form, the game will present you with battling AI. Avoid colliding with the various walls and use the trace you leave behind you to trap and kill the AI. After a few battles, leave the grid and return to this document.<br />
To start playing, from the main menu:<br />
*Select the first item, labeled "Game", and press enter. <br />
*Select the first item, labeled "Local Game", in the new menu, and press enter.<br />
<br />
= Rubber and Grinding =<br />
Battling AI at near constant speed is quite a challenge, but barely allows to overtake a fleeting enemy or to seal another in a closed area for them to die. These strategies and more are enabled through the usage of rubber and the technique of grinding. Together, they constitute the base of the play.<br />
<br />
== [[Rubber]] ==<br />
Rubber allows you to press yourself to a wall, preventing you from crashing into it for a very short period.<br />
<br />
Rubber allows a cycle to near itself to a wall, as if a cushion was laid before it. Press too hard on the cushion and you hit the wall. Turn while you are pressing on it, and you will yourself tightly placed against the wall, leaving little place for someone to follow.<br />
<br />
Each time a cycle uses this cushion, its rubber reserve are consumed. If it reaches its limit, it hits the wall it was pressing on. Coming to a wall at greater speed with consume rubber faster, as pressing to end up tighter with the wall. Normally the cycle will regenerate its own rubber reserve with time.<br />
<br />
== Grinding == <br />
Running a cycle parallel to nearby traces and sometimes walls will accelerate the cycle. The closer you are, the greater the acceleration you get. Useful when attempting to overtake an enemy. Driving between 2 traces will provide greater acceleration.<br />
<br />
Use your gained speed advantage promptly, as with time your cycle will return to its regular speed. Each turn you make will further slow you.<br />
<br />
== Learning Rubber and Grinding ==<br />
The default setting of the game give very little rubber. To help you experiment with rubber, we will raise its limit. We will also lower the basic speed for the cycle so you can more carefully observe how rubber is consumed and practice grinding walls.<br />
<br />
To change game settings, the console is used. The console is a simple text input field that allows you to redefine all the parameters of the game. It is accessible both during play and in any menu. To activate the console, press either the ^ key or the ` key. The text "Con:" should appear the bottom of the screen. There, type the parameter to affect followed by the value desired. The console is case insensitive, so typing "Cycle_speed 10", "cycle_speed 10" or CYCLE_SPEED 10" will produce the same result.<br />
<br />
Now activate the console and write, without the quotes:<br />
"cycle_speed 10"<br />
This will reduce the speed at which the cycle tend to move, giving you more time to think and maneuver. Feel free to adjust to your preference. <br />
<br />
The rubber meter is presented on the lower left part of the screen when you are playing. Note that by default the bar goes from 0 to 1, quite a small reserve of rubber. To change this, you will need to pass the command "cycle_rubber" (without the quotes) followed by a number. <br />
<br />
Activate the console and write, without the quotes:<br />
"cycle_rubber 10"<br />
This will raise the rubber available to all the cycles. Feel free to adjust to your preference.<br />
<br />
Once you have changed the cycle_speed and cycle_rubber settings, practice pressing your cycle agains traces and wall, and getting acceleration by grinding them. In the basic setup, no acceleration is gained from grinding the outer rim even though rubber is consumed when you press on it. Experiment and learn from those settings, but do not to used to them. Such a generous amount of rubber is not often seen on multi-player games.<br />
<br />
It is to be noted that setting changes through the use of the console are not saved. When restarting the game, the original values will be restored.<br />
<br />
=Zones=<br />
Zones are the game elements used in ArmagetronAd. As zones can offer perculiar behavior, this section will give you a rough introduction to them.<br />
<br />
== Win and Death Zones ==<br />
The win and death zones offers instant win and instant death to any cycle who enters them.<br />
<br />
To try them, you will be required to load a new map. To do this, from the console type map_file followed by the name of the map to be used. In this instance, the file name is AATeam/demo/win-1.aamap.xml, so at the console, type "map_file AATeam/demo/win-1.aamap.xml", without the quotes. If you dont have this map already on your system, the game will attempt to download it automatically, so you should probably be connected to Internet when you attempt this.<br />
<br />
On the next round, the arena should hold a green win zone and a red death zone. Experiment with either zones. Note that for your convenience that there are no AI, as they are too subject to the zones. Also, your trace is not of a finite length, allowing you move freedom of movement.<br />
<br />
== Conquest Zones ==<br />
Zones can be configured so it is not the action of entering them that produce the effect, but rather by the cycle being inside the zone, often or a certain amount of time.<br />
<br />
Using the console, type "map_file AATeam/demo/conquest-a-1.aamap.xml". This will load a map containing a single zone. You have to pass a total of 12 seconds in it in total to conquer it. As you conquer it, you should see it turning faster and faster onto itself, giving you a visual representation of the state of the conquest. Once conquered, the zone collapse and the round is won.<br />
<br />
Now load the map named "AATeam/demo/conquest-b-1.aamap.xml". This time, your conquest of the zone gets eroded with time, meaning that if a partially conquered zone is left alone for a while, it will return to its original status and you will have to re start the conquest. Do not worry, the conquest rate is in your favor at a rate of 4:1. It would take 4 seconds outside of the zone to loose the conquest generated from 1 second inside the zone. Experiment with this zone until you are comfortable with the conquest and decay concepts. Note that when totally left alone, the zone simply turn at its lowerst original rate, indicating that the conquest of this zone has been reset to nothing.<br />
<br />
This time the zone is configured in a way that it is the natural decay of the zone that conquers it. Left alone, the zone will naturally conquer itself and you will lose. To prevent this, passing time inside the zone will actually annulate the decay. Again, the odds are in your favor in a 4:1 rate. Each second passed inside will annulate 4 seconds of natural decay. So keep on your guards and do not wander too far. This map is named "AATeam/demo/conquest-c-1.aamap.xml".<br />
<br />
In multi-player setups, the following names can be encountered:<br />
- Fortress: Each team have to defend their own zone while trying to conquer the enemy's. The decay usually move the status of the zone toward non conquered.<br />
- Sumo: Multiple zones surimposed with decay set to conquer the zone. Each player has to fight the other players for some space under the common zones in to prevent his own zone of being conquered, or face certain death.<br />
<br />
= Multi player =<br />
Beside rudimentary AI, the ArmagetronAd games allow you to compete again other player on the same computer, on a LAN or over Internet. <br />
<br />
== Connecting to a LAN server ==<br />
For the main menu, navigate to "Game". There select "Network Game" and then "LAN Game". The game will query the local network (LAN) for any server, and present them in a list. <br />
<br />
It is possible to use the client to host a server. From the list of local servers, click on "Host Game" and then "Host Network Game". Your copy of ArmagetronAd will allow you to server as a server for other to connect to, while letting you join in the action. The server will run until you exit the menu. <br />
<br />
== Connecting to an Internet server ==<br />
For the main menu, navigate to "Game". There select "Network Game" followed by "Internet Game". The application will start querying different servers from all around the world and present you with a list of servers with a few details. It is strongly advised that you read the short description presented for each server at the bottom of your screen. It often gives you valuable information about the server you are about to join.<br />
<br />
Selecting one will connect you to it. More information might be presented to you during the connection operation. Read it carefully as it often describe the type of game you are about to try. And dont forget to communicate with the other players present using the chat capacity of the game, available on the 's' key.<br />
<br />
Internet access is of course required for this.<br />
<br />
== Type of play ==<br />
The dynamic of the game will be decided by the settings in use. These settings and resulting combinations are too various to cover here. Also, when connecting to a LAN based server or an Internet based one, the server will decide of the configuration.<br />
<br />
One rough categorization is possible: Free for all versus Team Play.<br />
<br />
When in doubt, do not hesitate to communicate with the other players. Chat capacity is associated with the key 's'. <br />
<br />
=== Free for all ===<br />
In this type of play, all the players compete against each others. It is left to you to make the best use of your cunning, reflexes, experience and even ad-hoc alliances to raise yourself to the top.<br />
<br />
=== Team Play ===<br />
In this type of play, cooperation between members of a team will usually produce better results than having everybody trying to accomplish the same goals. Often, individualism will actually harm your team mates, and incite their fury toward you. Be observant when joining a server, your team mates might be relying on you and ignoring them might cause great troubles.</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=Development_Docs&diff=21405Development Docs2008-04-04T23:30:26Z<p>AndySquirrel: </p>
<hr />
<div>{{Sections}} <!-- Template:Sections should be at the top of each section --><br />
<br />
This is documentation for developers or for people who just want to hack on the code. It is not intended to replace the automatic API documentation generated by doxygen (we do have a doxyfile, right?), but is intended to supplement those documents with additional information that may not necessarily appear in the API docs. It is also not intended as a substitute for good commenting tactics. And finally, it is a place to put planning documentation (like the stuff Philippe writes), proposals, RFC-type material, and so forth. But not the roadmap, we use Sourceforge's tracker for that.<br />
<br />
== Documentation ==<br />
<br />
* [[Wiki Structuring Project]]<br />
* [[Wiki Development Project]]<br />
<br />
== Building the Game ==<br />
<br />
Building Armagetron Advanced boils down to 4 basic steps. The steps themselves are each highly platform-dependent, but the four steps are the same everywhere. Each step differs further in whether or not you're building from a branch or the trunk, and each branch may differ. Finally, each step differs depending on if you're building a source release or from version control. Here we'll concern ourselves with building the trunk only. Releases should include their own build instructions.<br />
<br />
# Install the development environment<br />
# Satisfy dependencies<br />
# Unpackage source/source checkout from version control<br />
# Build a distribution<br />
<br />
Platform-specific instructions (they should all follow the four step structure given, that's why it's there!):<br />
<br />
* [[Windows Development]]<br />
* Linux<br />
* Mac OS X<br />
<br />
todo: the linux and mac os x pages<br />
<br />
== Other useful hacker documentation ==<br />
<br />
* [[Windows Development System]]<br />
* [[Working with SVN]]<br />
* [[Cross-compiler]]<br />
* [[Used Libraries]]<br />
* [[Working with SVK]]<br />
* [http://wrtlprnft.ath.cx/doxy/html/ Doxy]<br />
<br />
== Stuff That's Current ==<br />
<br />
* [[Config Item Purposes]]<br />
* [[Debug Recording]]<br />
* [[Error Handling]]<br />
* [[List of nDescriptors]]<br />
* [[Project Dependency Structure]]<br />
* [[Adding a buildslave]]<br />
<br />
== Stuff in SVN HEAD ==<br />
<br />
* [[Embedded Web Server]]<br />
* [[Map/Config Rotation]]<br />
* [[Particle System]]<br />
* [[Joda's Team Code]]<br />
* [[New Sound Engine]]<br />
* [[Spawn points]]<br />
* [[Zones v2]]<br />
<br />
* [[Cockpit Tutorial]] | [[Cockpits list]]<br />
* [[vValue]]<br />
<br />
== Data File Handling ==<br />
<br />
* [[Config Files]]<br />
* [[Resource System]]<br />
* [[Statistical Collections Database]] (fancy way of saying "stat files")<br />
<br />
== Source Control ==<br />
<br />
* [[Bazaar]] and how we use it<br />
<br />
== Stuff That's Real but doesn't fit above ==<br />
<br />
* [[Experimental Map Features]]<br />
* [[Send DTD on the resource repository through ssh]]&mdash;only of interest for people on the development team<br />
<br />
== Wishlist, or Stuff that's planned ==<br />
<br />
(Might not be planned, but this is it)<br />
<br />
* [[Goals]]<br />
* [[Scripted GUI Notes]]<br />
* [[Authentication]]<br />
* [http://forums.armagetronad.net/viewtopic.php?t=986 Reshaping the Arena]<br />
* [http://forums.armagetronad.net/viewtopic.php?t=1742 Map format]<br />
<br />
== History ==<br />
<br />
This is stuff that's of historical significance to the project. It's very difficult to remember where you're going if you don't remember where you came from, right? This is technical stuff. Community history should have its own section.<br />
<br />
* [[What Went Wrong in Armagetron]]<br />
<br />
{{Sections}} <!-- Template:Sections should be at the top of each section --><br />
{{Category:Development}}</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=Making_Maps_by_Hand&diff=21397Making Maps by Hand2008-04-04T01:07:54Z<p>AndySquirrel: </p>
<hr />
<div>This tutorial is to help map designer to get a grasp of the Map<br />
format used by Armagetron Advanced.<br />
<br />
This version of the tutorial address the syntax defined by map-0.2.8_beta3.dtd and present the rules of interpreting the syntax as used by the parsing engine in the version 0.2.8 of Armagetron Advanced.<br />
<br />
== Format overview ==<br />
<br />
The classic Armagetron arena could be described with the following<br />
map:<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
<Resource type="aamap" name="square" version="1.0.1" author="Anonymous" category="polygon/regular"><br />
<Map version="0.2.8"><br />
<!-- The original square map, technically created by z-man.<br />
Converted to XML by philippeqc.<br />
License: Do with it what you want. --><br />
<br />
<World><br />
<Field><br />
<Axes number="4"/><br />
<br />
<Spawn x="255" y="75" xdir="1" ydir="1" /><br />
<Spawn x="245" y="450" xdir="0" ydir="-1" /><br />
<Spawn x="50" y="245" xdir="1" ydir="0" /><br />
<Spawn x="450" y="255" xdir="-1" ydir="0" /><br />
<br />
<Spawn x="305" y="100" xdir="0" ydir="1" /><br />
<Spawn x="195" y="400" xdir="0" ydir="-1" /><br />
<Spawn x="100" y="195" xdir="1" ydir="0" /><br />
<Spawn x="400" y="305" xdir="-1" ydir="0" /><br />
<br />
<Spawn x="205" y="100" xdir="0" ydir="1" /><br />
<Spawn x="295" y="400" xdir="0" ydir="-1" /><br />
<Spawn x="100" y="295" xdir="1" ydir="0" /><br />
<Spawn x="400" y="205" xdir="-1" ydir="0" /><br />
<br />
<Wall><br />
<Point x="100" y="100" /><br />
<Point x="500" y="500" /><br />
<Point x="500" y="500" /><br />
<Point x="500" y="500" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
</Field><br />
</World><br />
</Map><br />
</Resource><br />
</pre><br />
<br />
The Map format start with a XML header. The actual definition<br />
of the Map is wrapped in a Resource. The Resource gives a<br />
description of the content, such as the author and the version of<br />
the map included. This particuliar map is the xml version of the<br />
original map that supported directly in the game before version<br />
0.2.8 (Arthemis). <br />
<br />
Skipping ahead in to the Field element, line 11 defines that <br />
that 4 axes are to be<br />
used. From line 13 to 26, all the spawn points, ie: the points where<br />
the cycles are located when the match starts, are defined. Finally<br />
the walls are defined, delimiting the play area.<br />
<br />
== Header ==<br />
The header of the map can nearly be considered as constant. It is<br />
composed of 2 lines.<br />
<br />
Header for Arthemis' maps:<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "AATeam/map-0.2.8.0.dtd"><br />
</pre><br />
<br />
The only element you need to consider is the name of the dtd. The<br />
dtd should always be named after the version it targets. For<br />
Arthemis, it should be "map-0.2.8.dtd". <br />
<br />
Note: during the beta process, version can change often and have<br />
great difference between them. To limit the scope of the problem<br />
during the beta phase, the name of the dtd should include the beta<br />
it targets. <br />
<br />
Header for the beta 3 of Arthemis' maps:<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
</pre><br />
<br />
== Resource ==<br />
The Resource element describe some meta-information of the Map,<br />
such as who created it, how should the resource file be named and<br />
what type of information is to be expected.<br />
<br />
One part of the Resource details describe who made this map a<br />
reality. In the Resource element, it is possible to differenciate<br />
between the person that comissioned the map, the<br />
commisionner, and the person who executed the request and coded<br />
it, the author. <br />
<br />
Both operations might be carried by the same and only person, in<br />
this instance both entities are the same and the commissioner<br />
field should be left blank. The commissioner field should be used<br />
when the concept of a map and its execution are performed by two<br />
different persons or entities. It could range from anything from<br />
"could someone make a map where the feeling of <X> is emphased" to<br />
coding from a hand-drawn sketch. The commissioner could also be<br />
implied. Without him/her ever placing an open request, a<br />
commisioner could be assigned to a map when the author wants to<br />
express an assumed sharing of the creation of the map. This can be<br />
the case, for example, when the member of a Clan wrote a map that<br />
falls in the ideals of the Clan.<br />
<br />
Maps can be implicitly grouped together. The category field is<br />
there for this purpose. Prolific authors and their public will<br />
appreciate a clear grouping of similar themed maps.<br />
<br />
As ever refining one's work is a very respected quality in the<br />
Armagetron community, the latest changes need to be properly<br />
propagated to everybody. The version field allow an author to<br />
identify each specific instance of his/her work, and also insure that<br />
a client will receive the exact version used by a server when<br />
playing on it.<br />
<br />
The type specifies that the file holds an Armagetron Advanced<br />
map. While this is the only type available at the moment, the<br />
development team is eager to expand this in the furture.<br />
<br />
Finally, and most importantly, the name of the ''ouvrage'' being<br />
presented. <br />
<br />
The fields for Resource are:<br />
;name<br />
:The name of the map, mandatory.<br />
;type<br />
:The only valid type is "aamap". This field is defaulted "aamap" when absent.<br />
;version <br />
:The version of the map described in this particuliar file. This value needs to be modified each time a change is applied to the map to ensure everybody have the proper copy.<br />
;author<br />
:The current maintainer of this map, usually the author who produced it. This either should be a user name registered with the central resource repository, or, for lone wolves who don't want to register, a valid email address encoded in the spambot safe as "unofficial/mailto/<Domain>/<User>", where "<User>@<Domain>" would be the address.<br />
:This field is defaulted to "Anonymous" when absent.<br />
;commisioner<br />
:The entity who dreamt, requested or inspired this map in any way. This field is optional and has no default value. <br />
;category<br />
:How this map should be categorised. This field can have any number of sub categories, each separated by a "/" (a forward slash). An example could be "category/subcategory/subsubcategory". This field is defaulted to "unsorted" when absent. <br />
<br />
Example: The castle map made by philippeqc<br />
<pre><br />
<Resource name="Castle" type="aamap" version="1.1" author="philippeqc" category="examples"><br />
...<br />
</Resource><br />
</pre><br />
<br />
Example: The StarTron ("5ptstar") map made by Your_mom (note that while 'beta' is more or less correct for the 'version' attribute, it should not be in the 'category' as it is here)<br />
<pre><br />
<Resource name="5ptstar" version="beta" author="Your_mom" category="beta" type="aamap"><br />
...<br />
</Resource><br />
</pre><br />
<br />
Example: The MBC training map, made by Zorgul<br />
<pre><br />
<Resource name="TrainingDay" version="1.6" author="Zorgul" category="MBC" type="aamap" commisioner="Micro Bus City"><br />
...<br />
</Resource><br />
</pre><br />
<br />
Example: The Reverso map, writen by Nemosultra based on a drawing by lucifer, for the Crack Pipe server<br />
<pre><br />
<Resource name="Reverso" version="1.1-b" author="Nemosultra" category="CrackPipe" type="aamap" commisioner="lucifer"><br />
...<br />
</Resource><br />
</pre><br />
<br />
To facilitate manipulation of the file over distributed systems,<br />
the Resource holds explicit information about the naming and<br />
storing of the file. This information can be used by tools such as<br />
scripts and resource repositories to manipulate the file. <br />
<br />
A resource has a unique filepath determined by these attributes. The resource must be the ''only'' one to ever appear as this filepath and any changes must affect the 'version' and the person making the change must place their name in the 'author' attribute unless given permission by the original author.<br />
<br />
The filepath is formed by the attributes in the following syntax:<br />
<br />
<Author>/[Category/]<ResourceName>-<VersionNumber>.<ResourceType>.xml<br />
<br />
== Map ==<br />
This element is the basic holder of the description of the<br />
Map. From the opening element to the closing one, all the<br />
information will be used to construct an in-game representation<br />
for the players to explore and possibly compete in.<br />
<br />
The version attribute of the map indicates a specific parsing<br />
engine version that should be used to express the map in the exact<br />
manners that are desired by the map creator. <br />
<br />
Example: Map element<br />
<pre><br />
<Map version="0.2.8"><br />
...<br />
</Map><br />
</pre><br />
<br />
Sooner in the file,<br />
the dtd has already specified a version. The difference between<br />
both version is one specify the version of the syntax to be use,<br />
and the other, the version of the rules to be used to interprete<br />
the syntax.<br />
<br />
The dtd controls the syntax, what keywords are valid and in what<br />
arrangement. The parsing engine has specific rules how to read the<br />
syntax and create the game elements. It is possible for different<br />
parsing engines to operate from the same syntax, be it because the syntax<br />
allows for many interpretations, or because a specific<br />
interpretation has been found faulty in some case. Because each<br />
interpretation could lead to very different instantiation, it is<br />
best for the map designer to specify the one that should be<br />
used. Even when no alternative interpretation exist, ie: there is<br />
only one version available, it is best for the map designer to<br />
specify it. Should a new one be implemented at a later time, the<br />
map defined would continue to be instanciated properly.<br />
<br />
At the time of writing, the only parsing engine version is<br />
"0.2.8". Maps using a version that is not understood by the<br />
parsing engine of a specific client or server will be<br />
automatically rejected by said application, on the ground that the<br />
parsing engine doesn't know how to operate on it.<br />
<br />
Even if only one value exists, it is impossible to provide it as a<br />
default, as there are no assurance that a new interpretation of<br />
the syntax will not arrive at a future time.<br />
<br />
== Settings ==<br />
It is possible for a map designer to indicate specific game<br />
settings, similar to the ones available through the configuration<br />
files of the application, to be used with the map. When<br />
this is not desired, the Settings element can be safely removed<br />
from the map definition.<br />
<br />
Any number of Setting can be defined inside of the Settings<br />
element. Each Setting defined will overwrite the value previously<br />
defined in the game. Each new Setting addressing a specific<br />
configuration item will keep on overwriting previously defined<br />
values. The Settings items are processed in order, from the top to<br />
the bottom one.<br />
<br />
The Settings should be considered to be global to the World and<br />
its sub-elements. This has very little relevance at the moment as<br />
only one World and one Field can exist in the game. It is not<br />
excluded that future version of the game could support multiple<br />
elements such as World and Field. Each such elements and sub-elements would<br />
receive the Settings defined in its parents, but would also be<br />
able to overwrite parent received Settings for itself and its<br />
sub-elements. <br />
<br />
One such overwriting capacity already exists, in the form of the<br />
Axes element. This element can and will overwrite the value passed<br />
by the Setting ARENA_AXES.<br />
<br />
At the time of writing, there are no known cases where the order of<br />
writing Settings should matter. There are no garanties of this being<br />
the case. Be carefull of the order of the Settings provided.<br />
<br />
<pre><br />
<Settings><br />
<Setting name="a" value="1"/><br />
<Setting name="b" value="2"/><br />
<Setting name="c" value="3"/><br />
</Settings><br />
</pre><br />
<br />
The Settings element is inserted in the Map element, before the World element.<br />
<br />
<pre><br />
<Map ...><br />
<Settings><br />
...<br />
</Settings><br />
<World><br />
...<br />
</World><br />
</Map><br />
</pre><br />
<br />
== Setting ==<br />
Each individual Setting defines a specific element normally<br />
configurable throught the config files of the game<br />
application. For a full list and description of the setting<br />
available, consult the [[Console Commands]] page. As config items<br />
are the same as console commands, you will find all the<br />
information there.<br />
<br />
The Setting has two attributes, the name and the value. The name<br />
field hold the setting name as found in the various configuration<br />
files. The value field will be assigned to the designated setting.<br />
<br />
<pre><br />
<Setting name="CYCLE_BRAKE_REFILL" value=".1"/><br />
</pre><br />
will assing .1 to the configuration item CYCLE_BRAKE_REFILL.<br />
<br />
No validation is done on any fields by the parsing engine. The<br />
values are passed directly to the setting engine, where the usual<br />
validation is performed. Unexisting or misspelled settings names<br />
will be ignored. Setting with valid names and invalid values have<br />
an undetermined effect.<br />
<br />
The different Settings used have the potential of overwriding<br />
client or server ones. While this behavior offers great capacity<br />
to custom behavior for a specific map, users playing locally on<br />
their machine and server administrator might find it a disruption<br />
of their craftfully designed settings. Use with care and<br />
moderation.<br />
<br />
== World ==<br />
At this moment, the element possible inside of the World element is<br />
the Field element. Only one Field can be defined. No parameters<br />
are available at the moment.<br />
<br />
<pre><br />
<World><br />
...<br />
</World><br />
</pre><br />
<br />
== Field ==<br />
The Field element holds the description required to construct the<br />
play area. Inside the Field, Axes, Spawn and Wall elements can be<br />
defined. <br />
<br />
The field defines the zone on a 2D plane where the gaming can<br />
occur. The full support of this definition will be developed under<br />
Bacchus. In Arthemis, the old philosophy of "the play zone has to<br />
be bounded by walls" is somewhat preserved. A secondary mechanism<br />
also exist to prevent the players from escaping the rim. This is a<br />
bried description of the mechanism used.<br />
<br />
While setting all the walls to be used during a round, the engine<br />
will keep track of the minimal and maximal x's and y's values<br />
encountered through wall coordinates.<br />
A logical box will be formed, using the coordinate<br />
(minX, minY), (maxX, minY), (maxX, maxY) and (minX, maxY) as its<br />
corners.<br />
<br />
Example: Logical box around the classical arena.<br />
The classical arena has the coordinates (0,0), (0,500), (500,500)<br />
and (500, 0). This means that minX=0, minY=0, maxX=500 and<br />
maxY=500.<br />
<br />
Example: Logical box around a square arena moved by 20 on the x's.<br />
The classical arena has the coordinates (20,0), (20,500), (520,500)<br />
and (520, 0). This means that minX=20, minY=0, maxX=520 and<br />
maxY=500.<br />
<br />
Example: Logical box around a trapazoid arena.<br />
A trapazoid has a base lenght of 300, a top length of 200 and a<br />
height of 200 with the following coordinates: (0, 0), (300, 0),<br />
(250, 200), (50, 200). This means that minX=0, minY=0, maxX=300,<br />
maxY=200.<br />
<br />
Example: Logical box around 2 walls of the classical arena.<br />
Should the south and west walls of the classical arena be ommited,<br />
and only the north (from (0,500) to (500,500)) and east one (from<br />
(500,0) to (500,500)) remain, the logical box is still the same<br />
around it. This means that minX=0, minY=0, maxX=500 and<br />
maxY=500.<br />
<br />
Example: 2 walls at strange angle<br />
If two walls, organized at strange angle and not even meeting,<br />
compose the arena, are described as (200,200) to (600, 400) and<br />
(350, 350) to (-10, 720). This means that minX=-10, minY=200,<br />
maxX=600 and maxY=720.<br />
<br />
A no-motion logical box will be put at 10 game units outside of the<br />
logical box. Should a player meet this no-motion zone, she will<br />
find herself pushing agains a coussin of air. Rubber has undefined<br />
effect agains this no-motion box.<br />
<br />
A second logical box will be put at 20 games units from the first<br />
logical box. Should any players be outside of this logical box,<br />
they are automatically killed.<br />
<br />
In game terms, should the players not be bounded by a continous<br />
wall, they are free to roam around it but they will find an<br />
invisible barrier keeping them from excaping into the infinite.<br />
<br />
Should you want to allow your players to roam without<br />
restrictions, exploring the infinity of the grid, you have to<br />
specify to use an infinite field.<br />
<br />
The Field supports a single parameter, named logicalBox, which<br />
controls if the logical box should be used to limit roaming on the<br />
Field. <br />
;logicalBox<br />
:When set to true, the motion will be restrained by the logical box, and when set to false, no logical box will be used. This field is optional and default to true.<br />
<br />
Example: Logical box bounded Field<br />
<pre><br />
<Field><br />
...<br />
</Field><br />
</pre><br />
<br />
Example: Field with its logical box disabled<br />
<pre><br />
<Field logicalBox="false"><br />
...<br />
</Field><br />
</pre><br />
<br />
The following 2 paragraphs are post map-0.1 and 0.2.8_beta2.<br />
<br />
For clarity purposes, the Axes element, if defined, need to be<br />
defined first. After this, Spawn point, Walls and Zones can be<br />
defined in any order.<br />
<br />
While a Field without any Spawn points is syntaxly valid, and<br />
the parsing engine doesnt report any error, the effect is<br />
undetermined. While a Field without any Wall is syntaxly valid,<br />
and the parsing engine doesn't report any error, the effect is<br />
undetermined.<br />
<br />
== Axes ==<br />
The Axes element defines how the cycles will behave on this<br />
particular Field. The original Armagetron used 4 axes. <br />
<br />
The Axes element has 2 fields:<br />
;number<br />
: This specifies the number of axes that should be used. If not specified, 4 axes are assumed.<br />
;normalize<br />
:When set to true, it specifies that the game should ensure that the direction vectors are scaled to have a size of exactly 1.0. When not specified, the individual axis will be keep at the exact length they are specified. This is covered in section 6. When not specified, it is assumed that normalization is desired.<br />
<br />
<Axes number="6" normalize="true"/><br />
<br />
When used without any other information, it is assumed that equally spaced axes should be generated, starting from (1,0) and going clockwise. The number generated is the value specified by the number attribute.<br />
<br />
The Axes element can also be used to describe each direction that can be used, instead of relying on the automatic generation. To do this, Axis elements are used to describe each direction.<br />
<br />
<pre><br />
<Axes number="4"><br />
<Axis xdir="1" ydir="1"/><br />
<Axis xdir="1" ydir="-1"/><br />
<Axis xdir="-1" ydir="-1"/><br />
<Axis xdir="-1" ydir="1"/><br />
</Axes><br />
</pre><br />
<br />
The Axis element uses the following fields:<br />
;xdir<br />
: This is the size of the displacement along the x's for this axis.<br />
;ydir<br />
: This is the size of the displacement along the y's for this axis.<br />
;angle<br />
: This allows to describe the Axes in degrees.<br />
;length<br />
: When the angle is specified, the length can be used to scale the size of the vector described. This value is only used when angle are specified.<br />
<br />
If the angle field is found, the length will be queried and used. If the length is absent, a default of 1 is used for the length. If no angle is specified, then both the xdir and ydir need to be specified for the Axis to be valid.<br />
<br />
The previous example could be re-written with:<br />
<pre><br />
<Axes number="4"><br />
<Axis angle="45" length="1.4142"/><br />
<Axis angle="135" length="1.4142"/><br />
<Axis angle="225" length="1.4142"/><br />
<Axis angle="335" length="1.4142"/><br />
</Axes><br />
</pre><br />
<br />
Note that even though the length is specified, because the Axes element doesn't have the normalize="false", all the lengths will be scaled back to exactly 1.<br />
<br />
The Axes should be specified in clockwise order. The specified axes are stored in the order they appear. When a player want to turn right, it is passed to the next axis on the list, or to the first when turning from the last direction.<br />
<br />
You might observe that in Example 5.2, the directions sum up to more than 1.0. For example, the first Axis has a xdir and a ydir of 1. The real length of the described Axis is <br />
<math>\sqrt{xdir^2+ydir^2}</math><br />
, which is approximately 1.4142. By specifying the normalize="true", or using the default behavior, you ensure that they are scaled back to 1.0.<br />
<br />
The number of Axis specified should be the same as the number of axes. Any extra axes will be discarded. Any missing Axis will be assumed to be (1,0). <br />
<br />
Note: Some old maps will use Point instead of Axis. The Point is deprecated in this context. New maps should use the Axis element.<br />
<br />
== Advanced Axes ==<br />
<br />
=== Normalization ===<br />
<br />
It is often easier to write directions are (2,1) rather than<br />
(.89442719099991587856 , .44721359549995793928), which is the<br />
normalized equivalent. The normalization mechanism ensure that<br />
displacement is constant on all the axes. This has always been the<br />
behavior of the game. So what is the effect of having non normalized<br />
Axis? Before anything else, a bit of understanding how the engine of<br />
Armagetron operates might be required. <br />
<br />
You might recall from your physics class that the distance traveled is<br />
computed from the speed at which you travel multiplied by the time<br />
during with you traveled ie: distance = speed * time.<br />
<br />
Armagetron has at its core a 2D engine. Vehicles move along a 2D<br />
surface, changing their x and y positions. To find the new position<br />
of a vehicle, the distance is multiplied by a 2D vector, the<br />
direction, before being added to the old position. Because the<br />
direction is a normalized vector, the resulting displacement is of the<br />
same size than the calculated distance. But if the direction is a<br />
non-normalized vector, ie: it has a size that is lesser or greater<br />
than 1, but not equal, then the displacement gets to have a different<br />
size than the distance.<br />
<br />
By setting the Axis to non-normalized values, the map designer can<br />
modify displacement in the arena. By defining Axis with a vector size<br />
of 2, see example 6.1.1, all the cycles would behave as if they where<br />
moving twice as fast. Setting the Axis a length of 0.5, see example<br />
6.1.2, the opposite effect occurs. Now the cycle move as if their<br />
speed was halved.<br />
<br />
Example: Axes of size 2<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="2"/><br />
<Axis xdir="2" ydir="0"/><br />
<Axis xdir="0" ydir="-2"/><br />
<Axis xdir="-2" ydir="0"/><br />
</Axes><br />
</pre><br />
<br />
Example: Axes of size 0.5<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="0.5"/><br />
<Axis xdir="0.5" ydir="0"/><br />
<Axis xdir="0" ydir="-0.5"/><br />
<Axis xdir="-0.5" ydir="0"/><br />
</Axes><br />
</pre><br />
<br />
By setting the normalize attribute to false, the designer ensures<br />
that the game will use the Axis values as is. While this section has<br />
used Axes that all have the same size, this is not a requirement. The<br />
next section will explore setting Axis with different sizes.<br />
This permits affecting the displacement on certain axes.<br />
<br />
=== Uneven Axes ===<br />
Up to now, the Axis have always have the same size. This mean that for<br />
a given speed, the displacement of a cycle is always the same in every<br />
direction. But nothing prevents you from defineing it differently. <br />
<br />
Imagine an arena shaped as a rectangle. The height, along the y's,<br />
would be ten times the size of the length, along the x's. Normally, with<br />
the Axis all of the same size, it would take a player ten time as long to<br />
run from one wall to another when cruising along the height of the<br />
rectangle. <br />
<br />
But you could decide to make motion along the height occur at ten time the<br />
rate, so it would take a player the same time to cover the height of<br />
the arena than to cover the length, giving it an "Alice in Wonderland"<br />
feeling (see example 6.2.1). This feeling could be exaggerated even more<br />
by making traveling along the longest distance occur in half the time<br />
that travel along the shortest distance. To do this, you could double<br />
the size of the Axis set in the previous example (see example<br />
6.2.2). Now, even though one dimension of the rectangle is 10 times that of the<br />
other, traveling along this longer dimension occurs at a much higher rate,<br />
compressing this dimension in the player's mind.<br />
<br />
Example: Rectangle of equal travel time<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="10"/><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="-10"/><br />
<Axis xdir="-1" ydir="0"/><br />
</Axes><br />
<Wall><br />
<Point x="0" y="0"/><br />
<Point x="100" y="0"/><br />
<Point x="100" y="1000"/><br />
<Point x="0" y="1000"/><br />
<Point x="0" y="0"/><br />
</Wall><br />
</pre><br />
<br />
Example: Rectangle of compressed travel time<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="20"/><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="-20"/><br />
<Axis xdir="-1" ydir="0"/><br />
</Axes><br />
<Wall><br />
<Point x="0" y="0"/><br />
<Point x="100" y="0"/><br />
<Point x="100" y="1000"/><br />
<Point x="0" y="1000"/><br />
<Point x="0" y="0"/><br />
</Wall><br />
</pre><br />
<br />
The current game play is balanced around the fact that normally,<br />
the displacement factor is of size 1. By increasing this too much, your<br />
map might quickly become unplayable. While the example present Axis<br />
size of 10's and 20's, it is only for a pedagogical value. If you want<br />
to create great difference of displacement among different Axis, you<br />
might find that augmenting Axes size a little bit and raising others<br />
also could produce a better effect. The following example offers a ratio of<br />
6 between the displacement on the x's and y's, while keeping the faster<br />
displacement at only 3 times the regular one. This reduce the<br />
effect of playing at very high speed while having a huge<br />
difference between directions.<br />
<br />
Example: Factor of 6 between displacement, centered around a speed<br />
of ~1.<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0.5" ydir="0"/><br />
<Axis xdir="0" ydir="-3"/><br />
<Axis xdir="-0.5" ydir="0"/><br />
<Axis xdir="0" ydir="3"/><br />
</Axes><br />
</pre><br />
<br />
Example: Factor of 6 between displacement, centered around a speed<br />
of ~3<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="-6"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0" ydir="6"/><br />
</Axes><br />
</pre><br />
<br />
While the ratio of speed is the same between both examples, the<br />
later one has speed that might be difficult to control in one<br />
direction. The first example produce the same difference, but<br />
present the players with a more balanced alternative.<br />
<br />
Up to now, the Axes where always evenly placed around the<br />
player. Distributing the Axes in a non-equal fashion can allow for<br />
different kind of game play. If you where to make a parallelogram<br />
shaped arena, you might want the players to be able to move along the<br />
walls of the arena. For this, the different Axis would need to be<br />
properly set. <br />
<br />
Example: Parallelogram arena<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="1"/><br />
<Axis xdir="1" ydir="0.5"/><br />
<Axis xdir="0" ydir="-1"/><br />
<Axis xdir="-1" ydir="-0.5"/><br />
</Axes><br />
<Wall><br />
<Point x="0" y="0"/><br />
<Point x="100" y="50"/><br />
<Point x="100" y="150"/><br />
<Point x="0" y="100"/><br />
<Point x="0" y="0"/><br />
</Wall><br />
</pre><br />
<br />
=== Order of the axes ===<br />
Turning right is translated to passing to the next axis, and<br />
turning left to the previous axis. But by changing the order that<br />
the axes are defined, this behavior can be altered.<br />
<br />
Example: 6 Axis in cartesian, in the order 4, 5, 6, 1, 2, 3<br />
<pre><br />
<Axes number="6" normalize="true"><br />
<Axis xdir="-0.5" ydir="-0.866025404"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="-0.5" ydir="0.866025404"/><br />
<Axis xdir="0.5" ydir="0.866025404"/><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0.5" ydir="-0.866025404"/><br />
</Axes><br />
</pre><br />
<br />
Example: 6 Axis in degrees, in the order 4, 5, 6, 1, 2, 3<br />
<pre><br />
<Axes number="6"><br />
<Axis angle="210"/><br />
<Axis angle="270"/><br />
<Axis angle="330"/><br />
<Axis angle="30"/><br />
<Axis angle="90"/><br />
<Axis angle="150"/><br />
</Axes><br />
</pre><br />
<br />
Both define a regular 6 axes. Turning right will make the cycle<br />
face a direction that is 60 degrees to its right. But by changing<br />
the order, this can be altered.<br />
<br />
Example: 6 Axis in cartesian, in the order 4, 6, 5, 1, 3, 2<br />
<pre><br />
<Axes number="6" normalize="true"><br />
<Axis xdir="-0.5" ydir="-0.866025404"/><br />
<Axis xdir="-0.5" ydir="0.866025404"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0.5" ydir="0.866025404"/><br />
<Axis xdir="0.5" ydir="-0.866025404"/><br />
<Axis xdir="1" ydir="0"/><br />
</Axes><br />
</pre><br />
<br />
Example: 6 Axis in degrees, in the order 4, 6, 5, 1, 3, 2<br />
<pre><br />
<Axes number="6"><br />
<Axis angle="210"/><br />
<Axis angle="330"/><br />
<Axis angle="270"/><br />
<Axis angle="30"/><br />
<Axis angle="150"/><br />
<Axis angle="90"/><br />
</Axes><br />
</pre><br />
<br />
Now turning right from the first axis, the player will have the<br />
impression of turning 120 degrees. Turning right again will turn<br />
the player by -60 degrees. Continuing, the player would experience<br />
turn of 120, 120 - 60 and 120 degrees, ending in the first<br />
direction.<br />
<br />
Also, the order of the axes could be totally reversed. This would<br />
effectively make the left key turn the player to the right, and<br />
the right key to the left<br />
<br />
Example: 4 Axis counter clockwise<br />
<pre><br />
<Axes number="4" normalize="true"><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="1"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0" ydir="-1"/><br />
</Axes><br />
</pre><br />
<br />
== Wall ==<br />
Walls are those big clunky elements normally associated with the<br />
rim.<br />
<br />
To define a wall, you need to specify all the vertices of all its<br />
segments. A wall segment will be created from one point to the<br />
next. <br />
<br />
Example: A square Wall of size 200<br />
<pre><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="200" y="0" /><br />
<Point x="200" y="200" /><br />
<Point x="0" y="200" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
</pre><br />
<br />
You should notice that for an wall to be closed, you need to loop<br />
back to the first point. <br />
<br />
Any number of walls can be specified inside the field element. A<br />
Wall need at least 2 Points, but doesn't have any upper limits.<br />
<br />
Walls to not need to be closed. In the arena defined earlier, it<br />
would be possible to add some obstacle walls. <br />
<br />
Example: A 2 points wall, possibly as an obstacle<br />
<pre><br />
<Wall><br />
<Point x="100" y="50" /><br />
<Point x="100" y="150" /><br />
</Wall><br />
</pre><br />
<br />
It is possible to have walls touching, and even crossing. There is<br />
no difference between segments assembled from many wall elements,<br />
or from a single one.<br />
<br />
While it is possible to leave the play arena unbounded, this<br />
behavior should be considered undefined and unsupported. It is<br />
highly recommended that the play area be bounded by a wall or a<br />
series of walls leaving no holes.<br />
<br />
Also, while it it possible to define "holes" , ie<br />
completely bounded areas inside a bigger area, or "islands", ie<br />
independent bounded areas independent of another play area, these<br />
behaviors are undefined and unsupported.<br />
<br />
The Wall element has one attribute, the height. Controlling the<br />
height affects the rendering height of a wall. A height of 1.0 is<br />
about the same as the height of the original cycle model. A height<br />
of 4.0 correspond to the Walls rendered with the lowRim setting on<br />
the client. When no height is defined, the client defined setting<br />
of either lowRim or highRim is used. This has the advantage of<br />
respecting the players choice and often, capacity to render high<br />
walls. When a height of 0 or less (ie: negative value) is given, an unresonably large value is substitued.<br />
<br />
;''height''<br />
: The height used for the rendering of the Wall. Positive value only.<br />
<br />
Example : Using the client default height<br />
<pre><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="10" y="10" /><br />
</Wall><br />
</pre><br />
<br />
Example : Controling the height<br />
<pre><br />
<Wall height="2.13"><br />
<Point x="0" y="0" /><br />
<Point x="10" y="10" /><br />
</Wall><br />
</pre><br />
<br />
== Spawn points ==<br />
Spawn points are where cycles are first located on the map. At<br />
game start, the game server will spread the players and AI among<br />
the different spawn locations described. You should provide<br />
sufficient spawn location for the number of players you entered to<br />
play on your map.<br />
<br />
Along with the location where the cycles will be placed, you<br />
need to specify the starting direction of the cycle. This will<br />
determine the direction that the cycle is facing when it appears.<br />
<br />
To specify this, two methods are offered:<br />
Vector orientation:<br />
In this method, you specify the direction as a vector, from (0, 0)<br />
to (xdir, ydir). This will indicate the direction to be face by<br />
the cycle.<br />
Angle orientation:<br />
In this method, you specify the direction as an angle in degrees.<br />
<br />
Because Armagetron is a game where motion occurs on certain axes<br />
only, starting direction should also be done on those axes. The<br />
game will use the direction described to find the closest matching<br />
axis. It is the direction of the chosen axis that is assigned to<br />
an spawned cycle. The direction specified is only used as a<br />
recommendation.<br />
<br />
A Spawn has six attributes. Only three or four are needed to<br />
describe a Spawn. Two of them, x and y, are mandatory.<br />
x= the x coordinate where the cycle is to be created<br />
y= the y coordinate where the cycle is to be created<br />
xdir= the x coordinate of the recommended direction the cycle will face at<br />
creation.<br />
ydir= the y coordinate of the recommended direction the cycle will face at<br />
creation.<br />
angle= the recommended angle to orient the cycle<br />
<br />
If the angle attribute is specified, xdir and ydir are<br />
ignored. When no angle attribute is specified, both xdir and ydir<br />
are needed.<br />
<br />
Example: Basic Spawn presentation<br />
<Spawn x="-15.5" y="368.0608" xdir="0.5" ydir="-0.866"/><br />
<Spawn x="-15.5" y="368.0608" angle="60"/><br />
<br />
Only the direction indicated is used. The size of the direction<br />
described doesn't influence the start up speed or displacement of a<br />
cycle.<br />
<br />
It is to be noted that specifying a direction of (0,0) is<br />
undefined. Also, specifying spawn points outside the play area<br />
that you defined is undefined and unsupported. <br />
<br />
== Zones ==<br />
Zones are interactive areas on the Field. They manifest themself as<br />
huge circles slowly rotating. The players can interact with the<br />
Zones by entering or being inside them.<br />
<br />
The Zone has an attribute effect which allows 3 values: win, death and<br />
fortress. Entering a Zone of effect win makes the player the round<br />
winner. Entering a Zone of effect death automatically kills the<br />
player. Zones of effect fortress need to be occupied to be<br />
triggered, and once triggered, they make the team the round winner.<br />
<br />
;effect<br />
:Any of win, death or fortress. When ommited, the value is defaulted to death<br />
<br />
Example: Zone syntax<br />
<pre><br />
<Zone effect="death"><br />
...<br />
</Zone><br />
</pre><br />
<br />
The Zone requires a sub element named ShapeCircle. <br />
<br />
The ShapeCircle has 2 attributes, the radius and the growth. The<br />
radius attribute describe the size of the ShapeCircle and is<br />
required. The unit used is the same game unit that are used as map<br />
coordinates. A ShapeCircle with a radius of 10 will extend of 10<br />
game units in every direction from its center.<br />
<br />
The growth describe how the radius of the ShapeCircle changes over<br />
time. This unit is game units per second from the moment the Zone<br />
is created, which is the round start.<br />
<br />
It is possible to specify a negative growth, in which case the ShapeCircle will<br />
slowly shrink. Should at any time the radius be of 0 or less, the<br />
Zone is removed without effect.<br />
The growth is optional and defaults to 0, which hold the<br />
ShapeCircle at a constant size during the round.<br />
<br />
;radius<br />
:The initial radius of the circle defining the Zone. This field is mandatory.<br />
;growth<br />
:The growth of the circle. The values can be positive, negative or 0. This field is optional and is defaulted to 0.<br />
<br />
Example: Zone with CircleShape<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20" growth="0.17"><br />
...<br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
The ShapeCircle requires a Point sub-element which describe the<br />
center of the ShapeCircle. The syntax of the Point is the same as<br />
the one used for the Wall.<br />
<br />
Example: A non-growing death zone<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20"><br />
<Point x="120" y="86"/><br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
Example: A growing fortress zone<br />
<pre><br />
<Zone effect="fortress"><br />
<ShapeCircle radius="20" growth="1.09"><br />
<Point x="250" y="7"/><br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
Example: A shrinking win zone<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="200" growth="-0.2"><br />
<Point x="440" y="325"/><br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
It is possible and valid to place the center of the Zone in a<br />
location that is not accessible to the players, such as in a<br />
walled compound or outside of the play area. This behavior might<br />
change in future version. Consult the appropriate documentation.<br />
<br />
Example: A death zone outside the rim<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20"><br />
<Point x="-25" y="100"/><br />
</ShapeCircle><br />
</Zone><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="200" y="0" /><br />
<Point x="200" y="200" /><br />
<Point x="0" y="200" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
<br />
</pre><br />
<br />
Example: A death zone partially outside the rim<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20"><br />
<Point x="-15" y="100"/><br />
</ShapeCircle><br />
</Zone><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="200" y="0" /><br />
<Point x="200" y="200" /><br />
<Point x="0" y="200" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
<br />
</pre><br />
<br />
Note: It is important to note that while Zones are introduced in<br />
Arthemis, a more complete implementation will follow in<br />
Bacchus. Curious minds consulting the documentation presenting the<br />
Bacchus implementation of Zones will notice that fortress isn't an<br />
effect, but rather a trigger type. The Arthemis implementation of<br />
Zones falsely uses it as an effect instead of exposing a trigger<br />
mechanism. Map designers are to be warned this will no longer be<br />
possible in maps defined for Bacchus.<br />
<br />
=== Fortress Zone ===<br />
The fortress Zone is particuliar because it uses a scoring system<br />
to determine if and when the Zone is triggered. The score is<br />
affected by the time passed in it by attackers and defenders.<br />
<br />
At start time, the score is set to 0.0. While the score can move<br />
freely, 2 restrictions are always applied. First, the score can<br />
never drop below 0.0. Second, if the score reaches or exceed 1.0,<br />
the Zone is triggered.<br />
<br />
Each single adversary in the Zone add to the score for their time<br />
passed in it. Each single defender in the Zone remove to the score<br />
for their time passed in it. Also, the score always decays. Each<br />
of these aspect is controlled by a different setting,<br />
CONQUEST_RATE, DEFEND_RATE and CONQUEST_DECAY_RATE. They all<br />
express a rate in points per seconds.<br />
<br />
;CONQUEST_RATE<br />
: Any single attacking player in the Zone add points to the score at this rate. <br />
;DEFEND_RATE<br />
: Any single defending player in the Zone removes points to the score at this rate. <br />
;CONQUEST_DECAY_RATE<br />
: The score of a Zone decays at this rate, irrelevantly of the numbers of attackers and defenders in the Zone. <br />
<br />
These 3 settings are global for all the Zones on a map.<br />
<br />
Example: Configuring Fortress from the config file<br />
<pre><br />
CONQUEST_RATE 0.5<br />
DEFEND_RATE 0.3<br />
CONQUEST_DECAY_RATE 0.1<br />
</pre><br />
<br />
Example: Configuring Fortress from the settings in the map<br />
<pre><br />
<Settings><br />
<Setting name="CONQUEST_RATE" value="0.5"/><br />
<Setting name="DEFEND_RATE" value="0.3"/><br />
<Setting name="CONQUEST_DECAY_RATE" value="0.1"/><br />
</Settings><br />
</pre><br />
<br />
<br />
== Appendices ==<br />
<br />
=== Map writing best practice ===<br />
<br />
==== Comment your work ====<br />
<br />
You should always comment the various parts of your work. Doing so improve maintainability. Something that is obvious during the creation of a particular map often becomes very cryptic after a few weeks. A good comment allow you to quickly grasp the meaning of what is described.<br />
<br />
A comment in xml starts with "<nowiki><!--</nowiki>" (without the quotes) and ends with "<nowiki>--></nowiki>". Comments can span multiple lines. If your editor doesn't highlight the commented part, be careful not to exclude a part of your map by mistake.<br />
<br />
==== Arena size ====<br />
<br />
The original map is of size 500 by 500. Many servers have setting<br />
that are oriented toward this size, and players are used to battle<br />
in such an environment. <br />
<br />
A map that is significantly larger or smaller will require the<br />
server admin to affect the scale facter to be used with the map to<br />
preserve the gaming experience tailorder to the server. <br />
<br />
Also, arenas with many divisions or made of many interconnecting<br />
rooms might find the efficace play space shrunk. Giving them a bit<br />
more surface might help balance this. <br />
<br />
For example, if rooms are organised in a 3 by 4 pattern, with<br />
corridors connecting them, many of the space between the rooms is<br />
lost. The map designer might try to have a total<br />
surface of for all the rooms that is of 250,000 square game units<br />
(the same surface than a 500 by 500 room). He might feel that<br />
ignoring the surface of the corridors compensate for the large<br />
amount of walls reducing the motion.<br />
<br />
On the other hand, one could easily imagine a<br />
extremely large maze. In this instance, the true factor would be<br />
the corridor width rather than the total size of the play area.<br />
<br />
There are no hard rules of any sort about the size of an<br />
arena. Experiment and adjust to produce the effect desired, and<br />
the players will most probably appreciate your efforts.<br />
<br />
==== Don't overload attributes ====<br />
<br />
Certain elements of the map have attributes that are exclusive. For<br />
example, in the Axis element, when the attribute angle is defined, the<br />
xdir and ydir attribute are never queried.<br />
<br />
While the engine ignore the exceeding data, this practice has the following drawbacks:<br />
<br />
* File size: The exceeding information is never used, but need to be transmitted as part of the file, and stored.<br />
* Readability: Exceeding information complicate the reading of a map by humans. <br />
* Maintenance: Maintenance of the map is not much more complex. If the author is minimalist, he/she risks updating the part of information that is ignored. Extremely good knowledge of the working of the parser is required to avoid this pitfall, and the change is only valid if the rule of precedences aren't updated. Specifying only one set of information avoid this problem. Also, if both sets of information are updated, then the task for the author is double, and so are the risks for error.<br />
<br />
=== Resource Filename Convention ===<br />
<br />
Resources are external content that makes the game interesting. Textures, sounds, models and maps are all resources for Armagetron Advanced. While at the time of writing of this tutorial, only maps are supported as true resources, soon support for the other types will be added. Also, while this section incorporated in the ''Maps'' tutorial, it might be moved as an independent document, and the standard described might be updated in a near future.<br />
<br />
For ease of administration, and to avoid conflicting versions all resources for Armagetron Advanced should adhere to the following naming convention:<br />
<br />
<pre><AuthorName>/[SubDirectory/]<ResourceName>-<VersionNumber>.<Extension></pre><br />
<br />
;AuthorName<br />
: The name of the person who currently maintains the resource; it needs to match the author attribute of the Resource element described above and either be a forum nickname on forums.armagetronad.net, a user name registered at the central resource repository, or an email address encoded as <code>unofficial/mailto/<Domain>@<User></code>.<br />
: Alternatively, the author can forgo his or her name and instead opt for a group-name. The group-name should be used when the author want to indicate that a set of resources are associate with a group. Instances of this could be when the resources are for a clan, a community, or a set of servers.<br />
<br />
;SubDirectory<br />
: Prolific authors and those are free to set up any number of sub directories to help them organize and possibly categorize their resources. The Armagetron Advanced team recommends that you to categorize resources by topics (ie: all the resources required for a particular movie-pack set in the same sub directory) over other categorization, such as categorization by type (ie: all the floor tiles set in the same sub directory). Any number of sub directory levels should be supported. This is not a mandatory item.<br />
<br />
;ResourceName<br />
: The actual name of the resource. This should be descriptive, and somewhat unique to facilitate identification of the described resource. The advantage of specifying a somewhat unique name here is that should the resource be accidentally moved out of its folder, it is still possible to quickly and easily identify it. A special note for maps: the ''ResourceName'' should be the same as the name attribute of the Map element defined in the xml file.<br />
<br />
;VersionNumber<br />
: This part should be used by the author to identify which version of the resource is described. During its life, a resource can receive many modifications and improvements. To find new resources, Armagetron Advanced relys solely on this part to be updated. Should a resource be updated and the old name kept, it would cause problems between different clients. Clients still having the old resource would not get the modifications, as they would expect the content to<br />
be the same, and only clients that would not have a local copy of file would get the latest version. The actual format to be used for the ''VersionNumber'' is left to the choice of the author. While the Armagetron Advanced team recommends a <code>VERSION.MAJOR.MINOR</code> dot notation similar to those used for software versions, any other notation can be<br />
used, such as a simple numeral: <code>GlowStick-1.png, GlowStick-2.png, ...</code>. Keep in mind that it should be obvious to other as to which is the most up to date version of the resource. A special note for maps: the ''VersionNumber'' should be the same as the version attribute of the Map element defined in the xml file.<br />
<br />
;Extension<br />
: This is the regular type of extension. While Armagetron Advanced doesn't verify that the extension describe the right type of content, it is favorable for other users that you set it to the appropriate type, and thus facilitate the usage of your resource.<br />
<br />
A few examples:<br />
<pre><br />
philippeqc/Firewall-0.3.2.png<br />
philippeqc/castle-6.aamap.xml<br />
TigersNetwork/CougarMoviepack/cougar-3.1.aamap.xml<br />
TigersNetwork/CougarMoviepack/PawTrace-floor-2.png<br />
AngelOfMercy-Clan/OfficialCycleMode-2.1.7.ace<br />
AngelOfMercy-Clan/trainingMap-6.aamap.xml<br />
</pre><br />
<br />
=== Resource repository ===<br />
<br />
When a player doesn't have the map being used on a server, their game will<br />
automatically download it from the resource repository. To add your completed<br />
maps to the official resource repository, go to:<br />
[[Resource repository]]<br />
<br />
=== Examples ===<br />
<br />
==== Parallelogram arena ====<br />
<br />
[[Image:Parallelogram-1.0.png|right|thumbnail|Parallelogram]]<br />
<br />
<pre><br />
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
<Resource type="aamap" name="Parallelogram" version="1.0" author="Philippe Villeneuve" category="example"><br />
<Map version="0.2.8"><br />
<br />
<World><br />
<!-- A variation on the classic arena --><br />
<Field><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="-0.2" ydir="-1"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0.2" ydir="1"/><br />
</Axes><br />
<br />
<Spawn x="265" y="50" xdir="0.2" ydir="1" /><br />
<Spawn x="335" y="450" xdir="-0.2" ydir="-1" /><br />
<Spawn x="99" y="245" xdir="1" ydir="0" /><br />
<Spawn x="501" y="255" xdir="-1" ydir="-0" /><br />
<br />
<Spawn x="325" y="100" xdir="0.2" ydir="1" /><br />
<Spawn x="275" y="400" xdir="-0.2" ydir="-1" /><br />
<Spawn x="139" y="195" xdir="1" ydir="0" /><br />
<Spawn x="461" y="305" xdir="-1" ydir="-0" /><br />
<br />
<Spawn x="225" y="100" xdir="0.2" ydir="1" /><br />
<Spawn x="375" y="400" xdir="-0.2" ydir="-1" /><br />
<Spawn x="159" y="295" xdir="1" ydir="0" /><br />
<Spawn x="441" y="205" xdir="-1" ydir="-0" /><br />
<br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="500" y="0" /><br />
<Point x="600" y="500" /><br />
<Point x="100" y="500" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
</Field><br />
</World><br />
</Map><br />
</Resource><br />
</pre><br />
<br />
==== HexaTRON ====<br />
<br />
[[Image:HexaTRON-0.2.png|right|thumbnail|HexaTRON]]<br />
<br />
The HexaTRON map has been developed by Luke-Jr for his HexaTRON<br />
mod on the code. It has a hexagonal flower and uses 6<br />
directions. Please note that this is version 0.2 of the map, and<br />
that many newer version have been published.<br />
<br />
<pre><br />
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
<Resource name="HexaTRON" version="0.2" author="Luke-Jr" category="HexaTRON"><br />
<br />
<Map version="0.2.8"><br />
<World><br />
<Field><br />
<!-- This is the Hexa map put in XML. This should work out of the<br />
box, ie: without changes to the aa engine code beside a flashy new<br />
parser. Errors might have been introduced during the conversion to<br />
XML by philippeqc, for your debugging amusement --><br />
<br />
<Axes number="6"/><br />
<Spawn x="99.5" y="73.612159" xdir="-0.5" ydir="0.866"/><br />
<Spawn x="-15.5" y="368.0608" xdir="0.5" ydir="-0.866"/><br />
<Spawn x="198.333333" y="196.29909" xdir="-1.0" ydir="0"/><br />
<Spawn x="-114.333333" y="245.37387" xdir="1" ydir="0"/><br />
<Spawn x="141.666666" y="343.52341" xdir="-0.5" ydir="-0.866"/><br />
<Spawn x="-57.666666" y="98.149545" xdir="0.5" ydir="0.866"/><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="85" y="0" /><br />
<Point x="127.5" y="73.612159" /><br />
<Point x="212.5" y="73.612159" /><br />
<Point x="255" y="147.22432" /><br />
<Point x="212.5" y="220.83648" /><br />
<Point x="255" y="294.44864" /><br />
<Point x="212.5" y="368.0608" /><br />
<Point x="127.5" y="368.0608" /><br />
<Point x="85" y="441.67296" /><br />
<Point x="0" y="441.67296" /><br />
<Point x="-43.5" y="368.0608" /><br />
<Point x="-128.5" y="368.0608" /><br />
<Point x="-170" y="294.44864" /><br />
<Point x="-128.5" y="220.83648" /><br />
<Point x="-170" y="147.22432" /><br />
<Point x="-128.5" y="73.612159" /><br />
<Point x="-43.5" y="73.612159" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
<Wall><br />
<Point x="127.5" y="73.612159" /><br />
<Point x="113.333333" y="98.149545" /><br />
</Wall><br />
<Wall><br />
<Point x="212.5" y="220.83648" /><br />
<Point x="184.166666" y="220.83648" /><br />
</Wall><br />
<Wall><br />
<Point x="127.5" y="368.0608" /><br />
<Point x="113.333333" y="343.52341" /><br />
</Wall><br />
<Wall><br />
<Point x="-43.5" y="368.0608" /><br />
<Point x="-29.666666" y="343.52341" /><br />
</Wall><br />
<Wall><br />
<Point x="-128.5" y="220.83648" /><br />
<Point x="-100.833333" y="220.83648" /><br />
</Wall><br />
<Wall><br />
<Point x="-43.5" y="73.612159" /><br />
<Point x="-29.666666" y="98.149545" /><br />
</Wall><br />
</Field><br />
</World><br />
</Map><br />
</Resource><br />
</pre><br />
<br />
=== About the "undefined and unsupported" ===<br />
<br />
Many possible combinations are marked as ''undefined and unsupported''. While it may be possible to do them now, and even amusing to do it, they are strongly discouraged. Later version of the World format will most probably conflict with those behaviors. This will make such behaviors difficult to preserve, if possible at all. For this reasons, it has been decided that '''no''' effort would be put to maintain them. Use them if you want, but do not come complaining if and when they stop working.</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=Making_Maps_by_Hand&diff=21396Making Maps by Hand2008-04-04T00:27:57Z<p>AndySquirrel: </p>
<hr />
<div>This tutorial is to help map designer to get a grasp of the Map<br />
format used by Armagetron Advanced.<br />
<br />
This version of the tutorial address the syntax defined by map-0.2.8_beta3.dtd and present the rules of interpreting the syntax as used by the parsing engine in the version 0.2.8 of Armagetron Advanced.<br />
<br />
== Format overview ==<br />
<br />
The classic Armagetron arena could be described with the following<br />
map:<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
<Resource type="aamap" name="square" version="1.0.1" author="Anonymous" category="polygon/regular"><br />
<Map version="0.2.8"><br />
<!-- The original square map, technically created by z-man.<br />
Converted to XML by philippeqc.<br />
License: Do with it what you want. --><br />
<br />
<World><br />
<Field><br />
<Axes number="4"/><br />
<br />
<Spawn x="255" y="75" xdir="1" ydir="1" /><br />
<Spawn x="245" y="450" xdir="0" ydir="-1" /><br />
<Spawn x="50" y="245" xdir="1" ydir="0" /><br />
<Spawn x="450" y="255" xdir="-1" ydir="0" /><br />
<br />
<Spawn x="305" y="100" xdir="0" ydir="1" /><br />
<Spawn x="195" y="400" xdir="0" ydir="-1" /><br />
<Spawn x="100" y="195" xdir="1" ydir="0" /><br />
<Spawn x="400" y="305" xdir="-1" ydir="0" /><br />
<br />
<Spawn x="205" y="100" xdir="0" ydir="1" /><br />
<Spawn x="295" y="400" xdir="0" ydir="-1" /><br />
<Spawn x="100" y="295" xdir="1" ydir="0" /><br />
<Spawn x="400" y="205" xdir="-1" ydir="0" /><br />
<br />
<Wall><br />
<Point x="100" y="100" /><br />
<Point x="500" y="500" /><br />
<Point x="500" y="500" /><br />
<Point x="500" y="500" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
</Field><br />
</World><br />
</Map><br />
</Resource><br />
</pre><br />
<br />
The Map format start with a XML header. The actual definition<br />
of the Map is wrapped in a Resource. The Resource gives a<br />
description of the content, such as the author and the version of<br />
the map included. This particuliar map is the xml version of the<br />
original map that supported directly in the game before version<br />
0.2.8 (Arthemis). <br />
<br />
Skipping ahead in to the Field element, line 11 defines that <br />
that 4 axes are to be<br />
used. From line 13 to 26, all the spawn points, ie: the points where<br />
the cycles are located when the match starts, are defined. Finally<br />
the walls are defined, delimiting the play area.<br />
<br />
== Header ==<br />
The header of the map can nearly be considered as constant. It is<br />
composed of 2 lines.<br />
<br />
Header for Arthemis' maps:<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "AATeam/map-0.2.8.0.dtd"><br />
</pre><br />
<br />
The only element you need to consider is the name of the dtd. The<br />
dtd should always be named after the version it targets. For<br />
Arthemis, it should be "map-0.2.8.dtd". <br />
<br />
Note: during the beta process, version can change often and have<br />
great difference between them. To limit the scope of the problem<br />
during the beta phase, the name of the dtd should include the beta<br />
it targets. <br />
<br />
Header for the beta 3 of Arthemis' maps:<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
</pre><br />
<br />
== Resource ==<br />
The Resource element describe some meta-information of the Map,<br />
such as who created it, how should the resource file be named and<br />
what type of information is to be expected.<br />
<br />
One part of the Resource details describe who made this map a<br />
reality. In the Resource element, it is possible to differenciate<br />
between the person that comissioned the map, the<br />
commisionner, and the person who executed the request and coded<br />
it, the author. <br />
<br />
Both operations might be carried by the same and only person, in<br />
this instance both entities are the same and the commissioner<br />
field should be left blank. The commissioner field should be used<br />
when the concept of a map and its execution are performed by two<br />
different persons or entities. It could range from anything from<br />
"could someone make a map where the feeling of <X> is emphased" to<br />
coding from a hand-drawn sketch. The commissioner could also be<br />
implied. Without him/her ever placing an open request, a<br />
commisioner could be assigned to a map when the author wants to<br />
express an assumed sharing of the creation of the map. This can be<br />
the case, for example, when the member of a Clan wrote a map that<br />
falls in the ideals of the Clan.<br />
<br />
Maps can be implicitly grouped together. The category field is<br />
there for this purpose. Prolific authors and their public will<br />
appreciate a clear grouping of similar themed maps.<br />
<br />
As ever refining one's work is a very respected quality in the<br />
Armagetron community, the latest changes need to be properly<br />
propagated to everybody. The version field allow an author to<br />
identify each specific instance of his/her work, and also insure that<br />
a client will receive the exact version used by a server when<br />
playing on it.<br />
<br />
The type specifies that the file holds an Armagetron Advanced<br />
map. While this is the only type available at the moment, the<br />
development team is eager to expand this in the furture.<br />
<br />
Finally, and most importantly, the name of the ''ouvrage'' being<br />
presented. <br />
<br />
The fields for Resource are:<br />
;name<br />
:The name of the map, mandatory.<br />
;type<br />
:The only valid type is "aamap". This field is defaulted "aamap" when absent.<br />
;version <br />
:The version of the map described in this particuliar file. This value needs to be modified each time a change is applied to the map to ensure everybody have the proper copy.<br />
;author<br />
:The current maintainer of this map, usually the author who produced it. This either should be a user name registered with the central resource repository, or, for lone wolves who don't want to register, a valid email address encoded in the spambot safe as "unofficial/mailto/<Domain>/<User>", where "<User>@<Domain>" would be the address.<br />
:This field is defaulted to "Anonymous" when absent.<br />
;commisioner<br />
:The entity who dreamt, requested or inspired this map in any way. This field is optional and has no default value. <br />
;category<br />
:How this map should be categorised. This field can have any number of sub categories, each separated by a "/" (a forward slash). An example could be "category/subcategory/subsubcategory". This field is defaulted to "unsorted" when absent. <br />
<br />
Example: The castle map made by philippeqc<br />
<pre><br />
<Resource name="Castle" type="aamap" version="1.1" author="philippeqc" category="examples"><br />
...<br />
</Resource><br />
</pre><br />
<br />
Example: The StarTron ("5ptstar") map made by Your_mom (note that while 'beta' is more or less correct for the 'version' attribute, it should not be in the 'category' as it is here)<br />
<pre><br />
<Resource name="5ptstar" version="beta" author="Your_mom" category="beta" type="aamap"><br />
...<br />
</Resource><br />
</pre><br />
<br />
Example: The MBC training map, made by Zorgul<br />
<pre><br />
<Resource name="TrainingDay" version="1.6" author="Zorgul" category="MBC" type="aamap" commisioner="Micro Bus City"><br />
...<br />
</Resource><br />
</pre><br />
<br />
Example: The Reverso map, writen by Nemosultra based on a drawing by lucifer, for the Crack Pipe server<br />
<pre><br />
<Resource name="Reverso" version="1.1-b" author="Nemosultra" category="CrackPipe" type="aamap" commisioner="lucifer"><br />
...<br />
</Resource><br />
</pre><br />
<br />
To facilitate manipulation of the file over distributed systems,<br />
the Resource holds explicit information about the naming and<br />
storing of the file. This information can be used by tools such as<br />
scripts and resource repositories to manipulate the file. <br />
<br />
A resource has a unique filepath determined by these attributes. The resource must be the ''only'' one to ever appear as this filepath and any changes must affect the 'version' and the person making the change must place their name in the 'author' attribute unless given permission by the original author.<br />
<br />
The filepath is formed by the attributes in the following syntax:<br />
<br />
<Author>/[Category/]<ResourceName>-<VersionNumber>.<ResourceType>.xml<br />
<br />
== Map ==<br />
This element is the basic holder of the description of the<br />
Map. From the opening element to the closing one, all the<br />
information will be used to construct an in-game representation<br />
for the players to explore and possibly compete in.<br />
<br />
The version attribute of the map indicates a specific parsing<br />
engine version that should be used to express the map in the exact<br />
manners that are desired by the map creator. <br />
<br />
Example: Map element<br />
<pre><br />
<Map version="0.2.8"><br />
...<br />
</Map><br />
</pre><br />
<br />
Sooner in the file,<br />
the dtd has already specified a version. The difference between<br />
both version is one specify the version of the syntax to be use,<br />
and the other, the version of the rules to be used to interprete<br />
the syntax.<br />
<br />
The dtd controls the syntax, what keywords are valid and in what<br />
arrangement. The parsing engine has specific rules how to read the<br />
syntax and create the game elements. It is possible for different<br />
parsing engines to operate from the same syntax, be it because the syntax<br />
allows for many interpretations, or because a specific<br />
interpretation has been found faulty in some case. Because each<br />
interpretation could lead to very different instantiation, it is<br />
best for the map designer to specify the one that should be<br />
used. Even when no alternative interpretation exist, ie: there is<br />
only one version available, it is best for the map designer to<br />
specify it. Should a new one be implemented at a later time, the<br />
map defined would continue to be instanciated properly.<br />
<br />
At the time of writing, the only parsing engine version is<br />
"0.2.8". Maps using a version that is not understood by the<br />
parsing engine of a specific client or server will be<br />
automatically rejected by said application, on the ground that the<br />
parsing engine doesn't know how to operate on it.<br />
<br />
Even if only one value exists, it is impossible to provide it as a<br />
default, as there are no assurance that a new interpretation of<br />
the syntax will not arrive at a future time.<br />
<br />
== Settings ==<br />
It is possible for a map designer to indicate specific game<br />
settings, similar to the ones available through the configuration<br />
files of the application, to be used with the map. When<br />
this is not desired, the Settings element can be safely removed<br />
from the map definition.<br />
<br />
Any number of Setting can be defined inside of the Settings<br />
element. Each Setting defined will overwrite the value previously<br />
defined in the game. Each new Setting addressing a specific<br />
configuration item will keep on overwriting previously defined<br />
values. The Settings items are processed in order, from the top to<br />
the bottom one.<br />
<br />
The Settings should be considered to be global to the World and<br />
its sub-elements. This has very little relevance at the moment as<br />
only one World and one Field can exist in the game. It is not<br />
excluded that future version of the game could support multiple<br />
elements such as World and Field. Each such elements and sub-elements would<br />
receive the Settings defined in its parents, but would also be<br />
able to overwrite parent received Settings for itself and its<br />
sub-elements. <br />
<br />
One such overwriting capacity already exists, in the form of the<br />
Axes element. This element can and will overwrite the value passed<br />
by the Setting ARENA_AXES.<br />
<br />
At the time of writing, there are no known cases where the order of<br />
writing Settings should matter. There are no garanties of this being<br />
the case. Be carefull of the order of the Settings provided.<br />
<br />
<pre><br />
<Settings><br />
<Setting name="a" value="1"/><br />
<Setting name="b" value="2"/><br />
<Setting name="c" value="3"/><br />
</Settings><br />
</pre><br />
<br />
The Settings element is inserted in the Map element, before the World element.<br />
<br />
<pre><br />
<Map ...><br />
<Settings><br />
...<br />
</Settings><br />
<World><br />
...<br />
</World><br />
</Map><br />
</pre><br />
<br />
== Setting ==<br />
Each individual Setting defines a specific element normally<br />
configurable throught the config files of the game<br />
application. For a full list and description of the setting<br />
available, consult the [[Console Commands]] page. As config items<br />
are the same as console commands, you will find all the<br />
information there.<br />
<br />
The Setting has two attributes, the name and the value. The name<br />
field hold the setting name as found in the various configuration<br />
files. The value field will be assigned to the designated setting.<br />
<br />
<pre><br />
<Setting name="CYCLE_BRAKE_REFILL" value=".1"/><br />
</pre><br />
will assing .1 to the configuration item CYCLE_BRAKE_REFILL.<br />
<br />
No validation is done on any fields by the parsing engine. The<br />
values are passed directly to the setting engine, where the usual<br />
validation is performed. Unexisting or misspelled settings names<br />
will be ignored. Setting with valid names and invalid values have<br />
an undetermined effect.<br />
<br />
The different Settings used have the potential of overwriding<br />
client or server ones. While this behavior offers great capacity<br />
to custom behavior for a specific map, users playing locally on<br />
their machine and server administrator might find it a disruption<br />
of their craftfully designed settings. Use with care and<br />
moderation.<br />
<br />
== World ==<br />
At this moment, the element possible inside of the World element is<br />
the Field element. Only one Field can be defined. No parameters<br />
are available at the moment.<br />
<br />
<pre><br />
<World><br />
...<br />
</World><br />
</pre><br />
<br />
== Field ==<br />
The Field element holds the description required to construct the<br />
play area. Inside the Field, Axes, Spawn and Wall elements can be<br />
defined. <br />
<br />
The field defines the zone on a 2D plane where the gaming can<br />
occur. The full support of this definition will be developed under<br />
Bacchus. In Arthemis, the old philosophy of "the play zone has to<br />
be bounded by walls" is somewhat preserved. A secondary mechanism<br />
also exist to prevent the players from escaping the rim. This is a<br />
bried description of the mechanism used.<br />
<br />
While setting all the walls to be used during a round, the engine<br />
will keep track of the minimal and maximal x's and y's values<br />
encountered through wall coordinates.<br />
A logical box will be formed, using the coordinate<br />
(minX, minY), (maxX, minY), (maxX, maxY) and (minX, maxY) as its<br />
corners.<br />
<br />
Example: Logical box around the classical arena.<br />
The classical arena has the coordinates (0,0), (0,500), (500,500)<br />
and (500, 0). This means that minX=0, minY=0, maxX=500 and<br />
maxY=500.<br />
<br />
Example: Logical box around a square arena moved by 20 on the x's.<br />
The classical arena has the coordinates (20,0), (20,500), (520,500)<br />
and (520, 0). This means that minX=20, minY=0, maxX=520 and<br />
maxY=500.<br />
<br />
Example: Logical box around a trapazoid arena.<br />
A trapazoid has a base lenght of 300, a top length of 200 and a<br />
height of 200 with the following coordinates: (0, 0), (300, 0),<br />
(250, 200), (50, 200). This means that minX=0, minY=0, maxX=300,<br />
maxY=200.<br />
<br />
Example: Logical box around 2 walls of the classical arena.<br />
Should the south and west walls of the classical arena be ommited,<br />
and only the north (from (0,500) to (500,500)) and east one (from<br />
(500,0) to (500,500)) remain, the logical box is still the same<br />
around it. This means that minX=0, minY=0, maxX=500 and<br />
maxY=500.<br />
<br />
Example: 2 walls at strange angle<br />
If two walls, organized at strange angle and not even meeting,<br />
compose the arena, are described as (200,200) to (600, 400) and<br />
(350, 350) to (-10, 720). This means that minX=-10, minY=200,<br />
maxX=600 and maxY=720.<br />
<br />
A no-motion logical box will be put at 10 game units outside of the<br />
logical box. Should a player meet this no-motion zone, she will<br />
find herself pushing agains a coussin of air. Rubber has undefined<br />
effect agains this no-motion box.<br />
<br />
A second logical box will be put at 20 games units from the first<br />
logical box. Should any players be outside of this logical box,<br />
they are automatically killed.<br />
<br />
In game terms, should the players not be bounded by a continous<br />
wall, they are free to roam around it but they will find an<br />
invisible barrier keeping them from excaping into the infinite.<br />
<br />
Should you want to allow your players to roam without<br />
restrictions, exploring the infinity of the grid, you have to<br />
specify to use an infinite field.<br />
<br />
The Field supports a single parameter, named logicalBox, which<br />
controls if the logical box should be used to limit roaming on the<br />
Field. <br />
;logicalBox<br />
:When set to true, the motion will be restrained by the logical box, and when set to false, no logical box will be used. This field is optional and default to true.<br />
<br />
Example: Logical box bounded Field<br />
<pre><br />
<Field><br />
...<br />
</Field><br />
</pre><br />
<br />
Example: Field with its logical box disabled<br />
<pre><br />
<Field logicalBox="false"><br />
...<br />
</Field><br />
</pre><br />
<br />
The following 2 paragraphs are post map-0.1 and 0.2.8_beta2.<br />
<br />
For clarity purposes, the Axes element, if defined, need to be<br />
defined first. After this, Spawn point, Walls and Zones can be<br />
defined in any order.<br />
<br />
While a Field without any Spawn points is syntaxly valid, and<br />
the parsing engine doesnt report any error, the effect is<br />
undetermined. While a Field without any Wall is syntaxly valid,<br />
and the parsing engine doesn't report any error, the effect is<br />
undetermined.<br />
<br />
== Axes ==<br />
The Axes element defines how the cycles will behave on this<br />
particular Field. The original Armagetron used 4 axes. <br />
<br />
The Axes element has 2 fields:<br />
;number<br />
: This specifies the number of axes that should be used. If not specified, 4 axes are assumed.<br />
;normalize<br />
:When set to true, it specifies that the game should ensure that the direction vectors are scaled to have a size of exactly 1.0. When not specified, the individual axis will be keep at the exact length they are specified. This is covered in section 6. When not specified, it is assumed that normalization is desired.<br />
<br />
<Axes number="6" normalize="true"/><br />
<br />
When used without any other information, it is assumed that equally spaced axes should be generated, starting from (1,0) and going clockwise. The number generated is the value specified by the number attribute.<br />
<br />
The Axes element can also be used to describe each direction that can be used, instead of relying on the automatic generation. To do this, Axis elements are used to describe each direction.<br />
<br />
<pre><br />
<Axes number="4"><br />
<Axis xdir="1" ydir="1"/><br />
<Axis xdir="1" ydir="-1"/><br />
<Axis xdir="-1" ydir="-1"/><br />
<Axis xdir="-1" ydir="1"/><br />
</Axes><br />
</pre><br />
<br />
The Axis element uses the following fields:<br />
;xdir<br />
: This is the size of the displacement along the x's for this axis.<br />
;ydir<br />
: This is the size of the displacement along the y's for this axis.<br />
;angle<br />
: This allows to describe the Axes in degrees.<br />
;length<br />
: When the angle is specified, the length can be used to scale the size of the vector described. This value is only used when angle are specified.<br />
<br />
If the angle field is found, the length will be queried and used. If the length is absent, a default of 1 is used for the length. If no angle is specified, then both the xdir and ydir need to be specified for the Axis to be valid.<br />
<br />
The previous example could be re-written with:<br />
<pre><br />
<Axes number="4"><br />
<Axis angle="45" length="1.4142"/><br />
<Axis angle="135" length="1.4142"/><br />
<Axis angle="225" length="1.4142"/><br />
<Axis angle="335" length="1.4142"/><br />
</Axes><br />
</pre><br />
<br />
Note that even though the length is specified, because the Axes element doesn't have the normalize="false", all the lengths will be scaled back to exactly 1.<br />
<br />
The Axes should be specified in clockwise order. The specified axes are stored in the order they appear. When a player want to turn right, it is passed to the next axis on the list, or to the first when turning from the last direction.<br />
<br />
You might observe that in Example 5.2, the directions sum up to more than 1.0. For example, the first Axis has a xdir and a ydir of 1. The real length of the described Axis is <br />
<math>\sqrt{xdir^2+ydir^2}</math><br />
, which is approximately 1.4142. By specifying the normalize="true", or using the default behavior, you ensure that they are scaled back to 1.0.<br />
<br />
The number of Axis specified should be the same as the number of axes. Any extra axes will be discarded. Any missing Axis will be assumed to be (1,0). <br />
<br />
Note: Some old maps will use Point instead of Axis. The Point is deprecated in this context. New maps should use the Axis element.<br />
<br />
== Advanced Axes ==<br />
<br />
=== Normalization ===<br />
<br />
It is often easier to write directions are (2,1) rather than<br />
(.89442719099991587856 , .44721359549995793928), which is the<br />
normalized equivalent. The normalization mechanism ensure that<br />
displacement is constant on all the axes. This has always been the<br />
behavior of the game. So what is the effect of having non normalized<br />
Axis? Before anything else, a bit of understanding how the engine of<br />
Armagetron operates might be required. <br />
<br />
You might recall from your physics class that the distance traveled is<br />
computed from the speed at which you travel multiplied by the time<br />
during with you traveled ie: distance = speed * time.<br />
<br />
Armagetron has at its core a 2D engine. Vehicles move along a 2D<br />
surface, changing their x and y positions. To find the new position<br />
of a vehicle, the distance is multiplied by a 2D vector, the<br />
direction, before being added to the old position. Because the<br />
direction is a normalized vector, the resulting displacement is of the<br />
same size than the calculated distance. But if the direction is a<br />
non-normalized vector, ie: it has a size that is lesser or greater<br />
than 1, but not equal, then the displacement gets to have a different<br />
size than the distance.<br />
<br />
By setting the Axis to non-normalized values, the map designer can<br />
modify displacement in the arena. By defining Axis with a vector size<br />
of 2, see example 6.1.1, all the cycles would behave as if they where<br />
moving twice as fast. Setting the Axis a length of 0.5, see example<br />
6.1.2, the opposite effect occurs. Now the cycle move as if their<br />
speed was halved.<br />
<br />
Example: Axes of size 2<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="2"/><br />
<Axis xdir="2" ydir="0"/><br />
<Axis xdir="0" ydir="-2"/><br />
<Axis xdir="-2" ydir="0"/><br />
</Axes><br />
</pre><br />
<br />
Example: Axes of size 0.5<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="0.5"/><br />
<Axis xdir="0.5" ydir="0"/><br />
<Axis xdir="0" ydir="-0.5"/><br />
<Axis xdir="-0.5" ydir="0"/><br />
</Axes><br />
</pre><br />
<br />
By setting the normalize attribute to false, the designer ensures<br />
that the game will use the Axis values as is. While this section has<br />
used Axes that all have the same size, this is not a requirement. The<br />
next section will explore setting Axis with different sizes.<br />
This permit to affect the displacement on certain axes.<br />
<br />
=== Uneven Axes ===<br />
Up to now, the Axis have always have the same size. This mean that for<br />
a given speed, the displacement of a cycle is always the same in every<br />
direction. But nothing permit you to define it differently. <br />
<br />
Imagine an arena shaped as a rectangle. The height, along the y's,<br />
would be ten times the size of the length, along the x's. Normally, with<br />
the Axis all of the same size, it would take a player ten time as long to<br />
run from one wall to another when cruising along the height of the<br />
rectangle. <br />
<br />
But you could decide to make motion along the height occur at ten time the<br />
rate, so it would take a player the same time to cover the height of<br />
the arena than to cover the length, giving it an "Alice in Wonderland"<br />
feeling (see example 6.2.1). This feeling could be exaggerated even more<br />
by making traveling along the longest distance occur in half the time<br />
that travel along the shortest distance. To do this, you could double<br />
the size of the Axis set in the previous example (see example<br />
6.2.2). Now, even thou one dimension of the rectangle is 10 time the<br />
other, travel along this longer dimension occur at a much higher rate,<br />
compressing this dimension in the player's mind.<br />
<br />
Example: Rectangle of equal travel time<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="10"/><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="-10"/><br />
<Axis xdir="-1" ydir="0"/><br />
</Axes><br />
<Wall><br />
<Point x="0" y="0"/><br />
<Point x="100" y="0"/><br />
<Point x="100" y="1000"/><br />
<Point x="0" y="1000"/><br />
<Point x="0" y="0"/><br />
</Wall><br />
</pre><br />
<br />
Example: Rectangle of compressed travel time<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="20"/><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="-20"/><br />
<Axis xdir="-1" ydir="0"/><br />
</Axes><br />
<Wall><br />
<Point x="0" y="0"/><br />
<Point x="100" y="0"/><br />
<Point x="100" y="1000"/><br />
<Point x="0" y="1000"/><br />
<Point x="0" y="0"/><br />
</Wall><br />
</pre><br />
<br />
The current game play is balanced around the fact that normally,<br />
the displacement factor is of size 1. By increasing this too much, your<br />
map might quickly become unplayable. While the example present Axis<br />
size of 10's and 20's, it is only for a pedagogical value. If you want<br />
to create great difference of displacement among different Axis, you<br />
might find that augmenting Axes size a little bit and raising others<br />
also could produce a better effect. The following example offers a ratio of<br />
6 between the displacement on the x's and y's, while keeping the faster<br />
displacement at only 3 times the regular one. This reduce the<br />
effect of playing at very high speed while having a huge<br />
difference between directions.<br />
<br />
Example: Factor of 6 between displacement, centered around a speed<br />
of ~1.<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0.5" ydir="0"/><br />
<Axis xdir="0" ydir="-3"/><br />
<Axis xdir="-0.5" ydir="0"/><br />
<Axis xdir="0" ydir="3"/><br />
</Axes><br />
</pre><br />
<br />
Example: Factor of 6 between displacement, centered around a speed<br />
of ~3<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="-6"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0" ydir="6"/><br />
</Axes><br />
</pre><br />
<br />
While the ratio of speed is the same between both examples, the<br />
later one has speed that might be difficult to control in one<br />
direction. The first example produce the same difference, but<br />
present the players with a more balanced alternative.<br />
<br />
Up to now, the Axes where always evenly placed around the<br />
player. Distributing the Axes in a non-equal fashion can allow for<br />
different kind of game play. If you where to make a parallelogram<br />
shaped arena, you might want the players to be able to move along the<br />
walls of the arena. For this, the different Axis would need to be<br />
properly set. <br />
<br />
Example: Parallelogram arena<br />
<pre><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="0" ydir="1"/><br />
<Axis xdir="1" ydir="0.5"/><br />
<Axis xdir="0" ydir="-1"/><br />
<Axis xdir="-1" ydir="-0.5"/><br />
</Axes><br />
<Wall><br />
<Point x="0" y="0"/><br />
<Point x="100" y="50"/><br />
<Point x="100" y="150"/><br />
<Point x="0" y="100"/><br />
<Point x="0" y="0"/><br />
</Wall><br />
</pre><br />
<br />
=== Order of the axes ===<br />
Turning right is translated to passing to the next axis, and<br />
turning left to the previous axis. But by changing the order that<br />
the axes are defined, this behavior can be altered.<br />
<br />
Example: 6 Axis in cartesian, in the order 4, 5, 6, 1, 2, 3<br />
<pre><br />
<Axes number="6" normalize="true"><br />
<Axis xdir="-0.5" ydir="-0.866025404"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="-0.5" ydir="0.866025404"/><br />
<Axis xdir="0.5" ydir="0.866025404"/><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0.5" ydir="-0.866025404"/><br />
</Axes><br />
</pre><br />
<br />
Example: 6 Axis in degrees, in the order 4, 5, 6, 1, 2, 3<br />
<pre><br />
<Axes number="6"><br />
<Axis angle="210"/><br />
<Axis angle="270"/><br />
<Axis angle="330"/><br />
<Axis angle="30"/><br />
<Axis angle="90"/><br />
<Axis angle="150"/><br />
</Axes><br />
</pre><br />
<br />
Both define a regular 6 axes. Turning right will make the cycle<br />
face a direction that is 60 degrees to its right. But by changing<br />
the order, this can be altered.<br />
<br />
Example: 6 Axis in cartesian, in the order 4, 6, 5, 1, 3, 2<br />
<pre><br />
<Axes number="6" normalize="true"><br />
<Axis xdir="-0.5" ydir="-0.866025404"/><br />
<Axis xdir="-0.5" ydir="0.866025404"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0.5" ydir="0.866025404"/><br />
<Axis xdir="0.5" ydir="-0.866025404"/><br />
<Axis xdir="1" ydir="0"/><br />
</Axes><br />
</pre><br />
<br />
Example: 6 Axis in degrees, in the order 4, 6, 5, 1, 3, 2<br />
<pre><br />
<Axes number="6"><br />
<Axis angle="210"/><br />
<Axis angle="330"/><br />
<Axis angle="270"/><br />
<Axis angle="30"/><br />
<Axis angle="150"/><br />
<Axis angle="90"/><br />
</Axes><br />
</pre><br />
<br />
Now turning right from the first axis, the player will have the<br />
impression of turning 120 degrees. Turning right again will turn<br />
the player by -60 degrees. Continuing, the player would experience<br />
turn of 120, 120 - 60 and 120 degrees, ending in the first<br />
direction.<br />
<br />
Also, the order of the axes could be totally reversed. This would<br />
effectively make the left key turn the player to the right, and<br />
the right key to the left<br />
<br />
Example: 4 Axis counter clockwise<br />
<pre><br />
<Axes number="4" normalize="true"><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="0" ydir="1"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0" ydir="-1"/><br />
</Axes><br />
</pre><br />
<br />
== Wall ==<br />
Walls are those big clunky elements normally associated with the<br />
rim.<br />
<br />
To define a wall, you need to specify all the corners of all its<br />
segments. A wall segment will be created from one point to the<br />
next. <br />
<br />
Example: A square Wall of size 200<br />
<pre><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="200" y="0" /><br />
<Point x="200" y="200" /><br />
<Point x="0" y="200" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
</pre><br />
<br />
You should notice that for an wall to be closed, you need to loop<br />
back to the first point. <br />
<br />
Any number of walls can be specified inside the field element. A<br />
Wall need at least 2 Points, but doesn't have any upper limits.<br />
<br />
Walls to not need to be closed. In the arena defined earlier, it<br />
would be possible to add some obstacle walls. <br />
<br />
Example: A 2 points wall, possibly as an obstacle<br />
<pre><br />
<Wall><br />
<Point x="100" y="50" /><br />
<Point x="100" y="150" /><br />
</Wall><br />
</pre><br />
<br />
It is possible to have walls touching, and even crossing. There is<br />
no difference between segments assembled from many wall elements,<br />
or from a single one.<br />
<br />
While it is possible to leave the play arena unbounded, this<br />
behavior should be considered undefined and unsupported. It is<br />
highly recommended that the play area be bounded by a wall or a<br />
series of walls leaving no holes.<br />
<br />
Also, while it it possible to define "holes" , ie<br />
completely bounded areas inside a bigger area, or "islands", ie<br />
independent bounded areas independent of another play area, these<br />
behaviors are undefined and unsupported.<br />
<br />
The Wall element has one attribute, the height. Controlling the<br />
height affect the rendering height of a wall. A height of 1.0 is<br />
about the same as the height of the original cycle model. A height<br />
of 4.0 correspond to the Walls rendered with the lowRim setting on<br />
the client. When no height is defined, the client defined setting<br />
of either lowRim or highRim is used. This has the advantage of<br />
respecting the players choice and often, capacity to render high<br />
walls. When a height of 0 or less (ie: negative value) is given, an unresonably large value is substitued.<br />
<br />
;''height''<br />
: The height used for the rendering of the Wall. Positive value only.<br />
<br />
Example : Using the client default height<br />
<pre><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="10" y="10" /><br />
</Wall><br />
</pre><br />
<br />
Example : Controling the height<br />
<pre><br />
<Wall height="2.13"><br />
<Point x="0" y="0" /><br />
<Point x="10" y="10" /><br />
</Wall><br />
</pre><br />
<br />
== Spawn points ==<br />
Spawn points are where cycles are first located on the map. At<br />
game start, the game server will spread the players and AI among<br />
the different spawn locations described. You should provide<br />
sufficient spawn location for the number of players you entered to<br />
play on your map.<br />
<br />
Along with the location where the cycles will be placed, you<br />
need to specify the starting direction of the cycle. This will<br />
determine the direction that the cycle is facing when it appears.<br />
<br />
To specify this, two methods are offered:<br />
Vector orientation:<br />
In this method, you specify the direction as a vector, from (0, 0)<br />
to (xdir, ydir). This will indicate the direction to be face by<br />
the cycle.<br />
Angle orientation:<br />
In this method, you specify the direction as an angle. Degrees are<br />
used for this.<br />
<br />
Because Armagetron is a game where motion occurs on certain axes<br />
only, starting direction should also be done on those axes. The<br />
game will use the direction described to find the closest matching<br />
axis. It is the direction of the chosen axis that is assigned to<br />
an spawned cycle. The direction specified is only used as a<br />
recommendation.<br />
<br />
A Spawn has six attributes. Only three to four are needed to<br />
describe a Spawn. Two of them, x and y, are mandatory.<br />
x= the x coordinate where the cycle is to be created<br />
y= the y coordinate where the cycle is to be created<br />
xdir= the x coordinate of the recommended direction the cycle will face at<br />
creation.<br />
ydir= the y coordinate of the recommended direction the cycle will face at<br />
creation.<br />
angle= the recommended angle to orient the cycle<br />
<br />
If the angle attribute is specified, xdir and ydir are<br />
ignored. When no angle attribute is specified, both xdir and ydir<br />
are needed.<br />
<br />
Example: Basic Spawn presentation<br />
<Spawn x="-15.5" y="368.0608" xdir="0.5" ydir="-0.866"/><br />
<Spawn x="-15.5" y="368.0608" angle="60"/><br />
<br />
Only the direction indicated is used. The size of the direction<br />
described doesn't influence the start up speed or displacement of a<br />
cycle.<br />
<br />
It is to be noted that specifying a direction of (0,0) is<br />
undefined. Also, specifying spawn points outside the play area<br />
that you defined is undefined and unsupported. <br />
<br />
== Zones ==<br />
Zone are interactive areas on the Field. They manifest themself as<br />
huge circles slowly rotating. The players can interact with the<br />
Zones by entering or being inside them.<br />
<br />
The Zone has an attribute effect which allows 3 values: win, death and<br />
fortress. Entering a Zone of effect win makes the player the round<br />
winner. Entering a Zone of effect death automatically kills the<br />
player. Zones of effect fortress need to be occupied to be<br />
triggered, and once triggered, they make the team the round winner.<br />
<br />
;effect<br />
:Any of win, death or fortress. When ommited, the value is defaulted to death<br />
<br />
Example: Zone syntax<br />
<pre><br />
<Zone effect="death"><br />
...<br />
</Zone><br />
</pre><br />
<br />
The Zone requires a sub element named ShapeCircle. <br />
<br />
The ShapeCircle has 2 attributes, the radius and the growth. The<br />
radius attribute describe the size of the CircleShape and is<br />
required. The unit used is the same game unit that are used as map<br />
coordinates. A ShapeCircle with a radius of 10 will extend of 10<br />
game units in every direction from its center.<br />
<br />
The growth describe how the radius of the ShapeCircle changes over<br />
time. This unit is game units per second from the moment the Zone<br />
is create, which is the round start.<br />
<br />
It is possible to specify a negative growth, in which case the ShapeCircle will<br />
slowly shrink. Should at any time the radius be of 0 or less, the<br />
Zone is removed without effect.<br />
The growth is optional and defaults to 0, which hold the<br />
ShapeCircle at a constant size during the round.<br />
<br />
;radius<br />
:The initial radius of the circle defining the Zone. This field is mandatory.<br />
;growth<br />
:The growth of the circle. The values can be positive, negative or 0. This field is optional and is defaulted to 0.<br />
<br />
Example: Zone with CircleShape<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20" growth="0.17"><br />
...<br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
The ShapeCircle requires a Point sub-element which describe the<br />
center of the ShapeCircle. The syntax of the Point is the same as<br />
the one used for the Wall.<br />
<br />
Example: A non-growing death zone<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20"><br />
<Point x="120" y="86"/><br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
Example: A growing fortress zone<br />
<pre><br />
<Zone effect="fortress"><br />
<ShapeCircle radius="20" growth="1.09"><br />
<Point x="250" y="7"/><br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
Example: A shrinking win zone<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="200" growth="-0.2"><br />
<Point x="440" y="325"/><br />
</ShapeCircle><br />
</Zone><br />
</pre><br />
<br />
It is possible and valid to place the center of the Zone in a<br />
location that is not accessible to the players, such as in a<br />
walled compound or outside of the play area. This behavior might<br />
change in future version. Consult the appropriate documentation.<br />
<br />
Example: A death zone outside the rim<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20"><br />
<Point x="-25" y="100"/><br />
</ShapeCircle><br />
</Zone><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="200" y="0" /><br />
<Point x="200" y="200" /><br />
<Point x="0" y="200" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
<br />
</pre><br />
<br />
Example: A death zone partially outside the rim<br />
<pre><br />
<Zone effect="death"><br />
<ShapeCircle radius="20"><br />
<Point x="-15" y="100"/><br />
</ShapeCircle><br />
</Zone><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="200" y="0" /><br />
<Point x="200" y="200" /><br />
<Point x="0" y="200" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
<br />
</pre><br />
<br />
Nota: It is important to note that while Zones are introduced in<br />
Arthemis, a more complete implementation will follow in<br />
Bacchus. Curious minds consulting the documentation presenting the<br />
Bacchus implementation of Zones will notice that fortress isn't an<br />
effect, but rather a trigger type. The Arthemis implementation of<br />
Zones falsely uses it as an effect instead of exposing a trigger<br />
mechanism. Map designers are to be warned this will no longer be<br />
possible in maps defined for Bacchus.<br />
<br />
=== Fortress Zone ===<br />
The fortress Zone is particuliar because it uses a scoring system<br />
to determine if and when the Zone is triggered. The score is<br />
affected by the time passed in it by attackers and defenders.<br />
<br />
At start time, the score is set to 0.0. While the score can move<br />
freely, 2 restrictions are always applied. First, the score can<br />
never drop below 0.0. Second, if the score reaches or exceed 1.0,<br />
the Zone is triggered.<br />
<br />
Each single adversary in the Zone add to the score for their time<br />
passed in it. Each single defender in the Zone remove to the score<br />
for their time passed in it. Also, the score always decays. Each<br />
of these aspect is controlled by a different setting,<br />
CONQUEST_RATE, DEFEND_RATE and CONQUEST_DECAY_RATE. They all<br />
express a rate in points per seconds.<br />
<br />
;CONQUEST_RATE<br />
: Any single attacking player in the Zone add points to the score at this rate. <br />
;DEFEND_RATE<br />
: Any single defending player in the Zone removes points to the score at this rate. <br />
;CONQUEST_DECAY_RATE<br />
: The score of a Zone decays at this rate, irrelevantly of the numbers of attackers and defenders in the Zone. <br />
<br />
These 3 settings are global for all the Zones on a map.<br />
<br />
Example: Configuring Fortress from the config file<br />
<pre><br />
CONQUEST_RATE 0.5<br />
DEFEND_RATE 0.3<br />
CONQUEST_DECAY_RATE 0.1<br />
</pre><br />
<br />
Example: Configuring Fortress from the settings in the map<br />
<pre><br />
<Settings><br />
<Setting name="CONQUEST_RATE" value="0.5"/><br />
<Setting name="DEFEND_RATE" value="0.3"/><br />
<Setting name="CONQUEST_DECAY_RATE" value="0.1"/><br />
</Settings><br />
</pre><br />
<br />
<br />
== Appendices ==<br />
<br />
=== Map writing best practice ===<br />
<br />
==== Comment your work ====<br />
<br />
You should always comment the various parts of your work. Doing so improve maintainability. Something that is obvious during the creation of a particular map often becomes very cryptic after a few weeks. A good comment allow you to quickly grasp the meaning of what is described.<br />
<br />
A comment in xml start with "<nowiki><!--</nowiki>" (without the quotes) and ends with "<nowiki>--></nowiki>". Comment can spawn on multiple lines. If your editor doesn't highlight the commented part, be careful not to exclude a part of your map by mistake.<br />
<br />
==== Arena size ====<br />
<br />
The original map is of size 500 by 500. Many servers have setting<br />
that are oriented toward this size, and players are used to battle<br />
in such an environment. <br />
<br />
A map that is significantly larger or smaller will require the<br />
server admin to affect the scale facter to be used with the map to<br />
preserve the gaming experience tailorder to the server. <br />
<br />
Also, arenas with many divisions or made of many interconnecting<br />
rooms might find the efficace play space shrunk. Giving them a bit<br />
more surface might help balance this. <br />
<br />
For example, if rooms are organised in a 3 by 4 pattern, with<br />
corridors connecting them, many of the space between the rooms is<br />
lost. The map designer might try to have a total<br />
surface of for all the rooms that is of 250 000 square game units<br />
(the same surface than a 500 by 500 room). He might feel that<br />
ignoring the surface of the corridors compensate for the large<br />
amount of walls reducing the motion.<br />
<br />
On the other hand, one could easily imagine a<br />
extremely large maze. In this instance, the true factor would be<br />
the corridor width rather than the total size of the play area.<br />
<br />
There are no hard rules of any sort about the size of an<br />
arena. Experiment and adjust to produce the effect desired, and<br />
the players will most probably appreciate your efforts.<br />
<br />
==== Don't overload attributes ====<br />
<br />
Certain elements of the map have attributes that are exclusive. For<br />
example, in the Axis element, when the attribute angle is defined, the<br />
xdir and ydir attribute are never queried.<br />
<br />
While the engine ignore the exceeding data, this practice has the following drawbacks:<br />
<br />
* File size: The exceeding information is never used, but need to be transmitted as part of the file, and stored.<br />
* Readability: Exceeding information complicate the reading of a map by humans. <br />
* Maintenance: Maintenance of the map is not much more complex. If the author is minimalist, he/she risk updating the part of information that is ignored. Extremely good knowledge of the working of the parser is required to avoid this pitfall, and the change is only valid if the rule of precedences aren't updated. Specifying only one set of information avoid this problem. Also, if both set of information are updated, then the task for the author is double, and so are the risks for error.<br />
<br />
=== Resource Filename Convention ===<br />
<br />
Resource are external content that makes the game interesting. Textures, sounds, models and maps are all resources for Armagetron Advanced. While at the time of writing of this tutorial, only maps are supported as true resources, soon support for the other types will be added. Also, while this section incorporated in the ''Maps'' tutorial, it might be moved as an independent document, and the standard described might be updated in a near future.<br />
<br />
For ease of administration, and to avoid conflicting versions all resources for Armagetron Advanced should adhere to the following naming convention:<br />
<br />
<pre><AuthorName>/[SubDirectory/]<ResourceName>-<VersionNumber>.<Extension></pre><br />
<br />
;AuthorName<br />
: The name of the person who currently maintains the resource; it needs to match the author attribute of the Resource element described above and either be a forum nickname on forums.armagetronad.net, a user name registered at the central resource repository, or an email address encoded as <code>unofficial/mailto/<Domain>@<User></code>.<br />
: Alternatively, the author can forgo his or her name and instead opt for a group-name. The group-name should be used when the author want to indicate that a set of resources are associate with a group. Instances of this could be when the resources are for a clan, a community, or a set of servers.<br />
<br />
;SubDirectory<br />
: Prolific authors and those are free to set up any number of sub directories to help them organize and possibly categorize their resources. The Armagetron Advanced team recommend you to categorize resources by topics (ie: all the resources required for a particular movie-pack set in the same sub directory) over other categorization, such as categorization by type (ie: all the floor tiles set in the same sub directory). Any number of sub directory level should be supported. This is not a mandatory item.<br />
<br />
;ResourceName<br />
: The actual name of the resource. This should be descriptive, and somewhat unique to facilitate identification of the described resource. The advantage of specifying a somewhat unique name here is that should the resource be accidentally moved out of its folder, it is still possible to quickly and easily identify it. A special note for maps: the ''ResourceName'' should be the same as the name attribute of the Map element defined in the xml file.<br />
<br />
;VersionNumber<br />
: This part should be used by the author to identify which version of the resource is described. During its life, a<br />
resource can receive many modifications and improvements. To find new resources, Armagetron Advanced rely solely on this part to be updated. Should a resource be updated and the old name kept, it would cause problems between different clients. Client already having the old resource would not get the modifications, as they would expect the content to<br />
be the same, and only clients that would not have a local copy of file would get the latest version. The actual format to be used for the ''VersionNumber'' is left to the choice of the author. While the Armagetron Advanced team recommend a <code>VERSION.MAJOR.MINOR</code> dot notation similar to those used for software's versions, any other notation can be<br />
used, such as a simple numeral: <code>GlowStick-1.png, GlowStick-2.png, ...</code>. Keep in mind that it should be obvious to other as to which is the most up to date version of the resource. A special note for maps: the ''VersionNumber'' should be the same as the version attribute of the Map element defined in the xml file.<br />
<br />
;Extension<br />
: This is the regular type of extension. While Armagetron Advanced doesn't verify that the extension describe the right type of content, it is favorable for other users that you set it to the appropriate type, and thus facilitate the usage of your resource.<br />
<br />
A few examples:<br />
<pre><br />
philippeqc/Firewall-0.3.2.png<br />
philippeqc/castle-6.aamap.xml<br />
TigersNetwork/CougarMoviepack/cougar-3.1.aamap.xml<br />
TigersNetwork/CougarMoviepack/PawTrace-floor-2.png<br />
AngelOfMercy-Clan/OfficialCycleMode-2.1.7.ace<br />
AngelOfMercy-Clan/trainingMap-6.aamap.xml<br />
</pre><br />
<br />
=== Resource repository ===<br />
<br />
When a player doesn't have the map being used on a server, their game will<br />
automatically download it from the resource repository. To add your completed<br />
maps to the official resource repository, go to:<br />
[[Resource repository]]<br />
<br />
=== Examples ===<br />
<br />
==== Parallelogram arena ====<br />
<br />
[[Image:Parallelogram-1.0.png|right|thumbnail|Parallelogram]]<br />
<br />
<pre><br />
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
<Resource type="aamap" name="Parallelogram" version="1.0" author="Philippe Villeneuve" category="example"><br />
<Map version="0.2.8"><br />
<br />
<World><br />
<!-- A variation on the classic arena --><br />
<Field><br />
<Axes number="4" normalize="false"><br />
<Axis xdir="1" ydir="0"/><br />
<Axis xdir="-0.2" ydir="-1"/><br />
<Axis xdir="-1" ydir="0"/><br />
<Axis xdir="0.2" ydir="1"/><br />
</Axes><br />
<br />
<Spawn x="265" y="50" xdir="0.2" ydir="1" /><br />
<Spawn x="335" y="450" xdir="-0.2" ydir="-1" /><br />
<Spawn x="99" y="245" xdir="1" ydir="0" /><br />
<Spawn x="501" y="255" xdir="-1" ydir="-0" /><br />
<br />
<Spawn x="325" y="100" xdir="0.2" ydir="1" /><br />
<Spawn x="275" y="400" xdir="-0.2" ydir="-1" /><br />
<Spawn x="139" y="195" xdir="1" ydir="0" /><br />
<Spawn x="461" y="305" xdir="-1" ydir="-0" /><br />
<br />
<Spawn x="225" y="100" xdir="0.2" ydir="1" /><br />
<Spawn x="375" y="400" xdir="-0.2" ydir="-1" /><br />
<Spawn x="159" y="295" xdir="1" ydir="0" /><br />
<Spawn x="441" y="205" xdir="-1" ydir="-0" /><br />
<br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="500" y="0" /><br />
<Point x="600" y="500" /><br />
<Point x="100" y="500" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
</Field><br />
</World><br />
</Map><br />
</Resource><br />
</pre><br />
<br />
==== HexaTRON ====<br />
<br />
[[Image:HexaTRON-0.2.png|right|thumbnail|HexaTRON]]<br />
<br />
The HexaTRON map has been developed by Luke-Jr for his HexaTRON<br />
mod on the code. It has a hexagonal flower and uses 6<br />
directions. Please note that this is version 0.2 of the map, and<br />
that many newer version have been published.<br />
<br />
<pre><br />
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><br />
<!DOCTYPE Resource SYSTEM "map-0.2.8_beta3.dtd"><br />
<Resource name="HexaTRON" version="0.2" author="Luke-Jr" category="HexaTRON"><br />
<br />
<Map version="0.2.8"><br />
<World><br />
<Field><br />
<!-- This is the Hexa map put in XML. This should work out of the<br />
box, ie: without changes to the aa engine code beside a flashy new<br />
parser. Errors might have been introduced during the conversion to<br />
XML by philippeqc, for your debugging amusement --><br />
<br />
<Axes number="6"/><br />
<Spawn x="99.5" y="73.612159" xdir="-0.5" ydir="0.866"/><br />
<Spawn x="-15.5" y="368.0608" xdir="0.5" ydir="-0.866"/><br />
<Spawn x="198.333333" y="196.29909" xdir="-1.0" ydir="0"/><br />
<Spawn x="-114.333333" y="245.37387" xdir="1" ydir="0"/><br />
<Spawn x="141.666666" y="343.52341" xdir="-0.5" ydir="-0.866"/><br />
<Spawn x="-57.666666" y="98.149545" xdir="0.5" ydir="0.866"/><br />
<Wall><br />
<Point x="0" y="0" /><br />
<Point x="85" y="0" /><br />
<Point x="127.5" y="73.612159" /><br />
<Point x="212.5" y="73.612159" /><br />
<Point x="255" y="147.22432" /><br />
<Point x="212.5" y="220.83648" /><br />
<Point x="255" y="294.44864" /><br />
<Point x="212.5" y="368.0608" /><br />
<Point x="127.5" y="368.0608" /><br />
<Point x="85" y="441.67296" /><br />
<Point x="0" y="441.67296" /><br />
<Point x="-43.5" y="368.0608" /><br />
<Point x="-128.5" y="368.0608" /><br />
<Point x="-170" y="294.44864" /><br />
<Point x="-128.5" y="220.83648" /><br />
<Point x="-170" y="147.22432" /><br />
<Point x="-128.5" y="73.612159" /><br />
<Point x="-43.5" y="73.612159" /><br />
<Point x="0" y="0" /><br />
</Wall><br />
<Wall><br />
<Point x="127.5" y="73.612159" /><br />
<Point x="113.333333" y="98.149545" /><br />
</Wall><br />
<Wall><br />
<Point x="212.5" y="220.83648" /><br />
<Point x="184.166666" y="220.83648" /><br />
</Wall><br />
<Wall><br />
<Point x="127.5" y="368.0608" /><br />
<Point x="113.333333" y="343.52341" /><br />
</Wall><br />
<Wall><br />
<Point x="-43.5" y="368.0608" /><br />
<Point x="-29.666666" y="343.52341" /><br />
</Wall><br />
<Wall><br />
<Point x="-128.5" y="220.83648" /><br />
<Point x="-100.833333" y="220.83648" /><br />
</Wall><br />
<Wall><br />
<Point x="-43.5" y="73.612159" /><br />
<Point x="-29.666666" y="98.149545" /><br />
</Wall><br />
</Field><br />
</World><br />
</Map><br />
</Resource><br />
</pre><br />
<br />
=== About the "undefined and unsupported" ===<br />
<br />
Many possible combinations are marked as ''undefined and unsupported''. While it may be possible to do them now, and even amusing to do it, they are strongly discouraged. Later version of the World format will most probably conflict with those behaviors. This will make such behaviors difficult to preserve, if possible at all. For this reasons, it has been decided that '''no''' effort would be put to maintain them. Use them if you want, but do not come complaining if and when they stop working.</div>AndySquirrelhttp://wiki.armagetronad.org/index.php?title=User:AndySquirrel&diff=21395User:AndySquirrel2008-04-03T23:28:34Z<p>AndySquirrel: New page: This page now contains text!</p>
<hr />
<div>This page now contains text!</div>AndySquirrel