Let's Make A Game! Episode 14: Agile Programming Development

Yes, this is Agile. No, he is not a programmer.

I'm taking time to learn some more about programming theory. I figure, the more I understand about HOW things work, the more I'll be able to put them together.

My programming mentor Matt led me to agile program development. My first thoughts turned to one of the antagonists from Mega Man X2, but after some gentle prodding and rolled eyes, it turns out it's a very useful method for getting things done.


Let's use a normal program as an example. In a normal programming environment there are a lot of dependencies. For example, let's say Gordon Freeman uses a shotgun. In order to make sure the shotgun works the right way, we have to make sure Gordon Freeman works first. Then we test the shotgun.

What if there's a problem with the shotgun, like, say, it doesn't fire properly. It could be with the programming for the shotgun, but it also could be a problem with Gordon Freeman. For example, what if the Gordon Freeman part of the program is having problems firing weapons? Now you have to dig through not only the Gordon Freeman method but also the shotgun method.

You can see how quickly this can spiral out of control in a very complex program. After a while, with so many dependencies layered on top of each other, everything can become intertwined in a really nasty way. A change to one part can have a ripple effect on a whole host of other methods and objects.

That's where agile program delevopment can help. It's a way of making the program work from the very beginning, and it's what all the cool kids are using.

Let's use our shotgun example again. I want to make sure the shotgun will fire when someone sends the command to fire. I'll take my method of shotgun.Fire and narrow it down to a binary value: Did it fire, or didn't it? Then, I'll subject the shotgun.Fire method to a script that tests it out. If my value comes back as true, then I can slap shotgun.Fire into the program without incident. If it doesn't, then I can figure out what's missing and go from there.

You can see the benefits of this technique. It doesn't require you to do as much code repetition. It means that you're not so much programming as snapping together very complex Legos.

There is a downside, though. It's not as easy to do as typical programming. It requires you to build a script to test out your chunks of code. It's also a little complex for someone just starting out like myself. Still, this may be the route I should go once I get more experience under my belt.

NES Games Announced For 3DS Ambassadors

The list of NES games available for the 3DS Ambassador program was released today. Let's go through them one by one and see if they're worth it.

Super Mario Bros. - Worth It - We've all played this game so many times. I think my fingers involuntarily twitch to Super Mario Bros. in my sleep. It was a given that they'd offer it. Still a fun game, though.

The Legend of Zelda - Worth It - Ditto with The Legend of Zelda. If they're shooting for nostalgia, then fine. They picked the right games.

Balloon Fight - Not Worth It - Seriously? Balloon Fight? I suppose we're lucky they didn't give us Clu Clu Land.

Ice Climber - Not Worth It - Maybe if the two-player stuff works this might be fun. Otherwise, a big pass.

Donkey Kong Jr. - Not Worth It - Why not Donkey Kong Classics instead? That had Donkey Kong AND Donkey Kong Jr. and it was released in 1984. Maybe then it would be worth it.

Metroid - Worth It - It's outdated now, but as an introduction to gaming, Metroid is fine. It'll be nice to play it without passwords.

Open Tournament Golf - Meh - It was an OK game for it's time. I dunno.

Wrecking Crew - Worth It - If only for the level creation aspect.

Yoshi - Not Worth It - SUCH a boring puzzle game. You literally can't lose. I've tried to lose at it and it simply doesn't happen.

Zelda II: The Adventure of Link - Worth It - If only to see one of the Zelda series' major departures.

So there we have it. Five games that are worth something, 4 that aren't and 1 that's middling. As much I don't want to complain about free stuff, come on.

I really hope that ALL the Super Mario Advance games are available, or someone's getting punched in the throat.

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

I'm not too happy with Mary Jane and Peter's role reversal in Spider-Man 3.

In previous movies, Mary Jane had all the power in the relationship. Sure, many times she was a damsel in distress, but she had a quality about her that made their relationship a little different. She was the unattainable beauty queen from the troubled background, and he was the forlorn, helpless nerd who couldn't bring himself to be with her.


In Spider-Man 3, their positions are reversed. Spider-Man is the toast of the town, and everyone loves him. He's getting great grades and doing pretty good at the Daily Bugle too. That's not a bad place to start our hero in. After two movies of seeing him down-and-out, it's nice to see Peter Parker get ahead a little bit.

At the beginning of the movie, Mary Jane is getting bad reviews for her play, singing in a nightclub and looking like she's bottoming out. Never mind that she just starred in a play and was the face of a fashion campaign. Putting that aside, in a lot of relationships, there's some give and take. Sometimes, you're up and your significant other is down, and sometimes you're down and your partner is up. That's just how life works.

In this instance, it creates a major issue. It's a very significant change to their relationship dynamic. Now Peter Parker has everything and his girlfriend has nothing. He's in charge even before he slips on the symbiotic suit. Peter Parker no longer needs Mary Jane. That's totally wrong for Peter Parker's character. On top of that, in a real relationship, you're happy for your partner when something good happens to them. If they're doing well, it makes you happy. The only way that it wouldn't is if you were completely self-absorbed.

(sound of record scratch) Wait, you mean we've changed another character's personality irrationally? Get out of town!

There's never been any indication that Mary Jane is too self-absorbed. Sure, in Spider-Man 2 she's performing in a play and is kind of upset that Peter's not there, but she has good reason to expect that a person who supposedly loves her would be there for an important time in her life. Heretofore, she's been pretty reasonable.

Of course, now that Peter's doing well, she doesn't like it at all and finds herself upset that the success is going to his head. There's never been any indication that the success is going to his head other than one kiss from Gwen Tracy and his advice to her based on what he's done as Spider-Man. However, because of those things, she stomps out of a dinner with him.

(Side note: I wish Bruce Campbell had a little more to do in Spider-Man 3. I'm a little gay for him now.)

I respect the filmmakers for trying to change the relationship a little bit and seeing if these crazy kids can muddle through. Every relationship hits rough patches. That being said, it was the wrong choice. If you really wanted to make Peter Parker's crash more devastating, how about this: Peter's life is going great. Mary Jane's is still modeling, and her acting is getting good reviews. That way, you keep their dynamic intact.

The added benefit? When Peter's life gets destroyed by the suit, it would be even worse. Peter is cruising along great and gets blindsided. Mary Jane thought her man was good and finds out that he's seemingly awful. It makes their situation that much more difficult to deal with and puts them under even more stress.

We're in the home stretch here, but let's go back and pile on to the movie's biggest flaw: Flint Marko. First of all, we're led to believe that he's some sort of Robin Hood character who only steals because he cares for his daughter and wants to get her treatment. It's a blatantly manipulative ploy. It's like the screenwriters just said, "When in doubt, throw in a sick kid." It's really kind of cynical to think that we're so easily manipulated to think that having a sick kid excuses murder, accidental though it may be.

Plus, with all this money he's supposedly stealing, how much of it actually goes to his kid? We see that he supposedly cares about the kid, but that's really the end of it. There's no follow-up, no attempts to get the money to the mother, and no more attempts to contact his child.

As much as I hated Marko, they could have redeemed it. How about if this scene was in the movie: After a fashion, Marko sneaks into his daughter's bedroom through the window and finds his daughter sleeping. He puts some of the stolen money under her pillow and kisses her on the cheek, leaving some sand on her face. She wakes up and smiles weakly.

The police have been waiting. They burst into the room and slam the window shut behind him. They have him surrounded. The kid is scared. He turns into sand and takes down all the officers while shots echo throughout the room.

Once it's all over, Marko comes back together and the mother comes in the room with a gun in her shaking hand, ready to shoot him. The daughter is scared and scurries away from him, crying. Marko tries to reach for her, but the mother threatens him. Marko can't do anything but escape through a hole that was shot in the window.

He's a freak rejected by his family, and there's nothing he can do about it.

Now you tell me, would that work or wouldn't it? It's just something I threw together in thirty seconds, and it's still a little manipulative, but wouldn't it put a bit of a coda on Flint Marko? Wouldn't it give his arc a little bit of depth and poignancy? Instead, we have him just running around stealing crap while fighting Spider-Man and claiming that it’s for his kid.

Last thing: In the end of the movie, Spider-Man forgives Marko for murdering Ben and Marko floats away. So, we're supposed to believe Spider-Man will just let him go after all the stuff he's stolen, after endangering the life of Mary Jane, directly killing Ben and indirectly killing Harry? I mean, a few minutes ago, Marko was just pounding Peter with a giant sand-shaped hammer, and now they're totally cool?

I think this was due to Raimi really liking Sandman. He liked Sandman as a character and as a concept, and it blinded him a bit. I'll bet he wanted to use Sandman again in the next movie and make him more of a good/bad guy.

Even if that never was the plan, isn't it odd that Venom got such finality and Sandman such an ambiguous ending? Raimi left no doubt that Venom was destroyed. All that was left of Venom was a pile of ash and a tiny bit of the suit left in Curt Connors' lab. Sandman gets away scot-free. It's also a little coincidental that Raimi really liked Sandman and disliked Venom.

Once again: What you like and what you have to do aren’t always the same thing.

So let's tally up the sins of Spider-Man 3:

1) Retconned Uncle Ben's death in the worst way possible, negating the emotional impact of the first two movies retroactively.
2) Ruined Harry Osborn's character arc.
3) Wasted Venom as a character, concept and villain.
4) Attempted to introduce too many new characters and ended developing all of them poorly.
5) Ruined Peter Parker and Mary Jane's relationship dynamic, as well as completely misunderstanding her character.
6) Wasted far too much screen time on Flint Marko and just sort of let him go at the end.

So am I going to watch The Amazing Spider-Man? Probably not. I'm pretty angry about how they ruined Spider-Man. I have interest in re-watching his origin story. I don't care about what happened to Peter Parker's parents. I don't want to see Sally Field play Aunt May.

What I want is for the story that was started by Sam Raimi to be brought to a conclusion the right way. Spider-Man 3 was a huge, disappointing missed opportunity. I know Spider-Man can do whatever a spider can, but it's too bad spiders don't have time-travel powers so he could go back and fix this atrocity of a film.

Let's Make A Game! Episode 13: Let's Stay Classy

We've been going through the tutorial so far. It's interesting stuff, but it's not teaching us everything we really need to know.

I've been having this major mental block when it comes to "object-based programming." What are we referring to? Is it just splitting a big program into a lot of little programs? What are objects?
There are a lot of tutorials, but a lot of them talk in "programmer speak." You ask something simple like, "What's an instance?" and you get an answer like "An instance as an object as defined by a class."

Then you ask, "What's a class?" and get, "It defines an object."

"What's an object?" "It's defined by a class."

And around we go. The problem is that there are lot of programmers who are really good at programming but by nature aren't teachers. That's OK. They're not supposed to be.

After pulling and prying the information I need out of a programmer, I think we have an analogy that might help explain object-based programming without getting horribly technical.

Let's say I want to drink coffee. I would have to define what coffee is in order to drink it, so first of all, it's a beverage. The beverage is kind of like our class: We're defining the parameters of what we're working with, or defining our object.

Now, coffee is a type of beverage, but how does it differ from other beverages? We'll have to define that too. Now we've defined another class, this time called "Coffee."

So now we've defined Coffee, but what do we do with it? In order to actually drink it, we have to make some. Using our definition of coffee that we've created in the "Coffee" class, we put coffee grounds and water in a coffee pot and make our own pot of coffee.

We have now "instantiated" the coffee, or made our own separate "instance" of coffee, which we'll call "coffeePot". Now we pour the coffee in our cup. We've instanced the coffee again, using "coffeePot" to make "leesCoffeeCup."

Coffee has very specific characteristics. I wouldn't be able to take grass clippings and vodka and throw it in a coffee pot, because that's not coffee. However, there is a little room for modification within the "Coffee" class.

For example, if I want to make my coffee a little stronger, in the instance of "coffeePot" I'll change the variable "coffeeGroundAmount" to a little larger than the normal amount. If I want weaker coffee, I'll take "coffeeGroundAmount" down a notch.

Those variables now affect my second instance of "leesCoffeeCup." If I've made the modifications in "coffeeGroundAmount" in the "coffeePot" class, now my coffee will be a little different. However, now that I've instantiated the coffee into my coffee cup, I can't really go back to the previous instance of "coffeePot" from this instance of "leesCoffeeCup." I can only instantiate another cup of coffee into "leesSecondCoffeeCup" from "coffeePot."

This makes it easier to program for a variety of reasons. For example, if I want to modify coffeePot next time I make Coffee, all I have to do is change the coffeeGroundAmount in THAT instance.

Finally, when I decide what I want to do with the coffee, I'll use the method drinkCoffee. This method explains that I'll pick up the coffee, put it to my lips, and tilt the cup back into my mouth until my mouth is full of coffee, then swallow it.

You still with me? Good, because here's the recap:

• Coffee - Class, which defines our object.
• coffeePot & leesCoffeeCup - Instance, which is this specific usage of our Class, Coffee.
• drinkCoffee - Method, where I explain what I'm going to do with the instantiated Coffee.

This explains, then, how a game like Warcraft III works. In Warcraft III, you have enemy units. The unit type is the class, but the specific units you see onscreen are all instances of that class. The method explains that they're going to go attack enemy units.

In Super Mario Bros, "Goomba" is a class. The goomba you see walking across the screen is an instance of that class. The method is that he'll walk in one direction until he's killed or until he falls off a cliff. Then that instance is removed.

Now that I have all this information sorted out, we'll hopefully be able to focus on the big picture instead of worrying about things like "my frigging character is off the screen."

Made Some Muffins

I made strawberry-cream-cheese-stuffed strawberry muffins. Yes, I meant to put "strawberry" twice. But how will they taste?

Let's Make A Game! Episode 12: WHAT IS WRONG

I moved on to the enemy-making portion of the project last night. Basically, what we're doing is creating a new class called "Enemy" and then using an array to manage multiple enemies at a time.

However, as is becoming de rigeur for me, I must have mis-typed or put some code in the wrong location, because enemies decided that they didn't want to appear on screen. There were no errors in the program that were readily apparent, so there was nothing I could point at and say "there's the problem."

I figured it might have something to do with the fact that my ship is slightly off-screen. It wasn't an outlandish guess. I mean, if my math is slightly off in one class, it's not inconceivable that it could affect another one, right? Then again, the classes generally don't intertwine in that way. Either way, even if I was way off on that guess, I decided that the safest thing to do would be to go out and get the fresh code from Microsoft and continue onward.

I downloaded the fresh code and ran it. What did I get?

--pic---

AAAAAAGH YOU HAVE GOT TO BE KIDDING ME

So I have enemies on screen and everything behaves as it should EXCEPT that. How? How is this happening? This makes about as much sense as a moustachioed duck riding a purple tricycle in Abu Dhabi. So NOW I'm going to want to start over and take a closer look at what happened. SIGH.

In the meantime, I was pointed here for more help. It's a list of guidelines for future reference. It's already proved pretty useful.

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

We've already broken down what some of the mistakes of Spider-Man 3 were. They wrecked the emotional center of the first two movies, didn't keep Harry's personality consistent, and squandered all the goodwill they earned in the first two installments to the point that they had to reboot the series.

Let's keep piling on!
Venom is one of Spider-Man's most iconic villains. When Sam Raimi complained about him in pre-production and said that he didn't want to use him, it should have thrown up a red flag for us. Usually, if you're forced to do something you don't want to do, you don't give it your all. Venom certainly didn't get the big movie that he deserved.

In fact, Venom was really only like a bit character in Spider-Man 3. We spent so much time on the black suit and how it made Peter Parker all emo and mean that we didn't really get to the meat of Eddie Brock as Venom. When we finally do get a little bit of Venom, all he really does is catch Sandman, asks him to be BFFs and then they go off to fight Spider-Man.

Then, during the final fight, Venom is defeated by bells. Don't get me started on that.

Venom was wasted to such a grand degree that I'm sure the studio wanted him back for the next two installments. Raimi probably disagreed and they ended up parting ways. I wouldn't be surprised if Raimi purposely killed not only Eddie Brock but all vestiges of the suit just so that he could be rid of the character.

I'm sure that in the reboot, Venom is going to appear right at the beginning of the series. I mean, why waste our time doing character-building and slowly making Venom Spider-Man's biggest threat? Why not just jump right to the biggest villain right away? Who needs subtlety in the reboot?

That's why I get so mad at Raimi for using Venom so sparingly. He had an opportunity to take a character that he might not have had a lot of affection for and make it his own. He could have done for Venom what he did for Norman Osborn and Otto Octavious: Make them real characters. Instead, he just sniffed at Venom and tossed him aside, ticking him off like a checkbox on a form.

Next up, let's talk about how Dylan Baker as Curt Connors was used throughout the series. I know they were saving him for something, but all the waiting never produced anything. Maybe they were planning on using him in Spider-Man 4 or 5, but it still doesn't make any sense to wait that long. Curt Conners was already there and had a solid backstory. They could have almost jumped right into the action surrounding him. Instead, they spent an hour developing Flint Marko and wasted everyone's time.

That leads us to another problem. How many major characters were introduced in this movie? Eddie Brock, Gwen Tracy and Flint Marko, and Gwen Tracy's father was in the periphery as the police chief. Why? Why did we need so many new characters this late in the game?

Let's consider one of the best trilogies of the past decade and how it uses characters: The Bourne Trilogy. In the first movie, we're introduced to a lot of the major players. We have Jason Bourne, Nicky Parsons, Marie Kreutz, Ward Abbott and Alexander Conklin. (If you don't remember the character names, think of it this way: Matt Damon, Julia Stiles, Franka Potente, Brian Cox and Chris Cooper.)

At the end of the movie, only the first four are standing. In the second movie, they add in Joan Allen's character, Pamela Landy. By the end of the second movie, Bourne, Parsons, and Landy are the only major players left.

In the third movie they introduce Noah Vosen, played by David Strathairn. At the end of the movie, we're introduced to Dr. Hirsch, played by Albert Finney. When it's all over, Vosen and Hirsch are in prison, and everyone else is OK.

There are secondary characters who go in and out of the movie as well, but the movies don't concern themselves with filling those players out as much. They focus on the core cast and don't spend too much time worrying about the rest.

Here's the final tally for core characters:

Bourne Identity: 5
Bourne Supremacy: 5
Bourne Ultimatum: 5

Spider-Man 1 and 2 kept the cast pretty constant. They really only introduced Doc Ock in the second movie, and kept the rest intact. In the first movie, our core was Peter, Mary Jane, Aunt May, J. Jonah Jameson, Harry and Norman. There were other people around the edges, but those were the most important players. In the second movie, it was Peter, Mary Jane, Aunt May, J. Jonah Jameson, Harry, and Doc Ock. That's it.

In the third movie, our core is now Peter, Mary Jane, Aunt May (who's largely wasted), J. Jonah Jameson, Harry, Flint Marko, Eddie Brock and arguably Gwen Tracy.

Here's the final tally for core characters:

Spider-Man 1: 6
Spider-Man 2: 6
Spider-Man 3: 8

How can you juggle that many core characters in two hours worth of screentime? Unless you're Bryan Singer directing way above your head in X-Men 2, you really can't.

You may argue that Lord of the Rings juggled at least 10 core characters in each installment. That may be true, but each movie had three hours to do it in. When you have more time, you can juggle more characters. It's as simple as that.

What we're getting to is that Spider-Man 3 reached way over its head. It attempted to do too much with too many characters and ended up not developing any of its new leads in any satisfying way.

Now, let's circle back to Dylan Baker. Let's say we take out the Sandman as the big bad and replace him with Dylan Baker playing Curt Connors. Connors is already half-developed in our minds since we know him a little bit. Now we have the ability to spend more time with Eddie Brock and even Gwen Tracy if we're so inclined.

Click here for Part 4!

First Impressions: Xenoblade Chronicles

Thanks to Joystiq's guide on playing PAL games on an NTSC Wii, I'm about an hour in to Xenoblade Chronicles so far. Here are some initial impressions.

First, as much as I hate to say it, Xenoblade Chronicles looks great for a Wii game. I can understand why Nintendo is choosing not to release it stateside so far: Some of the textures look downright HIDEOUS. There's one sequence in a cutscene where your character looks out over a hillside, and the entire hillside is one very large, very stretched texture.

Maybe this isn't a problem for Japan or Europe. I don't know. I do know that gamers here are a finicky lot, and it'll be difficult for them to overlook things like textures and draw-in.

Now that that's out of the way, let me just say this: WOW. So far, each of the characters is interesting. The location is interesting. The mechanics of the game are easy to learn and yet appear to be very deep. The music is stellar.

We're only an hour in, so some things might get grating, like how the characters talk incessantly. We'll see. As of right now, though, I'm having a really good time.

Little King's Story On PS Vita

So Little King's Story is getting a re-release on the PS Vita.

I like this idea. Look, Little King's Story is a great, great game. It would be completely at home on a handheld, and the more people that can play it, the better. While I'm a little disappointed it's not coming to my handheld of choice, if it does well on the Vita maybe it'll come to the 3DS.

In short: More gamers get to play a fantastic game, the makers of it get a little bit more money, and it gets the exposure that might enable the makers to make a sequel. Everyone wins.

Let's Make A Game! Episode 11: Parallax? I Hardly Knew Her Lax!

So parallaxing backgrounds.

First of all, what are they? It's not something you would see in Super Mario Bros. 1, 2, or 3. Usually, in those games the background moves along with the player. However, in other NES games, (and especially Super Nintendo games) they would sometimes take advantage of them. They work really well to give the illusion of depth in a 2-D plane without having to put in a lot of processing power


In this example, we're going to have three layers. One layer will be left alone to remain as the background. The next one will move from right to left, and the third will move from the right to left a little faster than the second. All of these layers appear to be the same texture, too, which is kind of cool.

We're also using an array. An array is normally a group of things that can be worked on very quickly. For example, instead of saying that we want to work with Texture 1, 2, 3, 4, 5 and 6 in a row, we can just say that we want Array 1 to handle all of that. This array is going to be a group of textures that act as a background. This way we can make it appear like they're seamlessly moving from one side of the screen to the other.

Now here's the cool thing: We're only creating ONE of the parallaxing background classes, but we're using it TWICE. It's just that one will be moving faster than the other so it appears that we have several different textures.

After my initial confusion and difficulty entering in some of these items, this lesson turned out to be not as complicated as I thought it was going to be. Now I'm looking forward to the next one: Adding enemies. Glee!

Project Moche Episode 2: An Overview

My whole plan in learning programming is to make a few different platform games. I have a roadmap in my head of what I'd like to make in order, but for now I'm only going to focus on the first game.

Project Moche is going to be an open-world Mega Man-style game, like I've mentioned before. I'm going to have eight "Robot Masters," although I'll have to change the name to avoid the wrath of Capcom. I'm going to eliminate bottomless pits because I hate them and they don't make any sense.

I'm not going to go story-crazy, either. That's a really hard decision for me because I really like good stories in games. Right now, though, I'd rather focus on the gameplay and worry about the other stuff next.

The basic idea will be this: You are supposed to infiltrate the fortress of the villain, defeat the bosses, and finally defeat the Big Bad. I'm going to have secrets hidden around the gameworld, like life extenders and upgrades for your equipment.

That's what I know so far. What I don't know is the name of the villain or really anything else about it.

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

So where do the problems with Spider-Man 3 start? Let's begin.

The most outrageous error is near the beginning of the movie. We find that out Flint Marko, the man who will become Sandman, was really the man who killed Uncle Ben. This retcon doesn't work for one major reason: Ben's murder was pivotal to Spider-Man's development. It is, in essence, why Peter Parker is Peter Parker. Changing that little fact not only turns the plot of Spider-Man 3 on a dime but actually negates the pathos of the previous two movies.


Let's revisit the first movie for a moment. Peter Parker lets a criminal run past him because he feels slighted by the victim. Shortly thereafter, that same criminal kills his surrogate father. Because of that, Peter realizes that he has not only the power but the responsibility to protect others.

In the second movie, Peter explains to Aunt May (who was perfectly cast, by the way) what happened the night of Ben's murder in Spider-Man 2's most powerful and best-directed scene. It's the emotional crux of the whole movie, with everything building to that point.

Let's also not forget about Peter's imagined conversation with Ben in the car, where Ben reiterates, "With great power comes great responsibility." That's the theme of both movies, and it couldn't have happened without Peter's selfishness leading directly to his uncle's death.

You may argue, "But the criminal still got away and caused Uncle Ben's death indirectly either way! What does it matter how it happened?"

That may be true to some degree, but there's a great difference in between "This man killed my uncle after I let him go selfishly, holy crap I made a mistake" to "This man accidentally bumped the arm of the man who accidentally killed my uncle because he wanted to take care of his sick daughter." They're worlds apart, as a matter of fact. It takes the defining moment in Spider-Man's development and completely ruins it.

How badly did they ruin this moment? This badly: The first two movies, which were pitch-perfect, are being thrown out and rebooted for The Amazing Spider-Man, which already looks like a trainwreck on wheels. You could say that it's because Sam Raimi left the series, but that's not really fair. Plenty of series have changed directors and kept going. Spider-Man can't. When you ruin the character that much, how can you keep going?

This is where Raimi really shot himself in the foot from the very beginning. Yes, Sandman looked really cool. The scene of him congealing in the sandpit was pretty neat. His special effects looked awesome. But did Sandman work? Even if you eliminated Venom and gave the whole movie to Sandman, he still wouldn't work. Sometimes, what you personally like and the right decision aren't the same thing.

That's to say nothing of the other characters in the film. Harry Osborn is ruined too. Lest we forget, he gets amnesia at the very beginning of the film. The whole "Peter Vs. Harry" plot line we were expecting evaporated in a pile of lazy writers cliches. I mean, seriously, amnesia? If we're going whole-hog with lazy writer cliches, why don't we just put Harry in a snowed-in cabin while we're at it?

That's not the only problem, though. His character arc goes way off the rails in the third film after it was building logically throughout the first two. Let's follow his character arc throughout the first two movies:

Spider-Man 1: Harry competes with Peter Parker, and has everything that Peter wishes he had. Meanwhile, Harry doesn't receive the love and respect that he craves from his father and envies Peter for the family he has. Harry is in love with Mary Jane, and is distressed when Peter ends up with her. Harry thinks Spider-Man killed his father and vows revenge on Spider-Man.

Here's what we're setting up: Harry is constantly in competition with Peter, and once he realizes that Peter is Spider-Man, fecal matter is going to hit the rotating bladed device.

Spider-Man 2: Harry takes over Oscorp and is mad at Peter for "defending" Spider-Man. He makes a deal with Doc Ock so Harry can unmask and kill Spider-Man and finds that Peter is Spider-Man. While contemplating this, he starts hallucinating and finds that his father was really the Green Goblin.

Harry now has the tools to defeat Spider-Man and knows who he is, yet he also knows that his father wasn't a good guy. He still thinks Peter killed his father, true, but now he finds that he had a reason of sorts.

All of these character arcs are logical to some degree. It's logical to assume that Harry would be mad at the person who killed his father, and it's logical to assume that if his father had mental health issues (as it appeared he did), he would have similar issues and start hallucinating.

And now, let's take a wild trip off the rails:

Spider-Man 3: We start off with Harry trying to kill Spider-Man. Harry gets amnesia and starts falling for Mary Jane. His amnesia goes away, and he tries to destroy Peter by forcing Mary Jane to break up with Peter. Peter attacks Harry, disfiguring him. Then Harry, who by this point should be extra mad that Peter disfigured him, forgives Peter after the butler insists that Norman was killed with his own glider. Harry decides to help Spider-Man without reservations and accidentally gets killed.

Where do we begin? We've already touched on the ridiculousness of amnesia, but let's reiterate: Amnesia is a lazy crutch for writers who don't know what to do with a character. It appears that they thought Harry's character arc throughout Spider-Man 3 was going to move too fast and they wanted to slow it down some. That would seem to tell me that the problem is that Harry's arc was moving too fast, wouldn't it? Maybe the whole character arc in Spider-Man 3 was illogical and that's why it needed to be slowed down. I mean, in the end, the amnesia doesn't affect anything. It doesn't factor in to the second half of the movie, so it just appears that it was there as a stopgap.

In fact, the more you examine it, the more it sounds like a screenplay's first draft. The first screenplay I ever wrote had amnesia in it in the first two drafts before I realized that it was stupid. Maybe they just didn't get to the part of the rewrite process where they were able to excise that crutch safely.

Next, Spider-Man is getting a lot of notoriety, and Harry is the head of a major corporation. It certainly wouldn't be difficult to approach a newspaper and say, "Hey, I know who Spider-Man is. I've known the guy since he was a kid." Ta-da! You've just ruined Spider-Man!

Sure, Harry may have wanted to kill Spider-Man instead of just ruining him. However, if Harry wanted to kill Spider-Man, why did he force Peter and Mary Jane to break up? Does that make any sense to anyone? Sure, it hurt Peter, but Harry didn't really have an endgame for that. It seems that his focus shifted from killing Spider-Man to ruining Peter Parker anyway.

Next up, Peter disfigures Harry and the butler tells Harry, "Hey, chill, the guy didn't really kill your father." The proper reaction should have been, "Why didn't you tell me that much sooner?" Instead, Harry immediately starts being super-nice to Peter.

The dude just blew off half your face, Harry. You're telling me that you're going to be buddy-buddy with him all of a sudden? It doesn't matter whether or not he killed your father at this point.

Besides, wouldn't it be apparent from the very beginning that Spider-Man didn't kill Norman Osborn with his bare hands? Spider-Man never used knives or weapons, and it had to have been obvious to everyone that Norman had been stabbed in the chest. If the only evidence that the butler was going on was, "Norman was killed by his own glider," that still doesn't prove anything. Obviously he was stabbed. Spider-Man still could have caused Norman to be stabbed by his own glider, and in fact, he did.

In other words, Harry's reaction is overly simplistic. He veers from balls-out hatred to sneering manipulation to over-compensatingly nice. There's no grey area anywhere in his reactions, and in the first two movies he at least has some modulation.

You could also argue that his extreme mood swings were caused by the serum that his father gave him, but when was Norman Osborn ever especially nice because of the serum? It only ever made him angry, even staring down Aunt May over Thanksgiving dinner. It never made him especially happy.

"You're overanalyzing things," may be your reaction. However, I don't think I am. The previous movies stand up to this type of character study. When you start having to go down the rabbit hole in order to explain a character's motivations and reasoning in order to explain why they did what they did, that's the sign of poor characterization.

While there may be some plot holes based on lousy movie physics in the first two movies, the characters and their reactions are pretty consistent. When characters behave the way they should, you can get away with a lot more in the way of action-movie plot holes. When characters start doing wacky things that make no sense, you simply can't forgive the other missteps in a movie.

Circling back to the beginning of this analysis, that's why the musical sequence in Spider-Man 3 bothers us so much. It's not that it was lame. No one complained that Spider-Man 2 stopped while "Raindrops Keep Falling On My Head" played. In a worse movie, that could have been the Jar-Jar Moment. However, since Spider-Man 2 was good everywhere else, we had no problem sitting for a bit for some character development married to some 70's pop.

Since the character development in Spider-Man 3 was so very, very awful, we had no desire to sit through a dance sequence and a musical number. Instead of focusing on the nebulous things that didn't sit well with us throughout the movie, we instead focus on the one thing that above all others bothered us, or the Jar-Jar Moment.

Click here for Part 3!

Let's Make A Game! Episode 10: I DID IT

I've been going CRAZY lately. I did the parallaxing tutorial and got nowhere for days. Every time I would make the tutorial, I would crash the program or create all sorts of bugs. I finally got fed up with it and was thiiiiiis close to quitting.

I was especially upset because it appeared to me like I had entered in everything correctly. It had to be a typing error, right? I mean, it's not like I could have made a mistake somehow.

Finally, I tried just copy-pasting the code over and got EXACTLY THE SAME THING. At this point, I was ready to chuck my computer through the window and become a Buddhist monk. I set everything aside for a day in hopes that maybe I wouldn't want to murder something when I returned.

I returned to the tutorial tonight and gave it another shot. Maybe this time things would be different.

I opened up by re-doing the animation tutorial. Since I forgot to actually READ what I was doing, I found that I gave this new animation class the wrong name and ended up with a pile of errors. I couldn't figure it out until I went back realized that somewhere I hadn't named my class the right thing. I had given it the name of animation.cs instead of Animation.cs. I knew that this stuff was case-sensitive, but somehow I always forget that when push comes to shove.

Anyway, after I fixed the problems formed by my own lack of comprehension, I got the same weird result as the previous attempt at animation: My character can easily wander offscreen without me wanting it to happen. I decided that I wasn't going to stress about it too much, as I was certain that I had copied the math and information over properly. Besides, the most important thing was forward progress at this time.

I moved back to the parallaxing tutorial and copy-pasted the code in the right places. A deep breath, and a press of Ctrl + F5...

BACKGROUND OMG I BELIEVE I DO HAVE THE VAPORS

Finally! Now that I have the completed result in front of me, now I can go back and figure out WHY it worked. I'm so glad my long national nightmare is over.

This is such a good way to ring in my 30th year. Woohoo!

New Domain!

We're moving, folks! Yes, if you come to downwardscompatible.blogspot.com, you'll still get to us, but we'll redirect you to www.downwardscompatible.com. Make sure to update the RSS reader of your choice or you won't catch any of our future posts.

Thanks for reading!

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.

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.

Let's Make A Game! Episode 2

So if I'm going to make a game, one of the first things I have to sort out is what method I'm going to use to make it. I've settled on a couple of options as to the tools I can use:

1. Game Making software, like GameMaker. An interesting solution. You can do some really cool stuff with GameMaker. For what I want to make it might be the easiest to learn, but it's also one of the least portable. It's Windows-only, and there may be some licensing restrictions in there. It also wouldn't help me learn actual programming skills, which is kind of what I'm shooting for
2. C++. Everyone tells me that learning C++ is a byzantine mess. You need a steady hand and a firm guide. Plus, the amount of knowledge necessary to make a game is crazy, especially considering that I don't want to build crazy first-person wall-hugging simulators with bump-mapped textures and whatever else. In my mind, learning C++ would be like bringing a shotgun to a snowball fight- overkill.
3. Python. The most recent Civilization games are made with Python. Some people think that Python is ridiculously awesome and can do everything you want it to. That may be so, but it appears to be good language to use if you already know C++ and just wish it was simpler.
4. C# with XNA. XNA is designed specifically to make games. XNA is designed to be portable to the 360 and Windows Phone 7, as well as Windows itself. The recent hit Terraria was made with it. If we're using the snowball fight analogy from before, XNA may be akin to a laser-guided snowball-firing sniper rifle. It's possible that it'll do exactly what I expect it to while providing me a good foundation for other types of programming, including C++ and Python if I choose.

I think you can tell which route I'm leaning towards. C# with XNA it is.

As far as art and music, I've decided to make the art and music myself. Whatever game I choose to make will be in the style of an 8-bit game, so it won't be crazy-difficult to make the art. I learned the principles of music at a young age, so the music shouldn't be terribly difficult. I've decided to use FamiTracker for the music because of its ability to do exact replicas of the the NES sound chip and have found it incredibly intuitive to use so far. I'm going to use Photoshop for the sprites, just because I know Photoshop reasonably well and can manipulate it pretty easily at this point.

I'm going to try and be humble, as well. If someone has a better method of doing something, I'm going to use it with their permission. If someone made a really easy way to put together levels or whatever, I'm going to use that as well. However, I'll want to analyze WHY their code does what it does so that I can gain a better understanding of the underpinnings of the language.

With all that being said, if you have a programming horror story, words of encouragement or even words of discouragement, send them my way. I really want to know what people think of what I'm doing here. In the course of making my game, if you see me making a huge mistake, scream it at me. If you want to lend me a helping hand, it's entirely welcome as well.

So I'm Going To Make A Game

Like most people who spend any amount of time around video games, it's always been my dream to make my own game.



This dream actually started shortly after I learned about video games. I was about 7 years old and had barely played 3 or 4 video games TOTAL and realized that I wanted to make my own game. I used to spend hours drawing screenshots for games I would never make. I was very meticulous: Each screenshot had to show a new part of the game, a new level or a new boss. I couldn't make a game idea unless I had a real idea for it.

I made up six games called "Stanley & Marvin" and another six based off of some characters named "R. Williamson & Joe" that were typical platformers. I wish I still had pictures, but those are lost to the mists of time and my disapproving mother who HATED video games and didn't want them in the house.

A few years later, I put together a series called "Hopeless Hero" where the hero would beat bosses and take their powers just like Mega Man and another couple of games called "Super Chicken" that was a shameless ripoff  of Earthworm Jim.

I always strived to put in something that wasn't being done at the time. Another of the Stanley & Marvin games was full of collectibles that would make it easier to beat the game, and if you found a super-secret item, you would find the "true" ending. That's right, I predicted the collect-a-thons of the N64 era when I was 8.

For example, one of my Hopeless Hero games included its own game-within-a-game that would be unlocked after you beat the final boss, a robot named Omicron. You could play as Omicron through his own separate series of levels and beat the "real" final boss of the game who was controlling Omicron. That's right, unlockables. I was 11.

I also put together my own Mario games by carefully copying the sprites out of my Super Mario Bros. 3 strategy guide and inserting them in my new Mario games. One final level I invented was full of EVERY enemy in the game, all in the same level, including "Jelectro," the unbeatable electric jellyfish. One of my games included a final boss that you had to beat before the clock ran out. How did you have to beat him? By ripping the clock out of the ground and throwing it at him, that's how.

Bear in mind all of these games were formulated in my head before I was 12 years old, and you have an idea about how badly I wanted to make a game. By the time I got to high school, I still didn't have a computer, but I had a graphing calculator that enabled me to finally program my own games. With the generous help of a few friends in class, I quickly became one of the better programmers in the class. I threw together an arcade game with powerups, but my crown jewels were two RPGs that I made in a week for each one. They had their own leveling system which revolved around purchasing your upgrades so that the only resource you were worrying about was money.

I went on to make my own engine for graphing calculators to handle movement on a 2D plane while still allowing for random battles. All you had to do was supply the background image and the engine would sort out your movement. I had hoped to use this to make piles of high-quality RPGs quickly and with as little overhead as possible.

The funny thing is that I would come back a few months later to these programs and engines and be really pleasantly surprised. I would look at my code and say, "Wow, how did I figure that out so well? That was a really elegant solution to a complex problem." Never mind that no one else could understand my code (which I understand now was pretty important), I understood it perfectly.

After a while I stopped making game ideas. Whereas before I had the time and the help of other people to help me through programming, all my programmer friends went on to different things while I stopped trying. I got super-depressed for a while and did nothing but play Lords of the Realm II for about a year (still a great game, by the way) until the itch to make a game started taking me over again.

When I wanted to make another game, I kept looking for a magic bullet to make game making easy. I tried DarkBasic, a programming language specifically designed to build games. I never got any farther than putting a logo on the screen for my "company." I even picked up some books that promised to "Teach you game programming in 30 days!!!" Every single one of them felt like this:

Day 1: Create "Hello World!" program.
Day 2: Create the Matrix.
Day 3: Bend the Matrix to your will.

And so on.

I moved away from it for a while and decided to just write about games for fun. It's a heck of a lot easier than making them, right? But that itch, that darn nagging itch keeps coming back. I keep wanting to make a game, and I keep building worlds in my head that can't be realized unless I know how to use the tools.

As I get older, I realize that there IS no magic bullet to making games, or doing anything worthwhile for that matter. You can't just pick up a simple program and expect it to transmute your raw thoughts into gameplay. Learning programming and making games is a slog, but it's a slog that I've decided that I should attempt for a couple of reasons.

First of all, I'm getting older. I'm 29, soon to be 30. I know I still (hopefully) have a long life in front of me, but  the days are going by quicker than I care to notice. Why wait to follow your dreams?

Second, I have ideas. I know ideas are worthless by themselves, but if you combine them with effort and action, you can create great things. Most things in this world start because someone with an idea decided to do whatever he could to make it a reality. That's what I want to do.

Third, I'm coming around to that idea that anything worth doing is going to be horribly difficult to accomplish. I learned Spanish and it was incredibly painful. It was also extremely rewarding. I got married and found it to by incredibly difficult, but also one of the most rewarding experiences in my life. I can't believe it took me almost 30 years to figure that out.

For these reasons, I've decided to bite the bullet and make my own game from scratch with very little prior programming experience and document every second of the struggle on this blog. I may not even make a real game for five or ten years. I'm okay with that. I would be remiss if I didn't at least try, though.

There are going to be a LOT of naysayers that will tell me it can't be done, and that good ideas alone can't make a game. They'll say that I'm going to quit as soon as it gets complicated. I understand that. A lot of people do quit. I'll need a lot of support if I'm going to pull this off, but I'll also need to call on my own (admittedly small) reserves of fortitude.

I'm pretty excited to do this, and above all else, I'm excited to be sharing this with my readers. My sincere hope is that I'll inspire other people to pick up some tools and make their own games. Wish me luck.