Mega Man X2! Wii Virtual Console! EXCLAMATION POINTS!!!

ESRB UPDATE! MEGA MAN X2!

Is it OK if I pee myself a little bit? Just a little.

Why am I so excited about this? Well, Mega Man X2 uses the Super FX chip. The only major games missing from the VC (aside from Earthbound) are games using that chip, like StarFox, Super Mario World 2, etc.

This could be it! This could be the beginning of the last major influx of Virtual Console releases. I hope so.

Let's Make A Game! Episode 9: Project Moche

This week has been a busy nightmare, so I've had very little time to program. I'm hoping to jump back in once I have a few minutes to catch my breath and put out some fires. In the meantime, I figured I'd talk about what kind of game I'm planning on making.
I got this idea back during my Mega Man article. I mentioned making an open-world Mega Man game with Mega Man 2 sprites and nearly peed myself over the idea. That got me thinking: I obviously can't make a Mega Man game in and of itself, but what could I make?

There's no trademark on the idea of "beat a boss, steal it's power." I could make something similar to Mega Man but pick and choose the things I like while removing what I don't like.

For example, I like stealing powers from enemies and returning to previous levels with those powers. I don't like really long wait times after deaths. I like the solid platforming mechanics of Mega Man. I don't like the lack of exploration involved in most levels.

I also don't like the excess baggage involved with Mega Man, all the sequels and story parts that get tangled up in the actual game. I want a clean slate, a reboot of Mega Man. That's something I can do myself.

Pictured: All the Mega Man sequels.

I have another idea that I want to attempt that examines death in platform games, but it's a pretty complicated concept that I have in mind for that one. I'd rather concentrate on this idea first. Since I'm not ready to pull back the curtain too hard on what I intend to do, I need some sort of codename. Plus, I really like giving codenames to things.

So, from here on out, anything having to do specifically with this game idea, like level design, music and sprites will be tagged "Project Moche," named after an ancient Peruvian civilization. "Let's Make A Game" will be for programming.

I now have to figure out the general rules of my game. What's the point? Who's the villain? What's the story? How much health does the hero have? Who are the bosses?

My head is already spinning, but I can do this. People do this stuff every day, so I can too.

An Excessively Long Analysis of Spider-Man 3 (Part 1 of 4)

Spider-Man made superhero movies mainstream.

Before Spider-Man, there had been exactly two successful superhero franchises: Superman and Batman. It's no surprise that these were also the two most famous superheroes with some of the most iconic imagery in comic book history.

After the rousing success of Spider-Man, X-Men 2 and then Spider-Man 2, studios started mining superhero franchises for all they were worth. That's why every single superhero that ever existed is getting its own franchise. At this point, I wouldn't be surprised to see a Bat-Mite movie.

The plus side of this? We're getting movies like Iron Man, where you have a great director tackling a complex and not entirely well-known character with an actor who's completely game and understands the point of the character. The downside? Movies like DareDevil, Elektra, and Ghost Rider, where the studio looks up from their pile of cocaine just long enough to greenlight a very misguided franchise.

However, by the time Spider-Man 3 hit, we were in the middle of a superhero renaissance. Sam Raimi showed that he "got" Peter Parker and understood how villains should work. In Spider-Man 2, Raimi gave Dr. Octopus real reasons for being the bad guy, deepened the relationship between Mary Jane and Peter Parker and had a bunch of cool action sequences to boot. He made these characters that were in impossible situations behave in real ways.

Keeping all that in mind, we were understandably psyched about Spider-Man 3. Here was a superhero movie that actually had the potential to be a bona-fide good superhero trilogy and tell a self-contained story from a director who just plain "got it"! Plus, Venom! How could they screw up Venom?

I always viewed the Spiderman movies as this: In the first movie, Spider-Man faced off against his equal in strength. Sure, Norman Osbourne was a scientist, but he was also as strong as Spidey. In the second movie, Spider-Man faced off against his equal in brains. Sure, Otto Octavious fought with Spider-Man too, but the main danger was in his research killing everyone.

In the third movie, I expected Venom to provide Spider-Man with his ultimate test: Himself. The symbiote would attach itself to Peter Parker and then carry what it learned to Eddie Brock or whomever would handle it.

What did we get instead?



The dancing sequence is frequently cited as the worst part of Spider-Man 3, but it really wasn't the biggest problem. It's more of a symptom than the actual disease. If the rest of the movie would have been good, it merely would have been a goofy diversion.

I read an interview with Shigeru Miyamoto where he talked about ideas. He said that when a project is going bad and you have an idea that's half good and half bad, you need to throw that idea out. If a project is going well and there's an idea that's about the same, you can use it.

Why is that the case? Because in a good project, the flaws are minimized. If everything else is clicking, you can hum right over some of the flaws without even noticing that they're there.

For instance, take 2009’s great movie The Dark Knight. It’s a fantastic movie, but if you scrutinize it, flaws bubble to the surface. For example, how did the Joker get tons of explosives into Gotham General Hospital, not to mention on to two heavily-guarded ships during a riot, and not get noticed? Someone would have certainly noticed the barrels of explosive sitting around, wouldn't they?

For that matter, after the Joker blows up Gotham General, he walks out of the hospital in full Joker makeup and gets on a bus without anyone even caring who he is. As they state later on, that bus is full of patients. Someone would have noticed and freaked out.

I’m not picking on The Dark Knight, and sorry if I ruined it for you. The point stands, though: Since the rest of the movie is so good, we gloss over those plot holes and goofy parts. They don't matter to us. We accept them and move on.

In Spider-Man 3, the dancing sequence bothers us because of the movie that surrounds it. Let's call this phenomenon the Jar-Jar Moment. It means that instead of being mad at the numerous faults of the movie that added up to make the whole thing bad, we focus on the one thing that is readily apparent. In Star Wars: Episode 1, that was Jar-Jar Binks. In Spider-Man 3, it was dancing. In a better movie those flaws may not have bothered us as much, but in a stinker it becomes a lightning rod of anger.

Instead of focusing my ire on that one scene, I argue that Spider-Man 3 went off the rails near the very beginning. Where did it all go wrong? We'll start from the very beginning and work our way through.

Click here for Part 2!

Let's Make A Game! Episode 8: Bug Hunt

So I got through the entire lesson about parallax scrolling and thought I was doing pretty well. Went to run my program, and what did I get?


A blank grey screen. Awesome.

I decided to go back and remove the full-screen code I put in, since it was making things a little difficult and annoying. Plus, I assumed that maybe it was part of the problem. I mean, if the parallax code was meant for a certain window size, I could be completely borking it, right?

I went back and tried to rerun the code and got a completely different error this time pointing to a random variable that I had added as part of the lesson. Awesome. After going back and being SUPER-CAREFUL about how I added all the code, I tried it again.

Still didn't work.

That's when I said, "Screw it." I'm going back a couple of steps, back to before I started experimenting. Now's not the time to experiment, I suppose. I'll give it another shot at the animation lesson and the parallaxing lesson and then we'll proceed onward.

From when I used to make programs, I remember that programming is debugging. For example, you enter in something and expect it to work one way and it works in a slightly different way. You go back and take another look and try and figure out what happened and fix it.

I forgot how ANNOYING it is, though.

On the plus side, I also found a tutorial for platform games, which makes me incredibly happy. Since that's the style of game that I'm planning to make, it should be incredibly useful.

I'm in need of a pump-up. Fortunately, I found this great live version of an LCD Soundsystem song that always gets me going. Here it is.



I can do this.

Let's Make A Game! Episode 7: Difficulties Arise

I'm finally starting to gain the confidence to experiment. I'll start fiddling with variables just to see what they do, or mess around with things just because. I'm starting to see how things work together and I'm getting able to see how games are made. There's a downside to that confidence, though. I finished up the last lesson about animation and sprite strips and somehow ended up with my character off the screen. I can't figure out quite why, although I suspect it's because I was goofing around with settings and ended up messing something up. Still, experimentation is good! Making mistakes is how we learn. That's what I'm telling myself.


Even with what I'm learning, I still can't quite figure out how a game like Super Mario Bros. is made yet. I understand the principles of collision detection, and with a seemingly simple game, it should be easy to figure out. I still can't wrap my head around how you make levels and scroll them. Ah well. I'll get there eventually.

One of the problems I'm running into recently is time. I usually write these entries several days in advance in order to have a bit of a backlog built up. I want to consistently put these entries out every few days. Even with the backlog, I'm just about caught up, which annoys me greatly.

Mainly, it's really hard finding quiet time to program. I can't really learn unless I'm all by myself and the house is quiet. Usually, when I'm home, my lovely wife and her lovely sister are home as well, and they usually watch endless episodes of Say Yes To The Dress. I simply can't concentrate when that happens.

All of this is adding up to get me a little frustrated, but I'm still making some headway. For example, I was poking around on the MSDN and found a command for making the game fullscreen. They had some sample code, so I inserted it. Here it is:

this.graphics.PreferredBackBufferWidth = 480;
this.graphics.PreferredBackBufferHeight = 800;

this.graphics.IsFullScreen = true;

It took me a bit of fiddling to figure out where this goes, but eventually I was able to insert it and got fullscreen! Woohoo!

Unfortunately, I didn't insert any code to end the game, so in order to close it I had to Alt+Tab back to Windows, open Task Manager and close the game manually. But still! We're getting there!

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.