Interesting post from Tim Anderson who is coming out in favour of WPF. The basis for this appears to be largely because we’re developing Visual Studio and Expression with WPF ourselves.

Good-o. WPF is a great technology.

But then an odd choice of words:

The big caveat is that developing new applications using a Windows-only API does not look like a smart choice in many scenarios, though it could still make sense within some organisations, or if your application is strongly hooked into Windows anyway.

What? Why?

The article begins with “So you need a new Windows application.” In that context, I’d suggest that making use of the Windows APIs would be a great idea…

From a development perspective it is because of innovations in Windows: touch, sensor APIs, UX techs like WPF – that developers are able to target these great features, innovate with solutions on top of them, and know that huge volumes of end users have those capabilities to ensure the viability of the solution.

Windows APIs are unique for developers who choose to target Windows but the point is that Windows is basically everywhere. Aside from the specific features, the real uniqueness here is that only Windows can enable the mass-market with those features and push the boundaries for solutions in that space – and I’m pleased that the Windows team continues to do that.

Developers using this stuff are gaining differentiation, and advantage.

Talking of great examples, MikeT had a crack at the Twistori thing that MikeO looked at but took a slightly different tack and employed WPF. He’s written the whole thing up as a 7-part (count ‘em) series. You can start here.

Much as I love Silverlight, I’m a sucker for those WPF shader effects…

In the last post, I cobbled together something that was serviceable as a pathfinding routine, and was left with the beginnings of some structures - such as Location and Unit - that would be needed in MicroQuest.

In this post, we'll look at building the beginning of the WPF application that will represent the MicroQuest game, and start binding up the functionality to a user interface.

Right now, I have two main projects in my solution:

• The 'Engine' which is a UI independent domain model for the game (and so contains the logic and classes for pathfinding, units etc.)
• The 'Viewer' which is a WPF application that will visualise the game world and provide an interaction model.

There's also a test project, and a console app for some quick spelunking.

We'll start small with the UI and build out some limited interactivity for the map before we think about game loops and the like.

To interact with the map, I'm going to build a control (MapViewer) that will render the map correctly and respond to mouse interactions.

I've wrapped the List<Location> structure as a Map, and then added a little functionality that will return a test map (simple 10x10 representation). In order to bind this to the UI, I'm hacking in some calls into the MapViewer for the time being.



The MapCanvas is actually a ListBox at the moment (though I'm sure you can see where I'm going with this). So our application looks like this:



That's not a bad start. We just need to get the layout and rendering to look right. Shouldn't be a problem.

In this case, I'm swapping from a ListBox (which offers stuff I don't need right now) to a plain old ItemsControl and then creating a panel template (a Canvas which sets it's Left and Top (i.e. X and Y)) and then a data template for a location which will be a button (as I want the Click event).



With the addition of this code, then the location list now looks as follows:



With the addition of a new button template (in this case just a green rectangle with a lighter stroke) we have the basis for a map.



This is a little boring, so the next step will be to get our Unit rendered and then move on to interaction.

Technorati Tags: wpf, game, microquest