The classic for loop

What I like to call the classic for loop is perhaps the most basic of all loops in Javascript. It looks like this:

for(var i = 0; i<10; i++) {
	// do stuff with i
}

This is the basic loop model provided by Javascript and is by far the most common variation of the for loop. You initialize an iterator (i), set a finish condition for i, and finally specify how i will be modified each iteration of the loop. Since i++ is just a statement, it’s possible to modify i however you want in the loop header using statement operators. for(var i = 0; i<10; i+= 2) will increment i by two each iteration, for example.

Note: You have to be careful. If you initialize the loop without putting var in front of the iterator variable (like this: for(i = 0; i<10; i++)), you’ll turn it into a global variable, which may not be what you were intending to do.

Using the for loop to iterate through an array

Assuming you have an array called things, you can use a for loop to iterate through it like so:

for(var i = 0, len = things.length; i<len; i++) {
	var currentThing = things[i];
}

The classic while loop

The while loop is another basic, very familiar loop. It’s a little more complicated than the for loop, but not by much. You can’t write it all on one line, but it’s about as simple as they come:

var i = 0;
while(i < 10) {
	// do stuff with i

	i++;
}

As you can see, you have to initialize i outside the loop and then increment it inside the loop. That’s why this method isn’t quite as clean as the basic for loop. However, I think it’s a bit easier to understand, because it’s more broken up. Because of this broken up format, it’s possible to do a lot with while loops, as you’ll see shortly.

Note: You’ll want to make sure you do all your loop operations before you increment your iterator variable; otherwise, you risk skipping an iteration of your loop.

The quick n’ dirty while loop

This method is one of the shortest methods of writing a loop, and it’s probably one of fastest, too.

var i = 10;
while(i--) {
	// do stuff with i, which is in the range 9 to 0
}

The reason this works and isn’t an infinite loop is that the while loop performs each iteration only when its condition evaluates to a truthy value (that is, anything that can’t be coerced into 0, or false). Since 0 is a falsy value, the condition evaluates to false and the loop performs its last iteration before exiting. Pretty neat, huh?

Using the while loop to iterate through an array

There are a few different ways to iterate through an array with a while loop, but they’re just slight variations of the previous while loops. Here’s the basic forward-iterating while loop:

// forward declaring our variables because that's recommended.
var 	len = things.length,
		currentThing,
		i;

while(i < len) {
	currentThing = things[i];
	// do stuff with the current thing

	// increment our counter
	i++;
}

As you can see, I cached the length of the array to speed up performance a micro-bit. Don’t do this if you’re modifying the length of your array inside the while loop. Instead, compare i to the length of the array every iteration.

And here’s the reverse while loop:

var 	i = things.length,
		currentThing;

while(i--) {
	currentThing = things[i];
	// do stuff with the current thing
}

This is the preferred way to loop through an array if you’re going to use a while loop. Since it’s reversed, it doesn’t care if you’re modifying the length of the array or chucking elements in each iteration (as long as you aren’t modifying elements ahead of the loop, of course). You also don’t have to define as many variables, since we no longer need to cache the length of the array.

The do-while loop

The do-while loop is similar to the while loop in many ways, barring syntax. It’s a broken up loop in which you have to manually increment your variable. However, the key difference here is that the do-while loop executes the statement and then evaluates the provided condition, meaning the loop will execute at least once. Here’s what it looks like:

var i = 0;

do {
	// do stuff with i, which is in the range 0-9

	i++; // remember, increment your counter at the very end of the loop
} while (i < 10);

As you can see, not too different from the while loop, except for a little change in the syntax. The main difference is, even if the condition at the bottom evaluates to false, the loop will still run once:

var i = 0;

do {
	i++;
} while (i < -1); // still evaluates once

I haven’t really found a use for the do-while loop yet, so if you do, feel free to let me know what you did with it in the comments below.

The Array.forEach loop

Array.forEach is a relatively new addition to the ECMA-262 standard, so it’s not seen a lot of use yet, nor do many older browsers support it. Nonetheless, there is a shim for it and it’s a remarkably useful function. Here’s some example usage:

var a = ["a", "b", "c", "d", "e"];

a.forEach(function(element, index, array) {
      console.log("Element: " + element + " at index " + index);
});

As you can see, the syntax is quite simple. Simply call forEach on an array and pass in the function you want executed on each of the array’s elements. As I mentioned before, for browsers that don’t natively support forEach, there’s a shim (which can be found in Mozilla’s forEach documentation):

if ( !Array.prototype.forEach ) {
  Array.prototype.forEach = function(fn, scope) {
    for(var i = 0, len = this.length; i < len; ++i) {
      fn.call(scope, this[i], i, this);
    }
  }
}

Simply include the above code in your Javascript project and you’ll have full support for the forEach function. Although it really just serves as syntactic sugar to cover the for loop, you have to admit it is quite nice to have.

Object property loops

The object property loop is a way of looping over the properties of objects that aren’t arrays, since you can’t really use the normal for loop or while loop to loop through the elements of an object effectively. Here’s how it works:

var currentProp;

for(prop in obj) {
    if(obj.hasOwnProperty(prop)) {
        currentProp = obj[prop];
        // do something with this property, where currentProp is the actual value
        // you're looking at, and prop is the name of that value on the object.
    }
}

One of the things you need to make sure you do is check to make sure the property of the object you’re looping over actually belongs to that object and hasn’t come down the prototype chain. If you don’t do that, properties such as functions from the object’s prototype will become part of the loop. Not cool.

Another thing to be aware of is that the object won’t be looped over necessarily in the order that the properties are specified, nor even in the same order each time the properties are looped through. A plain object is not like an array in this respect, so you’ve got to be careful how you handle it.

Partial loop unrolling (and when not to use it)

Partial loop unrolling is a nice trick to have up your sleeve, especially if you’re working with large arrays (arrays with entries in the thousands or more). Basically, loop unrolling just means covering more than one element in each iteration of your loop. Here’s an example:

var currentThing;

for(var i = 0, len = things.length; i<len; i+=4) {
    currentThing = things[i];
    // do something with the current thing

    currentThing = things[i+1];
    // do something with the next thing

    currentThing = things[i+2];
    // do something with the next next thing

    currentThing = things[i+3];
    // do something with the last next thing
}

Since you’re effectively cutting your amount of iterations by half, or two thirds, or three quarters, or four fifths, or whatever amount you choose, it’s easy to see why this method should speed up your performance. However, interestingly enough, the gain you get by partially unrolling your loop isn’t that great. Therefore this isn’t a very effective method for speeding up your code until you’ve got arrays with elements numbering in the thousands (or higher).

Wrapping up

Well, that just about covers it for the most commonly used loops. I hope this helps, and, as always, If I’ve made any mistakes or typos, or if you just want to suggest something, feel free to leave me a note in the comments! Thanks for reading.

Oh, and as for fruit loops… do I really have to explain those?

So the question is: is it possible to have a roguelike with a completely message-based interface? The answer is absolutely. In this post I’ll be talking about a few of the things that you’d have to deal with in the writing of such a game. (Note: not necessarily Javascript specific, just some rambling/brainstorming about RL development in general)

Displaying information in a textual format

There are a couple of key things the developer of a GUI-less RL needs to be aware of.

One of the most important things to get right is alerting the player about life-threatening events such as HPs dropping dangerously low, risk of starvation, etc. In a text game without any sort of health display it’d be awfully easy to miss the “HP low!” warnings and accidentally play your character to death.

Naturally, you’d want to spend a good portion of development time on creating some good grammar formatting/text generation algorithms. You don’t want “an foo” to attack you, nor would “a gloves” be a very interesting find. This is, of course, a concern for all games with messaging systems, but since the primary focus of a GUI-less game would be the text, the player would be paying a lot more attention to it, and thus would be more likely to catch any errors.

Furthermore, numbers don’t look very good in a textual context. A GUI-less game shouldn have very few, if any, numerical characters mixed in with the text. Instead of saying “You have 5 apples, 2 shirts, [...] in your inventory”, you’d want to display “You have five apples, two shirts, [...] in your inventory”. I suppose this might fall under creating solid algorithms for generating messages, but I feel that it’s important enough to deserve its own paragraph.

Receiving user input in a textual format

Another issue with a GUI-less roguelike would be how to get user input. Naturally, in the map screen, movement keys would be the same as in a “vanilla” roguelike, and I suspect many other “standard” commands such as g for grab, w for wear, e for equip, and the like, would remain the same as well. However, in addition to these normal keys, which I’ll call hotkeys for the sake of clarity, there would be a second method for interfacing with the game: commands. Commands would be longer and more complex instructions, often consisting of whole words, something somewhat similar to what Nethack offers with its array of one-word commands. It would be possible to enter a whole sequence of commands and have them executed sequentially.

However, constantly having to type in long commands could easily get annoying, so you’d want to provide a way to save custom macros and perhaps custom hotkeys as well. These hotkeys would execute specific macros in the console, which would of course have access not only to all longer commands, but also the commands the hotkeys call as well, such as “walk north”, “walk southeast”, and the like.

Another feature that would be useful would be the ability to quickly scroll through previously entered commands with, say, the up arrow key. This functionality is already offered in most consoles, and for good reason. It makes doing repetitive actions which don’t necessarily require a macro much easier to execute.

Closing thoughts

I guess you could call the type of game I’ve been describing a roguelike in which all the game-related information is presented to the player solely through a console. I think it’d be an interesting challenge and certainly something worth attempting. I might try to write such a game in the near future, since it’s (obviously) something that I find quite intriguing. If that does happen, I’ll be posting more about what goes into a GUI-less Roguelike. In the mean time, feel free to comment if you have any corrections or just want to add on to what I’ve said. Oh, and don’t forget to subscribe to my RSS feed!

Here’s a demo of it in action:

Click anywhere to start a path, then click again to complete it. As you can see, my implementation is pretty quick. Although I haven’t measured its performance, strictly speaking, it can calculate a 850 or so unit long path with a barely visible delay (and I suspect even that delay is largely due to <canvas>‘s rendering performance–it really drops after you hit about nine million pixels, or 360,000 tiles). The algorithm uses a custom ordered array so it is pretty speedy.

Why use AStar.js?

If you’re interested in A* pathfinding, there are a few other pathfinding packages for Javascript. However, most of them require several Javascript libraries and/or complex inter-dependencies. To use my module, you only need to include one file–astar.js, and there are no external dependancies.

Getting started with AStar.js

Once you’ve included astar.js, you need to create an instance of the AStar pathfinding tool before you can start calculating your path. To create an instance of AStar, you need to provide your map data, the map’s height, the map’s width, and a function to tell whether or not a particular node is blocked.

Say your map data looks like this:

var map = [
    [0, 1, 0, 0, 0, 1, 0],
    [0, 1, 0, 1, 0, 1, 0],
    [0, 1, 0, 1, 0, 1, 0],
    [0, 1, 0, 1, 0, 1, 0],
    [0, 1, 0, 1, 0, 1, 0],
    [0, 1, 0, 1, 0, 1, 0],
    [0, 0, 0, 1, 0, 0, 0],
];

You’d initialize your AStar object like this:

astar = new AStar(map, 7, 7, function(data, x, y) {
    return {
        blocks: data[x][y]
    }
});

The anonymous function you pass in takes three parameters; an inside reference to the data you passed in previously, the node’s x coordinate, and the node’s y coordinate. All it needs to return is an object with a boolean property, blocks, indicating whether or not the node in question is walkable. I may end up extending it to take values that let you determine the terrain cost of each node, but for now either a node is blocks movement or it doesn’t. In the case of the example, a “0″ indicates unwalkable terrain and a “1″ indicates walkable terrain. That’s why, in this example,  just returning the value at the specified node works.

Once you’ve initialized the AStar module, all it takes is a single line of code to get a path:

var path = astar.path(start_x, start_y, end_x, end_y);

AStar.path() returns an array containing the nodes found for the path specified, containing the starting and ending points. Each node is represented as an object with x and y values.

Demos and downloading AStar.js

You can find the link to the demo in the article here. I also put up a pathfinding stress test for fun; turns out that calculating an ~850 node long path takes about 200 ms (be warned, the linked page may take a while to load).

You can download AStar.js in an uncompressed format here (there’s also a minified version available). I hope somebody finds this helpful, and as always, be sure to let me know if I made any typos or errors in this article! (don’t forget to subscribe to my RSS feed, too)

What the book will be:

• A cut-and-paste resource for writing JS roguelikes, with a large number of useful algorithms covered in-depth.
• An introduction to the pros and cons of writing roguelikes in Javascript
• A starting point for your own browser-based roguelike

What it won’t be:

What will the book cover?

Here’s a list of some of the major topics I’m hoping to cover in no particular order (some may be cut out due to length limitations eventually):

1. Why Javascript? — where’s the logic in using Javascript for a Roguelike?
2. File and data management — how to manage source files and data
3. Display — several different paradigms you can use to display your game
4. Main loop — the main loop of the game; this handles lighting, monster AIs, stuff like that
5. Input handling — how to handle the input from the player
6. Map generation – how to actually generate maps
7. Map management – keeping track of what goes where on the map
8. Lighting – lighting the map
9. Items — how to handle items using object oriented programming techniques such as composition and inheritance
10. Actors — keeping track of all the actors in the game
11. Pathfinding — several different pathfinding algorithms such as A* and Dijkstra 
12. Actor AI — handling NPC behavior

That’s all, folks!

Field of view, which involves determining which tiles are visible to the player, is a particularly fun aspect of writing roguelikes, in my opinion. When writing a field of view algorithm, you often find yourself trading quality for performance, or vice versa. Some algorithms get around this with a bit of trickery, like the Rogue algorithm. Other algorithms have no visible artifacts and in fact are quite pleasing visually, but pay for this with a definite decrease in performance.

There have been, of course, plenty of articles written about field of vision, and there is in fact an excellent compendium of resources over at Roguebasin (you can check that out here). This is a problem that has been thoroughly solved many times, beginning with Rogue’s rudimentary solution (you can see all the tiles in the room you’re in, but nothing else is visible; when in corridors, only the corridor tiles next to you are visible). The thing is, only a few Javascript algorithms (if any) are available to calculate FOV. Since I’m writing a Roguelike and have of course come up with an algorithm of my own, I have decided to remedy this lack of JS algorithms by sharing mine with you. It’s nothing fancy, but does provide a rather nice gradient falloff, which works in tandem with the display.js library that I previously posted.

Finding the happy medium

Many FOV algorithms have been written in an attempt to find the happy medium between performance and quality. After trying a few algorithms out, I eventually settled with recursive shadowcasting, which was both optimized for maximum performance but also very few artifacts. All in all, I’m happy with my choice. Here are some of the results you can get with recursive shadowcasting combined with a gradient falloff:

The field of view you see here is using a radius that is roughly double that of which is found in my game in order to better display the nice lighting falloff. However, even with aforementioned smoothed lighting, performance isn’t impacted in the slightest.

Has the happy medium been found?

As I’ve mentioned before, performance is usually achieved at the cost of quality. However, I was able to find a way to boost the performance of the algorithm without impacting quality. Now, to update the lighting, most algorithms clear the map of light and reset all the tiles to “unlit” or, depending on whether the player has already seen the tiles, “unseen”, which basically means the player has seen that tile at some point but can’t currently see it. The lighting algorithm then calculates the tiles within the player’s field of view and sets those tiles to “visible”, and the rendering engine displays them as lit up. Pretty straightforward.

The difference in my algorithm is that instead of clearing the entire map, it only sets to “unseen” those tiles which were lit the previous turn. This means that loads of CPU cycles aren’t wasted trying to reset the entire map’s lighting, most of which is outside the player’s field of view anyways. The algorithm simply appends each tile that is set to “visible” to an array, which is stored. When the lighting is next updated, those tiles in the array, and only those tiles, are set to “unseen” and the algorithm proceeds to calculate lighting as normal; wash, rinse, repeat, and you’ve got yourself one quick little field of view algorithm.

If you’ve stuck with me this long…

…you must be interested in seeing the algorithm. So, without further ado, here it is. It’s been sparsely commented, but hopefully should be of some help to some of you. And, as before, the LightSource class which contains the algorithm does make use of some external functions, which I will be introducing to you later on as progress on my game continues. And, before I forget, here’s a demo demonstrating its use.

Hopefully this article has given you something to think about, and, as always, feel free to comment and let me know if I’ve made any mistakes or typos!

First off, the basic algorithm:

To begin, let’s take a look at basic algorithm behind generating nice-looking cave levels with cellular automata:

1. Scatter wall blocks across the level at a 30-40% saturation level (I've found that 39% is ideal).

2. Iterate through all the tiles on the map four times:
- For each tile in each iteration, set the tile to be floor.
- Then, calculate the number of wall tiles within both one square 
    of the original tile (these are neighbors) and two squares (these tiles are nearby). Store these numbers.
- If the number of neighbors for the tile is greater than or equal to 5, or there are less
    than two wall tiles nearby, set this tile to be a wall.</div>
- If it is not a wall already, leave this tile as a floor tile.

3. Iterate through all the tiles on the map three more times:
- For each tile in each iteration, set the tile to be floor.
- Calculate the number of wall tiles within both one square of the original tile.
- If this tile has five or more neighboring walls, make it a wall. Otherwise, leave it as a floor tile.

The issue with cellular automata is…

…the caves generated with the cellular automata technique are often unconnected. Since many roguelikes depend on all parts of a level being accessible, this is usually a bad thing. So, clearly, we need a way to drop the disconnected regions or otherwise ignore them. The best way to do this is with a flood fill algorithm. A flood fill algorithm is able to find all the nodes connected to each other that aren’t delimited by another type of node. In graphics applications, this is usually used to find regions of similar color.

In our algorithm, the flood fill algorithm will be used to find all the regions of the cave that are comprised of purely floor tiles–in other words, all the caverns (unconnected or not) on the map. Once we have a list of the caverns, we can select the largest cavern–this will be the main cavern. We can then simply drop the other patches, as they are small unconnected regions that are precisely what we don’t want.

Flood fill algorithm in Javascript:

Here’s how I managed the flood fill algorithm and subsequent cavern managing in Javascript:

// this variable will be used to store the various unconnected caverns
var caverns = [];
 
// begin looping through the map
for(var x = 1; x<this.size.x; x++) {
    for(var y = 1; y<this.size.y; y++) {
        var cavern = [];
        var totalCavern = [];
        
        if(this.data[x][y].type != "dirty floor") {
            // we've already been over this tile or it is already part of a cavern, 
            // no need to check it
            continue;
        }
        
        cavern.push(this.data[x][y]);
        totalCavern.push(this.data[x][y]);
        
        while(cavern.length > 0) {
            var n = cavern.pop();
            
            if(n.type == "dirty floor") {
                // set a flag on the tile indicating it has already been checked
                n.setType("floor");
                
                for(var i = 0; i<8; i++) {
                    var curTile = this.data[n.position.x + x_array[i]][n.position.y + y_array[i]];
                    if(curTile.type == "dirty floor") {
                        cavern.push(curTile);
                        totalCavern.push(curTile);
                    }
                }
            }
        }
        
        // add this cavern
        caverns.push(totalCavern);
        
        // sort the caverns
        caverns.sort(function(a, b) {
            return(b.length - a.length);
        });
    }
}
 
// remove the largest cavern, as it is the main cavern
caverns.shift();
 
// now that we've got the unconnected caverns, change their tile type
if(caverns.length > 0) {
    for(var i = 0; i<caverns.length; i++) {
        for(var j = 0; j<caverns[i].length; j++) {
            caverns[i][j].setType("wall");
        }
    }
}

As you can see, I loop through all the tiles. First, I check to see if I’ve already been over the tile; if so, I pass it on. If I haven’t, I go through that tile and search its neighbors, too. Eventually, I’ve searched all the tiles on the map and sorted them into the various caverns to which they belong. Once I’ve done that, I sort the caverns by size, from largest to smallest, and pick out the one with the most tiles in it (in other words, the biggest cavern). This is the main cavern, so we can get rid of or ignore the rest. I personally chose to get rid of my unconnected caverns, but it’s possible to connect them or just ignore them for the rest of the dungeon generation code–it’s up to you really.

In finis…

If you’ve read this far, you’re at least slightly intrigued by the cellular automata/flood fill cave generation algorithm–good! Hopefully you’ll have as much fun playing around with it as I did. As you can see, the Javascript code I included above makes heavy use of some external data-managing structures, such as a map data structure and a tile structure as well; I’ll be writing more articles about how I handle the map and tile stuff later. As always, thanks for the read, and if I made any mistakes during this article or if any of my code can be improved, please let me know!

So, let’s take a look at the code required initialize a basic 80 by 25 console and draw a few characters with the display class:

Okay, let’s step through this code really quickly. Before we begin, though, I’d like to note the Vector2 class I use here; it’s nothing more than a utility function I use to hold a position with X and Y values (you can grab a copy of it here). So, in the code, the first line initializes the console display. The first variable we pass in to this function call is the size of the display–I use 80 by 25 because that’s a standard console size, but these numbers could be anything you want. The second variable we pass in is the offset of the console from the rest of the page. The third variable we pass in is whether we want this display to open in a new window or not. If you set it to false, the display will simply be written to your HTML page. If it’s set to true, the console will open in a popup window.

The next line calls a function on our newly created console, namely ch. This allows you to display a character on the screen and takes a minimum of two and up to five parameters. In order, these are: the character to display, the position of that character, the color of the character, the opacity of the character, and the background color of the character. Only the character you want to write and the position of that character are required; the others are optional. The color variable accepts a few basic color names as well as hex values. The next few lines do nothing more than demonstrate the various applications of the ch function, which is the only function display.js makes use of.

In finis…

As you can see, the display class isn’t very advanced right now, but it’s been all I’ve needed so far. If you want to download the class, you can grab it here. Quick note, it does make use of jQuery, so make sure you include that in your project before you attempt to use it. As progress on my game continues, this library will likely be updated with more functions as I need them. Thanks for taking a look, and be sure to keep an eye on Hey Javascript for more updates in the near future! (hopefully, I’ll be posting some dungeon generation algorithms in Javascript soon)

Unfortunately, since it’s so new, there aren’t a lot of resources for those who want to begin working with Javascript. Many useful algorithms and formulas found in older development languages have yet to be ported to Javascript and most of the popular utility libraries aren’t available. Nonetheless, Javascript remains a powerful tool for Roguelike development, for those who are still interested.

Now, in order to combat this lack of resources, I’m going to be exploring the capabilities of Javascript for RL development. You can expect to see popular algorithms ranging from dungeon generation algorithms to A* pathfinding converted to Javascript and ready for you to use in your game. I’ll be explaining the shift in thinking required when switching from console-based programming languages to Javascript, which renders to the browser, and may even share with you the source code for the RL I’m currently working on.

Before we get to that, though, here are a few resources that I’m currently working with in my adventures into Javascript Roguelikes:

1. The one wiki to rule them all: RogueBasin

RogueBasin is an unparalleled resource for the aspiring Roguelike programmer. It’s a wiki–the wiki, I might go so far as to say–for Roguelike gaming, whether you’re interested in development or playing. It contains a number of excellent articles on developing Roguelikes and even has a page on the pros and cons of developing Roguelikes in Javascript. What makes it such an invaluable resource, however, is the number of algorithms (and more importantly, explanations of algorithms) that it has. It would be worth your time to read and re-read all the articles on there. While not Javascript-specific, they explain many of the key concepts that go into a good Roguelike.

2. “Amit’s Game Programming Information”

While not strictly related to Roguelikes, Amit’s Game Programming Information has a number of links to various resources which can prove useful to Roguelike development. Among others, it has articles on pathfinding, line of site algorithms, AI programming, and other equally important facets of Roguelike development.

3. A few resources for A* pathfinding

I’m working on writing a decent implementation of A* pathfinding in Javascript to be used in my game. Here are a few of the resources I’m using to help me clean up my implementation:

- A* Pathfinding for Beginners: Very explanatory and clear. If I were rating these (which I’m not) I’d give it a 5/5.

- Path Finding Tutorial: A decent tutorial, explains some uses for A* other than monster AIs.

- Introduction to A* Pathfinding: Another good tutorial. I like this article because it has cats in it.

I realize that I may have posted a few of these links already in my previous article on A* pathfinding, but if you didn’t catch that, no harm done. These should be enough to get you started with A* pathfinding, if you haven’t figured it out already. There aren’t really many changes we need to make to convert the algorithm to Javascript, as it’s fairly straightforward.

4. Several different algorithms for field of view computations

I’ve converted several different algorithms for field of view computations into Javascript, but I’m still cleaning them up, so I won’t publish them just yet. Until then, have a look at some of the resources I found useful in my ventures into field of view:

- Field of view calculations via raycasting: This was the first psuedocode I ported to Javascript, but as it turns out it was too slow for my uses, so I looked around for some other implementations.

- FOV using recursive shadowcasting: This article led me into writing a recursive shadowcasting algorithm in Javascript. It’s easily the fastest FOV algorithm I’ve found yet.

- Walls and Shadows in 2D: This article contains the explanation of an algorithm for lighting I’ve not yet implemented, although it does seem pretty promising.

5. Finally, a quick look at some dungeon generation algorithms

Dungeon generation is a key factor in most modern Roguelikes, so you want to be sure you’re doing it right. This is one of my favorite parts of Roguelike development, and something I’ll be touching on again in the future. There are a few different methods you can use: let’s take a quick look at some of the more interesting ones I’ve come across:

- Dungeon-Building Algorithm: This is an interesting algorithm and produces some nice results. I’ve played around with it on more than one occasion (in Javascript, of course).

- Dungeon generation on the PCG wiki: The PCG (Procedural Content Generation) wiki has a number of resources for dungeon generation, and I’ve found it valuable in researching different methods of creating dungeons on more than one occasion.

- Rogue’s original dungeon generation algorithm: The dungeon creation algorithm used in the original Rogue game. It’s actually pretty nifty.

6. In finis…

You’ll probably have noticed by now that most of the resources I’ve linked to have nothing to do with Javascript. That’s because, as I said earlier, there aren’t many resources for Javascript Roguelike development yet. I’ll be converting many of the algorithms I posted into Javascript in the upcoming months for your ease-of-use.

Eventually, if enough interest is shown, I may write a book on Roguelike development with Javascript. Let me know if you think such a book would be useful in the comments section, and as always, feel free to point out any mistakes I’ve made in this article!

1) Amit’s A* Pages

This site is an excellent compilation of articles on A*. It’s a great resource, but the articles it contains aren’t exactly for beginners. That said, I refer to them all the time–they’re not limited to just pathfinding articles. There’s stuff in there about pretty much every aspect of game programming.

2) A* Pathfinding for Beginners

This is really an excellent tutorial. It explains the concepts behind pathfinding very clearly and is pretty easy to grasp. If you’re just getting into A* pathfinding, this is definitely the article for you.

3) Wikipedia on A*

Wikipedia’s article is also quite useful, and this page has a handy language-agnostic implementation of pathfinding.

4) Ray Wenderlich’s “Introduction to A* Pathfinding”

Another great article. This guy uses a cat to illustrate his point, so kudos to him for that (I’m a big fan of cats).

5) Another article and accompanying psuedocode

I like the pseudocode in this article and there’s a useful discussion about actually implementing A* towards the end of the article–what you’ll need as far as abstract classes and interfaces go.

6) Justin Heyes’ C++ implementation

Justin Heyes has written an excellent implementation of A* which can be found in the above repository. Although it’s in C++ it clearly illustrates the finer points of the algorithm and how to interface with it.

7) Brian Grinstead’s Javascript implementation

Brian Grinstead has written a fast version of A* in Javascript. It’s quite effecient but can be tricky to understand. If you’re already “pro” and have a working implementation of A*, but want/need it to be faster, this is your article.

8) Some more A* pseudocode

Here’s yet another version of the pathfinding algorithm in pseudocode, in case you didn’t “get it” from any of the previous 7 articles. The explanation is short and sweet and the pseudocode fairly readable. There’s also a link to a version of A* written in LISP at the bottom of the page, if that’s your thing.

1) A vanilla Javascript method for cloning objects

This is a somewhat simple function that will clone an object and return the clone. If a non-object value is passed in, that value is returned.

If you try the above function, you’ll see that once bob has been cloned as bill, modifying values on bill won’t change the original values on bob.

2) A clever exploit of the JSON library to deep-clone objects

We can exploit the JSON library for a rather fast way of deep-cloning objects. Check it out:

This method is nice and fast (faster as a rule than the jQuery method and possibly the Mootools function as well), and certainly rather less code than the first example. Plus, it’s pretty clever–just make sure you add a comment explaining what you’re doing. Otherwise, it could cause quite a bit of confusion!

3) Using jQuery’s $.extend() function

jQuery has a method that can be used to deep-clone objects, the $.extend() function. Let’s take a look at how it can be used:

Pretty handy, eh? This method is a little slower than the JSON exploit, but that shouldn’t really be a problem when you’re only doing a few clones. If you’re doing hundreds or thousands of clones, it might be time to think about the JSON exploit or another solution.

4) Using Mootools’ clone() function to clone objects

Last but not least, the Javascript library Mootools also provides a means of cloning objects–the rather aptly named clone() function. Observe the wild clone() in its natural habitat: