If you are reading this blog and live in the Orlando area, please take a few moments and map yourself and at least fill out the google survey. Then spread the word, it would be pretty awesome to see this come to Orlando

The game focuses on controlling a small 2d chopper through a maze. There are “fans” which push and pull the chopper into the walls which of course will make it more difficult to navigate.

I got the idea after my brother-in-law received a small indoor helicopter for christmas. We all had so much fun trying to carefully control it (as much as one can control those tiny copters) and even trying to land it strange places like the blade of a ceiling fan. I thought that it would be fun to play a game that required the same skill. I was able to fairly quickly make a simple prototype (even simpler than what I posted up for playtest) using the FlatRedBall engine’s built in acceleration and collision functions.

The prototype I posted up is quite rough around the edges as it is just a prototype; But the idea is to get the community’s feedback early, before you have invested a lot of blood, sweat, and tears into a game. If you wait until the end to get a playtest, you will be so invested in what you’ve been working on that you will resist they playtester’s feedback. I hope to get some good ideas about possible directions that I could take it in … and hopefully it will validate the direction that I’ve already got in my mind. But who knows, I might get an idea that I was not expecting. That’s the great thing about getting it in front of other people early.

We will see just how far along I can get before my Orlando Code Camp presentation, which incidentally, is about actually finishing a game (this game). I’ll definitely have more to post on this topic after the codecamp

So far, I’m happy enough with it. When I plugged it into the USB port on my computer, windows 7 already had drivers for it so it was kind of nice that I did not have to install any extra software; Though I haven’t installed the software disc that came with the monitor so I don’t know if there are any extra niceties that come with it.

The first thing that hit me was how large and nice the screen is. Definitely a great picture. Of course the first thing I did was fire up MS Paint, which natively supports multiple touch points. Single finger manipulation (I’ll have to trademark that one) works really well and is quite accurate. Two fingers however seems to be pretty buggy, especially when you move the touchpoints near each other.

I’m looking forward to programming against some of the APIs that are available. In particular, I’m looking forward to experimenting with new interface models rather than the usual textboxes, buttons, tree views, and menus.

What’s the easiest way to let a custom application re-use accounts from a PHPBB installation?

Answer:

The first thing that occurred to me was that I’d have to look over the PHPBB user tables, connect to mysql, and read the user’s password (which I assume is hashed) to do the authentication. The second idea I had was to write a proxy service in PHP that I could call from my custom app.

Both of those options seemed like an awful pain in the butt. Then I had an epiphany, if you take a look at the ideals behind REST services, one could reason that PHPBB already exposes a REST service for logging in.

What if I simply used the already exposed HTML form as a sort of pseudo web service?

Making HTTP posts with C# is pretty easy, but I didn’t want to try to remember what the syntax was for the API; So I did a quick search online and found a nice little class that makes it really easy:
http://geekswithblogs.net/rakker/archive/2006/04/21/76044.aspx

With this class in hand, I used FireBug while logging in to the PHPBB and inspected the post variables. Easy, there were only four variables posted:

• autologin=on
• login=Login
• username=[My Username]
• password=[My Password]

I grabbed the URL it was posting to and added the variables (see the example below). Once I get the result back, a simple regular expression parses through the HTML and figures out if the login was successful or not. The result worked surprisingly well … the method below takes a username, password, and url. The URL will look something like this:

http://mywebsite.com/forum/ucp.php?mode=login&sid=9cd8b8da2649060b9d22d297f27a1dc7

private static bool Authenticate(string username, string password, string url)
{
    PostSubmitter post = new PostSubmitter();
    post.Url = url;

    post.PostItems.Add("autologin", "on");
    post.PostItems.Add("login", "Login");
    post.PostItems.Add("username", username);
    post.PostItems.Add("password", password);
    post.Type = PostSubmitter.PostTypeEnum.Post;
    string result = post.Post();

    string loggedinstring = string.Format("Logout \\[ {0} \\]", username);
    Regex r = new Regex(loggedinstring, RegexOptions.IgnoreCase);
    var match = r.Match(result);

    return match.Success;
}

Disclaimer: I’ve only tried this code with one instance of phpbb, not sure if it will work with other versions. The point of this was that we can trivially reuse existing user stores that are already exposed on the web via simple html forms.

Acer t230h

Dell SX2210

HP L2105tm

Because of the technique they’re using to do finger tracking, all the monitors only support two touchpoints at a time. Makes me wish that a homegrown solution like the optical webcam based solution I experimented with a while back was more feasible.

The HP L2105tm is the most inexpensive offering, but also, seems to have other deficiencies such as a slower response time than the other two monitors. The Dell monitor is nice because it has a built-in webcam, which is something that I’ve been interested in having for a while, but is ultimately secondary. The Acer T230H is the one that is currently capturing my interest; it’s the largest monitor of the three at 23 inches, and according to the specs has the best contrast ratio.

So, does anyone have any suggestions on which monitor I should go with? My primary goal is to have hardware that I can program multitouch enabled XNA games with

After a bit of online sleuthing (ie. searching Bing for “xna steam“) I came  across said XNA games on steam and, via one of the developer’s websites sent him an email. He was very nice and responded with:

Too bad they responded in such a way… usually they are very nice at Valve.

But yeah, they wrote a little C# wrapper for their Steamworks-dll.
They also made their installer script look for the dependencies (.NET
& XNA redist)
…
I didn’t really do anything to achieve this, they had
already decided to release the game when we ran into problems because
of the code being in C#, so they just put a guy on solving it.

This of course correlates with some of the other comments on my post saying that it would be trivial to write the wrapper; and in fact, even with my own assumptions before I even posted the blog entry. But the point I was trying to make was that I find Steam’s approach to developers rather strange. One of the FAQs from the steamworks site reads:

10. My game is in early development stages, don’t I need to plan for the SDK integration now?
The Steamworks SDK is easy to integrate, so you can wait until your game is further along in the development cycle before worrying about it.

Their approach is basically one of don’t call us, we’ll call you. Unless your game gets lots of publicity (for example, winning an indie contest) you will have to actively seek them out and pitch your game to them.

Contrast this with the approach that Microsoft is taking with XBox Live Indie Games. They provide an SDK, they provide hosting, they provide distribution, they provide some marketing … all for less than ten bucks a month ($99 a year). This model is so much more appealing to me as a developer because it is low risk (yes, $99 a year is low risk). If I end up not developing anything, or development goes longer than expected … I’m out $99 bucks at most.

If only Microsoft would extend xblig onto Windows …

After all this tablet hype started, I began to get excited about the possibilities of new markets emerging for touch enabled windows games. As Steam is currently one of the most robust and popular game distribution networks on windows, I was curious to know whether a game written with XNA could be published via Steam.

I visited their Steamworks developer site and the offering is very attractive: Anti-Piracy/DRM, Cloud Storage, Matchmaking, DLC. coupled with the fact that many gamers I know (a statistically insignificant metric, I know) trust and use Steam, and it warranted a further look.  So I emailed them and asked simply (edited for further brevity):

From: Joel Martinez
To: steamworks@valvesoftware.com

Hello, I was wondering if the Steamworks API is usable from a game written in C# … [I] would like to know if Steam would support games written using the XNA Framework.

Took them a few weeks to get back to me, but they answered succinctly:

From: Steam
To: Joel Martinez

Hello Joel,
We do not directly support games written using the XNA framework.  Steamworks is written in C++

A shame really.

I sought out to find out the state of multitouch. So far, I’m not too impressed. Here are two great references to get you started:

• Multitouch Madness: Brian Peek posted the slides and source code to a presentation he gave on multitouch. I really wish I could have been there but the source code and slides are a great resource.
• XNA And Windows 7 Multitouch: Great article that shows how to get a touch enabled xna window rendering in windows forms.

The thing that I walked away with is that the solutions that Microsoft seems to be proposing have pretty specific dependencies on windows forms, wpf, and silverlight.  All things that I would rather not really deal with when I am making an XNA game. I would really prefer not to have to resort to making and managing my own window. In addition to the APIs not even really being available; Brian’s slides mention that System.Windows.Input.Manipulations isn’t even redistributable yet until .NET 4.0 is released.

So I’m going to be looking into how one can take advantage of the built-in touch APIs without onerous dependencies on unreleased assemblies and hacking windows forms in the near future. Anyone have any tips on where to get started?

Recently at work, I wanted to perform a transaction across several unrelated modules with a custom resource. Of course TransactionScope was the first solution brought up. Unfortunately, after some analysis, I realized that this wasn’t going to work for us; We have existing database code in those modules that have different conditions in which the transaction would be rolled back.

We needed a way to have multiple transaction scopes, each with different conditions of success or failure. I started thinking about how to accomplish this, and decided to write my own implementation which mimics the TransactionScope, but lets me control things a bit closer.  So I came up with a class which can be used like this:

using (Txn scope = Txn.New<MyScope>())
{
    // ... do work

    scope.Commit();
}

Notice that the usage pattern is nearly identical to the TransactionScope API … put the scope in a using statement, and call .Commit if the work was completed.  In the example above, the MyScope class is defined quite simply as:

public class MyScope : Txn
{
    protected override void OnStart()
    {
        Console.WriteLine("\tstarting");
    }

    protected override void OnCommit()
    {
        Console.WriteLine("\tcommitting");
    }

    protected override void OnRollback()
    {
        Console.WriteLine("\trolling back");
    }
}

All you have to do is inherit from the Txn class, and implement three methods: OnStart, which occurs when the transaction is first beginning; OnCommit, which is invoked only when the top-most scope exits and all sub transactions were committed successfully; And OnRollback, which as you might imagine is only called if the transaction (or a subtransaction) was not committed successfully.

One difference between this API and the regular TransactionScope is that only one instance of “MyScope” will be created when the top-most transaction is first created. As I’ve alluded to, you can nest transactions just as you can with TransactionScope. And each scope must be committed if the entire transaction is to be completed.

The Txn class can be found below:

public abstract class Txn : IDisposable
{
    private Queue<bool> committed = new Queue<bool>();

    public Txn()
    {
    }

    [ThreadStatic]
    public static bool committable = true;

    [ThreadStatic]
    public static int depth = 0;

    [ThreadStatic]
    public static Txn current;

    protected abstract void OnStart();
    protected abstract void OnCommit();
    protected abstract void OnRollback();

    public void Commit()
    {
        this.committed.Enqueue(true);
    }

    void IDisposable.Dispose()
    {
        if (committed.Count == 0 || !committed.Dequeue())
        {
            committable = false;
        }

        depth--;
        if (depth == 0)
        {
            if (committable)
            {
                this.OnCommit();
            }
            else
            {
                this.OnRollback();
            }

            current = null;
        }
    }

    public static T New<T>() where T : Txn, new()
    {
        depth++;

        if (current == null)
        {
            current = new T();
        }

        if (depth == 1)
        {
            // first transaction, assume committable
            committable = true;
            current.OnStart();
        }

        return current as T;
    }

    #region IDisposable Members

    #endregion
}

There is one caveat to mention. My requirement was to run this code in a windows service. The entire scope of the transaction would be single threaded, but there would be multiple ongoing transactions at once. To support this scenario, notice that some of the internal state of the Txn class uses the [ThreadStatic] attribute. This means that the API can be used from multiple threads at once and each thread would have its own state.

Of course, this might be a problem if you want to use this in an ASP.NET project. I’ve written about this issue before. There is probably a way to make this work using the techniques I outlined in that article, but I haven’t given it a lot of thought (because I didn’t need to). But I thought I’d share the work I did in case it is useful for anyone else.

Here’s the changelog if you’re interested:

• Introduced TestStatusReporter to make reporting test status easier. DefaultReporter writes to the debug output, while the test console app implements a custom ConsoleReporter that writes it out to the stdout instead.
• Added additional methods and overloads to the Assert class for more assert options and the ability to replace your own custom TestStatusReporter instance.
• Added XBox version of Scurvy.Test assembly
• Upgraded solution to visual studio 2008
• now using SVN bindings instead of TFS Explorer
• Upgraded sample xna project to GS 3.1
• Added custom XNA test status reporter to sample project