#Zelda overworld map designer full#
#Zelda overworld map designer pro#

I started out hand-coding the map data myself, but this soon proved to be the gateway to madness, and I decided that I needed to build a map editing tool. Once the code for the new map was done, there was still the matter of encoding the map data in a way the Map/MapScreen classes could use. The code for both Map and MapScreen is here: map.js, and the data file is here: mapData.js Map and MapScreen both contain draw() methods that take an HTML Canvas 2d drawing context as a parameter, and which take care of drawing themselves when requested. Each MapScreen object knows its (x,y) position within the larger map, and contains a 16x11 array of cells, each an (x,y) coordinate pair representing that cell's source tile in the global 'tiles' image. Now came the long & tedious part: encoding the map as a data structure! I let the above structure inform my design decisions, creating a Map class with: a current property to contain an x/y pair representing the currently visible screen within the map, and a 16x8 two-dimensional array containing MapScreen objects each of which = a 16x11 matrix of 16x16 tiles.I chose to go one step further, subdividing the map into individual screens, and each screen into its component tiles. We can reproduce the whole thing by using a 2-dimenional array of 256x88 tiles, 16 pixels square.

#Zelda overworld map designer full#

in fact, these 79 tiles cover all the bases! As I said before, the full map of Hyrule is 4096 pixels wide by 1408 pixels high. What I discovered was that the game overworld uses a surprisingly sparse number of tiles to do its job.

#Zelda overworld map designer pro#

So, armed with my trusty copy of Paint Shop Pro 7, I started slicing up the map.

Use a 'tile' approach to limit image size in memory.Use two canvas layers to separate background from sprites (so player and enemy movement won't trigger a background redraw).Only repaint the background image when it changes (not every game tick!).So I went back to the drawing board, and came up with several design considerations:

Needless to say, upon reflection, that looked like a really bad idea. My first stab at the game used a single, huge (4096x1408) PNG image (downloaded from here, forgot to mention that last time) as its map, and I kept track of an offset to the current screen's position on the huge image, which the main program loop would repaint on the canvas every single game tick! Eeek! When I started researching and brainstorming solutions to the challenge of hit detection, not to mention the game's overall memory footprint, I realized I had a problem. Last time, I talked about how I had started working on a clone of the Legend of Zelda in a pure-JavaScript aesthetic.