Creating Mini Map of Isometric game world



I was going to take a shot at another gui element.

A mini map for an isometric game.

This kind of thing could double as a range finder, target finder, map, etc.

So, it seems like it would have a general enough use.

Anyway, I was looking through the wade docs and don't have a good idea of where to start.


Init a second iso engine but draw to a different layer ?

Write code  that duplicates all the iso drawing stuff but draw to a different layer ?

Do some sort of screen capture and then shrink the image down ?


If you could point me in a direction, I would appreciate it.


thanks for any help,


All 30 Comments

Hi Shri


That sounds like a very good idea, I'm sure it would be extremely useful in lots of situations.


The best way to do it I suppose depends on whether you want to make it static or dynamic. Static is fast, dynamic is cool - I don't know which aspect is more important, on a mobile device probably being fast would be preferable, but it depends.


Using some sort of screen capture for the static map would be sensible - interestingly, screen capture and drawing the screen or a layer to a virtual image (that you can the use in a sprite) are features that we are adding to WADE 1.2. It's about 10 days away, so I don't know if you want to wait for that. That would be the easiest way (really just a few lines of code), but not necessarily the fastest, especially for dynamic maps.


A slightly more complicated but probably faster implementation (which you could do with the current version too) would be this:


You could call wade.getSpritesInArea(area, layer) for an area that covers the whole world (or the part that you want to show), and for the terrain layer (wade.iso.getTerrainLayerId()). This would give you an array with all the terrain sprites. For each of them, you could get its position and size, and multiply them by a scale factor of your choice, and draw them to an image using Sprite.drawToImage() - you can pass in a position and scale factor when drawing to an image.


You could then use this image to create a new Sprite, which is your mini map.


If you want a dynamic map, you do this thing again every frame (or every so often, or whenever the map changes), but you don't need to create a new minimap sprite every time (drawing to the source image of the existing sprite will update it automatically).


It would be very easy then to give it different shapes, using a composite_() draw function, so you could have circular minimaps for example. It would be really cool, if you want to do it I'll be happy to help with some code.




Thanks for the help.

I think the dynamic version you suggested is what I had in mind.

I have started fooling around with a demo.


You mentioned wade.iso.getTerrainLayerId() as returning an array ? Doesn't that just return a number (the layer id) ?

I have looked through the iso documentation and I don't see anything that returns an array with all the terrain sprites ?

That would be nice, otherwise, it seems I would have to 'walk' the grid and call wade.iso.getTileData(). Then position and scale.


I'm also a little vague on how Sprite.drawToImage() works. Specifically the virtual path parameter.


Anyway, I will continue to fool around with it a let you know when I have something.


have a nice weekend,





Sorry for the confusion, I meant:

  • wade.iso.getTerrainLayerId() returns a number, the layer id, as you said
  • wade.getSpritesInArea(area, layer) is a function of the core WADE module, not the isometric module (that's why it isn't in the isometric documentation :) )

In fact, there is no reason to limit this to isometric games only - you could do it so that you pass in one or more layer id's and a radius, and it draws a map of everything that's in those layers and within the radius.


Regarding drawToImage - I know it can be a bit confusing, but it's a really powerful feature. The idea is that you draw to a sprite to an image, like this:


Which will draw your sprite to 'test.png. The point is that 'test.png' isn't necessarily a file on your disk - it doesn't need to be a physical file at all. You could use any name for the image you are drawing to, it isn't actually going to physically create or write to a file - that's why it's a virtual path. But you can then use this image as if it was a real image, to create new sprites. The cool thing is that you can draw to an image multiple times without necessarily having to clear what's there. You can use a second parameter (a boolean) to tell WADE that you want to completely overwrite the image with that name (true), or just write on top of it (false).


You can the pass a few additional parameters to this function, if you want to customize the drawing process: you can change the scale and position, rotation, skew and blend mode. In your case, you only care about the scale and position.


So something along the lines of this:

var generateMap = function(layerId, radius){	// create a transparent sprite that's as big as the map	var transparent = new Sprite();	transparent.setDrawFunction(function() {}); // set a draw function that does nothing, it's a transparent sprite	transparent.setSize(miniMapSize.x, miniMapSize.y);		// draw the transparent sprite to our target image, overwriting anything that's there	// the true parameter implies taht the 'miniMap' image, if it exists, will be destroyed and re-created.	transparent.drawToImage('miniMap', true);		// define an area around the camera        var cameraPosition = wade.getCameraPosition();        var area = {minX: cameraPosition.x - radius, minY: cameraPosition.y - radius);		// get an array of sprites in the area        var sprites = wade.getSpritesInArea(area, layerId);		// draw all the sprites to the miniMap image (without recreating the 'miniMap' image)	for (var i=0; i<sprites.length; i++)	{	    // work out position and size and draw to the image            ......            sprites[i].drawToImage('miniMap', false, ...... )	}	}

After generating the map, when you want to use it, you simply do:

var mapSprite = new Sprite('miniMap');

This is just an example, but in reality it would be nice to have the option to use an array of layerId's, and be able to customize the map as much as possible (different width and height, but also different shapes)




Thanks for the clarification and the code. After reading your email carefully, and fixing a couple of boneheaded programming errors, I was finally able to get something up and running.


I'm not sure what I am doing wrong on the transforms and offsets ?

Also, there is some wierdness going on when you resize or move the map ?

I have attached the zipped file of what I have so far.





Hi Shri


I have tried your code, and it seems that there is a bug in Sprite.drawImage - sorry about that. It will be fixed in the next release, but in the meantime you can include this patch file I have attached (patch.js) just after loading wade.js




I have spent some time playing with it, and noticed that even after applying Gio's patch (which made things better), the sprites didn't end up in the right position.


So I've changed one or two things. It took me a while to do all the math, but it seems correct now.


Gio, I have included wade and wade.iso in the zip file, is that a problem? If so, feel free to delete my attachment and I'll post it again without the engine files.


Elliot, thanks for your contribution.


Having wade and wade iso in the zip isn't a problem at all. In fact, it makes things easier for people who want to download the zip and try it, so please keep it that way.




Thanks for pitching in.

I downloaded your zip and tried and it looks excellent !


I didn't get anything done on it today because I started a slider control the other day while I was waiting to hear back from Gio.

I posted that and will have a look at improving the mini map tomorrow.







I have been working on the minimap

- works with multiple layers, added some iso objects and they are on the map

- made the map configurable through a json file similar to the other gui stuff I have done

- map updates through a timeout loop

- general code cleanup and commenting


Between the engine patch and Elliot's help it was pretty easy to make progress.


I will continue to work on it, regarding the composite functions and some other stuff I think will make it better.


see post below for zip file








I'd like to contribute too, but it's already really cool.


The new version is great for a fully dynamic map, but if you want a static (faster) map that doesn't need redrawing so often, you could draw a big map once, and then redraw the single map sprite every frame... having an option to do that would be brill, making it more useful for mobile games




You can now set the shape of the mini map

Look at the composite field in the json file. Setting this to  "none" will give you a standard rectangular shaped map.

If you set the composite field to any other value, ex: "true", then you have to define a draw function for your transparent

sprite in the setGuiShape function. Then when the map sprites are drawn to your image buffer, the "souce-atop" composite

string will draw your map into your shape.


If that sounded like rambling nonsense, then just check out the the miniMap.js and  miniMapData.json files in the zip below.

When you run the demo, the minimap should have a circular shape and be in the bottom left corner.


I also added an effects field in the json file. If I have time, I will try to integrate image effects into this.


Hermes - you're more than welcome to contribute, but I didn't exactly follow what you meant in your post.

I suggest you simply download the zip, make changes with comments like  /* Hermes was here */ and then we can figure out how to reintegrate later.




OK, I realize my explanation above was somewhat confusing... I've downloaded the latest version and will now try adding the option I was talking about.




Added the ability to apply image effects to the map.

Actually, it was so easy I didn't really have to do anything.

1. include the ifx plugin / library

2. modify the html test file to load the ifx plugin

3. add 3 lines of code to the miniMapTest file in the updataMiniMap function.


Gio, I figured it would be ok to add the ifx plugin because you were ok with the iso stuff.

If you run the demo now, the map appears in grayScale.

I have deleted the zip above and included it here.




OK, I downloaded it and had a quick go at changing a couple of things.


First of all, I wanted to say: great job! :) It's a really nice and useful thing.


Here's what I've changed:


  • I have updated patch.js to include a couple of other bug fixes that will be released for WADE 1.2 (but with the updated patch.js you get these bug fixes now).
  • You pass an options object, slightly different to the previous version:
    - width and height in pixel
    - it contains the layer id where you want to create the map sprite
  • The behavior creates a sprite that is then added to the parent scene object. So the user controls the position of the parent scene object directly to do whatever they like with the minimap (move it around, etc).
  • The update is managed internally by the behavior (using an onUpdate event)
  • You use the "effect" parameter in the map data to say which image effect you want to use. You can also omit it. If the user doesn't have the ifx plug-in, it will be ignored.
  • You pass the layers that you want to use to the behavior together  with the rest of the data (no need to call a separate function)
  • You pass all the options through onAddToScene, no need to call an initialize function

I believe this makes the minimap more "self-contained" and overall easier to use.


A couple of further improvements I'd like to suggest:

  • The API for the minimap behavior could be cleaner, at the moment it's all public, but you probably want things such as and this.guiSize to be hidden from the user, so I'd make the things that you don't want to show local variables, rather than member variables, and expose only the things that the user is supposed to interact with.
  • If I understand what hermes said above, I think that may be a good idea (have an optoion to redraw the map less often, not every frame... but reposition the map sprite whenever the camera moves)... is that what you meant, hermes?

Regarding the ifx plugin: it's OK to include it in the zip, like the iso plug-in.


It's looking great, so keep it up :)


Hi again


I had some time today, so I decided to implement the features that Gio and Hermes suggested. I found it a bit difficult and, since I ran out of time, I couldn't really clean up the code, so I apologize if it's a bit messy.


I have added these features:


1) an updateInterval option: this is how many seconds you want between each minimap update. If you set it to 0, it will never update the minimap. However, the minimap is now drawn to a larger sprite, so when you move, it shows you only the relevant portion of this larger sprite. If you move "too much" (beyond the area of the minimap that has been drawn to the larger sprite), it regenerates the minimap.

2) you can have an array of object names that you want to exclude from the minimap

3) following Gio's suggestion, I changed a lot of member variables into local variables, so the interface should be tidier

4) the minimap will not be regenerated if you haven't moved since the last time it was generated. But there is an option that you can set (forceUpdate) if you want to always regenerate it.

5) all the options that you pass to the minimap behavior are optional, i.e. there are default values.


I think the code still needs cleaning up and commenting (sorry, I didn't have enough time). Besides that, is there anything else that is worth adding or that you would like to add?




Thanks for pitching in again.

All great ideas and it looks good.

However, I tried the code with the line "forceUpdate": "true", and the demo got really "laggy" and unresponsive.

Did you notice that ? or is it just my machine ?

It seems like it has something to do with that flag, because when I remove forceUpdate, everything works fine.

Looking at the code, I can't understand why that is ?

Maybe you don't even need that option and instead make the game programmer call the generate map function if they want to force a reload ?


I was also curious as to how much time / memory you save by not refreshing the map on every update versus only on moving.

It seems like only updating when necessary as you have done it is more efficient, but I wanted to know the details if there are any.

Maybe that is more a question for Gio.


Anyway, I still like the changes.



Elliot, that's precisely what I meant.

I'm sorry I couldn't contribute, I did try but it probably was just too difficult for me:)

Ideally, by choosing an appropriate radius, you could now generate the whole map once and just move it around. It would be quick, and suitable for mobile applications. Thanks for doing this, guys!
Well done both of you!

Do you mind if I clean it up a bit and add it to the market?

I'd like to mention it in the newsletter that goes out when we release WADE 1.2.

Shri: from what I understand, running it with forceUpdate does pretty much the same thing that it used to do (i.e. it renders the whole thing every time). But in the current demo, the map is large and the radius is even larger, so doing that every frame is slow.

I believe it can be optimized a bit too, I'll see what I can do. Would you be able to create a pdf like you've done for the other behaviors?




Feel free to add it to the market.

The graphics are from this site

And he says that they are freely reusable, but I still give him attribution when I use them.

If you use your own graphics then you don't have to worry about that.


I have attached the zip file of the code that I had cleaned up and was about to release when Elliot posted his changes (doh !).

I haven't integrated all of Elliot's changes because I was waiting to see what was up with the force update.

I still think it would be better to have this as a call exposed through the api rather than through the configuation.

The code is cleaned up and should be pretty easy to integrate with Elliot's changes.

I have also attached the pdf file I was going to post. It does NOT have Elliot's changes, so you will have to modify some sections based on his changes.




It is great that you do this. It works perfect even in not isometric game!


I am still learning wade, when I have learned something I contribute too.




Could both of you (Shri and Elliot) please confirm that you're happy with the minimap behavior being released under the MIT license?


If so, it'll be available in the Market on Thursday, when we release WADE 1.2, and it will be mentioned in our newsletter.


If you don't mind, I'm changing the demo a bit, to use Clockwork Chilli's assets and simplify the code.






The MIT license is ok with me.

I figured you would 'Chilify' the demo and the documentation, so that is also ok.


As an aside, will the code in the marketplace be minified or obfuscated ?

If so, I would like to get a final version of the source so I can see your optimizations to improve my own coding.


If you want to pursue future efforts like this, you may want to explore adding a separate area to the web site ?

Or maybe setup something on github ?


thanks, it has been a pleasure working on this with you



The code won't be minified, I think it's better to leave it as it is in case people want to change things. In general, if something is opensource (MIT, GPL or otherwise), I think it's always better not to minify or obfuscate it.


I haven't really changed much in the minimap behavior itself, I mainly changed the test demo to make it a bit simpler - I like the word Chillify, I'll start using it now :) This also gave me an opportunity to review the iso plugin and make a couple of minor changes to it.


There is indeed a plan to add a new area to the website - this is the same thing I mentioned a couple of times in other threads, referring to it as a new way of sharing games on this site. It can be used to share other types of projects, such as this one too. I am not working on it myself, but the guy who's doing it says it should be ready in a couple of weeks time.


Having said that, it's still worth adding a "WADE Behaviors" category to the Market, which is what we'll do from Thursday. The main difference is that there will be some sort of "quality control" from Clockwork Chilli for the stuff that ends up in the Market, whereas things that you share with the other method are completely unmoderated.


Hi Gio


Yes, the MIT license is OK with me. I hope it helps some other wade users.


I'll try to think of some more UI behaviors to make


In fact the official release with the newsletter and all that will probably be tomorrow (fixing some bugs took a bit longer than anticipated), but in the meantime here's the final version of the MiniMap and demo.




Downloaded it and took a look. Very cool.

I looked around for a key to see if I could open the door and watch the hero get eaten, but no luck.

It looks like there are some new tricks in the engin/plug-in for setting up scene objects via json.


I pulled down all my previous versions of the so people would only download the final version.


Anyway, looks good,



Ah yes, a key would have been cool! But I had to keep it simple and quick :) But I thought the door would be an entrance to a dungeon or something, with the monster being above it - I just wish I had the time!

I removed the previous zip and replaced it with this one which contains a small fix. 


Once again, thanks very much for sharing the minimap code


EDIT: Updated again (with the final version of wade 1.2). To try it go here.

Very cool, a big thank you to all those involved!
I was away for log time, too busy. But minimap looks very good and i will find time now to help you with these gui stuff which you do. Even if i canot code very good like you :D i looked the code and looks very nice and easy to understand.
food = 
food["doughnut1"] = "chocolate"
$stdout.puts food["doughnut1"]


Post a reply
Add Attachment
Submit Reply
Login to Reply