Posts Tagged ‘GUI Design’

IGDA Ottawa: Indies in the Classroom Talk

Friday, April 22nd, 2011

At a recent Independent Game Developers Association meeting I was asked to talk about my experiences taking Hideout!, a project originally developed as schoolwork, to the Xbox 360 for public sale. The slides and a video of the presentation are below. As always, please pass on any feedback; it’s always much appreciated!

The presentation began with a brief introduction of myself and Hideout! including Hideout’s promotional video.

This meetup was focused on students going above and beyond class requirements and taking their games to the next level. The audience was comprised mainly of students in game development programs or recent graduates. The topics covered include the following:

  • Porting from Windows to Xbox 360 with XNA
  • Xbox Live “Indie Games”
  • Other general game design topics for Hideout!

Download Slides (PPTX)

Changing the Windows Mouse Cursor in XNA

Monday, April 4th, 2011

aero_arrow

Background

For anyone who is looking to develop a mouse-based game for Windows using the XNA framework, it’s pretty critical to be able to change your mouse cursor in game. The first method is to hide the mouse cursor and draw a custom texture in place of it – but anyone who is developing a game that might not be running at a full 60 frames/sec will know that this is does not work well, as it results in a very slow and unresponsive mouse movement.

The Windows operating system is designed to give extremely responsive mouse movement no matter how slow your applications are running, so we’d like to harness this power in XNA while also giving us the power to change our cursors.

Overview

The following will allow you to change the windows cursor in XNA to any .cur or .ani file (full colour, animated, just like through the Windows Control Panel). This is done by changing the cursor of the windows forms handle for the XNA window. To load full colour and animated cursors, we will use the IntPtr LoadCursorFromFile(string) method from user32.dll, as suggested by Hans Passant.

Step 1: Add References

  • Add the “System.Windows.Forms” reference to your game project. Do this by right clicking on the References folder in the Solution Explorer for your project and select “Add Reference…”. It can be found under the “.Net” tab.
  • You will need to include the following namespaces:
using System.Windows.Forms;
// For the NativeMethods helper class:
using System.ComponentModel;
using System.Runtime.InteropServices;
using System.Reflection;

Step 2: Add your Custom Cursor

  • Add cursor to your project (let’s say it’s called “cursor.ani” and you put it in the “Content\Cursors” directory).
  • Go to the Properties of this cursor in your Solution Explorer and set the “Build Action” to “None” and “Copy to Output Directory” to “Copy if newer”.

Step 3: Loading The Cursor

You will need something like the following helper method to load your full colour animated cursor into a handle that Windows Forms can use:

// Thanks Hans Passant!
// http://stackoverflow.com/questions/4305800/using-custom-colored-cursors-in-a-c-windows-application
static class NativeMethods
{
    public static Cursor LoadCustomCursor(string path)
    {
        IntPtr hCurs = LoadCursorFromFile(path);
        if (hCurs == IntPtr.Zero) throw new Win32Exception();
        var curs = new Cursor(hCurs);
        // Note: force the cursor to own the handle so it gets released properly
        var fi = typeof(Cursor).GetField("ownHandle", BindingFlags.NonPublic | BindingFlags.Instance);
        fi.SetValue(curs, true);
        return curs;
    }
    [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
    private static extern IntPtr LoadCursorFromFile(string path);
}

Step 4: Changing the Cursor

First, set the mouse to visible:

this.IsMouseVisible = true; // in your Game class

Next, load your cursor using the above static helper method:

Cursor myCursor = NativeMethods.LoadCustomCursor(@"Content\Cursors\cursor.ani");

Now load up the window handle that will let you change the window’s cursor:

Form winForm = (Form)Form.FromHandle(this.Window.Handle);

Simply do the following to change the cursor:

winForm.Cursor = myCursor;

That’s it! Happy game dev-ing!

Hideout! Post-mortem / Retrospective

Sunday, February 6th, 2011

It’s been a few moths since the Xbox 360 release of Hideout! on the Indie Games channel of Xbox Live. The sales were very low, but I was expecting that from this type of game. Regardless, with over 1200 trial downloads and only 45 sales, it would be good to look at why this game was not a blockbuster…

HideoutKidAbduct

1) Content, content, content!

Paraphrasing Antonio of Artech Studios, “It’s all about content nowadays.” If the player is able to experience the entire game in 5 minutes, then why would they put their money into buying it? Most players of modern video games expect a series of new experiences encapsulated in a single game, rather than just one experience per game like in the days of the Game and Watches.

This was the first problem with Hideout! – Once you’ve tried it, you know there won’t be any new and different experiences in the full version. To resolve this issue, a more refined version of the game would include new environments to unlock with new powerups, different enemies, and maybe even a variety of completely different gameplay mechanics.

This concept actually ties in a bit with the next point…

2) The trial game did not entice players to buy

The unique challenge that exists in designing games for Xbox Live and other similar platforms revolves around creating a trial game that will make the player want more. As described in the last point, it’s important to make sure that there actually is more, but that’s not enough on its own: the player needs to know about it and they need to want it.

So we need to think up a way to let the player know about the extra features and experiences while also triggering a desire to buy them. The method that should be used depends heavily on the features of the game – I would not be able to say exactly what the best implementation would be for Hideout! without strictly defining what the new features would be… Regardless, here are some methods that I’ve seen other games on similar marketplaces use:

Probably the most commonly used method is designing the trial to emphasize inaccessible features by displaying them in the game, but preventing the player from experiencing them. This works great with level-based games because it shows the player there is more and gives them a taste that will hopefully make them want more. Story-based games can simply be cut off at cliff-hangers, after the player has become involved in the story and has began to develop a relationship with the characters.

A strategy common to  Xbox Live games is including notices of achievements that would have been unlocked if the player had purchased the full game. Sadly, this ability is not available to Indie Games like Hideout!… but it would not be impossible to implement something else that would use this basic concept without having access to the Xbox Live API.

3) No strong reward for the player

This one is tricky. For some players, the reward of getting a higher score and moving to the next level is enough. But for others, they really need to see that they’re making a difference in the game world or be given something in return for their efforts. Hideout! did some of this right by giving the player a rewarding sound when saving another kid from the UFO invasion, but it was obvious during playtests that this was not enough for all players.

4) Lack of polish and “oops, I forgot.”

I could make up lots of excuses, and most of them would probably be valid, but when it comes down to sales, excuses don’t matter. Hideout! was definitely lacking in polish on the visual and performance elements. Spending extra time and effort on these elements can have an impact on sales, especially those derived from reviews, which I expect hold a large percent of total sales on this platform. On a similar note, I totally forgot to make use of the force feedback in the Xbox controller! Oops!

5) Accidental key presses in menus

This one was counterintuitive to me: I realized after making Hideout! that it is quite essential to have a slight pause between in-game menus to prevent the input intended for gameplay to be picked up by the menu system. Most major games do this nowadays with fancy animations or transitions between menus, but even a simple pause before accepting button presses in menus would have resolve this problem for Hideout!

6) Don’t distract me when I’m playing!

I’ll be honest and say that it was a bit of a surprise when I found that players were clueless about gameplay mechanics that were clearly being explained to them through in-game text. After seeing this, I learned the true power of well-constructed tutorial levels. Hideout! failed to introduce the player to the details of how to play in a safe, stress-free environment. Instead, without pausing the gameplay, the player was expected to read text while running away from UFOs and busily figuring out everything else about the game.

HideoutDontMove

In fact, a similar problem extended outside the gameplay: some players simply don’t read any text at all! Even though the reason for the game over was clearly stated at the end of the level, some players would just skip past it to continue the same mistakes over and over again in gameplay. I expect that the best solution for Hideout! would be a tutorial level that pauses the gameplay at different events, giving the player a chance to read the explanation and instructions.

7) Lack of support for player’s input preferences

I’ve played a number of 3D adventure games from Nintendo where it is convention to control the camera by rotating around the player: moving the joystick to the right rotates the the camera to the right relative to the player. This works great for Nintendo, as the majority of their platform’s games follow this convention… But a large majority of Xbox players are first-person and third-person shooter players who expect the camera to move in the reverse direction: moving the joystick to the right moves the camera left relative to the player causing the view to show what is to the right of the player’s character. This seems backwards to me, but after much playtesting, it has become obvious that on the Xbox it is critical to have invert-rotation options, even though it may not actually be necessary on Nintendo’s platforms.

That’s about all that comes to mind for now. I hope this has been a helpful insight to everyone. I’m always looking for feedback, either on my games or on these blog posts, so feel free to leave some comments!

720p Title Safe GUI Template

Saturday, June 19th, 2010

I am currently in the process of porting Hideout! to the Xbox 360 with XNA. As a part of this process, I needed to create a Photoshop GUI template for my GUI artist to ensure that our game would work well on all TVs. I thought this template may be useful to other developers as well:

Title-Safe-GUI-Template-PSD Title-Safe-GUI-Template-PNG

This file is essentially a compilation of notes from Best Practices for Indie Games and this topic. The guides (cyan lines) that you see are markings for 10% and 20% of total width and height. I chose these markings based on some comments by Shawn Hargreaves concerning development of professional games for the Xbox:

Native Xbox games have two different safe areas. They are strongly recommended to keep everything within 80%, and strictly required to keep everything within 90%. A single UI pixel outside the 90% region is an instant cert fail. UI outside the 80% region is going to get mentioned in the cert report, and they’ll most likely be asked to fix it, but if a big commercial developer pushes back and decides they don’t want to do that, it’s not a totally rigid requirement.

For indie games, there is no official cert and thus no rigid fail threshold. Our recommendation for indie games is exactly the same as for commercial titles: Microsoft thinks all games should keep all UI within the 80% region, and would love it if every developer would do this.

I have included notes about font size, as well as how much space is needed if you would like to make a 4:3 alternative.

4:3 Alternative

This 4:3 alternative can be achieved by simply changing the BackBuffer width in XNA to 960px instead of 1280px and letting XNA do the rest of the scaling. To stay within the 20% to 10% title safe area, you will need between 256 (20%) and 288 (10%) pixels in between left, center, and right aligned GUI elements. When you have shrunk the width to 960px, your GUI elements should still just fit within the title safe area after being moved closer together so long as you have left this extra space.

Concluding Thoughts

As a designer, I do understand the challenge of creating a well balanced and pleasing layout without being able to use 20% of your screen space… But that said, I must say that if you are looking to create a game that everyone can enjoy (which I hope you are), you should take on the challenge of keeping all critical elements within that 80% area. The minimum font size of 14 points is also a bit on the small size: Do not use this for common gameplay text, but instead lean towards around 20 point at minimum.