Game Concept: Messaging Maze

May 1st, 2011

The following is one in a series of game concepts that I thought would be good to get written down for future use or inspiration, either for myself or for anyone else who wants to take the idea further. Be sure to let me know if you make use of it – I’d love to see it fleshed out into a playable game.


messaging-maze

I was inspired to jot down this game concept after seeing the way that my mother plans trips with one of her friends over the phone. Each one will open up an internet browser on their respective computers and they will talk back and forth to make sure that they are both looking at the same webpage as they discuss places they can travel to and which hotel looks like the best option.

In fact, they seem to have a lot of fun doing this. From listening to them, I expect that some of this fun is actually coming from the challenge of keeping their browsers in sync while talking to each other. In this process, they are essentially both navigating their way through a maze in which they both must communicate in order to end up at the same goal.

By abstracting this behaviour, I feel that I have discovered something that is instinctively fun that could be effectively implemented into an existing social network infrastructure. Thinking back to when I was first learning to type and communicate effectively through instant messaging software, I actually found that the simple challenge of communicating through text messages to be quite fun. If this instant messaging was coupled with a maze game where both players must ensure that they both end up at the same goal, it could result in a very fun social gaming experience that may be very attractive to players who are new to a given social networking infrastructure and are still captivated by the novelty of communicating with their friends – this game could provide a strong purpose and framework for a fun experience. It may also be perceived to be an attractive social experience for those who are seasoned communicators of these infrastructures.

Some ideas that come to mind could revolve around timers where both players must reach a given area in the maze by a certain point in time. Or, both players cannot be in different rooms for more than a certain time length without repercussions.

Of course, this gameplay mechanic could be applied to a number of different themes. When first thinking about it, a paranormal/ghost theme comes to mind to explain why each player can’t see the other, even though they may exist in the same place. A haunted mansion also makes for the perfect maze environment: Maybe the players, being invisible ghosts, are the ones haunting the mansion?

Game Concept: Fading Opportunities

April 29th, 2011

The following is the first in a series of game concepts that I thought would be good to get written down for future use or inspiration, either for myself or for anyone else who wants to take the idea further. Be sure to let me know if you make use of it – I’d love to see it fleshed out into a playable game.


Fading-oportuinties

A simple character that presents an element of reality: no matter how hard we try, the results usually only last a short time before fading away.

This main character has the ability to create opportunities. Initially, I imagined these opportunities to be represented as stairways that could lead to new areas in the environment. But like our efforts in the real world, these stairways eventually fade away sometime after their creation – or in this world, very shortly after their creation.

As a game where the character uses his or her powers to explore the environment, similar to the Paper Mario series, it’s natural to expand the player’s abilities and powers for more gameplay options. Instead of only being able to only create stairs, maybe he can also create doorways into new areas. Barriers could be created to prevent enemies from attacking you, etc. This kind of gameplay would lead naturally into a reusable world/environment or sandbox.

All of this could be intertwined with a story explaining the struggles of the character and the limitations of his power. Through many trials and growth, the character will overcome obstacles and achieve new heights previously unimagined.

IGDA Ottawa: Indies in the Classroom Talk

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

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

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!