The designers created the map using Tiled Map Editor v0.5.1. The output of this software is used in the tools/maps section. At that time (and thus in the export scripy), the tmx file was "all XML" (or was chosen to be so to facilitate data processing). But files are really big and by default some of the element are filled with a binary blob. Tiled map editor can either generate (see software preferences):

• XML (big files, interpreted by the export script);
• XML w/ base64 blobs (not handled);
• XML w/ base64 gzipped blobs (not handled);
• XML w/ base64 zlib zipped blobs (not handled);
• csv files (not handled). The gzipped versions can be 300 times smaller than their XML counterpart, yet to this day the only format handled is the all XML. Make sure the "saving" settings are right in order to be able to export the maps.

Once inside browserquest each tile can be identified either:

• by its (x,y) coordinates ;
• by a unique Id ((x+1) + map_width*y)

In tiled map editor, there are mainly two types of object layers that can be superimposed: areas and tiles.

• ← Areas/Objects Areas can store various information (right-click on a given area to get its properties). The default properties are name, type, position (x,y) and size (height, width). The user then can create ad hoc properties, giving them name and value.
• ← Tiles The meaning of each layer (and each object in each layer) is dictated by some info added in the file.

A map should have the following layers (see processmap.js):

• checkpoints
• music
• blocking
• plateau
• roaming
• doors
• chestareas
• chests
• entities
• Terrain (a variety of sprites and landscape tiles), only the ticked (✔) layers will be included in the final map
• don't remove this layer

The following layers seem to be used for the developer's convenience, but are not exported to the game :

• zones ← used to see screens in the map editor
• mobile zones ← used to see mobiles screen in the map editor (when the player pass a door, the framing can be different)
• portals ← used to see portal doors in the map editor

The map editor uses tilesheets to associate with every tile you select a certain pixel set. The tilesheets are linked to the map by means of a relative path. The original maps will use :

• tools/maps/tmx/mobset.png → relative path: mobset.png
• client/img/1/tilesheet.png → relative path: ../../../client/img/1/tilesheet.png Whereas mobset is not necessary (yet see below the use of the 'entities' layer), it is crucial that the tilesheet (called tilesheet) is indeed the same as the one in the above directory.

###Tile properties Each tile of each tilesheet in Tile Map Editor can be assigned a set of attributes. Depending on the concerned tilesheet, the set of attributes is different.

Mobset: Whether they are NPC or items, every tile in the mobset is assigned a "type" property. The name will be reused afterwards in the code to define the sprite associated and the properties of the object (NPC or item).

Tilesheet: terrain tiles can have various properties (valueless attributes)

• none : user can tread on the tile;
• 'c' → closed(?): for walls and other sprites which block the player;
• 'v' → visible(?): the user can share the tile with the object, but the object will remain visible over the player (typically used to allow the player to walk behind the top of the trees or houses).
• 'length' → animated : animate using the X sprites on the right of the tilesheet (the beach waves for example)

This is used to create zones of "roaming" enemies. They will be placed randomly in the area, and behave according to their class.

The type of the area will bear the name of the class of "mob" to place in the zone.

The nb property says how many enemies should be added. (NB: there might be limits regarding the density of population in the area, haven't checked that yet…)

Each screen is a 30 tiles x 15 tiles portion of the map. The zones layer contains a sum of such rectangle. It does not appear to be used when the map is processed, but just to show the screens to the user and where they overlap. In the game screen change when the user reaches the edge.

This type of zone is pretty self-explanatory. Each door teleports the user to another spot in the map, thanks to its properties :

• cx: camera position → (coordinates)
• cy: camera position → (coordinates)
• o: orientation → 'u' up, 'd' down, 'l' left, 'r' right
• x: exit position → (coordinates)
• y: exitposition → (coordinates)

In the following illustration, a 30x15 screen is displayed. By convention, the camera always is separated by 7x7 tiles from the bottom left corner of the screen.

In the following screen, the door is situated at mid screen and the room is centered. The door is on tile (126,143), hence the origin (bottom left corner) at (112,145) and the camera will be at (112+7,145-7) = (119,138). From the bottom-left corner we move right (x+7) and up (y-7). To sum up, a door pointing to this room will have the following attributes:

• cx: 119
• cy: 138
• o: u ← the character looks up when going in through the door
• x: 126
• y: 143

todo

todo

todo

some notes on using the Tiled Map Editor to make a new map for particlequest (pretty general notes)

• for our style of game, select the "orthogonal" projection type.

• those layers are comprised of tiles, and the tiles are imported from images outside the program (ie, they

• the browserquest/particlequest game takes the original imported image (ie, the png/bmp) PLUS the tmx file. the TMX file is basically an xml-formatted set of instructions about how to take the contents of the image, and generate the map in the game. (ie, coordinates of specific tiles etc.)

cf. server/js/map.js: generateCollisionGrid: function() …

eg. i think the process to make collision tiles:

• set a layer property (ie, in the existing game, property "c" gets processed as a collision tile). add this property to as many layers as you want to act a collision tiles.
• those properties get processed via the processmap.js file.
• we could customize the processmap.js file to change the property and/or add different properties.

processmap.js recognizes the following property types:

• "type" (property.name = "type" and property.value = static entity ID (possibly from the shares/js/gametypes.js file?)
• "c" (collisions) (client and server)
• if mode === "client":
• "v" ==> map.high.push(id) (maybe this means that this tile is "high" or on top?
• "length" - seems to relate to animation
• "delay" - also for animation

processmap.js also recognizes Tiled layers named

• "roaming" (server)
• "chestareas" (server)
• "chests" (server)
• "music" (client)
• "checkpoints" (client and server)
• blocking (client)
• plateau (client)
• entities (server)
• visible layers that are !entities (client and server)

the script adds info about each layer to the map object (which is defined differently depending on whether it is the client or server running the script).

and processes them as server-side map info. each of these "areas" is pretty custom to the properties/info that's been added in Tiled. so we should be careful in editing it to understand what the side-effects would be. naturally there are game dynamics that rely on each of these map layers, so the easiest thing would be to use the same categories. renaming them wouldn't be hard but creating our own or removing certain layers would likely be more involved (to varying degrees - TBD! haven't looked at this code closely).

• import a random jpg and save it as the tile layer

• create an empty layer and put it at the bottom as per tools/maps/README.md

• create a new layer called collisions, and put some tiles in it.

• right click the collisions layer and select "layer properties..." create a new property with name "c" and value "true".

• save the map. it saves as a .TMX file automatically.

• create a new repo branch, eg. git branch maphack; git checkout maphack

• if you haven't already set up (optionally, virtualenv, and) pip.

• install the prerequisites in tools/maps/README.md. virtualenv is optional and definitely overkill if you don't use python for other things. but if you do any regular python development, it is completely indispensable. highly recommend taking the time to install it.

• sudo easy_install pip

• sudo pip install virtualenv

• sudo pip install virtualenvwrapper

• follow virtualenvwrapper initialization steps here

• create a virtual env for particlequest (eg. $ mkvirtualenv pq), and enter that virtual env ($ workon pq).

• pip install lxml (will install it in the virtual env if you are in it)

• the tools/maps/export.py has been modified to take an input filename as an argument.

• export.py filename.tmx [server|client]

• the output of the command is to create/overwrite ../../client/maps/world_client.js/json (client) or ../../server/maps/world_server.json (server).

• so MAKE SURE YOU SAVE/BACKUP ANY MAPS YOU DON'T WANT TO CLOBBER

• assuming the TMX file was saved into the repository's media/ directory, cd into tools/maps/ and run

• ./export.py ../../media/lhcmap_exp1.tmx client

• ./export.py ../../media/lhcmap_exp1.tmx server

• currently, running this gives me an error. it seems that the default map (tools/map/tmx/map.tmx) has a bunch of data layers. the tiled wiki page documenting the TMX format has a section the <data> tag. not sure how/if we want to create these yet!

• to be continued... !

Useful/relevant articles:

• http://www.raywenderlich.com/1163/how-to-make-a-tile-based-game-with-cocos2d
• http://www.raywenderlich.com/1186/collisions-and-collectables-how-to-make-a-tile-based-game-with-cocos2d-part-2
• http://silveiraneto.net/2009/01/11/game-map-edition-using-tiled/