Let's Make A Game! Episode 6: Sprite Strips: Not As Sexy As They Sound

Whew. This was a tough lesson for me.

I'm not really good at doing what people tell me to do. If you give me a list of things to accomplish, I'll usually miss one or two items on the list. It's just the way I am. I'm also not very good at dictation, which is what a lot of this stuff feels like. Add these two personality flaws, and you get a heap of trouble with this exceptionally long lesson. Let's dive in anyway.


This lesson deals with animations, like walking or jumping. There are two ways to handle animation in a 2-D game.

1) Each individual step that the character takes is its own separate picture played in quick succession. That means that for, say, Mario to take a step, you would have to do something like this:

Step 1: Load mariowalk1.jpg.
Step 2: Unload mariowalk1.jpg.
Step 3: Load mariowalk2.jpg.
Step 4: Unload mariowalk2.jpg.
...
Step 15: Unload mariowalk8.jpg.
Step 16: Load mariowalk1.jpg.

Now, you could do this easily by creating a variable called MarioWalk and then adding 1 to it every time it passes through a loop and play its corresponding picture. Then, when it reaches 8, you drop it back to 1.

However, think about it: Is this really the best use of processor cycles? Loading and unloading content isn't something that we want to waste too much time on. There has to be a better way.

2) Sprite strips. A sprite strip is a picture that already has all 8 still pictures in it. Therefore, you would do something like this:

Step 1: Load mariospritestrip.jpg.
Step 2: Create a rectangle with the first part of the image in it.
Step 3: Replace it with the second part of the image.

And so on. Math appears to be quicker for the processor than loading and unloading content, but I could be wrong about that. Either way, we're learning sprite strips and there is not a thing you can do about it.

So here's how it works. Every time we go through this loop, we're going to use a few variables.

The first two are ElapsedTime and FrameTime. We'll keep adding 1 to ElapsedTime until we reach the value that we've set for FrameTime. When that happens, we'll add 1 to CurrentFrame and reset ElapsedTime to 0. We'll keep doing this until CurrentFrame reaches the same amount as a different variable, frameCount. Then, we reset currentFrame back to 0 and start over.

Next, for every instance of currentFrame, we're going to look at the sprite strip. We'll multiply currentFrame by how wide the frame needs to be. For example, if the frame needs to be 10 pixels wide (which it doesn't, but we'll say it does for the sake of argument) and the currentFrame value is 3, we'll multiply the two to get a value of 30. Our formula then figures out that we need to grab the rectangle that starts from pixel 30 in the sprite strip and continues another 10 pixels. Then, once the currentFrame value changes, it'll start from pixel 40 and continue from there.

Clear as mud.

Let's Make A Game! Episode 5: The Answers You Seek

I finally got tired of not knowing what the arguments in those methods were. I was following along with the tutorial and hoping that they would explain them. I mean, any monkey can just type things into a box, but if you want to learn how to program, you need to learn the underpinnings of what you're typing.

I asked Matt, a programmer friend of mine, and he directed me to the place I should have looked in the first place: Google, or more specifically the method/argument documentation that you can find through there.

See, Microsoft documents EVERYTHING. If there's ever any file or command that you see and you don't know what it means, the MSDN more than like has what you need in spades.

For example, last time I was trying to figure out what this meant:

Vector2(GraphicsDevice.Viewport.TitleSafeArea.X,GraphicsDevice.Viewport.TitleSafeArea.Y +GraphicsDevice.Viewport.TitleSafeArea.Height / 2)

It looks pretty complex, right? Let's break down the structure of the Vector2 method. According to this page, here's what the command represents

Vector2 (Single, Single)

The first single is the x, or horizontal, value. The second is the y, or vertical value. Therefore, we can break down the above command a lot easier now.

The method:

Vector2

The X Value:

GraphicsDevice.Viewport.TitleSafeArea.X

The Y Value:

GraphicsDevice.Viewport.TitleSafeArea.Y+GraphicsDevice.Viewport.TitleSafeArea.Height / 2

For the X value, we're putting the player in the Viewport in the "TitleSafeArea," or first available safe place on the screen. That would be all the way on the left side of the screen, essentially at position 0.

For the Y value, we don't want to put the player in the first safe area on the screen. That would dump them on the bottom of the screen, meaning we'd be starting the player in the bottom left corner. It's kind of a sloppy place to start. Instead, we want to put them in the middle. How do we do that?

They chose to add two things: The first safe area (for the sake of argument, the number zero) plus HALF of the HEIGHT of the safe area. This way, no matter how big the screen is, the player will always end up in the middle of the screen. Pretty cool, huh?

It also explains a command in the next lesson about player movement. Here's the command that had me stumped:

MathHelper.Clamp(player.Position.X, 0,GraphicsDevice.Viewport.Width - player.Width)

"You want MathHelper.Clamps? YOU GET THE CLAMPS!"

So what does all this mean? Here's the syntax for the method:

public static float Clamp (
         float value,
         float min,
         float max

Basically, the Clamp command is keeping a value within certain parameters. This is what keeps us from taking the player off the screen accidentally.

So, breaking down the method, here's what the previous command means:

The Method:

MathHelper.Clamp

The value we're checking:

player.position.X

The minimum value we want to allow for X:

0

The maximum we want to allow for X:

GraphicsDevice.Viewport.Width - player.Width

All right so what does the last part mean? Basically, if we just say "GraphicsDevice.Viewport.Width is the maximum amount we want for X," we would have the right side of the player completely off the screen, since it appears we're determining X from the left side of the character.

However, if we subtract the width of the player off of the width of the screen, now the player will stay on the screen entirely instead of accidentally getting partly obscured.

Now that we're armed with this information, we'll be able to understand much more about what we're doing and where we're going.

Me Am Brain Hurting

Learning programming is starting to hurt my brain a little bit. It's been a long time since I really sat down and learned something that wasn't easy for me to pick up.


Usually, most every subject I pick up is something I already have some familiarity with. For instance, I wanted to learn about dog training. I knew a bit about it to begin with and had family who worked with animals, so it wasn't that bad to learn. I wanted to learn about World War II. I already knew the basics, so it wasn't that difficult.

However, programming is tough. It's really tough. It's not even just the syntax, which is literally like learning a brand new language. Reconfiguring my brain to sort out the equations necessary is what's really been the most draining.

Now, I've reconfigured my brain like this in the past. I've picked up math classes really quickly after the initial shock wore off. For example, I had a math class that I started six weeks after the rest of the class and I finished a week ahead of everyone else. At the start of the class, it took a week or two of headaches (literally) and then I was able to push through.

I think that's been the hardest part for me so far: The headaches. Whenever I learn a concept that's totally foreign to me or take on a new large task, I get raging headaches that only go away after I sleep. Then I'm usually able to take on the next task or chunk of the lesson. It's almost like when you exercise and your muscles hurt afterwards. I'm exercising my brain and it hurts.

If this post is a little rambling, that's because I'm right in the middle of, you guessed it, a major headache. I'm just trying to dump my feelings on the page in hopes that someone else who's in the same boat might read this and feel that they're not alone in this.

Must sleep now.

Let's Make A Game! Episode 4: Rumble In The Jumble (Of Code)

So we continue onward with our exploration into programming C# with XNA. I want to draw our attention to a couple of different loops that I forgot to mention last time around.

First, we have Initialize. Think of this one as putting everything in order to begin the game. In this loop, we're going to set all of our starting points: How much health your guy has, how fast he's going, and all that other fun stuff.

In the next loop, we have Update. In this loop, we determine if anything has changed. For example, did the player press a button? How far did a bullet travel? Is an enemy moving across the screen? How far did he move? This step is pure math.

Next, the fun loop: Draw. This is where all of the changes that we've figured out in the Update loop get written on the screen. After this loop, we drop back to Update.

That's the crux of most games. It's setting the table, seeing what's different, and then displaying the difference to the player.

Going back to our program, they want us to enter in these lines of code:

// Load the player resources
Vector2 playerPosition = new Vector2(GraphicsDevice.Viewport.TitleSafeArea.X,GraphicsDevice.Viewport.TitleSafeArea.Y +GraphicsDevice.Viewport.TitleSafeArea.Height / 2);
player.Initialize(Content.Load("player"), playerPosition);

What does this all mean? I dunno. I kind of wish I did. I mean, I added it, and I got the result they were looking for. Anyone out there have a good explanation as to what this all means?

In the meantime, here's what we've got after finishing the lesson:

MY GOD IT'S FULL OF STARS

So not entirely impressive yet, but these things take time. In the next lessons, we'll be learning about input, so it should be much more exciting.

Let's Make A Game! Episode 3

I was going to try and explain what I know about programming, but it's complicated stuff. Anything I spit out here would sound like the ramblings of an above-average seven-year-old, so I'm just going to stick to what I know.


Instead, we're going to work off of XNA tutorials to learn the underpinnings of the language itself. Microsoft's site doesn't reveal tutorials unless you really go digging, but I finally found one that's been EXTREMELY helpful. Here's a link if you want to follow along with me.

The idea behind this tutorial is to give us all a better idea of how to build a simple game while walking alongside us with the code. We'll try and follow along.

I hope we're all familiar with the idea of a "variable." In case you're not, a variable is a value that can change over the course of our program. For example, let's take a video game character like Cloud Strife. When he starts out the game, he may have 200 hit points. Over time, that number can change. It can go up, down, or do whatever within certain limits. That's a variable.

There are couple main types of variables that we'll use: integers, Boolean expressions, vectors and textures. Cloud's hit points are an integer, or a whole number.

A boolean expression is something that's either true or false. For example, when Cloud has one or more hit points, he's alive. When he has zero hit points, he's dead. That's a boolean value.

Vectors are the location of an item in 2D or 3D space, and textures are what any given tile will look like, as far as I know. I could be way off on those definitions.

So, if we want to declare a variable, the tutorial suggests that we do something like this:

public int Health;

What I've done here is said that this variable is going to be an integer (or "int"). We're naming the variable "Health" and ending the statement with a semicolon to end the "sentence."

This goes hand in hand with the idea behind "methods," or "functions." The nearest analogy I can come up with is this:

During the day, you do several tasks repeatedly. Most boil down to a few basic things. For example, you eat, go to work, brush your teeth, use the bathroom, etc. Each of those individual things you do is comparable to a "method."

For example, when you eat, some of the possible variables could be:

• The food you're eating


• How much time you have to eat


• What utensils you have

Using those variables, you will do the method that we'll call "Eat." After "Eat," you'll use the method "Work." Some of the possible variables for that could be:

• How long you have to work


• What tasks you must accomplish


• Who you're working with

After you've done the method "Work," you may go back to "Eat." Maybe after "Eat," you'll do more "Work." Then you'll do the method "Drive," where you'll go home. Some of the variables may be:

• What you need to do on the way home


• What the traffic is like


• If there are any roads closed

And so on. In the program from the example above, they've declared a few methods at the beginning which will form that basis of most of our programs:

• Initialize


• Update


• Draw

"Initialize" appears to be the beginning of the game. "Update" asks the program what's changed. Has the player hit the left mouse button? Has he hit the space bar? Has an enemy moved to the left or right? Did the player shoot a gun? "Draw" puts the results of the update on the screen.

That should give us a good starting point. We'll complete the step called "Creating the Player" and then go from there.

5 Ways To Save Mega Man

We've discussed what's killing Mega Man games in a previous article. How can Mega Man be brought back from the brink of death?
1) Stop. Just... Stop.

I want to be clear: When I say "stop releasing Mega Man games," I mean for them to end all Mega Man games for the time being. No RPGs. No sports games. Nothing. Radio silence. It's time for Capcom to let Mega Man rest for a while. After almost two games per year in 24 years, he's tired.

After a while, excessive sequels kill any interest that people have in a franchise. The only way to counteract that is to stop making games for that franchise for a while.

You might say that putting Mega Man out to seed for a while is a tremendously risky move for Capcom to make, but on further reflection it's not that bad. The series is doing so poorly right now that Capcom has to be losing money on every Mega Man game. How many copies do you think they sold of Mega Man ZX Advent? 75,000 copies in Japan. That's barely worth talking about.

On top of that, Keiji Inafune, the creator and guiding force behind the Mega Man series, has also moved on. No one has really stepped up at this point to fill that void and be the voice of Mega Man in a figurative sense. Why not let Mega Man lie fallow for a bit, give someone a chance to come up with something really good and then unleash it on the world? As it is right now, every new entry only further dilutes Mega Man down to almost nothing. It's time for it to stop.

So how long is too long? I'd say that if Capcom lets Mega Man sit for three years, that's the absolute maximum amount of time. That should be enough time to come up a with a new, long-term strategy to allow Mega Man to be viable for the foreseeable future. It's a temporary setback to ensure the long-term survival of a gaming icon.

2) Reboot.

The less complicated Mega Man is, the more popular he is. I don't know why Capcom doesn't get this. How much story does Mega Man 10 have? It's minimal. Was it a mild success? Yes, it was. By current standard, it's a rousing success. It's possible that the original Mega Man series doesn't need rebooting.

So which series needs a clean slate? In my opinion, it's the Mega Man X series. If there's a way we can pretend that all games after X2 were just a dream, that would be great. I would even be OK if we avoided a hard reboot. If we just go back to X and Zero blowing up robots, that would be awesome. Jettison dead weight like Axl and Sigma being a virus and lengthy cutscenes and other garbage.

Just like Sega does with Sonic fans, Capcom has a tendency to listen too closely to the most die-hard fans who really legitimately CARE about the minutiae of the Reploids and can rattle off biographies of minor characters. It's to the point that the series is starting to devour its own tail.

Die-Hard Fans: "We want more story!"

Capcom: "Here you go!"

Buying Public: (crickets)

Die-Hard Fans: "See, forget about them! They don't love Mega Man like we do! Give us more story! Satisfy us!"

Capcom: "I guess so, here you are."

Buying Public: (emphatic crickets)

Die-Hard Fans: "Philistines! We're the only ones who truly appreciate Mega Man! MORE STORY!"

And so on. It's time to cut off the maniacal fans and focus on the public at large or face death at the hands of public indifference.

3) No More RPGs.

Look, I played the first Battle Network game and found it interesting. Then I woke up one morning and there were 3 more of them waiting outside my window and peering at me while I slept. That's enough. I know they're cheap to produce, Capcom, because you can reuse sprites and make minor variations of the same battle systems. Here's the problem: NO ONE LIKES THESE GAMES.

Who's buying these games? Honestly? Japan, is this your fault? Because I will come over there RIGHT NOW, I am not even kidding.

If Capcom wants to make 50 RPGs a year in a series no one cares about, fine. Spin off the series. Take the Mega Man name off of it. YOU'RE DILUTING THE BRAND. I wish I could grab Capcom by the lapels and shake them until they understood this.

I would even be OK if Capcom decided to make only ONE Mega Man RPG for every handheld system, but only on one condition: Make Mega Man the star. That dovetails nicely with the next point...

4) Put Mega Man Back In Mega Man Games.

If I pick up ONE MORE Mega Man game that doesn't have Mega Man as the star, I swear to Odin that I am going to lose it. They did this with the Mega Man X series. I am going to make this clear to you, Capcom:

When someone buys a Mega Man game, they want to play as Mega Man.

Sega learned this lesson the hard way with Sonic. We don't want to play as Big the Cat or Shadow or whatever characters that they're loading up Sonic games with nowadays. Now that they're refocusing on Sonic, the series is recovering ever so slightly.

And no, Capcom, you can't bend the rules by having "MegaMan.exe" be an assistant or making an offhanded comment in the game about there being "Mega Men." NO. Mega Man is iconic, and making Generic RPG X or Platformer X and slapping a reference to Mega Man in there is irresponsible and is cheapening your brand.

It's ridiculous that I even have to say this, frankly.

5) Unleash Hell.

So, after you've let Mega Man sit for a few years, reinstated your commitment to quality and spacing out your releases, stopped making RPGs and started putting Mega Man back into Mega Man games, what next?

After the two to three year waiting period, unleash Mega Man 11, the relaunched Mega Man X series, and, what the heck, a Metroidvania Mega Man game for handhelds where your weapons are required to open up new passages while USING THE SAME SPRITES as Mega Man 2. I think I just pooped myself a little bit over how awesome that sounded.

Then, sit back and stagger your releases. NEVER release more than one Mega Man game per year from there on out. Make your releases count. Make sure that each game is quality or it doesn't make the cut.

----

Listen, Capcom, we all love Mega Man. We really do. We're ITCHING to play a good Mega Man game again. You have an enormous audience that's waiting patiently. If you play your cards right, you'll end up with more Mega Man fans than you can count.

If you don't? Well, let's not think about that.

Casey McGeehee! Where Have You Been?

Three homers in one day! Geez, who woke him up? Glad to have him back, and I hope he keeps it up.