So Where's "Let's Make A Game?"

So you might be asking, "Where's the 'Let's Make a Game' feature? You gave up, didn't you? I knew it! I totally called it."

Slow down, partner. I didn't quit. A variety of factors led to-

"See! He's making excuses! I knew he would quit all along! He's just a-"

*GUNSHOT*

All right, now we can talk. Let's Make A Game didn't go away, but right now we're in the process of buying a home, which takes up a lot of time. My evenings are pretty much occupied with paperwork and buying supplies.

Plus, I don't like what I'm working on. I feel like I'm polishing a turd. I don't feel passionate about a dumb little shooting game. I want to make something that's more personal and, frankly, fun. I have a few ideas in mind, but nothing solid yet.

I also have to get out of the mindset that I need art assets and music RIGHT NOW or I can't program. Heck, I can make a game with rectangles and insert the art later if I want. I don't even have to insert art if I don't want to and just make it "Rectangle World."

Crap. I have to copyright that quick.

Let's Make A Game Episode 23: Falling Away

So here's what we've decided to do. First, we're going to take control of the player away after they've died. That's easy enough to do:

player.Update(gameTime);

// Player only has control if he's still alive

if (player.Active == true)
{
// All our stuff

Next, though, is the tricky section. What happens to a ship if it gets hit in mid-air? It slows down and falls to the ground, correct? Ergo, we should decelerate the ship and drop it by lowering its X and Y values like so:

player.Position.X -= playerMoveSpeed;
player.Position.Y += playerMoveSpeed;

It's not working quite right, though.  I've placed it a place that doesn't checked often, the UpdateCollision area. It actually only updates this once, which means that after the ship gets hit, it twitches on in that direction instead of continually falling.

It's better to put this in the UpdatePlayer area, where this will run along with the rest of the loop. We'll do two things in this area:

1. We'll only have MathHelper.Clamp run when the player is active, first of all. Otherwise, it looks silly to have the ship hit the bottom of the viewable area and then stop moving, right?
2. We'll create this:

    if (player.Active == false)
            {
                player.Position.X -= playerMoveSpeed;
                player.Position.Y += playerMoveSpeed;
            }

So now we're actually making the ship fall off the screen when it blows up. We still have to work out some kind of counter to start the game over, though, or else the ship will continually falling in perpetuity.

Let's Make A Game Episode 22: Blow'd Up

Where we left off last time, we wanted to make the game end somehow. As it is, once you lose all your health, the score resets. That's all. There's not even an indicator that you lost, no "A LOSER IS YOU" words on the screen or anything.
One of the ways we can resolve this is by having a visual indicator. I would like there to be multiple explosions over your character to let you know that you just got BLOWED UP GOOD. The most simple method would be a simple for/next loop:

For (1,3)
{
    AddExplosion(Player.Position);
}

Except this method sucks. Since the game loop is so fast, the three explosions sound like one. There's no delay. If we trim it back to one explosion, once again, it happens so fast that the player may not even realize that they lost.

Another option would be to create the explosion and then toss in an Initialize() call to restart everything, but that doesn't seem to work very well either. Once again, the loop is so fast that you can't even tell that the explosion happened. There has to be a better way.

Let's Make A Game! Episode 21: A More Elegant Kludge For A More Civilized Age

If you'll remember, my character was accidentally wandering off the screen. I slapped in some code to keep him in the right place, but it wasn't very elegant.

It occurred to me: There's already a function for clamping values within a valid area: MathHelper.Clamp.

I fiddled with MathHelper.Clamp a little bit. First, I did this:

player.Position.X = MathHelper.Clamp(player.Position.X + 50, 0,GraphicsDevice.Viewport.Width - player.Width);

That was pretty stupid of me. It just made the character rocket across the screen every time it went through a loop.

I realized that the value was ALREADY built in to this function. How could I be so stupid? It's right here:

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

Changed that to 50. Boom. Done.

Another thing I changed: I decided to switch my sounds. When a character gets hit, he screams bloody murder but when he dies, he just lets out a little groan. I switched the two sounds and renamed them appropriately so I could keep track of them. Much better (and less annoying).

Next up... making the game end.

Let's Make A Game! Episode 20: Kludges And You

I'm just starting programming and I'm already taking the easy way out.

Here's the problem: My character keeps wandering off the screen to the left and on top. It doesn't matter what I do. I've copied the code directly from Microsoft and still get nowhere. It seems it's an issue with the animation somehow, since I don't have this problem without the animation active.

I have two ways I can handle this:

1. Figure out what's wrong with the animation and fix it. Dig into the numbers and break my brain against the desk until grey matter oozes out and I'm forced to start crying.
2. Say "screw it" and insert some kludged code to fix the issue.

Guess what I chose!

Right above my MathHelper.Clamp call, I tossed this in:

// Fix the "animation off the screen" problem temporarily

if (player.Position.X <= 50)
player.Position.X = 50;

if (player.Position.Y <= 50)
player.Position.Y = 50;

No more off-screen character! Everyone is happy, although there may still be an underlying problem with this animation. Not sure yet, so it's just a temporary fix (that will probably become permanent knowing myself).

I've also done a few extra things: I was tired of not necessarily knowing when I had died. I decided to toss in a special scream when the character dies and an explosion over the top of the character. It's not pretty, but it's something.

I would like to have the ship move onto the screen to start, have several explosions in a row, and then vanish when the character dies. Not sure how to do that yet. I suspect I'll learn.

...And Panic Sets In

I'm starting to freak out a little bit.

When "learning programming" was still a nebulous concept for me, imagining how I was going to make my game was a fun mental exercise, nothing more. Sure, I was going to make a game someday, but it was still a ways off. It wasn't something I was going to be starting today by any means.
However, learning XNA is easier than I thought it would be. I'm understanding the concepts easier than I assumed I would, and I'm starting to realize that soon it's going to be time to put my money where my mouth is. It's making me nervous.

When you think about all the work that goes in to a video game: Planning, level design, character design, programming, sound design, marketing, fine-tuning... it's overwhelming. I'm trying to break it all in to chunks mentally, but it's not working.

Of course, when I start freaking out, I start thinking of other projects I can do instead. Maybe I could write a book, or make an album of chiptunes, or do this, or do that. Anything to keep me from actually making something big or having to commit so much time to something.

I have to keep on reminding myself that nothing worth doing is easy. This isn't about "having fun," although making games can be like that. This is about doing something big that I've always wanted to do. I just need to suck it up and do it.

Let's Make a Game! Episode 19: Timing Is Everything

Well, that was easy enough.

Since we already had the variables in place to fix the timing of our weapon, it was merely a matter of throwing in an if -> then command. Done and done.
So now, I thought it would be a good idea to give some indicator to the player that their ship has been damaged. Otherwise, the only way you know if you've been hit is by looking in the upper right-hand corner and seeing your health drop by a bit. There's a few things we could do:

• A physical cue. Your ship could shake or something like that.
• An audio cue.

The audio cue is easier to make, I think. Plus, while you may miss the subtle shake of your ship, you can't avoid a sound that makes your character yell, right? I found a freeware sound of someone screaming "Ow," so let's see if I can toss it in.

I copied the file into the directory, and created this variable:

// The sound used when the player is hit
SoundEffect playerHit; 

I've loaded the content like this:

// Load the "playerhit" sound effect
playerHit = Content.Load("sound/ouch");

And then placed the reference in the area it should be:

// Play an audio cue to show us we got hit
playerHit.Play();

When I run it, it says that the file "Sound/ouch" doesn't exist. How can that be? We've loaded the content, right? It's in the right folder, correct? That should be all we need to do, I would think. Yet, we're getting nothing. Huh.

I fiddled around in the MSDN looking for answers but couldn't get anywhere. Finally, I noticed this little guy sitting in Visual Studio:

Figuring I didn't have anything to lose, I navigated to the folder where I had saved my "ouch.wav" file and drag-and-dropped the file into this Sound folder.

I run my program...

And it works! My character now screams every time he gets hit! Woo-hoo! I've made someone yell in pain repeatedly!

Let's Make A Game! Episode 18: Laser Overload

Seriously, adding score and health to this game is EASY. All we did were declare a few variables, loaded a font, added the score up and put it on screen. That's it. I could drop the code in this post, but it's seriously easy to do. It's not even worth discussing.
However, now we're getting into uncharted territory. We have two choices: Keep messing around with this program or move onto the next one. I'd like to keep messing around with this program for a while, I think. Not too long, because this isn't that exciting of a program.

The first thing I'd like to do is fix the shooting. You have to shoot each enemy several times before you kill it, and your character automatically shoots. There has to be a better way of doing it.

I think we should do this: Each bullet is enough to kill an enemy, and the space bar/a forward swipe of the finger shoots. Why? Well, once we start creating a difficulty curve, having each enemy take several bullets is going to be problematic. We also want to turn off auto-shooting because we can seriously make this game ten times better when we give that power to the player.

I've also decided to download a fresh copy of the code and create a backup. If I screw up the code too badly, I can always go back and do more stuff.

Quick Note: This fresh copy of the code has the main character off the screen as well. Ah well. I'm not going to stress about it.

So here's the code I added underneath the UpdatePlayer() method:

// Shooting fix... only fire when we say so

if (currentKeyboardState.IsKeyDown(Keys.Space))

{
AddProjectile(player.Position + new Vector2(player.Width / 2, 0));

// Play the laser sound
laserSound.Play();

}

I also went ahead and removed the autofire function. Let's see what happens when we run it.

Well, it only shoots when we press the Space bar, but it shoots too much. It's HILARIOUS, don't get me wrong, but it's a little sloppy. We're on our way, though.

Let's Make A Game! Episode 17: The Sound and the Fury

Putting sound into our program is a lot easier than I thought it would be. I thought we were going to have to create new classes and all sorts of other things to get it to work. Instead, it's just naming the variables, loading the content and playing the sounds in the right places.
Since we're in the home stretch, here are a few things I'm going to be experimenting with once we're done:

• Changing out the sounds
• Changing out the sprites
• Instead of having the weapon autofire, have it fire only when I press the space bar
• Create a difficulty curve
• Create a title screen

There's also a code sample for a platformer available for download. That'll be next on my to-do list after I start breaking up this program and making it do crazy things.

Let's Make A Game! Episode 16: BAYSPLOSION

I'm now in the part of the tutorial that discusses making explosions. I threw it all together and ended up with no explosions. Now, I've done all this stuff before. How come it wasn't working? I went back through and looked at my code.

The instructions were thusly: I was supposed to put this code:

// If not active and health <= 0

if (enemies[i].Health <= 0)

{

// Add an explosion

AddExplosion(enemies[i].Position);

}

In the UpdateMethod() method. I was sure I had done that, but I put it in the wrong place. I put it in the right place, and we now have this:

BAYSPLOSIONS

So this wasn't the most exciting episode. I'm sorry to disappoint. However, it's exciting for me because I noticed a problem, went through and figured out where it was. That's exciting for me. I'm excited.

Let's Make A Game! Episode 15: When Enemies Collide!

Collision detection in 2D games is handled surprisingly easily in XNA.

A brief explanation of what collision detection is: Games are built on things colliding. For example, it's important to know that Mario has touched a Goomba and also from which direction. It's important to know that Mario has hit a brick from below. It's important to know when he's free-falling. That's what we call collision detection: Making sure that two objects, be they friend or foe, are or aren't touching.
In all the programming I've done, I've had to do those calculations myself. I've had to tell the game, "Hey, look. My character is X pixels wide. I need you to measure from the bottom left corner of the character (or whatever), add X pixels, and then tell me if there's anything touching my character." It's not unwieldy, but not a lot of fun either.

In XNA, you're working with rectangles. Here's the code:

// Do the collision between the player and the enemies
for (int i = 0; i
{
rectangle2 = new Rectangle((int)enemies[i].Position.X,
(int)enemies[i].Position.Y,
enemies[i].Width,
enemies[i].Height);

// Determine if the two objects collided with each
// other
if(rectangle1.Intersects(rectangle2))
{
// Subtract the health from the player based on
// the enemy damage
player.Health -= enemies[i].Damage;

// Since the enemy collided with the player
// destroy it
enemies[i].Health = 0;

// If the player health is less than zero we died
if (player.Health <= 0)
player.Active = false;
}

}

BOOM. Rectangle1 gets assigned to the player. Rectangle2 is assigned to each enemy in turn, and the game is basically asking in turn, "Hey, Enemy 1, are you and the player intersecting? No? Well, what about you, Enemy 2? No? OK. Enemy 3? Yes? All right, now we'll adjust the game accordingly."

It's not a perfect system, because if your character isn't exactly a rectangle, it may end up in some people saying, "Hey, that didn't really hit me!" Still, it's a heck of a lot easier than doing all the calculations ourself. Thanks, XNA!

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.

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."

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.

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.

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!

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.

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!