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.

Update on BSP Dungeons

Work is progressing :)  Still don't have anything playable, but I've almost got the BSP Dungeon algorithm fully implemented.  You can split it down and generate rooms at any split level.  You can test it out here: http://goo.gl/VCr9H.  What I need to do now is get the rooms connected and then add in a UI for configuring the parameters.  Eventually I want to have it so players can have some measure of control over how the dungeons look.

Current Focus: Get the BSP Dungeon algorithm finished, implement the basic UI, then get the player moving through the dungeon.  After that we will see.  Probably monsters.

Progress report

Tracking down the shim for cross-platform usage of window.requestAnimationFrame was a pain.  Especially since I couldn't remember what it was called, just that Google recommended something besides setInterval for timing for web pages at GDC11.  For those looking for a link: https://gist.github.com/838785 for just the code, and http://paulirish.com/2011/requestanimationframe-for-smart-animating/ for the author's original article.

I was considering using inline vectors for the first round, but came across something that gave me a major pause: http://caniuse.com/#cats=SVG  According to this chart, only 16.19% of browsers support in-line SVG.  Ouch.  That's IE 9, Chrome 10, and FF 4 only.  Opera isn't scheduled to support it until 11.5 and Safari not until 6.0.  I'm willing to take some hits on using HTML5 stuff, but not that big of a hit.  HTML5 canvas gives me 51%, which is basically just losing the people stuck on IE 8.  That hit I'm willing to take.  So if you are using IE 8 and have a choice:  go get Chrome or FireFox :)

Slowly getting my head wrapped around javascript again.  It has been a very, very long time since I've worked with it.  Like 12-13 years.  It has changed a lot in that time.  With that said, work on core.js has been started. I need to get a source control repo setup sometime this week.  Not 100% sure how to do that using Kodingen though...

Might finally get something playable tomorrow!

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.