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

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.

In a previous post I talked about inspiration and decided that I'd spend more time 'just coding'. This series of posts on 'MicroQuest' will be about my adventures doing just that.

It’s sort of a vague attempt to copy from the master (Andrew Braybrook of course!) and keep a diary on the creation of a simple game (from the point of view of someone who doesn’t know how to do it…). I like game programming because it saves me having to think about real-life troubles (such as integration) and allows you to construct a domain model from scratch.

About MicroQuest

This is a bit of an exploration, so I haven't fully formed exactly what MicroQuest will look like when it's finished, but a few principles for how it will work:

• A turn-based game (so I'm not concentrating on game loops and perf and stuff)
• A tile-based game (lends itself to layout and controls in WPF)
• A little bit of online/multiplayer stuff - I have some ideas on this which I'll think about later.

I want to create a game that's a little RPG-ish, and a little Strategy-ish. Influences are Advance Wars, Golden Sun and Fire Emblem on the GBA. I've done some of the basics of coding for this a couple of times using GDI+, but this will be the first time using WPF.

The game loop will be something like:

• From 1 until x turns (x will have a concrete number)
  • Move, Check for Events, Combat, Check for Events, Action, End Turn

• At x turns, assess achievements and ranking

About Technology

I'm going to use WPF to create my game. It's not the technology I should probably choose - maybe I'd be better off using XNA. Actually I'd probably be better off using Popfly Game Creator...

But the point here is to flex my general coding skills with the mainstream techs such as WPF and Silverlight, and the surrounding technologies such as LINQ, Astoria and all that.

And have some fun along the way.

Finally

I'd be happy to put this on CodePlex or similar if anyone is interesting in contributing. Feel free to contribute some graphics too. Best set gets to decide the actual game!

If you haven’t already seen the Kit3D stuff before then take a look at this demo site…

Sometimes it’s easy to forget that a lot of the fun of coding – in whatever form that is – is the exploration and discovery of new tools and techniques.

A couple of things that jogged my conscience happened in the last week:

• This month’s Edge had a feature on RuneScape and how they’ve developed a hugely successful MMOG from back-bedroom beginnings.
• Scott Hanselman kicked off his exploration of WPF with the creation of BabySmash and a call to action to help him out with it. Lifehacker have already picked it up.

It reminded me that being a master is an aspiration, but all of the fun is in the journey to that point. I think that technologies like WPF and Silverlight lend themselves to the fun of the journey because they’re directly accessible and efficient but have tons of depth and possibility should you wish to master them. Stuff like this.

With that in mind I started thinking about why I got into programming in the first place. (Professionally it’s because I wasn’t dedicated enough to be a doctor, but that’s a different story.) It boils down to a childhood subscription to Zzap64 magazine, which focused on the Commodore 64, and a 4-part article by Andrew Braybrook on the creation of Paradroid (probably one of the best C64 games ever). I’d already bought Gribbly’s Day Out and thought it was brilliant, so reading about a hero building his new game, and then the game turning out as good as it did was just great. And that’s why I started programming.

Braybrook did some other great stuff too (notably for me was Uridium) but it was the Paradroid article that represented the zeitgeist for me as a kid.

I found the diary on an archive site – you can read it here. Looking at again made me nostalgic, but also inspired by the discovery process, and the hacking that is clear through the writing.

I was pleased that Andrew has a Wikipedia page, though I’m hoping that the note that he now works for an insurance firm is code for “is living in gaming paradise for heroes”.

For my part in this, I’ll be doing more coding, and less thinking about the correctness of the approach in the long term: a limiting factor on my fun. Inspiration is a strange thing.

I often talk about the starting points for thinking about the value of RIAs as being:

• Data visualisation: graphs, charts and other data
• Use of metaphors that makes the experience more joyful and useful

On the second point then, it’s great to see the updated support for control skinning in the latest Beta drop. Tim Heuer helps us out here and here.

Then look no further at this healthcare demonstrator from friend and colleague Martin "Larry" Grayson...

There's been some really useful updates to the DeepZoom Composer that means that it will now generate some boilerplate code - a web page and a bunch of mouse and keyboard event handling so you can enjoy your compositions right away.

That's very useful by itself, but it also means that it suddenly becomes very easy to host your composition on Silverlight Streaming. Here's how:

Sign up for a Silverlight Streaming account if you don't have one.

Next, create your composition in DeepZoom Composer. Once you're happy with it, you can run the Export, and 'Preview in Browser'.

If you've accepted the export defaults, then you'll typically find the output web project, XAML and code at:

C:\Users\<User>\Documents\Expression\Seadragon Projects\<My Project Name>\source images\OutputSdi\<My Export Name>\

Using the solution in this folder means you can edit the output and maybe make something more complex, or integrate with another application.

But for upload into Silverlight Streaming, we can look in a folder further down the folder tree:

C:\Users\<User>\Documents\Expression\Seadragon Projects\<My Project Name>\source images\OutputSdi\<My Export Name>\DeepZoomOutput_Web\ClientBin

This folder contains the compiled XAP file, and a folder with all of the generated images from DeepZoom Composer. First, we need to add a file that Silverlight Streaming understands: Manifest.xml.

The Manifest.xml file should look something like follows (where source, width and height should be set as desired):

<SilverlightApp>
  <version>2.0</version> 
  <source>DeepZoomOutput.xap</source> 
  <width>1400</width> 
  <height>1400</height> 
  <background>white</background> 
  <isWindowless>false</isWindowless> 
  <framerate>24</framerate> 
</SilverlightApp>

Once this file is added, before zipping, my folder looks like:

Now we can zip together the Manifest.xml, XAP file, and images folder, and we're good to upload to Silverlight Streaming, and then to embed the content into blog pages.

Here's one I made earlier.

Through the magic of DeepZoom, you can zoom into Simon's eye and see what he's really thinking...

(Dammit Jim, I'm a tech not a photographer)