Now that the map is displaying in the way we want, the next step is to add some kind of representation of the player or unit.

This is going to require a little bit more plumbing, as we haven't actually created a Unit object yet. And it's probably about time to think about tying things together in a representation of the GameWorld.

I've created a simple GameWorld class which will create a Unit and a Map (a List<Location>) when instantiated. At this point I've also implemented a Singleton utility class (found in C# 3.0 Design Patterns). I'm sure I don't really need a Singleton, but this implementation makes things easy for the time being, and can be refactored later.

I'm going to expose this GameWorld as an ObjectDataProvider to the WPF application in a resource dictionary. Here is the ODP:

I'm now making a few decisions about the content of the WPF application too. Here I'm beginning to create a series of resource dictionaries, which I'm splitting by general concern. This makes things a little easier to navigate and understand as the number of objects, styles and templates increases.

These are then merged in App.xaml.

To render a Unit on screen, we can add some more XAML to the MapViewer control. Notice here that I'm overlaying a new Canvas on top of the main panel, and then adding the Unit to that. This is for convenience, but also some separation of concerns in case I decide to alter either of these parts (or use them separately). This canvas and its contents have IsHitTestVisibile=false as I am only interested in using the Locations (Tiles) for interactivity though it will look like the Unit is interactive.

The MapViewer now plots a Unit as follows.

A quick change to the logic for Unit means it will initialise at X, Y = 2,2. We can bind up the properties on Unit as follows:

And we can see the rendered result.

At this point I decided to refactor some of the MapViewer bindings to a series of constants which allow me to change the size of a tile, and the dimensions of the map as I wish without impacting on the rendering and interaction logic.

Here are a few useful constants:

And here is an example of a binding to enable that flexibility. This means I can amend my 'real' GameWorld to 50px tiles on a 16x12 grid just by changing these parameters.

Next time we'll make the unit move around.

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

Linerider has been moved to Silverlight. Very cool, and a nice integration with Messenger and the Contacts API. It’s a winner, casual gaming fans!

Great DeepZoom example – a Barack Obama collage made from 12,000 thumbnails from his supporters. I wonder if they could rustle up enough photos to do one of Gordon Brown? (Note: cheap jibe, rather than some description of my political bias.)

The new BBC iPlayer Beta has impressed me. Not so much because it changes the general iPlayer experience in terms of play out, but simply because of the approach to releasing the software.

The new additions of recommendations, last played and the consolidation of radio and TV are helpful, but it’s more about the confident forward motion of the overall strategy that indicates a platform that has been well planned, executed and will be successful.

I don’t often think too hard about the player experience itself as it seems like a very normal thing to do on the web now. But I’ve been looking at some player stuff myself in the past couple of weeks, and with the iPlayer release and Tim Heuer’s work on a generic Silverlight player, I thought I’d see what the general breadth of player experiences looked like.

I’ve created a series of screen grabs on ScrnShots comprising the main UK broadcasting channels and then the list of stuff from the Wikipedia list of Video Sharing websites.

The similarity of each is striking, but hardly surprising, and it would make sense given the statistics that a player should have a similar control set to that of the YouTube player. There are nuances in the behaviours of each of course – particularly in the non-core features (sharing, rating/ranking, advertising) that are still up for grabs in some respects.

So which is my favourite? Ultimately I’m familiar with YouTube and am drawn to that and I like the Hulu player, but actually I think Vimeo is the best. Chunky, friendly and simple. Just like me.

Anyway, maybe there’s some inspiration for you in the list. I’d be interested to know which players I’ve missed and which you prefer.

From the Long Tail blog, Chris Anderson provides a response to a great HBR article entitled “Should You Invest in The Long Tail?”.

Clearly the focus of the article is about the pressing matters facing producers and retailers, but it’s relevant to all of us Web 2.0 types in any case.

I agree with Chris that it’s great to see a well researched article on the Long Tail beyond the usual examples pointed to in the book itself.

It’d be great to see some research on the real effect of Long Tail discoverability mechanisms such as recommendations, ranking and social collaboration. Where’s the value? Are we doing it right? What else is waiting to happen?

Today’s lesson in ‘how to overcomplicate what should be a fairly straightforward matter’ is courtesy of Pampers:

The first thing I want to be able to do in MicroQuest is move my "unit" around the "game world". So I need to establish a mechanism for the movement of the unit.

Given this is a tile based game then it seems obvious that my unit can move a certain number of tiles per turn. Taking my cue from GBA games such as Advance Wars then those games use (at least something similar to) the A* algorithm to perform pathfinding and costing on a map. I just need to code up a generic A* algorithm (it won't be super optimal) to provide the movement capability for my unit.

The AStar class only needs to perform one job, and that is to solve the current path from a starting location to a goal location.

I'm not going to describe how the AStar algorithm works - you can see that in the Wikipedia article, suffice to say that it relies on a sorted set of costs for a given 'node' in a search space (in other words, a tile on the map has a cost which is an assessment of its value as a possible solution).

To make AStar efficient, we try to ensure that we trim the available set of nodes such as those that have already been evaluated. These are kept in the lists of open and closed nodes. So, our AStar class looks like:

The costing algorithm can vary according to need, but the easiest heuristic for a square tile map is that of 'Manhattan Distance' which calculates how many blocks away from a goal a given node is using some basic maths. (In a regular space, then Euclidean Distance may be preferable). I've implemented this as a simple strategy pattern. Not so much because I'm likely to change the algorithm: just for clarity/intent.

The 'Node' is the main class we need. A node essentially wraps a tile on the map (which I'm calling a Location at this point, as Tile has UI connotations).

A Node knows where it is (from its Location) and can assess its cost. This is described as f = g + h which means: total cost = cost so far + estimated cost to goal.

It's important to understand the cost so far and the estimated cost separately as the actual cost may differ from the Manhattan distance heuristic. (For instance, on a tile map, the tiles may have differing movement costs representative of the 'terrain' of the tile).

Finally, a Node can return its 'children' (or neighbours I suppose). And it can generate the path from itself to its origin.

LINQ comes in really handy here as you can see. The GenerateChildren method doesn't just return all possible children. It will also trim that set for those locations that are not passable (obstacles or some such).

This leaves the core of the AStar Solve method looking something like:

Finally, the GetPath method on a Node will return a list of co-ordinates (it could also just return a list of nodes, or locations. That may be helpful later on but this will do for now.

Testing this is straightforward. Creating a simple 10x10 map and then solving various paths (with and without obstacles) are the basic tests needed.

Now this is written, I need to be able to interact with the map in a UI and build on the work so far thinking about Locations and Units. So I'll kick up a WPF application to do just that.

In the process of this, I came across this excellent guide on AStar from the smart chaps at Vertigo. I toyed with the idea of using that implementation, but decided I didn't need the flexibility that it offered and I was also keen on implementing AStar as I understand it which is not necessarily the correct way, but it works for me... ;)

Ah, and then I discovered Eric Lippert's 4 part series on implementing A* in C#3.0. Oh well, done now!

Talking of quests… Chris Craft has been on a quest this month to create 30 Mobile apps in 30 days over June.

You may have noticed that I’ve started using my MSDN Blog again as well as my own. I’ll be trying to ensure I’m cross-posting, though MarcMyWords will also contain the more spurious content.

You can choose which you prefer. If any :)