Miniclip recently sent out a press release announcing support for Silverlight games on their site.  The announcement refers to a specific game, Zombomatic, developed by Terralever. The game has actually been on the Mini Clip site for a while along with another Silverlight game, Tunnel Trouble, by the same developer.

Although the timing of the press release is slightly delayed, this is still a big deal for anyone developing or planning to develop Silverlight games.

By announcing this in an official press release, it shows Miniclip, the largest online web-games portal with 43 million user, really sees a future in Silverlight as a gaming platform. It adds some legitimacy to what many of us early adopters already knew: Silverlight is a great platform for games.

I hope this will spur other flash-only game portals to take notice.  Silverlight games are coming. A LOT of them.  Web-game portals with a keen eye for the future will be ready.

Thank you Miniclip for leading the way...

A couple weeks ago, Larry Clarkin, from Microsoft interviewed me about the Farseer Physics Engine for the Thirsty Developer podcast.  The podcast is now available here here.

In preparation for the upcoming alpha release of Diver, I have updated the Diver landing page with a Silverlight 2 intro screen. It has waves! :-)

I've got a few more things to clean up before the alpha is ready for release.  I hope to have something up in the next couple weeks.

The game's graphics are not final so expect to see changes as I start releasing playable versions.

There is also no sound yet for the landing page. I'm still trying to find something that fits.

Here's a screen shot of the intro screen if you don't feel like jumping to the actual page.

Andy Beaulieu has updated his game, Sort the Foobars, for Silverlight 2.0 Beta 1.

The physics for Sort the Foobars is powered by the Farseer Physics Engine.

In the process of developing my Silverlight game, Diver, I came across what can only be a bug or limitation of the current Silverlight Beta 1 release.

If you create a PathGeometry in Blend using the pen tool, you can not automatically access the path data from code.

For example, the following snippet is the XAML created by Blend for a simple triangle. (I removed some of the attributes to to keep the code snippet short.)

<Path x:Name="Triangle" Data="M195,81 L267,173 L158,177 z" Fill="#FFFFFFFF" .../> 

(Note that Blend uses the short-hand path mini-language to describe the geometry of the triangle.)

Now, in Visual Studio, if you try to get access to the PathFigureCollection of the triangle's PathGeometry like so:

PathGeometry pg = (PathGeometry)Triangle.Data;
PathFigureCollection pf = pg.Figures;

no errors are thrown, but the pg.Figures returns null.

Furthermore, there is no property, that I could find, to get at the PathGeometry's mini language text.

It turns out this is only true of PathGeometry objects that use the mini language in their XAML mark-up.  If a PathGeometry is fully described (ie no mini language) then you can programmatically get at the PathFigureCollection.

The problem is Blend ONLY creates PathGeometry objects using the short-hand mini-language. There is no option in Blend to force full XAML mark-up for all PathGeometry objects.

This has been an issue since Silverlight 1.1 and I was hoping it would be fixed for the Silverlight 2.0 Beta, but no such luck it seems.

I have, however, found a bit of a hack to get around this for now.  This hack will force Blend to generate the full PathGeometry XAML rather than the mini language. 

Within Blend, go into XAML view and in the UserControl.Resources section add a bogus Storyboard like so. (I apologize for the poor formatting, my blog editor was not cooperating)

<UserControl.Resources>
<Storyboard x:Name="PathGeomHack">                    
<PointAnimationUsingKeyFrames Storyboard.TargetName="MyPath">                    
</PointAnimationUsingKeyFrames>             
</Storyboard>      
</UserControl.Resources>

Where "Triangle" is the PathGeometry for which I want Blend to render the full XAML.

Now go back to the design view and make an edit to the PathGeometry. I usually just slide a vertex point around a little. This is just to trigger Blend to regenerate the XAML.

What you should see is that with the bogus Storyboard pointing at your PathGemoetry, Blend will generate the full XAML tree rather than just the mini language.  This means you can then get programmatic access to the PathFigureCollection object from your code-behind.

I haven't done much else with this to discover any further simplifications or limitations, but this does give me what I need for now. Hopefully the next beta will have this issue resolved.

Hope this helps someone.