I just came across this post on Mike Taulty’s blog where you can view his 50! Silverlight 2 tutorial screencasts. I really recommend taking a look, they cover a wide range of Silverlight features and are excellent.
Last night I completed the initial version of Digger, the SilverRogue dungeon editor. It doesn’t do a whole lot right now but can be used to paint Floor and Wall tiles on a serializable map. It didn’t take that long to implement - after spending an evening on a failed attempt to create the editor in Silverlight, it only took two further evenings to implement in WPF.
The screenshot shows a dungeon consisting of Floor (light green) and Wall (dark green) tiles. A map is basically a 2D array of ITile. Floor and Wall tiles are separate classes which implement ITile and other interfaces specific for their required purpose. Tile views (what you see on the screen) are not persisted, but instead created by the executing application. Digger is used to create and serialize dungeons that SilverRogue can deserialize and render with Silverlight UI controls.
I had to do some work to build separate Silverlight and WPF compatible assemblies from the SilverRogue engine single source. The Silverlight SilverRogue app and WPF Digger editor both need to reference the SilverRogue engine code which contains all the game data structures, but because of binary incompatibility, it’s not possible for them both to reference the same engine assembly.
To workaround this, I wrote a utility that inspects the Silverlight SilverRogue engine csproj and generates a WPF compatible csproj in the Editors solution and is referenced by Digger. This generated project (and unit test project) is not checked in to subversion but auto generated every time the source project is modified and built. It works pretty well even if I do have to occasionally flip between solutions. The engine project only contains game data structures / logic, or what you might term the Model layer in the Presentation Model design pattern. All the View code (UI controls) is contained in Digger (WPF) and SilverRogue (Silverlight), and maybe even XNA one day. 
I’m in two minds of what to work on next. I’d really like to support Sprites, but I think I’ll probably make a start on the game framework in Silverlight so that I can load a dungeon in SilverRogue and move the hero through it using the keyboard. It’ll be great to have something playable even if it doesn’t look that good.
I had a few hours spare last night so I made a start on the SilverRogue map editor. The SilverRogue projects are Silverlight so the editor needs to be a Silverlight application to link to those assemblies. Editor/Designer applications are typically desktop based but Silverlight brings the power of the desktop to the browser, so implementing a fully featured Editor/Designer in Silverlight isn’t going to be a problem. Right?
Wrong.
Maybe I’m being a little unfair because I’m criticising the beta and I was expecting to find the WPF features I’m familiar with. Hopefully the features I need might be present in the final release.
Currently SIlverlight doesn’t support Menus and Toolbars. OK, no biggy, it’s just a simple editor, I’ll just add some buttons at the top for Load and Save. Ah, um, saving to the local file system is not supported! Some have the opinion that the desktop is truly dead once Photoshop runs in the browser. Well that’s not going to happen with Silverlight 2 beta if the user can’t save their files!
Also, mouse support isn’t quite as fully featured as in WPF. I’d like to know the mouse button states on the MouseEnter event. Maybe only a minor issue but I really wanted to be able to paint tiles onto the map. I couldn’t work around this by recording a mouse-down flag in conjunction with MouseMove. I had a few other minor issues but it was the no save issue that was the show stopper.
So I’ve decided to implement the Editor in WPF. Of course this presents me the issue that the editor can’t link to the SilverRogue assemblies because of binary incompatibility. I can get around this by auto-generating .net 3.5 projects from the SilverRogue Silverlight source as part of the build process.
The good news however, is that I’ve implemented the tile/map data structures, so once the WPF UI is complete I’ll have an editor to create and edit empty dungeons.
Finding time to work on SilverRogue over the last few days has been difficult but I’ve now met my first deadline of porting Juniper to Silverlight. Juniper is an IoC framework plus additional application blocks I wrote which I use to quick start development on new apps. I only ported the IoC container, Logging and Serialization blocks. The other blocks weren’t ported as I either won’t require them for SilverRogue or they just can’t be ported (such as aspects (AOP)) due to the limited subset of .net 3.5.
Porting was pretty straight forward. The only rewrite was to swap out XmlDocument usage for XDocument. Fortunately I have unit tests so I could confirm the rewrite worked as it should. Frustratingly I had to implement lots of mocks in the unit tests to replace the ones dynamically created by RhinoMocks.
I typically build applications from services (contracts/interfaces) and components. The Serialization block enables graphs of components to be persisted to xml. This essentially solves all requirements of loading/saving games, levels, monsters etc if they are constructed from components. The framework isn’t intrusive, you don’t need to derive your class from a special Juniper base class, just sprinkle a few attributes through your code and the framework will be able to register, construct with auto creation of dependencies, and serialize components. And of course, just like an IoC container should, you can explicitly bind components to services so that I can plug-in and use new components without changing any calling code.
So now that’s out the way, I’ve started work on the components required to build a Map (dungeon) and also a Map Editor. Most of the dungeons in SilverRogue are going to be randomly generated but I think some will be created by me to aid the story. The Editor will be very useful for creating maps used for unit testing to confirm the game correctly handles certain map layouts. Maps and Tiles architecturally consist of two layers, the Model and View. I’m using the Presentation Model pattern for this. MVP is probably overkill and likely too bloated for a video game? Separating the game engine/logic from rendering really helps with making unit testing easy.
Hopefully I’ll get the first cut of the editor complete next week and post some screen shots.
If you read the common definition of a Roguelike such as stated on the excellent RogueBasin site, you’ll learn that it is typically a turn based dungeon crawler where you, the hero explore a 2D world rendered in ASCII, collecting items to aid you in your exploration and fighting monsters. Dungeons are randomly generated and once you’re dead, you’re dead! The next time you play it will be through completely different dungeons.
I’m not a hardcore Rogue player, in fact my only experience of Rogue was on the Mac when I was a kid. It had 2D (monochrome) sprites, not ASCII, and I don’t really remember much more than it was a lot of fun to play and very addictive.
So SilverRogue will be born more out of nostalgia and my imagination than based on any concrete Roguelike game. It’ll respect the spirit of the typical Roguelike but with some notable differences. No ASCII but tiled (vector?) graphics. It’s going to be written in Silverlight and provide more of a casual rather than hardcore gaming experience. Dungeons will be smaller and faster levels. And there will be LOTS of monsters and items. LOTS! I’ve also got a story in mind but I’m keeping it secret until release. It has a wicked twist!
Silverlight TDD just got a whole lot easier. Thanks Jamie!
Jamie Cansdale has just released a Silverlight NUnit Project template that enables you to write your tests in NUnit. The big advantage of this over the MS Silverlight Unit Testing framework is that you can use TestDriven.net to run one or multiple tests from within Visual Studio and also have test coverage reporting using NCover.
This is great news for me as I have lots of existing NUnit tests that I need to port to Silverlight. I’ve just followed the instructions on Jamie’s blog and can confirm that it all works perfectly.
For SilverRogue, I’ll be using the MVC pattern to seperate the game logic from rendering which will enable me to TDD the majority of the code with NUnit (as I’m currently used to working) and test Silverlight rendering with the MS Unit Testing framework.
I’m not yet sure how all the different unit tests will be run from CCNet.
update: CCNet runs (via NAnt) the Silverlight NUnit tests just fine.
Welcome to the SilverRogue blog!
Today I start the development of SilverRogue, a Roguelike video game written in Microsoft Silverlight.
There’s lots to do to set up the project and build environment before I can even start designing the game:
Once all the above is done I can start on the fun stuff!
