Archive for XNA

Smooth Control with Touch

The new touch capabilities that are present in XNA 4.0/windows phone 7 present new opportunities for letting the user take control of the games that we can write. Unlike the input from the xbox 360 gamepad, or the mouse though, the user is not restricted to incremental analog adjustments (ie. moving the mouse by 5 pixels per frame, or having the left stick pushed up to a value of .5). So it is completely possible for the user to press his finger in the bottom left of the screen, drag it 20 pixels, lift for 5 seconds, and then press it down somewhere in the upper right of the screen.

In a naive implementation of handling touch input, you could just take the touch point as fact, and the entity would snap directly over to the user’s finger in the scenario described above. This may be visually jarring, which of course may be ok for your game. However, if you want your entity to have more of a realistic presence in the game world, to feel more “real”, the you probably don’t want it teleporting around the screen; At the same time, you want the user’s input not to feel laggy or non-responsive.

So how do we handle this fundamental difference in user input techniques?

The problem of incomplete or inconsistent input reminded me of the network prediction sample, which is available on the XNA Creator’s Club site (http://creators.xna.com/en-US/sample/networkprediction). In that sample, they present two solutions to deal with the issues brought on by network latency. Particularly, I was interested in their smoothing solution because it solves my problem.

Smoothing is a simple concept. When a network packet is received, rather than teleporting immediately to the new position, we can interpolate gradually from the previous position toward this new location, giving the illusion of continuous motion …

I took that smoothing concept and applied it here so that when the user re-touches in another location, the onscreen entity will smoothly accelerate towards his current touch point. And because it’s using interpolation, it will always catch up to the current location after half a second regardless of where the user is moving his finger.

The entity class from the project is listed below. The important bits are the “isCatchingUp” and “currentSmoothing” variables. When the input handling code realizes that it needs to catch up, it starts to decay the “currentSmoothing” variable, which is then used in the interpolation to smoothly transition to the current location (via Vector2.Lerp).

class Entity
{
    private Vector2 lastKnownPosition;
    private Vector2 touchPosition;
    private float currentSmoothing;

    public Vector2 Position;
    public Texture2D Texture;

    public void Update()
    {
        var touches = TouchPanel.GetState();
        float decay = 1f / 15f;

        bool isTouching = touches.Count > 0;
        bool isCatchingUp = currentSmoothing > 0;

        if (isTouching)
        {
            if (isCatchingUp)
            {
                currentSmoothing -= decay;
            }

            foreach (var touch in touches)
            {
                touchPosition = touch.Position;
            }
        }
        else if (!isCatchingUp)
        {
            currentSmoothing = 1;
        }

        if (!isCatchingUp)
        {
            lastKnownPosition = touchPosition;
        }

        Vector2 positionToDraw = lastKnownPosition;
        if (isCatchingUp)
        {
            Vector2.Lerp(
                ref touchPosition,
                ref lastKnownPosition,
                currentSmoothing,
                out positionToDraw);
        }

        this.Position = new Vector2(
            positionToDraw.X - Texture.Width / 2,
            positionToDraw.Y - Texture.Height / 2);
    }
}

Little touches like this add an extra level of polish that players will appreciate … and yes, I intended the pun ;-)

Comments

XNA Slides from Orlando CodeCamp 2010

The 2010 Orlando CodeCamp has now come to an end. It was a great event, and I’m glad I was a part of it. Many congratulations go out to Esteban, Will, and the rest of the board and volunteers that put it together. With almost 600 .NET developers in attendance, it shows that the central florida area is brimming with talent.

I’ve uploaded the slides to my presentation which was titled, “How to Finish a Game with XNA“. You can download them here:
XNA_CodeCamp_2010_Slides

If you attended the meeting, please don’t hesitate to contact me if you have a question about XNA, Windows Phone, or any other topic that we spoke about :-)

Comments

Windows Phone 7 Game Archetypes

Now that the .NET landscape has a new “screen” to design for in the form of Windows Phone 7 (WM6.x doesn’t count ;-) ), we need to start thinking about how to provide users with consistent metaphors and input mechanisms.

Microsoft’s patterns and practices group wrote the book on web and desktop application architectures (literally). One of the sections in that book is application archetypes which describes the types of applications that you can build. This is useful because an ecosystem can spring up around each archetype (controls, usability studies, tutorials) which can provide a lot of feedback and guidance for new projects to follow.

To that end I wanted to start a list of the different archetypes that might be available to choose from when designing a game for windows phone 7. Don’t confuse this with a discussion about game genres … those are already well known and documented. This list covers types of applications, game mechanics, and input styles that you can use to directly affect your game’s design in a fundamental way.

  • The Mini-Console
    If you already have a game that you’ve written (using XNA for example) and you want to do a direct port to the phone, then you are writing a Mini-Console game. Games like this will generally be played in landscape mode, which gives the developer enough room to provide a virtual d-pad and button(s) on the bottom left/right of the screen. The idea here is that the user will feel like they are playing a handheld console like the DS or PSP.
  • The ARG
    Alternate Reality Games are growing in popularity. They typified by involving real world elements in one way or another. This can involve using the player’s real world lat-lon location to have in-game effects (using the System.Device.Location namespace), or using the device’s camera as an input mechanism. I don’t see much of these, but it’s an interesting space which I hope more people will investigate.
  • The Physical
    These types of games involve the user physically manipulating either the screen, or the device itself to affect the game play. Games like this have to take this analog data and approximate the user’s intent in making that motion or touch. I often see games which should be mini-consoles try to use this type of physical input just because they can … and it sometimes results in awkward gameplay. More research and testing needs to be done in this space to figure out what works and what doesn’t. For an example of the types of things we should be thinking about, check out my article on approximating touch points.
  • The Casual
    Casual Games are tearing their way through the game industry. Read this report from the recent game developer’s conference for some of that commentary (http://www.designer-notes.com/?p=195). Regardless of which side of that divide you land on, I think one thing everyone can agree on is that casual games are here to stay. WP7′s push notifications and asynchronous game features will be very useful for games like these.

I’d love to keep updating this post with links to more resources on each archetype … if you find something please don’t hesitate to post it as a comment and I will update the post as time goes on :-)

Comments

Approximating Touch Points

The Windows Phone 7 Phone UI Guidelines calls out that the minimum touch target size should be about 9mm (34px) and I started to think about what it would take to implement this in an XNA game. Of course the first thing that comes to mind is that I can define a simple bounding box for each entity that wishes to be touched. This box would have to be of the correct size, and would have to be kept in sync with the entity’s position on the screen. Easy enough I guess.

One of the things that I’ve been thinking a lot about recently is writing software that, instead of strictly defining things can infer a user’s intent. As I pondered the solution above, it occurred to me that defining a bounding box exactly 34 pixels in size was doing just that … limiting the ability for the software to infer the user’s intent in touching the screen. What if his touch point is 35 pixels away from his intended target?

Instead, what if you compare the user’s touch point against the entity positions and simply select the closest one (regardless of whether it’s 35 or 36 pixels away)?

The method below does just that given an array of entities and a touch location:

private static Entity FindNearestEntity(Entity[] entities, ref TouchLocation touch)
{
    Entity selectedEntity = null;
    float currentDistance = 0;

    // The entity with the nearest
    for (int i = 0; i < entities.Length; i++)
    {
        var entity = entities[i];

        float distance = Vector2.DistanceSquared(touch.Position, entity.Position);
        if (distance < currentDistance)
        {
            selectedEntity = entity;
            currentDistance = distance;
        }
    }
    return selectedEntity;
}

This assumes single finger data entry, meaning that it’s probably best served for things like menus and options.

It’s pretty exciting now that XNA has these touch APIs available to it. I am looking forward to doing more research in this space, and playing around with different “natural user interfaces”.

For some great additional resources, be sure to drop by the natural user interface group on the web at: http://nuigroup.com/

Comments (1)

Windows Phone 7 Flashlight

Now that the developer tools for Windows Phone 7 are out in the wild, I wondered how long before we see the ubiquitous “flashlight” app. I decided to grab the bull by the horns and put it out there myself. So find below the steps required to make your own flashlight app

  1. Create a new XNA Game Project for the phone
  2. Add this line of code to the Draw method:
graphics.GraphicsDevice.Clear(Color.White);

And BAM! that’s it!

Comments (4)

Of Choppers, Physics, and Challenge

After receiving some sage advice from Andy “The ZMan” Dunn, I posted up the prototype of a game that I am working on for play test on the XNA Creator’s Club site:
http://forums.xna.com/forums/t/49219.aspx

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 :-)

Comments

State of Multitouch with XNA

I’ve been very interested in multitouch every since I saw Johnny Lee’s awesome finger tracking videos. Specifically, multitouch as it relates to game development. With the impending release of windows 7 tablet PCs, I have hopes that it might open up new possibilities and markets for games on the windows platform. I’m planning on picking up a Dell SX2210 monitor to start playing with it.

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?

Comments

Scurvy.Test v1.2 Released

Quick on the heals of yesterday’s post, I’ve released v1.2 of Scurvy.Test. This is the first official release of the framework and improvements over the initial announcement are mainly centered around the status reporting of test pass/failure.  I also upgraded the solution to vs 2k8 and xnags 3.1.

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

Comments

ScurvyTest v.next under way

I finally had a chance to do some long planned work on ScurvyTest, my flexible unit testing framework that was design from the ground up to be friendly to XNA project unit testing.

Specifically, one of the drawbacks to the previous version was that unit test status was only communicated via an easy to miss write to the debug output.  This next release will improve that by introducing an official status reporting mechanism. You will be able to replace this reporting channel with your own implementation to let you integrate with any custom game or engine.

I’m also adding more methods which will be available to you on the Assert class, and fixing a few bugs that have been reported in the exit criteria feature.

Check out the latest change set if you’re curious as to the latest, otherwise you can wait for the official release here in the next weeks :-)

http://scurvytest.codeplex.com/SourceControl/list/changesets

Comments

Resource Pool in F#

Erik Schulz, who has written a bunch of articles on how to make XNA games with F# has ported the Resource Pool class I wrote about in F#. Cool!

type FPool<'a>(newRoutine, capacity : int) =
    let queue = Queue<'a> capacity

    member this.Count = queue.Count

    member this.New() =
        if queue.Count > 0 then queue.Dequeue() else newRoutine()

    member this.Return(item) =
        queue.Enqueue(item)

I’ve been toying around with F# recently, it’s good to see an example that you can easily compare and contrast with the C# version. Has anyone else tried out F#?

Comments