http://steve-yegge.blogspot.com/2008/12/fable-ii-arguably-better-than-getting.html
Busywork jobs only exist in MMORPGs to limit per-player CPU usage. They’re not fun. “Innovatively” bringing them into a single-player game was just flat-out brain damaged.
This is Zynga’s whole business model.
Have a nice extended vacation? Time to get our noses back to the grindstone and add some things to our game to make it more of a “game” and less of a “slideshow”. I think it’s as good a time as any to introduce a control scheme, and something we can directly interact with – a ship! A player! For now we’ll focus on the keyboard as our prime method of control.
Hey all you Allegro guys! You may or may not have a problem in your project where it seems to flicker – this is casue by it attempting to clear and redraw the screen a hojillion times per second. We can solve this using a technique known as double buffering. Remember how we were drawing directly to the magical “screen” bitmap before? We set up another bitmap, the same SIZE as the screen, and draw onto that instead – and then once every frame we copy that bitmap to the screen. That way we don’t redraw the screen more times than necessary. Ready? Let’s begin!
Remember our last lesson? With putting things on the screen? Good times, good times. If you’re an astute observer, you noticed that to actually put the image on the screen took some strange commands – blit() in Allegro, and spriteBatch.Draw() in XNA. They each took a number of pieces of information to do exactly what we wanted them to. Wouldn’t it be nice for me, and for you, if we had a way to use the same command in both languages to do the same thing? Fortunately, we do – we’ll wrap them up in a Function.
Still got your sample project around from last week? Good. (If not, go back and make a new one – and hang on to it this time.) We’re going to make our very first steps toward building our Space Invaders game – we’re going to draw something on the screen. Granted, it may not SOUND like much of a step, but as per the title, you can flag someone down and yell “Hey look!”, with some proof that you’re finally making a step toward makign your first video game.
I think it’s time we finalize our Space Invaders design document. This will probably look a bit overblown at first, but the more detail we have, the less we have to guess when we’re putting together our code. As with the entire series of tutorials here, feel free to deviate as much as you wish – but make sure you HAVE a solid design, and don’t deviate too much from yours. I also cannot say that this is completely immutable – it’s subject to change as we go along, or discover things that don’t work (or possibly work better).
So what exactly makes Space Invaders? (Or, in my case, Star Attackers?)
There are a wide variety of “development methods” out there, and a lot of them have their very useful purposes in a large team or corporate environment. Odds are that if you’re reading this blog, you’re not a large team or corporate developer – or at least you aren’t for the sake of learning to write games. We’ll talk about the two main categories of approaching a game’s design today, and see if you can figure out which one I give my stamp of approval to. After all, following SOME sort of process is the only way to get from “crazy idea” to “working, implemented crazy idea”.
The very first computer programs, for gigantic systems that filled entire floors of buildings, were essentially just giant equations. Whole basements were full of nothing but extremely large, extremely precise calculators. The notable thing about these old systems is that they were one-pass – you gave it some input, you started it running, it gave you some output and then it stopped. Games tend to follow a slightly different model: You start it, you give it input WHILE it is running, it changes what it’s doing accordingly, until you actively TELL it to stop. How do we achieve that effect in our program?
Loops, of course.
At the very heart and soul, programming a computer is nothing more than math, math, math. Don’t let that frighten you away, though, we’re not talking ridiculous amounts of super-calculus or anything (at least, not yet) – it’s all the same skills you use to balance a checkbook. Programming languages exist almost for the soul purpose of making it easier to read and understand, and keeping you as far away from the “nuts and bolts” math that drives a computer. However, we do have to make certain concessions to the machine – one of the important ones is deciding HOW to store information.
If we’re going to write a video game, or a program of any sort, we’ll need to look into some of the tools of the trade. I’ve worked in several different environments, and you are going to end up doing the same (trust me), but for now I’m going to pick out two specifically that I’ve grown strikingly familiar with. If you install either of these two you’ll be able to follow along fairly easily with the tutorials I give, although I’ll be descriptive enough that with some finesse you can work in whichever you like. So, if you have your favorite programming environment set up, you can probably skip most of this post and come back toward the end.