Website Design United States, Website Design California, Website Designing United States, Website Designing California

theraje's Introduction to Game Programming

...Or the Appaholic's Ten-Step Program

Hello there, and welcome to my little article about making computer games. I assume that you're reading this because you are at least a little interested in writing games. If not, you might be curious to at least know why you should be.

Assumptions, Expectations, and Hanging Out on Limbs

I'm not going to tell you how to code anything in this article for the simple reason that everybody has their own favorite language, and there's no way I can accommodate them all. I will, however, use what we coders like to call "pseudocode" from time to time, which is a little like code, but more like plain-old spoken language. Additionally, I will give some notes for those who program in Visual Basic 6.0, since that's the language with which I am most familiar.

I'm not going to teach you how to use a programming language either - at least, not in this article. Don't worry, though, if you know how to declare variables and are handy with If statements and the like, then you should be fine.

I'm furthermore going to assume that you're using a language with an IDE and RAD interface. Huh? Basically something with windows you use to do all your work, not something to write console apps (although you can do that later, if you want). You know, a thingy where you can create a window, drag buttons and whatnot onto it, etc. If you don't have such an IDE, then you should still be fine as long as you know how to draw a window with buttons on it and such.

You should not assume, however, that this article stands alone. Rather, it is something that should be used in conjunction with other tutorials to help get you started. As we get to points where other tutorials would help, I'll let you know.

Confused?

Here's a brief list of words you may not be familiar with if you've never coded a game before:
  • Pixel - just a fancy name for one of those little dots on the screen. If your screen resolution is 800x600, it means that your screen has 800 pixels from left to right on the screen, and 600 pixels from top to bottom.
  • Sprite - A collection of pixels that make up a picture.
  • Mask - A sort of "canvas" used to draw sprites that are transparent in some places. Makes sprites look as though they have shapes more complex than a simple box.
  • X/Y - X means distance from the left, and Y means distance from the top, in simplest terms.
  • Raster - Another name for a display that uses pixels.
  • Bitblt - Bit Block Transfer. A Windows API method used for drawing bitmaps.
  • Blit - To draw something on the screen.

Now, let's get started! Yeeha!
Part I: Gearing Up

So you want to write the next big first-person massively multiplayer online role playing game with puzzle elements and lots of processor-hogging special effects, but don't know where to start. Let's pull up to the intersection between fantasy and the real world for a second, so I can smack you upside the head a few times (as there will be plenty of more painful situations down the road) and tell you it ain't gonna happen... not anytime soon, at least.

The chances of your first game being as the one I described is like telling an arthritic man in his late seventies who has never touched a musical instrument that he has to play the guitar like Carlos Santana by the end of the week, and today's Wednesday. My point is that there are very, very, very few exceptions to this rule, so don't count on it happening to you. Ignorance is bliss, but you won't be ignorant forever unless you never bother chasing your dreams of being a game coder.

In order to gear up, you have to change your mindset a little. OK, a lot. Especially if you've never programmed anything before, but even if you have, you still have a lot more to learn. The realistic, practical way to go about it is to program games like Tic-Tac-Toe and Ping-Pong before even trying to program something like Checkers or even Tetris. Like a guitar player, you have to learn how to play single notes before you can play even a simple songs, let alone play leads, chords, etc. Or, as they say, you have to learn to crawl before you try and go winning any track meets.

Anyway, the first thing you really, really need to do is adjust your mindset. It's perfectly OK to dream about your FPMMORPG (first-person massively multiplayer online role playing game, for those of you not into the acrolingo) while taking your first steps. You can think of new ideas, features, and whatnot along the way. Just save yourself time by not starting the coding yet. Don't worry, there's still a lot of fun stuff to do between now and then, so just relax and play around a bit!

Part II: Your First Project

Assuming you at least know the very basics of a language (how to declare variables, use If statements, how to make a simple calculator, etc.), you are well on your way to coding your first game. Hurray! Now it's time for some fun. Think of a VERY simple game, such as Tic-Tac-Toe, or a slider puzzle game. One that you could create using the basic knowledge you've already attained at this point. We'll start by making a Tic-Tac-Toe game.

Before we get started though, keep in mind we're not doing any actual planning yet at this point. I think everybody knows how to play Tic-Tac-Toe already, so let's just do something that works, with no extraneous features to bog us down.

Now, be creative. If you don't know how to make Tic-Tac-Toe using what you already know, think of a way to get it to work with something you DO know. It's all about changing the mindset you have when approaching game development - baby steps, man! If you don't know how to draw a picture of an X onto a form, no worries. We can do that later. For now, let's just get it going as best as we can.

Make a form, and put a command button on the top-left of it. Name it something that makes sense... for now, we'll just call it Space0, but leave the caption (you know, the part of the button you can read) blank. Now, make another button to the right of that, call it Space1, and add another to the right of that one called Space2. Then drop down below Space0 and add Space3, and so on, until you have nine buttons in the three-by-three pattern. Simple enough, eh?

Now, the code! Since we don't know how to actually draw pictures yet, let's be creative and think of a way to get it to work using what we already know. Know how to change the caption of a button? If so, problem solved! We'll just change the caption to "X" or "O" when clicked.

The next thing to do in order to make a working Tic-Tac-Toe game is to toggle to the next player after each click, so that each time you click a button, it will be X, O, X, O, and not just X, X, X. How? Hmm... I think I have an idea! Let's make a boolean (true/false) variable. If it's True, let's draw an O; if false, an X.

Ok, so now we have a program that has some semblence of Tic-Tac-Toe, but it isn't finished yet. If we were going by a plan, we'd see that we still need to implement the boolean before we do anything, as well make sure that if a button already has an X or an O on it, one can't accidently (or otherwise) click it again to change it to the opposite mark. Let's stick to that for now.

Getting bored yet? Don't worry, it all seems pretty lame now, but later on we'll take a look at the hidden lessons this little project provides us.

OK, next we'll code the buttons to use an If statement to see whether the button that was just clicked is blank. Something like this:

Comment: Space0 Code
If the caption for this button is blank, then we'll change it to...

Uh oh! What do we change it to?! Oh no, tragedy has stricken! We have failed in our endeavor to create a computer game! OK, I'm just being silly. If you were paying attention (which no one ever seems to do while I'm talking), you know we made a boolean variable to take care of this. We implement it as such:

Comment: Space0 Code
If the caption for this button is blank, we change it to O if our boolean is True, and X if it is False. After that, we toggle the boolean to False if it is currently True, and vice versa.

Now, we should have a working Tic-Tac-Toe game once we get all the buttons coded. We could leave it at that, but let's code some extras, like a way for the program itself to determine who wins, rather than leaving that up to the players. You could do this in a variety of ways. Try to think of using your own ways to do it (an If statement, a switch/Case statement, whatever you think is best). The basic gist of it though is to determine who has won by checking whether there are three of a certain mark in a row, vertically, horizontally, or diagonally. If all spaces are full and no one has three in a row, the game's a cat. Then, you're done. Congratulations! You've passed the gauntlet!

Part III: Learning from Simple Projects

So, while it appears we didn't learn a whole lot - seeing as we used stuff we already know and all - we actually may have. For one, you got to see basically what is like to code any game. Normally, you'd have a plan written out for the game, a sort of checklist of features necessary for the game to work. You follow the plan step by step, implementing things one at a time, until you get a whole.

You also learned, although perhaps unknowingly, how to improvise a bit. We didn't know how to draw a picture of an X or an O, but that didn't stop us, did it? Such workarounds are handy when learning to code a game. They teach us simpler ways of doing things than we had previously planned for our big huge dream project. That is why we start small - all these bits and pieces help us learn new things, not only by searching for ways to things we have no idea how, but by problem-solving in a pinch as well. When you learn how to solve a problem with what you already know, you have at least part of the battle won already.

Coding games is about creativity - whether the creativity you think you don't have, or the kind that solves problems - you can get by fine with the latter more than the former in most cases. This is just one reason why game programming can help you in programming less fun-oriented programs.

Next, we'll take another look at our Tic-Tac-Toe game, and find out how we can learn the tools necessary for our big game by using a small one. Let's learn something that applies to almost all games - drawing pictures onto the screen.

Part IV: Using Simple Games to Learn the Essentials

This is where we divert a bit, and go looking for tutorials that teach us how to use a particular function; in this case, drawing, or "blitting," a small picture. Almost every game made in the past decade or so uses graphics to represent the goings-on in a game. If you're using Windows, one common way of blitting pictures is called "Bitblt," and it's part of the Windows API. If you don't know how to declare and use API function calls, you might want to pick up a tutorial on that, too (though normally a Bitblt tutorial will include all the necessary setup).

Bitblt has several big, scary arguments. These include hdcDest, dwRop, and several that include the letters X or Y. To put it in simplest terms, hdcDest is the place where we want to draw a picture (where hdcSource is, of course, the source - the picture we want to draw onto the destination). dwRop is a "Raster Operation" - a fancy way of saying how to draw the picture (semi-transparent, opaque, etc.). X is simply how far to the left something is, and Y is how far from the top of the screen (or window or whatever you're drawing on) something is. That's not so bad now, is it?

With Bitblt tutorial in hand, let's make some quick graphics. Open Paint (or your favorite graphic editor) and make a picture... say, 64 pixels high by 64 pixels wide. Draw a blue X in the upper-left 32 pixel by 32 pixel quarter of the image, and a red O to the right of it. Draw and fill a black border around the X and O. Why? We'll see later. Just make sure the X and O are in the top 32 pixels, and leave the bottom blank for now. Too lazy to do it yourself, or don't know what in the world I'm saying? Here you go...

Now, let's put a control on our form to hold this picture. Just put it out to the side for now, to give room for drawing them in the top-left of the form. While you're at it, move all those buttons down, too. Leave at least an area 96 pixels by 96 pixels on the top-left of the form with nothing on it, because that's where we'll do our drawing. Why 96 by 96? Because our X's and O's are 32 pixels by 32 pixels, and there are three rows and columns. Intuitive enough for you?

Next, let's make two more variables - integers called DrawX and DrawY (add any notation or whatever you like, just remember that here we'll be calling these variables DrawX and DrawY). These will hold our destination areas to draw on - DrawX will be how far from the left of the window we'll draw, and DrawY will be how far from the top.

In later games, you might want to add variables for picture widths and heights, too, especially when using images of different sizes. Use these variables to pass as arguments to Bitblt calls.

Going back to our code, let's modify the part where we tell the game to change the caption of a particular button to an X or an O. Add a Bitblt call, and tell it to draw an X on the form in relation to the button clicked. Since we're using pictures that are 32 pixels by 32 pixels, we'll need to change DrawX and DrawY before blitting. We'll just draw the pictures in 32-pixel increments, with no borders (or add a pixel and make it 33-pixel increments if you want a border between each mark). So, try this:

Comment: Space0 Code
If the caption of this button is blank, change it to the current mark, and change DrawX and DrawY (to 0 and 0 for Space0, 32 and 0 for Space1, 0 and 32 for Space3, etc.), Bitblt to the form's hdc, at DrawX, at DrawY, 32 pixels wide, 32 pixels high, from our picture control with our X's and O's, starting from the top and left of the picture control, and draw it exactly like it is.

Your Bitblt call should look something like this:

  • Bitblt frmMain's hDC, DrawX, DrawY, 32, 32, picXO's hDC, 0, 0, SRCCOPY
  • Or this (if you're using Visual Basic 6):
  • Bitblt Me.hDC, DrawX, DrawY, 32, 32, picXO.hDC, 0, 0, vbSrcCopy

NOTE, VISUAL BASIC 6.0 USERS: Be sure to use a PictureBox control instead of an image - image controls do not have an hDC property.

So, we call Bitblt, tell it what to draw on, where to draw it, how big it should be, where our source picture is, what part of the source to draw, and how to draw it. Piece of cake, right? If not, don't worry. Just keep at it, and eventually it will be so easy you could do it with your hands tied behind your back while asleep blindfolded. Some people have even written some pretty... er, "interesting" games while stone drunk.

If everything's done as above, we should now have an app that has nine buttons which, when clicked, draw an X on the form, in a location that relates to the button that was chosen. To change it to draw X's and O's, change the nXsrc/nYsrc (the two variables just after the source DC) to 32 and 0, respectively, when drawing an O. When combined with nWidth (which is 32 here) and nHeight (also 32 in this example), it tells the program to blit a 32 by 32 area of the source picture, starting from the 33rd pixel (keeping in mind that the first pixel is 0) from the left. So, to draw an X, which is at the very top-left of our source, we set nXsrc and nYsrc to 0, and to draw an O, which is 32 pixels to the right, we change nXsrc to 32. Since the O is at the top, we leave nYsrc at zero.

Neat, huh? This comes in handy later on when you want to make animations, since you can have all the animations for a particular object in the same bitmap.

When you finish this, you should have a working Tic-Tac-Toe game that draws X's and O's on the form instead of just changing the captions of buttons.

This illustrates how using a small program can help you learn things that are necessary to writing larger, more ambitious games. You might've had trouble getting Bitblt to do just what you wanted at first, but by using this game as practice, you'll have no problem getting it running once you start on a later project.

You can accumulate these skills by writing new games and incorporating new features into them, just as we have before. Start writing a new game using everything you've learned so far, and add a new feature that you haven't used before - such as sound, keyboard input, etc. You could even spice things up in our Tic-Tac-Toe game by playing sound effects when a button is clicked, by making the marks move to their locations, and by making the marks animated (by making them "dance" or something, be creative).

Remember how we left the bottom portion of our source picture blank? Try this as an exercise - draw the O and X below in the blank space, exactly the same as above, but in all black. Leave the rest alone. Take this as an example:

What we did was make "masks," which is another name for a sort of "canvas" where we can draw parts of a picture, but not others. Edit the portion where you made your bitblt call, first drawing the masks with the dwRop SRCAND (vbSrcAnd for VB6 users), then in the next call, draw the old mark (or "sprite") in the same place, but with the dwRop SRCPAINT (or vbSrcPaint). Instead of having a black square surrounding each mark, it should have whatever was underneath each mark still there. This way, you could make a 96x96 background to draw your sprites onto. Cool!

Before long, you'll be writing games that will entertain people the world over. Or at least you'll have something fun to play with.

You can also cross certain things over from gaming to applications. For instance, a text adventure game where you type two- to three-word commands would be great for learning string parsing. That's how I learned everything I know about string manipulation.

Part V: Learning to be Creative

I sometimes grow weary of people who would like to code a game, but say "Well, I'm just not creative enough." I don't buy it! The misconception about creativity is that it requires a natural ability to come up with new ideas. Again, let's change our mindset. Creativity isn't so much coming up with new ideas, but looking at things in a different way.

So, let's say you have an itch to make, oh, let's say a mini-golf game, because you don't know of any out there. Then you find out your friend has already done so. So what? Start absorbing things around you - for instance, if you like emoticons, make a mini-golf game where the players are all just round balls with faces on them that do funny things, like stick their tongues out at you when you miss, or make a big grin when you sink the ball. Have to do chores? Make a course where a lawn mower rides around and shreds the ball to pieces if it comes in contact with it. There are literally billions of ideas all around you. Being creative isn't doing something new - it's doing something old in a new way. Vampire Swamp Buggy Racing, Falling Bouncy Sheep Race Betting, Attack of the Blue Stickmen... the possibilities are virtually endless!

Part VI: Planning

When you come to coding a large game, or one that is atypical, you'll need to plan things out first. For instance, you'll need to make a few checklists, divided into what must be done, what would be nice to have but aren't required, and some things you might like to add later on. This way, you can keep track of what you're doing. Not only does it help you keep from getting lost, it also gives you a sense of accomplishment each time you check something off the list - especially the more difficult, laborious tasks. Also remember to write down ideas you have for implementing such-and-such feature to help you remember what you're planning to do, as well as possibly find some things that won't work well together.

First, start off with an idea of what kind of game you want to make. An adventure? A simple RPG? These two are perhaps the easiest and best to start off with, as long as you keep it reasonable. An RPG, for instance, can be as simple as walking around, exploring, and getting into the occasional random battle. Or, it can be as complicated as having weapons with various characteristics, a backpack that as it gets full can weigh so much that carrying it slows you down, armor that can take damage and break, and characters with several different statistics. In the beginning, just make a checklist for the essentials - getting a character to move around, making areas that can and cannot be walked over, handling random battles (if that's the kind you're into), and, if you want, talking to characters. Save all that other stuff for the "would be nice, but not critical" list.

By tackling a gaming project from that angle, you'll see that even if you don't finish a game and have it be the way you wanted at the beginning, you'll have something playable. You'll also learn better ways of doing things as you go along. Sometimes the biggest challenge is just getting a game that plays, let alone adding all the extra details. Chances are that you and your friends can still enjoy it without all that other stuff. Starting and completing a game in a way that makes it at least playable is much better than starting a game and never being able to play it. I learned that the hard way. Multiple times.

Another recommendation is to keep a separate folder for each day you work on a project. This is a good, easy way of keeping a sort of journal of your progress. If it's a small game, store them on floppies, and if you have a large game or one that you've been working on more than a few weeks, burn it onto a CD. This way, you can not only protect your precious work from unexpected but inevitable hard drive problems, but you can also save room on your drive for other things (like all those ill-gotten MP3s, for instance).

Part VII: Polishing

When I finish a game, I usually don't upload it for a week or two. Why? Because even with planning, it's easy to forget to add some finishing touches, like adding an About box to your program, thinking of a simple feature to add that would make the game better, etc. I also use this time to look for things like spelling errors (both in-game and in the documentation), ways to improve the graphics a little, things like that. This is one of my favorite parts, because I get to play a working game, while looking for simple little touches I could add to make it just a tad better.

Part VIII: Research

Once you get a few games circulating the 'Net, it's time to start moving on to things more like that big huge game you thought you were going to have done by now. This is an opportune time to do some heavy searching on methods for achieving more efficient games, special effects, game libraries (such as DirectX and OpenGL), online play, whatever you want to do. Look every place you can find, harvest as many tutorials as you can get your paws on, read articles, learn the appropriate terms, all that jazz. Unless you begin to notice that your hats don't fit anymore, you can never have too much information (although you may just be in need of a haircut).

A good place to do research is GameDev.Net. They have game programming information by the truckload.

The best part about being a game programmer is that playing games is actually considered research! If you're wanting to make a simple RPG, go to a download site and look for small shareware RPG games. Play it, take what you like about it, and make your own game based on some of those ideas, combined with your own ideas, and even ideas from other games. You'll end up with a unique creation you can truly call your own.

Part IX: Releasing Your Work

Once you get your game playing well, have everything polished-up nicely, and are ready to unleash your unique creation upon the world, it's high time to find a place to present that sucker.

A lot of people will spring for their own domain name and server, as I did a few years ago, when I still had the money to do so. Don't worry, though, you can get by with a decent setup without liposuctioning your wallet.

If you want a good starting-level setup, I would register a domain name with GoDaddy, and get a year's worth of hosting from VM Domain. With bare minimum, you can get your game(s) up for a year for under $30 US. Sweet!

There are some considerations to... er, consider. For instance, transfer. You need to work out how much traffic to expect, because if you go over your transfer limit, you'll usually get charged outrageous amounts for it (although VM Domain is the best I've seen as far as leniency when going over your limit, as well as not charging you an arm and a leg).

What I do is total the size (content, not space) of the entire site - pages, graphics, and games - and count that as a visit. Then I divide the transfer limit by the visit size to get how many visits I can support. For instance, with a site that is 2 megabytes total content, and a monthly transfer limit of, oh, let's say 10 gigabytes, I can safely have about 5,000 visits a month. The actual number will probably be more, since most people won't take the time to visit every single page of your site or download every one of your games (sad, but true). Fortunately, for beginning game programmers, such a site will be much smaller than two megs, so you could do well with just a ten-gig transfer limit.

Free servers are a great alternative to paid hosting when trying to get your games on the Web. However, there are a few pitfalls you should be aware of. First is that the transfer limits are usually pretty low, and when you go over, the service usually just shuts your site down until the end of the month. If that happens very often, they may just take your site down completely. The nerve!

Some more bogies include limited storage space, disallowance of remote linking, pop-up and banner ads all over the place, and copyright issues. For instance, the GeoCities TOS states that anything you upload to their free servers becomes their copyrighted material. Every time you upload one of your precious games to their free servers, you're signing over your intellectual property rights to someone else. Be sure to actually read a free hosting service's TOS before uploading anything. I know it's a pain, but it's better safe than sorry.

Part X: Keep Your Chin Up

One thing that's easy to forget is that you'll often be discouraged and frustrated when trying to write games. Just remember that no one ever said game programming is always easy, just that after doing it a while, certain things get a lot easier.

One of the best ways to keep yourself going is to find a game programming community with nice, helpful, knowledgeable people. These people can get you out of a jam better than anything. They'll often be able to at least give you some hints as to how to do something, and if you stick with it long enough, it will usually be enough to get you going. They can either help you on your way to doing what you're doing, or say "it's easier if you do it this way," or "that's not how you do it, try this instead." They can even give you a reality check when you need it, in case you're getting too far ahead of yourself.

Well, hopefully that's enough to get you started, if nothing else. Remember, game programming takes a certain perspective. That, combined with the treasure troves of information online, as well as getting to know other game coders, should be enough for you to be well on your way to programming enjoyable games for years to come.

Author Information:

Clint V Franklin

http://theraje.programmers-corner.com

Comments:

Add your comments here.

Name

Comment

You can also send feedback to feedback@programmers-corner.com

There are currently no comments available.

 















 


© 2008-2009 dotnet4all.com