Monday, April 25, 2011

BSP Dungeons are Harder Than They Sound

So I finally have a perfectly working implementation of the BSP Dungeon algorithm.  What a journey.  Of course a lot of the trouble was fighting JavaScript.  It's not that JS is a bad language, far from it.  There are some language features that I really like in the language, and for client-side scripts you really can't beat it.  But there are some defined gotcha's that you need to watch out for coming from a C++ or C# background as I was.  The two biggest I ran across are:

Loosely Typed
JS is not strongly typed, meaning if you decalre a variable, it's data type depends on the data it is holding.  So you can create an integer, and if you then mistakenly assign a string to it, nothing bad will happen.  Well, nothing until you go to use said variable, then you're scratching your head trying to figure out where that NaN came from.

Very Dynamic Objects
Objects, and indeed variables in general, are extremely dynamic in JS.  Generally speaking, if JS sees an assignment to a variable it doesn't recognize, it assumes that it is a new variable, not a typo.  So if you define your rectangle object to have a .width, and you assign to .w, it happily creates a 'w' property for that specific instance of the rectangle object.  Not fun to track down.

Solutions
Well, it isn't all doom and gloom here.  There's some very simple solutions to those two issues.  Perhaps the biggest is to unlearn some of the laziness that modern IDE's install in you.  I never realized just how heavily I rely on IntelliSense when working on C# code to complete variable names and to make sure I didn't use the wrong data type.  Simply being more aware of what your variable names are will help in any language, and is very important in JS.

For the Dynamic Objects, as soon as I stopped fighting it and instead embraced it, things went a lot smoother.  At one point I was fighting with arrays and them not passing through functions by reference like I thought they should.  I was agonizing over this, because I didn't want to totally break OOP and place the arrays that were used in just these two functions as object level arrays.  Then I realized: Hey, JS has been tormenting me with creating Objects/attributes at will, so why not go with it?  Create a one-off object right there with the two arrays I needed, and it worked just fine.

The other major lesson I learned was to use a debugger.  Initially I didn't have any tools beyond the syntax highlighting in the Ace editor in Kodingen.  Pain.  So.  Much.  Pain.  Once I installed Firebug and got familiar with using it for debugging, things went a lot smoother.

So with these lessons under my belt, it is time to start getting things moving a little quicker.  I'm already far behind where I thought I would be, and would like to get the player visible and moving through the dungeon.

But for now, I'll just hit the split button a few times, generate some rooms, and bask in the glory of a working algorithm.

No comments: