Nick on Tech

A common flaw in lots of games is reacting to people hitting the “Buy Game” option and not making sure that user can actually purchase content. Almost worse is the common response that all you have to do is make sure the user is signed in to LIVE. That is wrong.

Child accounts, for example, can be set up to allow the user to be online but not be allowed to purchase the game. Remember that only the account that starts the game must be allowed unrestricted access to content. Other users can still join in and play. This means controller two might be Little Jonny who isn’t allowed to buy a game, but has a Silver LIVE account.

So here’s a little method I just wrote up that you can use all you want to determine if a given PlayerIndex matches up with someone allowed to buy your game:

public static bool CanPlayerBuyGame(PlayerIndex player)
{
	SignedInGamer gamer = Gamer.SignedInGamers[player];

        // if the player isn't signed in, they can't buy games
	if (gamer == null)
		return false;

        // if the player isn't on LIVE, they can't buy games
	if (!gamer.IsSignedInToLive)
		return false;

        // lastly check to see if the account is allowed to buy games
	return gamer.Privileges.AllowPurchaseContent;
}

So steal this code and use it. You have to check the AllowPurchaseContent privilege to be absolutely sure a user is allowed to buy a game.

EDIT:
To make this cooler, let’s make an extension method for PlayerIndex that lets us do this:

public static class PlayerIndexExtensions
{
	public static bool CanBuyGame(this PlayerIndex player)
	{
		SignedInGamer gamer = Gamer.SignedInGamers[player];

		if (gamer == null)
			return false;

		if (!gamer.IsSignedInToLive)
			return false;

		return gamer.Privileges.AllowPurchaseContent;
	}
}

So with this, all you have to do is a simple “if (PlayerIndex.One.CanBuyGame()) { }” and you’re all set. Gotta love C# 3.0.

Lots of people are thinking of implementing some sort of in-game achievement system for their game. I took some time last weekend to submit an article for Ziggyware’s latest contest that shows how you can quickly get a nice little system in place: http://www.ziggyware.com/readarticle.php?article_id=217.

Here we are just a few days after the start of Existence and I have a pretty good start. Animated sprites, full tile map with collisions, and some fun floating sprites (those music notes you see in the screen shot bob up and down). Next up on my list of things to do is tweak my camera system and get started on a level editor. Hopefully I’ll have that done by the end of the week so I can show a level of running through a level. (The screen above is generated as a random level which is how I’ve been testing thus far).

I’ve also decided to just call the game Existence. I decided that I don’t have enough in common with Being to justify calling this Being 2. I’m not using the former main character, the former bad guy, nor even keeping the gameplay the same. About the only relationship is the sprite sets and playful, non-violent nature of the game.

That’s about it for now. I’ll probably do blogs, videos, and screen shots during the life of Existence to keep people interested and also because I don’t do those sorts of things for Metacreature Games titles. It’s always fun to talk about and show off projects.

While reading through the XNA forums, I noticed this quote. I decided to respond partly because they’re talking about my game, but also because I see two design “philosophies” that I rather disagree with:

I was really wanting more to be going on in Bloc, like the different colors doing different things. I’ve done enough design to know it’s not hard having something come in from one side of the screen and leave on the other, so there is obvious room for improvement there, if for no other reason than to force more of a reaction from the player.

To me this sentiment oozes of a couple design philosophies I can’t stand:

1) Design to design.
2) If the design is easy to implement, it must be bad.

Now those are simplified a tad, but let me explain what each of these means to me:

1) Design to design. All too often I see people who cram more and more stuff into games. They try and over-analyze and over-design everything. The more that goes in the better. In their mind if you can do something, you should.

To me this is just a bad way to go. Putting things in just to have more things doesn’t make a game better. To the contrary it often makes the game a convoluted mess. The key phrase that tips this to me is when someone justifies their criticism with “if for no other reason than X”. If you have no good reason to implement the idea, then don’t implement the idea. If the idea fit well with the rest of the design, you wouldn’t need that clause as you would have a solid justification for adding the idea to the overall design.

To personalize this for Bloc, Bloc is a simple game. It was intended to be simple. We had ideas for blocks that rotated, did little waves across the screen, changed colors, and all mess of other things. But at the end of the day, all of those things just made the game frustrating. So we opted for simplicity.

2) If the design is easy to implement, it must be bad. If it didn’t take you days to figure out how to implement the design, you have room for improvement. If it looks technically simple, your design is flawed.

This is even more frustrating to me because, to me, the difficulty of implementation has nothing to do with the quality of design. You can have great designs that are easy to implement and you can have horrible designs that take ages to implement. Being a simple implementation is not an indication of a flawed design.

Again to personalize this, moving blocks across the screen is dead simple. It was the easiest part of making Bloc. But that’s how the game is supposed to be. That is the design. It’s ok if you don’t like it, but that doesn’t mean the design is inherently flawed; it just means the design didn’t resonate with you.

As mentioned above, we had all sorts of ideas that would complicate the movement patterns and make the blocks more erradic, but given the nature of the game and the already decently high learning curve of the controls, we decided that it was best for the design if we kept the gameplay itself decently simple.

Ultimately I think design means a little something different to each person out there. To me game design is all about finding those one or two great ideas you want to implement and building a design to emphasize those. For Bloc it was the color matching, both in game and on the game pad, that was our chief focus. So to not distract from that we chose to stick with a more basic implementation of the gameplay itself.

One of the trickier parts of starting out with XNA is figuring out what is called when and by whom and where you can put this or that without breaking something. It’s somewhat confusing at first. So I’m going to try to explain the flow of an XNA game as best I can. I can’t use Visio to save my life (at least not to create something coherent), so you’ll have to live with a text description. Let’s just dive in:

First your game’s constructor is called. No magic happens here and technically speaking you don’t have to have any code in your game’s constructor. You could move all the template code to Initialize (as long as it’s before you call base.Initialize()) and everything would work just the same.

Next the Run() method is called on the game. This is what starts all the hidden stuff that nobody knows. There’s a lot going on behind the scenes, but for now we’ll just talk about the common stuff:

1. First you’ll get a call to Initialize. This is where you generally put non-graphical initialization code for your game*. You also need to make sure you call base.Initialize(). When you do, the game does a few things:
   • Calls Initialize on each GameComponent in the Components collection.
   • Creates the GraphicsDevice.
   • Calls LoadContent on the game.
   • Calls LoadContent for each DrawableGameComponent in the Components collection.

   So if you’ve ever gotten that “GamerServicesComponent is not Initialized method” and your method call was before base.Initialize(), that’s why. It’s also worth noting that it is base.Initialize() which will call LoadContent for your components; not base.LoadContent(). The base Game implementation of the LoadContent method is empty. This means you can simply not call it and nothing will change.

   Another note is that adding game components in Initialize but after base.Initialize() will result in them not being initialized by the game. There are three ways to deal with this:

   • Add the component before base.Initialize().
   • Manually call the Initialize method of the component.
   • Override the BeginRun method and add the component there.
2. Next we enter the main game loop of Update/Draw. At this point, any game component added to the Components collection will be automatically have Initialize and, if the component is a DrawableGameComponent, LoadContent called. The game remains here until the told to Exit.
3. Now your game is exiting so UnloadContent is called on your Game. UnloadContent is also called automatically on your DrawableGameComponents so you do not need to call base.UnloadContent() at all (unless it makes you feel better; then go for it).

That’s a very high level look at it, but it should answer some questions. Those being these big points:

1. If you are doing some initialization that relies on the GraphicsDevice, put it in LoadContent or in Initialize after you call base.Initialize().
2. If you are doing some initialization that relies on a game component being initialized or loaded, put it in LoadContent or in Initialize after you call base.Initialize().
3. If you add a game component in the Update method, it will automatically have the Initialize and, if appropriate, LoadContent methods called.

Hopefully this helps out more than it confuses. I’ll admit I’m not the best at explaining this flow, but since I’ve seen the question come up a couple times I figured I’d take a stab at it. If you want one of the best ways to find the flow, I’d recommend grabbing Reflector (free download) and opening up the XNA dll files. There you can trace the Run method and follow what the framework is doing line by line.

*: In my experience, I’ve found little use for the Initialize method. Personally I stick any initialization code that doesn’t rely on the graphics device or game components in my constructor. I’ve yet to find any real good reason why I should put that code in Initialize instead of the constructor. If you have a good reason, please leave me a comment. I’m always up for realizing something I hadn’t previously.

EDIT: Thanks to one of my colleagues at Visi3D I now have a diagram of the process. Send all your love and thanks to Gary for this:

I’m not quite ready to announce the next game from Metacreature Games just yet. Partly because we’re still figuring out what exactly it is, partly because we have no art, and partly because we like to wait until we have it mostly done before announcing things.

However I did start a little side project today. I plan to do a fair amount of blogging about the building of this game as I go, presuming that I don’t get distracted with the primary game project. The basic premise is to take some of the ideas from Being and make my own take on that gameplay and world. This won’t be a sequel, per se, but I’m hoping to create a familiar experience while taking things a little further.

Thanks to Jesse for allowing me the official use of the name Being as well as pointing me towards some of the sprites he used for his game. For now, at least, I’m thinking the name will be Existence: Being 2. I’m bad at naming stuff, I know. But who cares about a name anyway? My last game was called Bloc for goodness sake.

That said I don’t actually have anything to show yet as I’m still building on things, however I will leave you with this wonderful sprite of what is likely going to be the main character.

Yes, I’m aware it isn’t the little red guy. It’s a bear. I think. With a 16×19 pixel image it’s hard to tell what it was supposed to be so I’m calling it a bear. Get used to it.

For those of you who don’t follow my every move, you may not know that my brothers and I (moreso my brother because I tend to be busy) run a little family/gamer blog over at SuperGravelynBros.com. Today Matthew, my older brother and lead designer on Bloc, wrote up a post that runs down some of the press coverage Bloc has gotten since its creation. Pretty exciting to see Ars Technica calling our game the “best game to hit Community Games” as well as the potential inclusion into an OXM UK article.

Check out the article and let us know what you think of Bloc. Heck we even have an official Xbox.com forum, too!

It was pretty exciting seeing Bloc up on the marketplace last week. To see something you made on the Xbox in a place where, literally, millions of people will be able to download and buy is just crazy. But now we’ve reached a new level. Bloc has gotten press coverage.

In a post titeld XNA Preview: What You’ll Be Playing On Day 1, Part 1, GamerBytes does a little write up on some of the launch titles for XBLCG including Bloc. Even better than just being covered, they had some good things to say:

A shooter that is more complex than it looks. You move around the screen as a ball of color. You rotate the ball around to change the direction the colors are facing, and then shoot said colors using the buttons of the controller. It’s an interesting concept which might be worth your money. It does have cooperative play where each player controls two colors, so it might be good to get you and your girlfriend playing.

It’s pretty cool to see your game being discussed and talked about. I can’t wait to see some statistics later and see how many people are giving Bloc a try. I’m also very excited to see if other sites write anything up on Bloc. If you spot something, please leave me a comment so I can check them out.

Coming once more to the aid of XBLCG developers everywhere, ZMan of the famous The ZBuffer has started looking into creating videos for XBLCG developers. He has a fancy pants capture card that let’s him get 720p video straight from his Xbox which means you get great quality video directly from the target hardware. You can then use this video using Silverlight Streaming to easily post it up in HD, or send it off to SoapBox to use as your official trailer.

Zman was nice enought to get me some footage of Bloc using his new toy, so here’s a nice hi-res version of Bloc for you to see the quality (or at least, the embeded quality) of these videos when put on Silverlight Streaming.

Extension methods are a new feature in C# 3.0 that we finally have full use of in our XNA games now that we are using Visual Studio 2008 (or Visual C# 2008 Express). Extension methods are simply static methods that are able to be used to simulate instance methods of any type. Put another way, extension methods let you implement new functionality in a static class, and execute it as if it was built in to the type, thus extending the type.

So where are these useful? Well, one of my new favorite places is with the GameTime type. Most people use the elapsed game time’s TotalSeconds property to get the elapsed time between frames so they can use a time based motion. This generally winds up with this everywhere:

float dt = (float)gameTime.ElapsedGameTime.TotalSeconds;

Not really that bad, but it gets annoying having to cast and type that out each time. What we can do is make an extension method to expose this is a shorter, cleaner way:

public static class GameTimeExtensions
{
   public static float GetElapsedSeconds(this GameTime gameTime)
   {
      return (float)gameTime.ElapsedGameTime.TotalSeconds;
   }
}

Note the ‘this’ keyword in the method declaration. That indicates to the compiler that this is an extension method. Now when we want to use it, we can call it just like an instance method. So our line of code above now becomes:

float dt = gameTime.GetElapsedSeconds();

And that’s it. Another example is with 2D rendering. Generally speaking, I find that I like rounding all my Vector2 position values to integers for rendering to avoid strange filtering artifacts from trying to render to a partial pixel position. This usually looks like this:

spriteBatch.Draw(spriteTex, new Vector2((int)pos.X, (int)pos.Y), Color.White);

After a while, I got sick of all the casting and wrote up an extension method for it:

public static class Vector2Extensions
{
   public static Vector2 ToIntVector(this Vector2 v)
   {
      return new Vector2((int)v.X, (int)v.Y);
   }
}

So now to render I can use this simple method instead:

spriteBatch.Draw(spriteTex, pos.ToIntVector(), Color.White);

And my third example shows how you can use some more complex logic with your extension methods to hide some cool functionality into objects. For this I’m implementing a system for managing Viewports on a GraphicsDevice. So here’s the extension class:

public enum ViewportLocation
{
   FullScreen,
   TopHalf,
   BottomHalf,
   LeftHalf,
   RightHalf,
   TopLeftQuarter,
   TopRightQuarter,
   BottomLeftQuarter,
   BottomRightQuarter
}

public static class GraphicsDeviceExtensions
{
   public static void SetViewport(
      this GraphicsDevice device,
      ViewportLocation location)
   {
      Viewport viewport = new Viewport();
      viewport.MinDepth = device.Viewport.MinDepth;
      viewport.MaxDepth = device.Viewport.MaxDepth;

      switch (location)
      {
         case ViewportLocation.FullScreen:
            viewport.X = 0;
            viewport.Y = 0;
            viewport.Width = device.PresentationParameters.BackBufferWidth;
            viewport.Height = device.PresentationParameters.BackBufferHeight;
            break;
         case ViewportLocation.TopHalf:
            viewport.X = 0;
            viewport.Y = 0;
            viewport.Width = device.PresentationParameters.BackBufferWidth;
            viewport.Height = device.PresentationParameters.BackBufferHeight / 2;
            break;
         case ViewportLocation.BottomHalf:
            viewport.X = 0;
            viewport.Y = device.PresentationParameters.BackBufferHeight / 2;
            viewport.Width = device.PresentationParameters.BackBufferWidth;
            viewport.Height = device.PresentationParameters.BackBufferHeight / 2;
            break;
         case ViewportLocation.LeftHalf:
            viewport.X = 0;
            viewport.Y = 0;
            viewport.Width = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Height = device.PresentationParameters.BackBufferHeight;
            break;
         case ViewportLocation.RightHalf:
            viewport.X = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Y = 0;
            viewport.Width = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Height = device.PresentationParameters.BackBufferHeight;
            break;
         case ViewportLocation.TopLeftQuarter:
            viewport.X = 0;
            viewport.Y = 0;
            viewport.Width = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Height = device.PresentationParameters.BackBufferHeight / 2;
            break;
         case ViewportLocation.TopRightQuarter:
            viewport.X = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Y = 0;
            viewport.Width = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Height = device.PresentationParameters.BackBufferHeight / 2;
            break;
         case ViewportLocation.BottomLeftQuarter:
            viewport.X = 0;
            viewport.Y = device.PresentationParameters.BackBufferHeight / 2;
            viewport.Width = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Height = device.PresentationParameters.BackBufferHeight / 2;
            break;
         case ViewportLocation.BottomRightQuarter:
            viewport.X = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Y = device.PresentationParameters.BackBufferHeight / 2;
            viewport.Width = device.PresentationParameters.BackBufferWidth / 2;
            viewport.Height = device.PresentationParameters.BackBufferHeight / 2;
            break;
      }

      device.Viewport = viewport;
   }
}

Now you can easily pick any half or quarter of the screen (or the whole thing) and just set that viewport with one method call:

graphics.GraphicsDevice.SetViewport(ViewportLocation.TopHalf);

Extension methods are a powerful way for you to add functionality based around existing types without the mess of standard static method syntax. Now that C# 3.0 is fully supported for XNA Game Studio 3.0, take advantage of them to help make your game code just a little bit cleaner.