For loops, while loops, fruit loops…
There are a lot of different kinds of ways to write loops in Javascript. You have your standard for loop and while loop, but beyond that you have the do-while loop, the object properties loop, and lots of different variation of all four “basic” loops. In this post, we’ll examine the four basic loops, the reverse for loop, the reverse while loop, the short reverse while loop, object property loops, and more. I’ll also explain a bit about loop unrolling and where/how it can help you optimize your code. Read on, if you dare!
One of the ideas that I’ve been rolling around in my head lately is the possibility of a roguelike completely lacking in any sort of graphical user interface (GUI). Basically, this means the game would have no menus or displays of any sort–not even a health display or or turn counter–on the main screen of the game. Instead, the user interface would all be in text, displayed in a separate message console/log thingy (don’t you just love my technical terminology?). Events in the game, player stats, monster stats, and all that would be displayed through such a console.
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)
I’ve been meaning to release my self-contained implementation of A* pathfinding for a while now, but it took me forever to get around to cleaning up the codebase and stuff. Anyways, once I did tidy it up, I decided to release it. Hopefully somebody out there will find it useful.
So, for a while now, I’ve been planning out a book on writing Roguelikes with Javascript. Unfortunately, there aren’t a lot of resources for RLs in Javascript at the moment, so the book will have to be pretty broad, as it won’t be able to build on previously established information. I will attempt to cover most of the aspects of writing a Roguelike in Javascript; the book will contain the algorithms that are most essential to writing a Roguelike.
Field of view, and stuff
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.
In this article, I’ll be discussing how to generate neat-looking fully connected caves using cellular automata. This algorithm builds off of another algorithm which can be found here. As noted, the linked algorithm is incomplete and cannot be used for generating dungeons that are suitable for a real roguelike. This article is about the method I used to make that algorithm workable.
Console-like display in the browser?
I’ve been working for some time on a Roguelike in Javascript. One of the first things I had to do for my Roguelike, of course, was establish some sort of display routine. I could have gone with HTML5′s new <canvas> tag or something similar, but setting up a console-like environment for canvas can get a little involved. So instead, I established a way to use the browser’s native text rendering. Say hello to a simple Javascript class for console-like rendering in the browser: I call it display.js.
The Roguelike genre has been in development for decades–since 1980, in fact, when Rogue, the first Roguelike game, was written. Since then, Roguelike games have been created in many different programming languages. Among the more popular of these languages are C, C++, Java, and Python. However, a new contender is appearing: Javascript. Although it’s the new kid on the block, Javascript is quickly becoming a popular choice for Roguelike development and has already been used to make quite a few games.
8 great A* pathfinding resources
If you’re writing a game that incorporates both a terrain of some sort and enemies that walk around, the chances are you’ll need some version of pathfinding to control the enemy movement patterns. The thing is, pathfinding is serious business–it’s not easy to grasp. To make things worse, there aren’t many good pathfinding resources–most of the articles that turn up on Google and such only serve to confuse you further. That’s why I’ve taken the time to compile this list of pathfinding resources that I’ve found to be actually helpful, as opposed to confusing or just plain wrong. Enjoy!
4 creative ways to clone objects
There are a lot of ways to clone objects in Javascript, and some of them get pretty creative. jQuery has an excellent method for cloning objects, as does Mootools. There’s a Javascript hack we can sort of “exploit”, or we could just clone our object in plain Javascript. Let’s start with the vanilla Javascript first and move on from there.