After a week of tearing my hair out trying to get my game XNA game working in Silverlight (Microsoft’s answer to Flash), I finally have my Black Triangle:

Play Silverlight Demo

For those who don’t know, Jay Barnson explains:

The black triangle was a pioneer. It demonstrated that the foundation was finally complete, and we were now ready to put it to work doing cool stuff.

Actually it’s a spinning cat-girl, which I think has a better ring to it than “black triangle”. (PS: Click her for rainbow mode!)

“What is so special about a spinning cat-girl in Silverlight?” you might ask. Well, the magic part is that the same code also works in XNA – you can download the XNA version here.

Originally I had intended to use SilverSprite to provide my compatibility layer between XNA and Silverlight. As it turns out, the way SilverSprite does graphics is a colossal hack (and very buggy to boot).

The problem is that XNA is based around issuing a sequence of draw commands like “draw a box, draw another box”, whereas in Silverlight you have an object tree (that, for example, describes those boxes) that you can manipulate and that Silverlight will draw for you.

SilverSprite attempts to be a drop-in replacement for XNA, so it must find some way to pair stand-alone draw calls with objects in Silverlight’s object tree. The only way it can do that is by effectively guessing which objects should be moved, removed and created on each frame. This is extremely slow and error prone (did I mention that SilverSprite is buggy?).

My approach is instead to replace the draw calls in my game with my own object tree. In the Silverlight version, that object tree maps onto Silverlight’s object tree. In the XNA version I can just go through the object tree rendering each node.

The upshot of this is that I now have an excellent pathway for porting Captain Stretchy-Arms (and future games) between XNA and Silverlight. Stay tuned!

(PS: I was going to rant more about how obtuse Silverlight’s API is, and how poorly suited it is to doing high-performance and accurate graphics like those needed for games. But now that I have this working, I’m not really feeling that cross with it any more.)

So I started working on the laser effect for Baron von Badass. I did not expect it to take so long!

I started with the animation. After much fiddling I figured out a nice way to animate things in code. Fortunately this is reusable, so any future animations should be much easier to create.

Then I went a bit overboard making the sprite for the laser turret, giving it directional shading despite being drawn only 15 pixels tall. All up, the sprites for the laser took a bit less than a day.

And then I went to work on adding a sound to the laser beam! My goodness, who would have thought that it would be so difficult. As it turns out, it was. It’s not easy to fit a laser-charging sound effect, a laser firing sound effect, and an explosion sound effect all into 1.5 seconds. Especially when you have to make it not-annoying, for when it loops in-game.

But at least it’s done now and I’m happy with the result. I’ve uploaded the first video of Captain Stretchy-Arms, demonstrating the laser effect:

Watch Laser Effect Video

~

You can download this version of the game here.

So I finally bit the bullet and started designing Captain:

(Yes, I know my schedule has gone a bit wobbly. I’ll look into that later.)

The biggest complaint that I have had in play-testing is that the player can get stuck at the bottom of the map (below the “path”) with no way to move forward or return to the top.

The reintroduction of the “bad guy” partially solved this by killing a stuck player – especially when I made the AI specifically do that. But even then it seemed like a hack. It forced the player to have some knowledge of how the levels were generated, in order to play effectively. And when they fail because of this they get frustrated and blame the game.

The reason I haven’t fixed this before is that there is no easy way to get the player from the bottom half of the map to the top without putting blocks in the middle of the path. And that can’t be done because the path needs to be clear to allow the player room to swing across large gaps.

The solution seems obvious in hindsight: A block that the player can grab, but that allows the player to move through it. Introducing: The Girder.

The art for the girder is only temporary, and the way the AI destroys it needs to be fixed. But otherwise it works. You can download and try it out here.

There’s no new art yet. I’ve mostly been working on the opening screen, which I’ll probably post about when it gets added to the game itself.

I’m pretty sure I’m going to overrun my one week of art. I’m strongly inclined to just make it two weeks.

This will just be a quick entry to show you some new art:

First of all: clouds are real this time. Procedurally generated with multi-layered parallax scrolling!

The new scheme for the blocks I stumbled upon almost by accident. I love it and I’m going to go with it. The game will now have a greyscale theme for the background, with colours used only for the characters. I’d like to add some biplanes and perhaps zeppelins now to liven up background a little.

And finally you can see that block destruction now has a visual effect associated with it. I had to waste a lot of time hunting down a very nasty bug in the physics engine to get that working. Grr.

Download this version of the game.