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.

Dragon Sim

An idea I'm working on for an AI competition. The basic idea is that the simulator provides a world for a dragon to interact in. The sim part is locked down, there is no way to modify it or the maps available. Instead what is done is the player creates the logic that the dragon follows. The simulator would then step through a number of iterations, and then the dragon would be scored based on various factors such as how long did it live, how many knights did it kill, ect.

The DPS Game

DPS - Damage-Per-Second

While an incredibly useful tidbit of information in an action oriented game, it really is an overused metric, especialy in rpg type games. So how about a game that focuses on DPS?

You have HP (or life) and DPS. HP of oppenants should be scaled such that normal foes around your level should take 3-4 seconds to kill. These are the only two stats in the game. Maybe two more stats, one called focus that allows you more control over your DPS, and the other a 'stamina' stat that controls.

You can 'allocate' you DPS in several ways. You can have area affect, single affect, and ranges. Focusing all your DPS into a single melee target will give a more intense focus vs trying to hit everything in a circle around you.

Thoughts:

• keep the 'control' and 'stamina' stats. Control affects the ability to create ranged and area attacks. Increasing the stamina cost decreases the DPS penlty.
• thought - 'attacks' can be created with a variety of special effects. The effects have no impact on DPS
• thought - armor does NOT reduce DPS. Primarily visual, maybe have some rare suits that boost one of the 4 stats.
• 'weapons' and 'spells' have a minimal affect on stats. The primarily provide the set of visuals that can be used to construct attacks.

The core mechanic is DPS. Anything that distracts from that is bad.

Train Destroyer

Trains are the only method (for whatever bizarre reason) that certain kinds of goods can be moved about. For whatever equally bizarre reason, you want to shut down the trains. Now the problem with this is the rails, not the trains but the rails themselves are owned by the government. Blow up the trains? That's fine, security is their problem. Blow up the rails? Oh, you're in for it now. So the challenge of the game becomes to destroy as much as possible of the train without damaging the rails.

You get points for :

• Damaging cargo - usually by shooting it with weapons
• Destroying cargo - this is much more risky because the usual method of doing this is by blowing up the cargo container, which carries a high risk of damaging the rails
• Contaminating cargo - the cargo is intact, but in some way 'contaminate' so it is less useful than it normally would be
• Slowing down the train - no one likes late shipments. Doing so is dangerous, as the best way to do this is by taking on the engine, which is heavily protected. Plus, destroying the engine so the train stalls on the tracks will get you penalized as well.

*thought - rival companies hire 'lane pirates' to strike at each others trains. You can start out as a loner, and eventually either create your own group or sign up with an existing one.

Initially you have a very modest base of operations, with a simple strike flyer. You initially have to be cautions about which targets you take on.

*thought - trains can carry cargo for more than one company. In some cases you will have to be very careful not to hit the wrong sections of the train.

As you get better and earn more money, you can upgrade your craft and weapons.

Victory conditions could be crippling a certain industry, or taking down a monolithic corporation.