I was a little bored.

So we’re going to have three libraries progressing in the immediate future, with quite a few more over time:

1. HtStub – An embeddable, zero-config, zero-behavior secure Erlang webserver
2. SC A-Star – An efficient, modular ECMAscript (flash/actionscript, javascript, jscript etc) A* implementation with support for custom grid geometries (includes algorithm tutorial)
3. TestErl – unit, regression and stochastic testing for Erlang
4. ScUtil – a fairly large list of gap filling functionality for Erlang

In the near future, I will add C++ and PHP libraries, as well as many some libraries for more obscure languages like FormulaONE, Mozart-Oz, Factor and maybe (sadly) Delphi.  I have more than 30 libraries ready for release.

All those repos are pretty empty at the moment.  That will change in coming days, and I’m sure I’ll post lots of boring little snippets here about whatever minor new thing my crap does.

Yay!

Now that’s a win.

And, to be plain, I’d forgotten how much of a hassle a shadowcaster actually is. I went to dig up maybe some example code, but the good answers were few and far between; there are several each at various roguelike sites like Dungeondweller, but the articles are written to widely varying levels of quality, most without source, and with no apparent method to compare between methods. Most of them an experienced programmer can ignore out of hand, but one of the algorithms up there is just repeated line of sight, which is dead slow. It’s enough to make a man think about writing another tutorial…

Luckily, I know what’s up, so I’m going to implement recursive shadowcasting. There’s a not-half-bad implementation in this tutorial by Gordon Lipford, but in several places he sacrifices efficiency or power for readability. Right thing to do for a tutorial. Wrong thing to do for production code. (He also has several unexplained actions here and there, writes pseudocode where interactions aren’t clear, and requires the reader to reimplement several structures from explanations, but whatever.) At any rate, his method is efficient, flexible, and less painful to implement than some of its competition, so I’m running with it.

One of the very cool things about Lipford’s method is that it’s arc-angle based. As a result, objects don’t actually have to fit a tile; rays are radiated. That means that anti-aliasing one’s shadows is in fact realistic; I’m halfway done with that in my shadowcaster now. Other things could be added, but I’ve decided to skip them for now. One of the really neat things about this modified method, though, which uprises from the line of sight algorithm is that I have accurate overhead cover rules and a good set of premise data to work in the notion of “perception.”

Simulating perception accurately is traditionally a problem for AI behavior, but in a Roguelike it’s a bigger problem than usual. Because roguelikes offer such complex tactical situations, and because speed in varying environments is such an issue, players often want to “lose” the predators by hiding. Lots of the common methods for handling roguelike behavior involve simple distance calculations, meaning monsters can semi-effectively follow you through visual obstacles which otherwise should confuse them, such as walls. Sometimes this is of great tactical advantage to the player; s/he can use slight speed or distance advantages to get around a wall with a u-turn, then rely on the monster keeping the nearest mathematical distance and walk the other way down the wall, acquiring some safety.

Now, I’m all for cheating on the player’s behalf; one of these days I’ll blog about it at length. However, there’s cheating and there’s cheating. Some of it keeps little nagging things from ruining gameplay; that’s good cheating. Being lax on player bullet collision, and being overstrict on player personal collision, means that the player “just barely gets by” when oftentimes they shouldn’t, and “just barely makes the shot” when oftentimes they shouldn’t. You can just crank the game difficulty to compensate, and it leads to a player never feeling like they were ripped off or cheated. The Japanese game company Treasure are absolute masters of this careful balance (sorry, AFAIK they don’t have an English-language page. Just pretend you can read it.) But, there’s another kind of cheating that game programmers do. Actually, there are several others; I’m gonna skip stuff like giving opponent AI information it shouldn’t have to keep it competitive. Right now, what I’m going to talk about is sacrificing realism for computation time.

There are several problems with cheating to save computation time. Some of them are reconcilable; others aren’t. Generally the least controllable issue here is that oftentimes you just can’t afford the raw horsepower to do what you want to do correctly. First person shooters in the 286/386 era are a prime example; Wolfenstein and DooM got by just fine with blitting, but given modern standards they look positively silly. The important bit here, though, is that Wolfenstein and DooM’s approximations were good enough™ they did not adversely impact the game, and until they were made outdated by the horsepower required for a more accurate solution, the impositions their techniques created generally didn’t impact the game. (There are a few exceptions, notably the 2d+height map preventing truly 3d maps, but that was more of an engine issue than an issue of approach, so whatever.)

Horsepower aside, though, there are also issues of sloth or ignorance. In fact, field of view algorithms provide an excellent example even compounded above the previous example. Gee, can you guess what I’m gonna start going on about?

The fact of the matter is that on a complex 2d planar map, even implemented well, field of vision code is moderately expensive. Hansjörg Malthaner brags, and rightfully so, that his field of view implementation can crank out a 59×59 area in under 2ms on a 400mHz k6/2. Whereas that may sound like hopelessly antiquated equipment by today’s standards, please remember that that’s talking about the field of view for just one creature; even dealing with a machine that can push 16x what that does, when you’re dealing with (say) 256 creatures – and that’s not terribly unlikely in a Roguelike at deeper levels – you’re still looking at around 32ms, just to figure out what monsters can see what. That’s before you consider anything like, say, what the monsters’ responses would be. And, to put that in perspective, we’re talking about a full two frames at 60fps (the rate at which most console hardware runs) – that’s slow enough to see a stutter, even on modern hardware.

And – I cannot emphasize this enough – Hansjörg’s implementation is good. This is not the upshot of some naïve bumbling. This is what kind of speeds one should expect.

Now, granted, this is a fairly severe situation. For one, 59×59 implies sight radius 29, which is big by anyone’s standards, and since we’re talking about area which is exponential and a workload tied to a surface unit instead of an edge, and since that workload is also exponential, then having an area that big is pretty serious. Also, games other than roguelikes don’t usually have low to middling hundreds of active, thinking opponents at a time (well, inasfar as roguelike creatures think, really, but that’s beside the point.) But, as we all know, I’m working on the Nintendo DS, which is a 67mHz ARM9; when we’re there, we’re just not talking about cutting edge computational power, and therefore speed seriously matters to me. Granted that the field of view in my game is much smaller, it’s still a pretty big issue.

This is where the kung-fu comes in. See, there are other repurcussions to choosing a field of vision mechanism other than speed. Granted speed is what we’re interested in here, but there are other things to be considered. That is, for example, why I’m not implementing the giant goto map generator of Jesse Welton’s. Instead, what I’m doing is going to give me view regions for specific tiles; that information will be enough to implement a much, much stronger perception algorithm, by gauging what fraction of a tile is visible. That way I can have monsters with very long sight who won’t notice you sneaking up on them around corners, or monsters who only see six or seven tiles away, but who notice absolutely everything in range. It should make far more satisfactory AI chase behavior, especially since I’m going to be tracking actual creature knowledge.

Anyway, that’s just what I’m working on in Southgate at the moment. New topics soon.

Mad props to Bret, I’m just jealous. But, good work, and also I hate you now.

Depending on how well it turns out, I dunno, I might release the code and/or write a tutorial. The code is based on the tutorial by Gordon Lipford (which I originally found on Dungeondweller.) My adjustments to it are just tuning and slight extensions which aren’t in fact very difficult to make, plus a bunch of style refactorings. We’ll see – maybe I’ll put it with the other tutorials and example code. For now, Björn Bergström’s tutorial or Tobias Downer’s tutorial will be the best no-code explanations you can find.

Because every time I develop a tool to make things easier, that just gives me an excuse to make a system triple as complicated. Every time I make something easier, it turns harder. This is something of an annoying habit of mine, though it’s also led to some of the best things I’ve invented. That said, it’s also led to a lot of wasted time and extra complexity – not that that’s exactly a terrible thing in a hobby project, but still. Whether this is going to turn out in that fashion remains to be seen.

Once again I’m babbling about my new dungeon generator. I set up a sort of tagging system which allows the system to determine what kinds of styles are appropriate for the rooms, so that themed levels will come out correctly. The problem is, I wanted all this flexibility, and now I’ve got this giant mass of code that quivers every time I touch it, and occasionally howls at the moon. Unfortunately, that’s actually fairly common behavior for my code. Go figure.

Anyway, I’ve got six room types implemented under the new system, and the dungeon generator’s already turning out surprisingly interesting results. I’m veddy pleased. Hopefully, you will be too, but if I don’t get out of the blog and actually write it, we’ll never know.

I’m discovering, since I haven’t attempted one in several years, that the older a programmer you are and the more strange tools in your belt, the more fun dungeon generators are to write. Back in the day, it seemed like a huge and painful task. Now that modularity is second nature, it’s turning into a joy to write. This is sort of a surprise to me; last time I wrote a Roguelike, the monster system was by far and away the most entertaining, and the level system something of a chore. I kind of wonder whether the new monster system is going to be as much fun.

Anyway, one of the greatest joys of the new way I’m doing things is the distribution method for rooms. It’s a little memory hungry, but on the bright side I can just snap new room types into place, and bang, they’re used appropriately throughout the whole game, according to depth, theme, and several things I’m not yet discussing. I’ve only snapped in a few kinds of room so far, but already I can play around with the probabilities, and I’m getting results I really like. This generator is both much easier to extend and to balance than the old one. It’s going to be quite a bit more entertaining for me, I think.

After that, I think it’s time to put my foot down about how the character system actually works. It’s changed too many times in my head. I need an implementation. I have a really weird idea, though, and if it pans out, you guys are going to give me total horizon stare. (Teh awesumm.)

In the meantime, besides the daily image, I have a neat link which someone handed to me on IRC. It’s weird – half the people who watch it think it’s gross, and the other half think it’s hawt. I find myself in the latter camp.

So, the tree culler that Aske Plaat came up with is pretty damned fast. I snapped it into my Highly Crappy™ chess algorithm, and sure enough I got about a 7% cull increase over the old iterative deepening Alpha Beta culler.

Yeah, except it’s got a small problem, is the problem. For reasons I don’t yet understand, it’s playing the wrong side of the tree. It walks and evaluates the tree correctly, but instead of playing the best move it can find, it plays the worst. (Actually I’m keeping it around for misere games, and it’s not half bad at them, but that’s not the point.)

The point is, what the hell is wrong with my code?

I’ll release the revised mtd(f) code Real Soon Now; I just need to, you know, get it to work. (Oddly, there’s another version of that page on his old academic web page, except it seems to be out of date, and as a result is missing several bug-fixes.)

Still, it’s just amazing watching this game play. It’s fantastically good at sucking. I can’t not beat it.