Archive for the ‘Games’ Category.

Another year, another restart :(

Well, not a complete restart at least.

What I have decided to do, is attempt to focus on and complete one game before moving on to another.  I’ve been fighting the “squirrel” battle for a long time, but I’m hoping to overcome it this year (just in time for the world to end, I know).



I’m digging up an old game that I’d started a number of times but put on the back burner since it’s a fairly big game, at least from the number of features I’m planning. I’m planning on releasing it on XBLIG (why I still haven’t figure out given it’s a virtual graveyard that’s to the mismanagement and/or uncaring of MS 🙁 ) and then probably IndieCity or possibly Steam if I’m lucky. WP7 is a dream, but I’m not sure how well it would do on that platform. If I can get enough done for the next DreamBuildPlay, so much the better.

The short list of significant features I’m planning on:

  • In-game level editor
  • Level sharing
  • “Global” leaderboards
  • In-game (and possibly out-of-game for the PC version) “store” for players to upgrade their “character”
  • 6 player multiplayer
  • Single player with AI

I’m hoping this game will be my ticket to indie game developer freedom so I can ditch the boring (although fairly well-paying) day job. I’m not holding my breath though. If I can make a decent chunk of money I’ll be happy.

I probably won’t share any more details about the actual game until it’s ready for playtest. I will be posting status updates here though for the 1 person that actually might follow this blog. 🙂

On a personal note, I did receive my MVP award again my contributions to the tech for last year. That’s 6 years in a row for anyone counting. I’m not sure how much longer I’ll be able to maintain it with XNA slowly dying however. I guess I’ll just keep chugging away and see what happens.

XNA Snake

So I was going through the App Hub forums, randomly locking and deleting threads like normal (well, maybe not so randomly and not really that often relatively despite what everyone says :D) when I came across a post asking how to do the classic Snake game. As so often happens, I thought “This might be interesting to see how quickly I could do this” and went off and started hacking together a basic snake game.

If you don’t know this game, read about it here.

I thought about explaining everything, but it’s relatively simple and you should be able to puzzle everything out rather quickly. If not, post a comment. 🙂

I will say that the one thing that’s likely to trip up someone that hasn’t done rotated graphics is the code to draw the snake sections. I’ll briefly talk about that portion of code.

I decided to have the snake head have eyes because a blind snake is a bit silly:

So if the snake is heading north, nothing special needs to be done. If the snake (or any part for that matter) is heading in a direction other than north, the texture needs to be rotated. This means using one of the overloaded SpriteBatch Draw calls that takes a rotation parameter:

SpriteBatch.Draw (Texture2D, Vector2, Nullable<Rectangle>, Color, Single, Vector2, Single, SpriteEffects, Single)

The parameters for this overload are: texture, screen position, optional source rectangle, color tint, rotation, origin, scale, effects, and sort depth. The last three we really aren’t going to worry about and will just get default values. The source rectangle will get a null since we’re always drawing the entire thing. The Color will, of course, be Color.White. The screen position, rotation, and origin are the tricky pieces here.

The screen position will depend on whether we’re drawing the texture rotated:

part.Location * 32 + new Vector2(GetOffset(part.PartDirection), GetOffset(part.PartDirection))

The Location member of the SnakePart class we use for each part is a Vector2. Each square of the area the snake can run around is 32 pixels square so we can just multiply the member by 32 and both X and Y values will be multiplied by 32. To that result we then add a Vector2 that will either have both X and Y values as 0 or 16 (the middle of the texture):

       private int GetOffset(Direction dir)
            if (dir != Direction.North)
                return 16;
                return 0;


The rotation parameter is done with a simple function call:

        private float GetRotation(Direction dir)
            float ret = 0.0f;

            switch (dir)
                case Direction.North:
                    ret = 0.0f;
                case Direction.East:
                    ret = MathHelper.PiOver2;
                case Direction.South:
                    ret = MathHelper.Pi;
                case Direction.West:
                    ret = MathHelper.PiOver2 * 3;

            return ret;

The MathHelper class gives us an easy way to get the value for the 3 compass points other than the default North.

The origin point of the texture is another direction dependent value:

part.PartDirection != Direction.North ? _vecOrigin : Vector2.Zero

_vecOrigin is a Vector2 with the X and Y members set to 16.

The complete draw Method of the Snake class that I use looks like this:

        public void Draw(SpriteBatch sb)
            foreach (SnakePart part in _parts)
                sb.Draw(_partGraphics[(int)part.PartType], part.Location * 32 + new Vector2(GetOffset(part.PartDirection), GetOffset(part.PartDirection)), null, Color.White, GetRotation(part.PartDirection),
                    part.PartDirection != Direction.North ? _vecOrigin : Vector2.Zero, 1.0f, SpriteEffects.None, 0.0f);



A little unintuitive maybe, but that’s how it is when you’re dealing with rotated sprites. The big thing to remember is that if you’re rotating the sprite the origin needs to be the center of the texture otherwise the upper left corner. Likewise, the destination also has to be offset by half the width and height of the texture.

Here’s my result of a couple of hours of work. One thing I haven’t implemented is checking if the snake head collides with a part of itself. I had to leave something for you guys to do, right? 🙂 Also, a check should be done to see if the game is over and, if so, the Initialize method of the Game class should be called.

Both Gamepad and Keyboard (DPad and arrow keys respectively) can be used. The snake also increases speed every other fruit that’s eaten. I did this just for testing and it should increase speed a bit slower than that. See if you can figure out how to do that. It should be quickly obvious.

Another teaser

Coming along, should be ready to play in, ohhhh, a year or so. 🙁 Need more free time.



XNA Is Dead, Long Live DirectX

edit: I should have made it clear that the title for this post is a semi-joke. Yes, I know XNA isn’t dead and XNA games will run on Win8 and there’s still the 360 and WP7 platforms. My apologies for any confusion. 🙂

I’ve held off with this post until I had what I thought was enough information to speak intelligently on the topic. I know, that makes me unusual for someone ranting on the interwebz, but that’s the way I sometimes like to roll. 🙂

So XNA games on Windows 8 won’t be able to be Metro-style games. They’ll still run as desktop games so everything is good, right? Not really, in my opinion.

MS had the chance of making XNA a first class citizen on Win8 and finally make the “3 screens and the cloud” mantra that they’ve been preaching the past couple of years a reality, but instead it’s even more of a red-headed stepchild that it has been.

My hope for XNA over the past couple of years has been that the PC would get a shiny new coat of paint by MS overhauling Games For Windows LIVE to make it a Steam competitor and allow XNA games to be submitted to it just like WP7 and Xbox.

Given the sorry state of XBLIG with it’s bugs, shovelware, and lack of exposure that allows XNA games to actually make decent money and the newness of the WP7 Marketplace that means income from XNA games on that platform isn’t much better, I was looking towards the PC to receive some love that would make it the savior of XNA. Sadly, that’s not to be.

It seems there will be a marketplace, but XNA games, being that they cannot be Metro-style apps, will have a Marketplace entry that is just a link to a site the developer designates, which means we have to handle all the nasty business details that the other two marketplaces take care of for us. While that’s not impossible, it means extra work that we don’t have to deal with on the other two platforms, and possibly having to maintain an extra code base for whatever distribution platform is used. It also means that many gamers will probably see the off-Marketplace hosting and either worry about security issues (viruses, payment, etc.) or get the feeling that XNA games just aren’t up to snuff to be allowed to be on the real Marketplace. They probably won’t know, nor care, about the technical issues that don’t allow XNA games to be on the Marketplace. Perception is a killer when it’s negative.

Being Desktop apps on Win8 also means that XNA games cannot take advantage of whatever functionality exists only for Metro-style apps. What exactly all that is, is only speculation at this point, but I’ve found this:


Metro style apps

Native API access through C or C++ or through P/Invoke in .NET. Native APIs projected into C++, C#, Visual Basic, and JavaScript. Third parties can supply environments for additional languages.
Native common controls, with most UI support provided by added frameworks. Can also use DirectX for highly optimized graphics. Rich, native UI support (Windows.UI.Xaml), including direct use of HTML+CSS for JavaScript. Apps written in C++ can also use DirectX.
Full-trust; able to access any system resource, including all areas of the file system. Base-trust, isolated in individual app containers with brokered access to protected resources (those affecting user data, identity, and privacy), and no access to system-critical resources.
Written with the Classic/Desktop SDK using the full Win32 API surface area along with the WinRT API. Written with the Windows SDK for Metro style Apps using the Windows Runtime (WinRT; all languages) API and a small subset of Win32 and .NET (C++, C#, and VB only).
Run with the desktop environment with overlapping windows. Typically, run full screen, or might share part of the screen with at most one other app; operating system chrome appears as needed.
Continue running until user explicitly closes them; can easily run in the background without user interaction, and can be set to launch on startup. Are typically suspended when not in the foreground, unless an app specifically requests background tasks. Those tasks are still subject to user control.
Licensed per machine. Licensed per user with automatic roaming app settings via the cloud.
Open distribution: retail stores, web, private networks, individual sharing, and so on. Distributed through the Windows Store. Apps must pass certification so that users download and try apps with confidence in their safety and privacy. Side-loading is available for enterprises and developers.
Provide their own commerce engines to do trial versions or in-app purchasing. Can provide trial versions and in-app purchases directly through the Windows Store. Apps can also use a custom commerce engine to handle subscription or similar purchases.
Custom anti-piracy, commerce, licensing, updates, and analytics. Licensing, core anti-piracy, and updates provided through the Windows Store; analytics provided through the Windows Store developer portal.
Can generally access system devices such as webcams and microphones, and user data without restriction. Must declare access to needed hardware and file libraries. Unless specifically allowed by user action, such requests are otherwise denied.
Custom install/uninstall processes; allowed to alter the system. Declarative install/uninstall with no customizable steps and no ability to alter the system.
Maintains its own user authentication. Can share a single user sign-on across apps.
Static desktop icons and custom notifications. Live tiles, content tiles, and consistent notifications.
Custom code for cross-app features like search, share, and contact management. System search is limited to the file system. Integrated contracts that allow apps to provide services to each other and to the system, including search, share, contacts app-to-app file picking, Sent To, Play To, and more.


Exactly how much of the Metro-style functionality is useful is going to be up to the developer I guess. There are some things that are actually nice for Desktop apps, but overall the negatives outweigh the positives to me.

There is already talk in the community about ways around the outcast status of XNA games. My opinion is that workarounds shouldn’t have been necessary. For whatever reason though, MS thought that updating XNA to allow games to be Metro-style software just wasn’t important enough to be done. Could that change in the future? Sure, but that doesn’t help those of us that want to plan and be ready to take advantage of the market when Win8 is released.

As much as it saddens me, I’m seeing the announcement of Win8 as the last gasp of a dying technology. Hopefully my prophetic talents are completely wrong.

Something to whet the appetite…?