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.