This gets in the way of other libraries doing things and it causes unexpected results. For example, I'm trying to use d20.js but any time I use their roll function, I get this:

41function () {
    if (!this.length) { return null; }
    return this[Math.floor(ROT.RNG.getUniform() * this.length)];
}function () {
    var result = [];
    while (this.length) {
        var index = this.indexOf(this.random());
        result.push(this.splice(index, 1)[0]);
    }
    return result;
}

i think it would be a good idea to give the option to scale tile based games.

For example, here:

I copied listed numbers and got a compiler error (error CS1525: Unexpected symbol```<internal>' — yep, I'm trying something in Unity3D) which costs me about half an hour to trace. The problem is Unicode minus symbol instead of -. Since they both look quite the same in the monospaced fonts it is hard to spot.

Normally I vote both hands for proper typography characters wherever possible, but this seems an exception to me. If you agree, I'll make PR with suitable replaces.

Has anyone tried using rot with NW.js ? (aka node-webkit)

My NW application was crashing and I pinpointed the problem to rot (not sure exactly where within rot however; and to be fair perhaps the problem is with NW).

I found that if I include a var rot = require('rot-js') and then do anything related to changing the NW window object the application will crash. If rot is not included, changes to the NW window object happen AOK.

For example, if you want to change the size of the window in NW you do something like this:

var gui = require('nw.gui'),
    win = gui.Window.get()
win.resizeTo(800, 600) //< this will crash the app if you also require('rot-js') somewhere

So perhaps some global conflict with "Window" ?

Tested and definitely crashes with the latest NW.js v0.12.1 (based off of IO.js v1.2) 64 bit Linux build. However, it doesn't crash on the alternate version; node-webkit 0.8.6 (based off Node v0.10, older Chromium)

Is it possible to have text based (html) instead of canvas? If no is it possible to add some code on top of rot.js without the need to fork and modify the core?

Does creating new ROT.Display that work with html instead of canvas will work?

I use Windows 8.1, and the latest Chrome.

When I open the manual and click on a link like "Interactive Manual", it takes me to the directory that the manual is in. I then have to click on "index.html" to open it. This is because Chrome does not treat local web pages like a web site, and infer the existence of default pages - which to be fair is the prerogative of the web server.

Going to the Interactive Manual, clicking on "Map Creation" and having it open up and seeing "Maze", "Whatever" and "Dungeon", nothing happens when clicking on them.

Color.hsl2rgb() is supposed to return integers in the range 0..255. However not all code paths return rounded numbers -- specifically for greyscale values. This causes problems when the resulting numbers are converted to rgb and then hex.

Fix seems to be simple -- change the line:

l *= 255;

to

l = Math.round(l*255);

I've done that in my local copy and it worked perfectly for me.

Hi there!

I was recently looking at some old 7DRL submissions and came across the code for Beware of the Space Bears (which uses the ROT lib). I noticed that the author was using an undocumented option for the Cellular dungeon generator called "connected". When I looked at the Cellular generator code, I did see evidence that this has been implemented (though is not documented).

My assumption (based on the comments in the ROT code) is that this is meant to connect all parts of the generated "cave". However, I can't seem to get it to work...

Can someone tell me more about this feature and why it's currently undocumented? Is it known to be broken or might I be misusing it?

Thanks!

Add onClick(x, y) and onHover(x, y) callbacks to level and/or display.
Maybe even onSwipeProgress(x1, y1, x2, y2), onSwipeEnd(x1, y1, x2, y2) and so on for pinch for touch devices.

Greetings,

as an alternative dungeon generator, have you considered the original rogue algorithm: http://kuoi.com/~kamikaze/GameDesign/art07_rogue_dungeon.php

T.

I'm wondering if any work was being done into better unicode support, specifically support for the box drawing characters. Gives a nice clean look to dungeons, when they render correctly. I'd really like to submit a wall drawing function to call as a digger parameter, but honestly it's not worth the effort without special wall characters.

It appears that ROT.Display.Tile.prototype.draw will draw an image if passed in using tileMap and tileColorize for the tile, but hexes don't (likely because of the complex geometry of building a tile map of an image). Any suggestions on how best to add in similar capability for hexes so as to align to the functionality found in: http://ondras.github.io/rot.js/manual/#tiles

• support for colored/bgcolored text
• support for returned value (number of lines?)

I'm very interested in using some classic rogue tilesets with Rot.js. Because rot.js is already using canvas and drawing letters into it, it looks to me that supporting blits from a sprite sheet should be a minor change. I'm thinking about passing it in as an option into ROT.Display (as opposed to creating a separate backend). Or would it be better to make a whole new backend? All of the layout logic is identical, it's basically just a tweak to fillText() calls in the backend's draw() implementations.

ROT works nicely for languages that are written left-to-right in a non-connecting script. It handles Unicode just fine (as long as the browser does) so that covers a lot of ground. However, two areas that I believe would open this up to a much broader global audience would be support for a native right-to-left rendering and the ability to nicely display characters from languages that use cursive scripts (such as Arabic, Farsi, Hindi, etc). This ticket is for right-to-left rendering to keep the issues able to be separately pulled.

Issue

The issue is that if an author wants to include text from a non-left-to-right language, ROT does not work. The author has to reverse the text before displaying, as well as do all their computations for layout based on where the end of the word should fall, instead of where it should start.

I have some ideas for rogue-likes based in the Middle East which cannot be implemented using ROT without support for right-to-left languages. There are possible work arounds, such as simply flipping every String I'd want to display, but that would make internationalization a lot trickier.

Proposed Solution

One solution would be to mess with ROT.Display.drawText to reverse a string if passed a particular boolean, or have a ROT.Display.drawReversedString method. I do not believe this is optimal because it will complicate a rogue-like author's work for figuring out text placement and layout. It also requires the author to call the right functions based on the language to display, instead of relying on code that reads the same regardless (which is what one would want for an internationalized game). The upside to this solution would be that an author can include "flavor text" in a game containing a different script without having to create an entirely new canvas.

Due to ROT's design, I believe this can be solved relatively easily by adding a variable (rightToLeft) to the ROT.Display.options hash and checking that in the relative drawWithCache or drawNoCache functions. What we'll do is to draw the X coordinate backwards, starting at the width and subtracting however far we should go.

ROT.Display.Rect.prototype._drawNoCache = function(data, clearBefore) {
    var x = data[0];
    var y = data[1];
    var ch = data[2];
    var fg = data[3];
    var bg = data[4];

    if (clearBefore) {
        var b = this._options.border;
        this._context.fillStyle = bg;
        this._context.fillRect(x*this._spacingX + b, y*this._spacingY + b, this._spacingX - b, this._spacingY - b);
    }

    if (!ch) { return; }

    this._context.fillStyle = fg;

    var chars = [].concat(ch);
    for (var i=0;i<chars.length;i++) {
        //Normal x placement
        var tmpX = (x + 0.5) * this._spacingX;
        //Check added to change to right-to-left
        if(this._options['rightToLeft'] == true) {
            //Reversed x placement
            tmpX = this._context.canvas.width - ((x+0.5) * this._spacingX);
        }
        var tmpY = (y+0.5) * this._spacingY;
        this._context.fillText(chars[i], tmpX, tmpY);
    }
}

While this is really just a clever hack it has two benefits. The first is that for someone dealing with a language that's right-to-left, they can do all their layout right-to-left. Rather than doing the calculations of width - string.length etc, they can lay it out the same as someone writing in a left-to-right language would, from the author's perspective, x legitimately increases as one moves to the left. The second benefit is that because this is so low-level in the code, everything else just works. You don't need to change any other draw functions, it's all there.

Just by making the above tweak it's easy to go from displaying Arabic characters completely wrong:

To completely right:

Note: In both examples the bottom line is using ROT.Display.drawText and the correct Arabic Uncode characters for connecting words. Just by flipping the x coordinate in Rot.Display.drawNoCache Arabic text displays correctly. The downside to this solution is that once in RTL mode, displaying text in a left-to--right language has the exact same issue as right-to-left does today.

This is definitely not a solved issue and I'm willing to try to do the work to integrate it as described above. However I'd like to discuss if this is the best solution, whether it's a correct solution, and if it's something you'll pull into ROT.

Impact

As for why I believe this is important, one of the top five most spoken languages in the world (Arabic) is written right-to-left, along with a slew of other smaller languages. Allowing for this support would enable much closer to native development (outside of Javascript using English syntax) for the Middle East as a whole, along with expat communities world-wide that desire to hold on to their heritage.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I've been working on an "automated" roguelike (see here). Currently, the game goes pretty fast - the player takes a turn every 50ms. Every 100 turns 1-3 enemies spawn, and when they do, there's a noticeable performance drop. Currently, all of the enemies are using A* to find their way to the player, but I'm wondering if that's a wise idea.

What sorts of options do I have here? Should I compute a weighted grid and use that (plus something like easystar) instead of using the callback-based ROT.AStar? Or am I just doing it wrong?

Website doesn't work now.

I thought it might be something I have done. But it happened in the interactive manual. To recreate:

1. Go to http://ondras.github.io/rot.js/manual/#display
2. Add this code to the end of the first same that creates a display:

display.draw(0, 0, "Hello World!");

3. Refresh it and you will see that only 'World' is visible (at least on my browse which is Chrome).

Hi!

I've been using ROT for a while, and for my particular game it seems I've run into some memory leaks. I definitely have some of my own at the moment, but internally ROT seems to be eating a ton of memory.

You can find my project here live if you want to profile it, and here is the code.

I've asked some folks to take a look at it and it was suggested to me that ROT.Display._data keeps increasing in size, but personally I've not made heads or tails of heap snapshots.

The way the game works is that a dungeon is generated, you go through it, die, and then the game automatically regenerates and spawns a new dungeon. I'm not sure if this is causing something internal to eat up a bunch of space. I could be completely wrong, but I'd rather get verification if possible of where the problem is.

Thanks in advance!

Upon entering the main page I somehow expected the keyboard shortcuts to guide me around. =)

Currently the FOV class only allows you to compute all tiles in the FOV for a starting position. It would be nice to have a way to simply compute whether another position was visible from the starting position without having to do the extra work of all other tiles.

I tried implementing this with Bresenham's line algorithm but I don't believe it lines up correctly with the topologies used by both the discrete and the precise FOV engine.

Something like:

var fov = new ROT.FOV.DiscreteShadowcasting(callback, options);
fov.getVisibility(startX, startY, radius, endX, endY, callback(function(visibility) {
    // ...
});

Hey all.

I read about using "Dijkstra Maps" for AI (see below links). I decided to give it a try, and came up with this implementation: https://gist.github.com/hyakugei/ace116bd9ce72f2bf92c

The visualization stuff on the index.html demo page is similar to the images on the "Dijkstra Maps Visualized" page. I tried to follow the same design style as the FOV or Map bits of Rot.js (using callbacks so as to not proscribe the data storage format). I don't know if it fits into Rot.js, or is better left as a gist/project on its own, but i thought i'd ping ya'll and see what you think.

Comments, suggestions etc welcome.

Note - hex map formatting is not currently supported. I'm not sure how easy/hard it would be to do this.

I have been reading about the JS Module Pattern and also using requireJS. Both these things seem like things that help make using JS libraries (or modules) easier and more consistent.

I was wondering if there is any interest or desire in refactoring the rot.js code to be closer to the module pattern? Regardless, i will be experimenting with enabling this on a branch of my own. I think having easy support for sub-modules, which you are already using, is pretty awesome for people who would like to add on to the code. Like, for instance, adding your own Dungeon/Map generator. Using this pattern, you would not have to touch the "main" code, just create a new .js file.

Anyway, it seems interesting, and i thought i'd ask about it here.

Thanks for all the work that has gone into this library already!

Currently, with the default ROT.Display settings. I'm getting bad rendering results, where part of the character bottoms is rendered outside of the rendering square.

If ROT.Display.Rect.cache is true then part of the character is cut off.
If ROT.Display.Rect.cache is false then I get a ghosting effect like this:
http://i.imgur.com/RlMXAVj.png
(Note that it's not just the @ that goes wrong, other letters show ghosting as well)

This seems to depend on the browser&OS configuration combination. As it seems to go wrong in Chrome on my laptop (Windows7) which has anti-aliasing enabled on fonts.
Firefox on this same machine does not show issues, but it does show anti-aliasing on fonts.
While my other (small&cheap) laptop (Windows Vista) has firefox without anti-aliasing and does not show problems. Did not try chrome on that machine yet.

Setting the display spacing to 1.001 seems to workaround it for now, as then the actual boundary box is increased by 1 pixel.

Actual fix might be to draw a character (or multiple) to a canvas, and actually measure the width/height that it used instead of assuming the point size is the same as the character height in pixels.
If you think this could be a valuable contribution I can make a pull request which implements this solution, but you might have other ideas.

The eventToPosition() function assumes that the viewport is at the top of the page.

If the window is scrolled down, the (x,y) returned will be above the mouse cursor.

Verified this in Chrome and Safari with this: toomuchpete/Grove@519437a -- make your window smaller (vertically) than the page and click, mousewheel scroll, click again -- notice that the selected tile doesn't change.

Seems like you should be able to add the click event listener to the canvas object and then base the calcs on the upper left corner.

I just tried this out and successfully made a Construct2 plugin port with it: https://dl.dropboxusercontent.com/u/23959551/demos/rot1/index.html. Your work is awesome! :)

I'm trying to implement doors, and I manage to add a callback within the getDoors function (with parameters x and y) but seems that it only gives 1 door position per room. If a room is connected with more than 1 corridors, it doesn't have a door there. Is this intentional? Or if not, how should I fetch other door positions?

Suppose I wanted to flicker text on the screen; how do I clear previous text? I've tried this:

      if(this.flicker) {
        display.drawText(33, 12, 'Generating ...');
      } else {
        display.drawText(33, 12, '              ');
      }

(where this.flicker changes every few seconds) but no dice.

Perhaps a display.clearText would be nice?

The header for the side menu is missing the unprefixed transform-origin property, causing it to display incorrectly in modern browsers.

https://github.com/ondras/rot.js/blob/gh-pages/manual/menu.css#L106

#menu > li:first-child {
  -webkit-transform-origin: 0 100%;
  -moz-transform-origin: 0 100%;
  -ms-transform-origin: 0 100%;
  >>>-webkit-transform-origin: 0 100%; should be unprefixed

• all Rooms shall be aware of their doors
• all Rooms shall have public and documented .create method
• all Corridors shall be accessible (generator.getCorridors())
• all Corridors shall have public and documented .create method

    var display = new ROT.Display({ layout: "hex" });
    var mapGen = new ROT.Map.Cellular(null, null, {
        topology: 6,
        born: [4, 5, 6],
        survive: [3, 4, 5, 6]
    });

If I then call mapGen.create, I get 1s where walls exist and 0s both in legal empty hexes and in illegal locations. By the latter, I mean that if I have the display draw at each coordinate that comes out of the map, it'll have many overlapping hexes.

While a simple workaround for the walls is to only store 1s, that doesn't allow me to determine a good coordinate for placing the player. I assume there's some good way to filter it on my end (perhaps only even/odd x coords should be accepted), but it'd be better if the map generator didn't output those coords.

Line 31 begins:

if (clearBefore) {
    var b = this._options.border;
    this._context.fillStyle = bg;

    if (this._options.tileColor) {this._context.clearRect(x*tileWidth, y*tileHeight, tileWidth, tileHeight);} else {
        this._context.fillRect(x*tileWidth, y*tileHeight, tileWidth, tileHeight);
    }

}

var b is declared and initialized, but is not used anywhere. A similar declaration is found in hex.js and rect.js, where it actually does modify what is drawn. tile.js does not appear to use it.

this._options.tileColor is unique to this spot in tile.js. There is a tileColorize option initialized in display.js and discussed in the rot.js Interactive Manual. This tileColorize option is also used later in tile.js itself.

The formatting of the if-else around tileColor has an odd layout; else on the same line, but the else block is properly formatted beneath?

The documentation says I should be able to forceSquareRatio, which doesn't work from the npm release, but does for the rot.min.js download. I'd rather be able to rely on my my package.json file for managing libraries. Would you like help keeping this up to date?

This is useful if you want to use one for random decisions in the game and one for UI stuff. The only one you'd really want to save is the game one. This way you would be able to avoid stuff like the players actions effecting the RNG state.

The downside here is that the places that use the RNG inside ROT now should take the RNG to use as a parameter (but you could always make it optional and default to ROT.RNG, or something).

Adding this library broke stuff because I wasn't checking hasOwnProperty when iterating my arrays. I'm fixing this, but it could also be fixed on your end by making the new methods non-enumerable. It's more complicated, yes, but it's safer.

I'm using the speed scheduler, and I'm just now adding projectiles to my project. I figure the least hacky way to implement projectiles is to add them to the scheduler and give them turns, but I'm not sure how to add them and make sure the next X turns are theirs (where X is the number of steps between the caster and the target). Is this currently possible, or is there a better way? I've read a bit about the action scheduler, but I'm not sure it fits my use-case entirely.

This took some time to find. But what happens is that rot.js adds properties to arrays, for example the 'random' function.

When you use arrays as hashtables, you will then always get at least one 'hidden' property that will jump pout and be the 'random' function.

This breaks pretty much all of my code (in a message router and ORM built separately, and which works very well with everything else I've used it with) and is really not an expected behavior of arrays.

I would respectfully recommend to rewrite those part of rot.js that extends the prototype of intrinsic JS objects so that they avoid to do so.

Thanks for a very nice project, otherwise.

I've installed rot using bower:

bower install rot.js --save

And got empty folder (with only one file):

EDITED: It skipped my mind that the double width plot in the tutorials page is almost exactly what my map needs... just inverted + flat topped... so I am leaving my original text below and just adding this explanation above it. I am currently digging through rot.js examples and code trying to make this happen on my own but not having much luck of it.

----- END EDIT -----

Hi, I was recently pointed towards your project because I am trying to track down a hex map system that supports a slightly odd coordinates system... I hope I can illustrate it here cleanly... It is very similar to your Double Width system except the hexes are rotated to be flat topped vs pointed. Below is an ascii representation of how it ends up looking with coordinates inside each hex...

I have played around with a few options in rot.js trying to mimic this but to my knowledge it seems simple adjustments (rotate 90) for example is not enough to get this effect... I am hoping maybe I just am missing something... If this is not possible I completely understand, however with some pointers in the write direction if this is possible, I will happily work on a pull request to contribute it back to the project.

Thanks in advance either way!

              -----               
             /     \             
        -----  0,4  -----        
       /     \     /     \       
  ----- -1,3  -----  1,3  -----  
 /     \     /     \     /     \ 
- -2,2  -----  0,2  -----  2,2  -
 \     /     \     /     \     / 
  ----- -1,1  -----  1,1  -----  
 /     \     /     \     /     \ 
- -2,0  -----  0,0  -----  2,0  -
 \     /     \     /     \     / 
  ----- -1,-1 ----- 1,-1  -----  
 /     \     /     \     /     \ 
- -2,-2 ----- 0,-2  ----- 2,-2  -
 \     /     \     /     \     / 
  ----- -1,-3 ----- 1,-3  -----  
       \     /     \     /       
        ----- 0,-4  -----        
             \     /             
              -----              

Or even just demos? I'm curious to see how everything plays out. Also, is there a possibility to be able to add tiles/sprites to use for the images? Or is this built more like nethack?

When calling ROT.Display(), TypeError is thrown:

Object #<Object> has no method 'setOptions'

The same issue occurs on manual page http://ondras.github.com/rot.js/manual/#display also.

EDIT

URGH, My bad, for some (unknown) reason I was trying to call ROT.Display() instead of creating new instance. Closing issue.

Is there a way to limit the FPS for the game? For example, my game can have up to 4 people playing (automatically), but when one of them dies, the processing speed picks up quite a bit (player turns are comptuationally expensive). If I could limit the FPS this wouldn't be too much of a problem, I think.

ROT works nicely for languages that are written left-to-right in a non-connecting script. It handles Unicode just fine (as long as the browser does) so that covers a lot of ground. However, two areas that I believe would open this up to a much broader global audience would be support for a native right-to-left rendering and the ability to nicely display characters from languages that use cursive scripts (such as Arabic, Farsi, Hindi, etc). This ticket is for cursive scripts to keep the issues able to be separately pulled.

Arabic is my example below, but it holds for any cursive script wherein the letters change based on position(for instance an 'a' at the start of a word appears differently than an 'a' at the end).

Issue

The crux of this issue is that while a browser correctly knows how to display a string of Unicode characters while in the context of that string, pulling each character out to stand on its own breaks the connectivity. Currently ROT.Display.drawText prints each character on its own, leading to only the isolated form of that character being printed, regardless of the context it was pulled from.

To illustrate the point, in the code below you can see how the characters join together

//For the sake of these examples, Test is a new Rect Display of size 30x10
Test._drawText(1, 1, "Hello World");
Test.display.draw(10, 3, 'مرحبا يا عالم'); //Included hack to show the difference, see below
Test._drawText(5, 5, 'مرحبا يا عالم');

However, after running the code, we see this:

The middle row is how they'd look connected, the bottom row is the issue because it used drawText. This occurs because the Unicode characters being used and displayed nicely in a browser are from the "Arabic" Unicode range (0600–06FF) and the browser is correctly interpreting it in context. Because ROT.Display.drawText grabs each character separately one needs to replace it with the proper contextual character from the Arabic Presentation Forms B range (FE70–FEFF).

As an example of how to fix this, I wrote up a quick Arabic lookup table [https://gist.github.com/thesnarky1/10012004] that takes standard Unicode and checks the context to replace the character. In this case getRealCharCodes checks the string for anything it can translate, then replaces those characters based on the context it sees them in.

//For the sake of these examples, Test is a new Rect Display of size 30x10
Test._drawText(1, 1, "Hello World");
Test.display.draw(10, 3, 'مرحبا يا عالم'); //Included hack to show the difference, see below
Test._drawText(5, 5, 'مرحبا يا عالم');
Test._drawText(5, 6, getRealCharCodes('مرحبا يا عالم'));

Even without understanding an Arabic alphabet, you can see that the characters on the bottom line are now changed to connect to something (even if right-to-left is still not working).

Proposed Solution

One hack to bypass this is to call ROT.Display.draw() and provide a string instead of a character. This prints the entire string as one unit which correctly connects the letters. Unfortunately this also negates the ability to do any sort of intelligent padding because spacing is not considered. This is really not a solution, just a work-around.

This is something that could be left up to each developer to figure out, however I disagree with that approach because I believe one's native language should have a low-barrier for entry to programming.

I would propose allowing for a community-built approach wherein ROT provides a basic framework to do this character substitution, provided the community provides the appropriate translations. Essentially it would amount to adding two new variables in ROT.Text (for instance ROT.Text.cursiveCharactersToTranslate and ROT.Text.cursiveCharactersWhichDontConnect), adding a method to ROT.Text that would perform the lookup, and then allowing anyone to put language packs into the addon directory.

Each language pack would consist of additions to that variable indexed by the base Unicode letter (so there should be no collisions), as well as additions to the list of characters that don't connect. For example, Arabic could be a small Javascript file containing:

ROT.Text.cursiveCharactersToTranslate[1575] = [1575, 65165, 65166, 65166, 65165];
ROT.Text.cursiveCharactersToTranslate[1576] = [1576, 65169, 65170, 65168, 65167];
//...
ROT.Text.cursiveCharactersToTranslate[1610] = [1610, 65267, 65268, 65266, 65265];
ROT.Text.cursiveCharactersWhichDontConnect.push([1575, 1583, 1584, 1585, 1586, 1608]);

This would keep the burden of maintenance of specific languages on those who actually know the language, while providing a very key improvement to ROT overall. It would also stay small because if someone did not use any special languages, the only additional size to their ROT would be the function in ROT.Text.

I'm more than happy to draft up a pull request for this, wanted to check interest before I did, however. Also wanted to debate whether this is better as part of ROT.Text or ROT.Display adding it into ROT.Display.DrawText as an additional boolean variable.

Impact

As for why I believe this is important, two of the top five most spoken languages in the world (Arabic and Hindi) are cursive (estimated around 700 million people)(http://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers). Allowing for this support would enable much closer to native development (outside of Javascript using English syntax) for a swath of the world stretching from Morocco to India, along with expat communities world-wide that desire to hold on to their heritage.

Opening a new issue for ROT.Map.Rogue per @ondras in #61.

Instead of:

var displayOptions = {
    // ...
    tileMap: {
        "@": [0, 0],
        "#": [0, 32],
        "a": [32, 0],
        "!": [32, 32] // absolute position
    }
    // ...
}

I was thinking something:

var displayOptions = {
    // ...
    tileMap: {
        "@": [0, 0],
        "#": [0, 1],
        "a": [1, 0],
        "!": [1, 1] // grid position
    }
    // ...
}

// OR

var displayOptions = {
    // ...
    tileMap: {
        "@": 0,
        "#": 1,
        "a": 2,
        "!": 3 // index position
    }
    // ...
}

What do you think?

I'd post this in a forum somewhere, but can't seem to find such a thing, so I'll try here. I'm trying to figure out if rot.js can meet a couple of my project requirements. One is that I want tooltips for map elements. e.g. mouse over a monster and it pops up a tooltip with details about it. This is easy with javascript, css and an html table, but I don't know anything about the canvas. I don't see anything in the rot.js docs.

Second, I need to implement ascii animations for things like explosions that will manipulate the opacity of map elements. Color looks easy, but can I set opacity for individual map cells with rot.js?

Is there a map generation algorithm that supports rooms of a given size in a maze, while still having a fully-connected maze?

The array functions "Array.prototype.random" and "Array.prototype.randomize" are causing blocking issues when using ROT with other libraries. One example is the Babylon WebGL engine, but I have encountered this issue with other libraries as well.
I had to convert them to standalone methods and replace any instance of Array.random/randomize with a call to the functions. Upon removing them, everything works perfectly.

I can submit a PR if needed, but there isn't much in the README so I wasn't sure where to put it. I only know I can install via bower because of #48, so it'd be nice to have that info documented.

It seems like it isn't doing the transposition on the incoming event, and needs to be done manually... there appear to be other issues that are more than just flipping x/y coords as well.

When using topology 8 with both Dijkstra and A*, it tends to ignore straight-line paths.

Using the interactive manual as a sample: change the map generation to create an empty room, like this:

var w = 150, h = 80;
ROT.RNG.setSeed(12345);
var display = new ROT.Display({width:w, height:h, fontSize:6});
SHOW(display.getContainer());

/* generate map and store its data */
var data = {};
var map = new ROT.Map.Uniform(w, h);
map.create(function(x, y, value) {
    data[x+","+y] = 0; // ONLY THIS LINE CHANGES
    display.DEBUG(x, y, value);
});

/* input callback informs about map structure */
var passableCallback = function(x, y) {
    return (data[x+","+y] === 0);
}

/* prepare path to given coords */
var dijkstra = new ROT.Path.Dijkstra(98, 38, passableCallback);

/* compute from given coords #1 */
dijkstra.compute(8, 45, function(x, y) {
    display.draw(x, y, "", "", "#800");
});

/* compute from given coords #2 */
dijkstra.compute(130, 8, function(x, y) {
    display.draw(x, y, "", "", "#800");
});

/* highlight */
display.draw(8,  45, "", "", "#3f3");
display.draw(130, 8, "", "", "#3f3");
display.draw(98, 38, "", "", "#f33");