There was a piece on Kotaku this weekend looking at the development at AI in games, It specifically set out to ask leading figures what they thought of the development of virtual “beings” in games,

“Kotaku set out to ask experts in the fields of Hollywood movie magic, theme park creators, robotics experts and AI specialists to answer the question: Do the AI-controlled characters in games qualify as robots or some other form of artificial life. Are those creatures who are at the player’s mercy in Lionhead Studio’s Black & White games truly virtual beings?”

Inside the article was a rather worrying quote from self declared futurist Thomas Frey, executive director of the DaVinci Institute,

"In short, our games have indeed evolved into crude life forms," said Frey. "Innovations in the digital world are happening exponentially faster than in the material world, so the digital beings in games will soon become far more lifelike, and will eventually step out of the screens and exist as 3D avatars, interacting with us, much like other people."

I always get a little upset and slightly concerned when people from places like the DaVinci Institute (from their "about us" page: "Launched in 1997 as a non-profit futurist think tank, the Institute has emerged as a centre of visionary thought, attracting both a national and international following of idea junkies and business leaders alike.") start to talk about things like programming and AI.  I always feel like these kind of think tanks highlight a bit of a problem with the development of new technology.

All you learn is that "futurist thinkers" actually have no grasp on the practical implementation of the technology.  I’m all for creative thinking and speculation, but somehow implying that very simple game mechanics are going to develop rapidly and with little to no point into some Skynet like Ai is simply absurd. 

Thankfully the Kotaku article actually asked someone with half a clue (Chris Darken, conference chair for Artificial Intelligence and Interactive Digital Entertainment and an associate professor of computer science at the Naval Postgraduate School) who equated videogame AI to an expert system.

In all honesty it’s a stretch to even call them that.  The problem domain that your average game AI lives in is so rudimentary small that I’d rather use a phrase closer to "novice system".

Game AI is nowhere near close to simulating human behaviour, near all "humans" are scripted, and the most simulated behaviour comes from games like Spore or The Sims where the actual behaviour is so generalised (eat/sleep/mate/die) that any nuance of actual behaviour is lost and what results is little more than a general abstraction to suite the purpose of game mechanics; which is utterly perfect for the task at hand, because honestly, developing something more sophisticated would be a huge undertaking with no practical benefit to the game project.

I’m honestly perplexed as to why some gamers seem to think building “AI” is appropriate for a game.  The term AI is exceptionally misleading and would likely never be appropriate unless you were working on something that wasn’t as strictly defined as your average “regular” game environment.

Imagine playing a game where a key NPC suddenly decides that they just weren’t into the plot anymore and just stopped playing, a “real AI” of this nature just isn’t for purpose.  I’m not suggesting that what we perceive as “AI” in games doesn’t have room for improvement, far from it, I am however suggesting that games will never lead to developing a “true” AI, simply because it’s not an appropriate avenue to approach game design from.

People need to realise that good path finding is not the same thing as intelligence, and that they probably wouldn’t actually enjoy a game where the AI attempted to simulate sentience.  It’s work enough dealing with other players in a multiplayer game, let alone having to contend with a simulated intelligence in a single player oriented experience.

A quick code snippet.  These two extension methods (C# 3.0+) enables you to return custom attributes from types, both on a specific type and any data type.  They both return null if the attribute is not present.  

The first extension is useful for extending a type of your choice.  It’s especially useful when considering Enums and the DescriptionAttribute, or other enumeration attributes (especially custom attributes).  The usage examples below should make the use more obvious.

The second extension allows you to return an Attribute from ANY type.  Use with caution, but I find it interesting that it’s actually possible to write an extension method that works that way.

    public static class ElementExtensions
    {    

        public static T GetAttributeValue<T>(this SomeConcreteType val)
        {
            var attributes = val.GetType().GetField(val.ToString()).GetCustomAttributes(typeof(T), false);

            T response = default(T);
            if(attributes.Length > 0)
            {
                response = (T)attributes[0];
            }

            return response;
        }

        public static TReturnType GetAttributeValueFromType<TInstanceType, TReturnType>(this TInstanceType val)
        {
            var attributes = val.GetType().GetField(val.ToString()).GetCustomAttributes(typeof(TReturnType), false);

            TReturnType response = default(TReturnType);
            if(attributes.Length > 0)
            {
                response = (TReturnType)attributes[0];
            }

            return response;
        }       
    }   

Some usage examples….

    public enum RegexEnum
    {
        [RandomAttribute("^(([a-zA-Z]{1}[0-9]{3,4})|([a-zA-Z]{2}[0-9]{2,3})|[0-9]{4})$")]
        SomeEnumValue,
    }   

    public class RandomAttribute: Attribute
    {
        public string Expression { get; set; }

        public RandomAttribute(string expression)
        {
            Expression = expression;
        }
    }

    private static void Example()
    {
        // Both of these are equivalent
        foreach(var enumMember in Enum.GetValues(typeof(RegexEnum)))
        {
            var value = enumMember.GetAttributeValue();   
            var valueFromAnyType = enumMember.GetAttributeValueFromType<RegexEnum, RandomAttribute>();
        }       
    }

Some nice syntactic sugar for use with enumerations.

I’ve previously provided a code snippet illustrating how to use WiX (the “new” Windows Installer framework) to install certificates onto the target machine.

I’ve had some good feedback about the post, but also had a request for a working example (in order to illustrate how the code fragment is used in an Installer.wxs file).

I’ve cooked up a sample visual studio solution that installs a test certificate (generated using the MSDN makecert certificate example “makecert -sk XYZ -n “CN=XYZ Company” testXYZ.cer “).

You’ll probably need to re-path references to the WixIISExtension and WixUIExtension in relation to your development environment but hopefully this should help you.

The previous post is the third most accessed post in my blog (which probably speaks as much for the number of people that read this as it does it’s utility) so this should be useful to someone.

It’s worth noting that this example installs the junk certificate as a Root CA so you might want to change that or ensure you remove it once you’re done.

Download the Sample Solution

I Know It Sucks, But You Need Requirements To Work

There are two parts of software development that really suck. Traditional requirements analysis and documentation. This isn’t some silly joke, both practices are terribly antiquated and essentially useless, not least in an agile (read: rapidly changing) project.

However, one of the common misconceptions I often hear when working on agile projects is stakeholders not quite “getting it” and thinking that agile is the same thing as requirement-less development.

However you paint it, you need something that resembles requirements to write code with. Requirements needn’t be exhaustive, and in an agile environment are rarely ever final, but you need to know what you’re working on- the average user story isn’t going to cut it.  User stories are designed to start conversation between the developer and the stakeholder but you need to do something with the detail once you have it.

Make The Requirements As Accountable As You Are

You know what else sucks? The fact that most businesses don’t have any kind of document management strategy. Sure, you do, you’re a developer. You have source control (and if you don’t, go take care of that now), you’re accountable and auditable line by line, check-in by check-in. This same rigor rarely extends to other areas of businesses (though it should).

When all is said and done, if you’re maintaining a traditional requirements document for your project you’re probably already making a big mistake. Who owns the document? How do you track changes? How do you know people haven’t changed the requirements without a reasonable discussion? What happens when somebody accidentally deletes it?

Requirements documents are the “Excel Applications” of development. They’re unreliable, often so large that nobody will ever read them, and as such fundamentally useless. It’s a bit of a trick question really, monolithic requirements documents are about as “Write-Once-Read-Never” as most Perl code.

I Think We Have a Problem…

So lets recap. Requirements documents are evil and nobody reads them, but you need requirements to develop. Requirements documents aren’t auditable yet it’d really be a good idea if they were. Oh and documentation sucks.

You Need Wikimentation!

Wikimentation is a particularly amusing portmanteau but what you need is a wiki and if you do it right, you’ll never have to write documentation again.

In an agile project, the requirements are meant to evolve and change as you go, so they deserve to be stored in a format that naturally leans towards allowing the users to do just that.

There’s also an immediate bonus to either you or your business analysts in the way requirements are captured as a traditional requirements capturing exercise is eschewed in favour of documenting requirements as they become relevant. This is a very natural way of working and allows you to prototype or stub out components until you need to delve into detail (in fact, doing this is very much the SCRUM way).

When I approach a new project I like to keep a few things in mind, I’ll call them the Holy Trinity of software maintainability…

The Holy Trinity Of Software Maintainability

• Readable Code
• Good Developer Documentation
• Source Control

So how will a wiki help you get there?
I’d argue that after the implementation of a set of requirements, the requirement and it’s details have effectively been superseded by the precedent set in the code.

Those requirements you coded to, after implementation are useless. If the code doesn’t adhere to the requirement the code is buggy, and your bug tracking system should contain information explaining why.

If the code is correct, the requirements would be classified as obsolete. Keeping them around only serves the purpose of misleading anyone who attempts to read the requirements to establish the coded behaviour of an application.

So what we do is we maintain the list of requirements in a wiki in a slightly less formal manner. This is hypertext remember, big long lists of stuff are so 1990. Use links and divide the content into requirements for logical components, leaving a well maintained index on the project homepage in the wiki.

Now as features are completed instead of the requirements eventually rotting away into irrelevance, they can be replaced by a simple developer commentary of the implementation. As you follow this pattern, your requirements will develop into a solid set of searchable developer documentation at the same rate as your project progresses.

Constructing Your Own Evolving Requirements Wiki

There are plenty of FOSS and OSS Wiki platforms out there. I have a personal preference for ScrewTurn Wiki on Windows and you can be up and running in literally under 5 minutes (web server not even required).

A few simple guidelines

• Ensure that the home page of your wiki clearly links to the discrete sub projects or components you’re developing
• It’s encouraged to create wiki links for content that doesn’t exist but needs elaborating on by yourself or your team, to serve as a visual reminder of what is left to do
• Create a standard template for a project and component wiki page
• Populate each of your component wiki pages with the top level requirements for that component, along with “pre-links” to any sub-components of specific note or percieved complexity
• Encourage your developers to document as they write
• Don’t duplicate code comments or huge chunks of code in the wiki - that’s what clean and readable code is for
• Do encourage the posting of examples for reusable or common components - share individual developer knowledge

The wonderful thing about using a wiki is that it breeds accountability. Modifications are logged and audited; you can always see the history of any given page, from requirements to documentation.

A wiki will provide you with a sound and adaptable framework for producing project documentation that evolves with your project. Used in conjunction with a good bug tracking system, a good version control system and some good developers, you’ll have a good chance at edging closer to that holy grail of maintainable well documented code at low cost.

Zero Friction Documentation

Your developers won’t resent a little bit of writing as they finish off logical units of work, and it could be even encourage to keep a “scratchpad” of information on the wiki as opposed to paper-notebooks. It’s also good to remember that you can always generate a traditional requirements document from the content stored in the wiki if an occasion calls for it.

I’ve had a lot of success implementing these ideas in past projects (both agile and none agile) and I’d certainly recommend it.

This is a round about response to both Leigh Alexander’s response to Heather Chaplin’s GDC rant session.  It’s worth noting that I wasn’t at GDC and that all my information is second hand, and as such, susceptible to Chinese whispers-style misinformation.  To quote Leigh’s post (as a good source of a direct quote)

‘She argued that medium’s age is not the correct source of blame for the often insultingly juvenile nature of games, the tiresome prevalence of space marines, bikini girls and typified young male power fantasies. Her point: Games aren’t adolescent. Game developers are a bunch of, in her words, "fucking adolescents."’

This is really not a response to Leigh’s post at all, but more to the original subject that it made me aware of. 

I always feel a bit defensive when people imply that the only video games that ever get produced are space marine staring male power-fantasies. 

Just as a case point, lets take a look at the top selling games of last year (via a quick Google search)

Wii Play
Mario Kart Wii
Wii Fit
Super Smash Bros Brawl
Grand Theft Auto IV
Call of Duty: World at War
Gears Of War 2
New Super Mario Bros
Madden NFL 09

It’s difficult to claim that all of those titles fit into that narrow criteria.

There’s often talk of cinema reaching a comparative maturity with the release of Citizen Kane, and The Beatles representing the maturity of pop music by a similar timeframe in their respective mediums development.

I really don’t think that the respective age of the medium is a safe measure to judge it’s maturity.  By the time of Citizen Kane and the Beatles arrived in their respective mediums the supporting technology had plateaued to a degree that allowed for artists to have unencumbered technical freedom in comparison to the respective "technical freedom" that game designers have now.

There are a lot of critics that underplay the difficulty of perfectly nailing both concept and execution of a game.  It’s difficult, stuff, even more difficult to make the game work well, be playable and be great.  If you manage artistic integrity and ingenuity on top of that you’ve managed something exceptional. 

It’s no surprise that some of the most celebrated titles in video gaming are often technically flawed "classics" that get lauded for being "near misses".  Taking risks on titles is difficult and expensive on top of the desire to be artistically vibrant.

I certainly don’t think Citizen Kane would have had the budget and resource to be "great" if the camera men were still learning how to use cameras and I really think that we’ve got a way to go before we can expect every game made to be a high concept piece. 

Even after the technology reaches this point (as it has in the film industry) there’ll still be more summer action films / games made than artistic victories.

It’s also worth nothing that in this constant strive for something else, it’s easy to loose the purity and fun of more "pure" game play experiences, including male power fantasies and computerised D&D implementations.  Some people find game mechanics fun, to some people that is the point and it always feels that some critics always call so loudly for something different that they miss some of the point of what we already have.

The artistic indie film vision of influential games is a laudable one, but without the Gear of War’s there just isn’t the ecosystem to support them.  Much like when I watch films, I don’t always want to watch Capote or Chinatown.  Sometimes I want to watch Die Hard, and sometimes I want to watch Star Wars.  And sometimes I’d quite like to watch Twelve Monkeys or Being John Malkovich, but without Star Wars, the framework to support those often loss-leading productions just wouldn’t exist.

I don’t pretend to play at “legitimate game criticism” however I certainly follow the area with more than a casual interest and I’m often very surprised at how the desire for strong artistic games in the “niche of a niche” press seems to forgo the need for any other kind of game. 

The last thing I’d want is for the games press to take a Pitchfork media style pretentious view of the world, reducing anything that isn’t trendy or progressive to dirt.  There’s tonnes of very good games writing out there that I very much enjoy reading and I really hope that people allow at least some games to still be “just games” alongside the more “worthwhile” and “deep” experiences available.

A little bit of site administration…

Anyone who writes on the internet will happily tell you that the best way to keep your readers happy is to carve out a niche and devote your time to well researched detailed content.

I’ve always treated davidwhitney.co.uk as a traditional “home page”. It’s my blank canvas, and I intend to keep it that way. However, a lot of my content is straying deeper into more technical topics that don’t flow with the rest of the content.

In an attempt to tighten the focus of my writing, I’ve registered the URL http://daviddevelops.co.uk (following the tried and tested practice of terrible “developer name in title” blogs!).

The actual content of the two sites is the same, they run off the same database, the same tables. David Develops is a subset of the content available on davidwhitney.co.uk. Siphoning off the develop-oriented content also allows me to use an alternate site layout more applicable to technical content / posting source code. No more red-on-black source code samples.

If you are only interested in the technical content available I’d recommend you subscribe to the feed available on that site rather than the main davidwhitney.co.uk feed, because you don’t want to end up looking at pictures of cats.

Due to the shared database (”David Develops” is a quickly carved up version of WordPress that grabs specifically catagorised posts) any comments you post here will be visable on the other site, and vice versa.

I expect that by refocusing I’ll be able to cover more topics in depth in the future, on both sides of the fence, guilt free.

Fear Of Deployment

When you start working on a new project there are four really important pieces of information you should be aware of regarding the deployment of your software

1. Are you unafraid of deploying your code to production?
2. Do you know how your code will react in your production environment with production configuration?
3. Does your code react in the same way in your production environment as it does in development?
4. Are you confident in the repeatability of your installation procedure?

Fear and uncertainty in the deployment of software projects is a common theme I’ve seen across all the companies where I’ve worked and it’s never good for your project.  The fear of deployment is always a good indicator of the confidence your staff have in the project they are working on.

A project with unknown qualities and suspicious (or known but unreported) bugs often causes an serious fear of deployment.  There’s nothing like the fear of deploying an application and reducing a business critical system to it’s knees.

I’ve worked on a handful of projects where I’ve taken it upon myself to reign in this deployment fear and chaos, and more often than not, the fear has it’s roots in an uncontrolled development environment.

Configuring A Development Environment

I have very few suggestions regarding which tools you should use to develop your software.  I think that you gain the maximum benefit by allowing developers to pick and choose the absolute best tools for the job, be that technically or by preference.  Allowing developers to use their tools of choice makes happy developers.

By contrast however, the one thing I’m really certain about is that every development environment should start with an absolute base configuration that should not be changed.  This is the first way to solve the eternal “works on my machine” developer problem.  In essence, if all the development environments start off the same, there’s no excuse for a “works on my machine” error.  Not only will this reduce friction between team members, but it’ll speed up the development process because you’re all working to one known configuration.

Furthermore, the development environments alone shouldn’t share this configuration, they should share the base configuration with your production servers.  A huge percentage of software release issues are relating to the differences between production and test and development and the only way to solve what amounts to human error is to make this discrepancy go away.

In the current IT landscape where virtualisation is painfully simple (and often free) there are no excuses not to have a development environment (or at the very least development staging virtual machine) that accurately and completely mirrors your production server.  If you’re struggling with licenses of third party software, produce mocks / proxies / approximations.  I can assure you that the time you spend building these glorified testing rigs will work healthily towards eradicating development-to-production errors.

If It’s Worth Doing Once, It’s Worth Doing Three Times

Another nasty pattern I see frequently is the development-to-production pattern.  If you’re compiling software on your development machines and releasing it to production, “you’re doing it wrong”.  What’s worse than a “works-on-my-machine” conversation with a colleague?  You got it, a “works-on-my-machine” conversation with a system administrator.  It’s not an excuse.  Stop it.

You need to start dog-fooding your deployments, and this means environment cloning and real test servers.  I always follow a simple pattern; developer machine -> developer test box -> system-test box -> user acceptance test box -> production.

In order to do this you’ll need a series of environments (physical or virtual)

• Developer machine
• Developer environment
• Test environment
• UAT environment
• Production environment

That might sound like a lot of hardware but it really isn’t.  Use virtualisation and use it well.  Clone your virtual environments if need be.  Use snapshots and rollbacks to test deployments.  It shouldn’t take any time to administer (and I’ll explain why in the next section) and by the time your code is running on production you’ll have moved it through three different environments.  This is absolutely key to having faith in your deployment procedures.  When you’ve deployed your code so many times that you’re sure it works, in an environment that’s a mirror image of production, production is a far less scary place to be deploying to.

The key to this technique is that the environments all have very clearly defined purposes.  The developer produces his code changes to a system on his development box.  The code seems to work so it’s deployed to the developer environment and checked into your source control repository.  The development environment should be treated as a place where things could potentially get messed up, but it’s also a good place to host joint resources (a database, some middleware) that all the developers make use of.  If the code works in the developer environment it can be promoted to the test environment for the system tester (or a developer wearing a system testers hat) to test.  Once passed on the test box, the code changes can be promoted to the UAT environment for users to preview coming code releases.  Once these changes have been accepted, the code is released into production.

Beware of release insanity.  It makes perfect sense to frequently deploy to the developer environment but only occasionally promote code up to test and UAT.  This should fit around your way of working, just be sure to keep the conceptual integrity of the environments.  If you find a bug in test, don’t fix it in the test environment, fix it in development. It’s up to you to ensure you know what code is running across your environments to avoid any nasty surprises.

One Install To Rule Them All

At this point you’re probably thinking that this all sounds like a huge amount of effort but it isn’t.  The reason it isn’t is that you should, for the most part, be able to deploy your entire system in about 5 clicks / commands.  Don’t let your deployment mechanism be the week link in your application.  There are tonnes of install technologies on the market, both free and costly, to match whichever platform and tool chain you’re working in.

I wish I could remember where I read it, but one of the pieces of setup advice I read long ago that always stuck with me is that you should aim for a one-click install.  You might not achieve it, but you should aim to get very very close.

You need to invest time in configuration management for your application.  Build tools to auto-generate configurations for your deployment environments, build tools to automate setup and deployment.  These tools are worthwhile, because from the moment they’re built, you never need to worry about deploying your software.  They remove risk, and anything that removes risk from software development should be embraced.

Once you’ve build these tools and installers you’ll find your able to do things that you only thought were possible in large companies with seemingly limitless resources.  You’ll be able to configure nightly builds using a continuous integration package of your choice and have the nightly builds install themselves in your developer environment,  You’ll be confident that at any point you can provide a working copy of your software on request.

No Fear Of The Unexpected

The wonderful benefit you get at the end of this process is confidence in your software.

So you’ve released your system to production, do you then feel the need to slavishly test the system in the live environment? 

Imagine that urge going away, knowing that by the time the code hits production that any environmental glitches that could manifest have had the ability to fail three times already.  Any amount of cursory testing you could perform at this point should pale in comparison to the testing you did in the test environment and the user testing environment.  If your “at a glance” testing somehow discovers a bug, you’ve done something very very wrong in the lead up to release.  You should be confident in the fact that your code has been run exhaustively and often by the time it’s reached production.

The world isn’t perfect however, and it’s obviously advisable to a quick audit of the software once installed, just don’t force yourself to repeat your system tests in production (an obvious anti-pattern) and you’ll gain no benefits from doing so.

If you can devise an automated tool to verify your deployments after install, you’ll be able to round off your sense of deployment-security.

A Zen-like State Of Satisfaction

I opened this piece with a few simple questions.

• Are you unafraid of deploying your code to production?
• Do you know how your code will react in your production environment with production configuration?
• Does your code react in the same way in your production environment as it does in development?
• Are you confident in the repeatability of your installation procedure?

I can answer yes to all three questions because I understand my environments and I hope you can too.

Just a quick note here as I had to do a lot of digging to fix this issue.

Issue: HTC Diamond (potentially other models) not waking up from “sleep mode” when you have an email send/receive schedule. Instead, when you wake the device up it establishes a connection immediately and performs the check.

Problem: It appears the root of the problem are two registry settings that define how long a process is allowed to attempt to wake a device from sleeping before it is terminated by the OS. Evidently checking email takes a number of seconds. I’m not sure what the default value is in a stock ROM, but in a few of the custom ROMs I’ve used this value is 1. 1 seconds generally is not long enough.

Solution: Change the following registry settings to a value in seconds that represents the tasks you’re expecting to wake up your device. I’ve got my device set to 15 and it happily collects email while sleeping and provides a glowing / audible notification.

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\Timeouts]
“BattResumingSuspendTimeout”=15
“ACResumingSuspendTimeout”=15

I’ve just compiled what I hope is the final version of this application barring London growing extra underground lines.

I’ve written a small Windows Mobile application for phones running WinMo 5.0+ with Compact Framework 2.0+.  It syndicates the Transport for London live data in similar way to the pre-existing iPhone and Android applications allowing you to view the current tube network status, planned engineering outages and local station notifications at the push of a finger on your Windows Mobile.

It’s currently living at a holding page at http://ww.davidwhitney.co.uk/software (soon to become a larger site) and it’s a free download for anyone that uses Windows Mobile.

The 1.0.0.4 update is a reaction to some feedback I’ve received over at http://www.xda-developers.com and comes complete with coloured glyphs representing each tube line and enhanced resolution support for devices with “unusual” resolutions such as the Sony X1.  I’ve also had a stab at some font and UI element scaling so hopefully the interface will look quite natural on all your devices.

I’ve only managed to test it in the wild on a Touch Diamond, Touch Cruise and the Windows Mobile 5.0 Virtual Machine (along with in Windows).  It seems to run admirably in those conditions.

Obviously it requires a data plan so beware of any provider costs.

You can download the .cab directly at this link: http://www.davidwhitney.co.uk/software/repository/MobileTFL/1.0.0.4/MobileTFL.Setup.CAB

A very quick late night post.

I’m a big fan of HTC’s Touch Diamond once you remove all the cruft that the major phone networks like to cram onto their devices.  It’s a pocket sized, powerful smart phone.  I picked one up only a few months ago as a replacement for my HTC Touch, which was starting to feel very very slow compared to some of the handsets on the market, and the addition of HDSPA on the Diamond was the clincher.

Anyway, as a result the good lady has been quite impressed with the functionality of the Diamond.  She works in the media and the ability to access the internet with an almost desktop like experience (and without an iPhone) was very appealing.  While we were in town this weekend sorting out a new contract for her, I noticed that Google’s G1 ships with a London Tube service status application.  Seeing as Eleanor lives in London it seemed like an instantly cool thing to have on hand, but to my surprise, there isn’t anything comparable available for Windows Mobile (or there is and it’s too difficult to track down).

So I wrote one.

I’ve put up a really REALLY retro holding page at http://www.davidwhitney.co.uk/software for the purpose of releasing this application, hopefully over the coming months I’ll use it as a gather place for all the applications I’ve written, both free and pay-for, but for the moment, feel free to go and pick up a copy of the ingeniously named MobileTFL (after the transport-for-London website, where the application sources its data).

If you’re too lazy to click through one link:

Download Mobile TFL for Windows Mobile Here (Cab file)

You’ll have to forgive the exceptionally low-fi website and hilarious low res Visual Studio 2008 virtual machine screenshot.  I’ve only really tested the app on the Diamond I have sitting on my desk right now and it works a treat.

Obviously it requires you have a data plan that’s from a company that believes in Mobile internet rather than customer robbery but it only uses a tiny amount of data (it’s just a Http request).

It also requires the Compact Framework.  I’ve built it under CF3.5 but I suspect it’ll run just fine under CF2.0 (they’re binary compatible after all).

Feedback is more than welcome, just send me an email about it.  I’m especially interested on how the rendering looks on your devices, as the rendering code was written quite quickly and as soon as it looked ok in the VM and on my device I pretty much packaged it up.

I doubt it’ll brick your device, but if it does, you know the drill, it’s your problem.

Time for sleep now.

[Update: Microupdate to version 1.0.0.3 to fix a few bugs and aestetics, the above link has changed, revisit it for the new version]