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.

Dev Environment

Initially I was going to use my staff web page, but two things cooled my heals on that:  Speed and customization. Publishing to my staff page is slooooooooow unless I'm on campus.  Not good for iterative development.  So I switched over to http://kodingen.com.  So far I've enjoyed working with this in-browser dev environment.  As long as I don't go over 1GB of data transfer each month, I'm good.  Of course going over 1GB of data because of people playing WebRogue would be a nice problem to have....  The URL for the project is http://webrouge.languard.kodingen.com.  At this time I haven't decided on where I'll keep issues/bugs/source control.  Considering using the fine folks at http://www.fogcreek.com/ as I really liked their software the one time I got to use it in a commercial project pre-teaching days.

As for progress made: Site is setup, Google API key obtained, and the base index.html page is setup.  Should be able to get the tag setup and get something moving on screen tomorrow.

WebRogue - The start

So, why do I think RLs can be used to teach game programming and design?  Why would I care?  And why am I writing all of this?  These are fairly simple whys.  The main inspiration struck me during the Game Developer's Conference listening to Andy Schatz talk about Monoco and some of the tricks he did.  I just suddenly realized that were RLs an approachable project, something that could result in a fun playable game within a semester.  As to why this matters to me, I teach said topics at Johnson County Community College in Overland Park, KS.  And finally for the writing, it has been a while since I've written something that is sustained over more than a day or two, so I need to sharpen my skills.  I also want a good record of what I did when and why, to better enable me to make good conclusions at the end of this.