I'm going to take a quick break from the graphics programming stuff to talk a bit about all the components that make up a "simple" game. This won't really be too technical, but rather an overview of all the parts that make up an interactive system.
Oh, and take note that some aspects of games I mention below may or may not be necessary for particular types of games, but in a nutshell, most or all of what I talk about will be needed in some capacity.
So, what makes a game, a game anyways?
Interactivity. Without this, the "game" would just be some sort of animation maybe mixed in with some sounds. If you want that, watch television or youtube or whatever. While this may seem like a "duh" kind of moment, it also identifies one of the key aspects of making games -- programming how input affects the game itself.
If the game is on a computer system, this could be a keyboard, mouse, pointer, gamepad, or really many other components. The standard to consider is keyboard and maybe a mouse. With these days and touchscreens and mobile devices, you will likely need to consider touch interfaces as well. Where did the user touch the screen? How do you keep track if the screen is already touched and another touch comes in, maybe from another finger?
Ok, we got input out of the way, but what about what happens when input occurs? This is input response. The timing of when you handle player input is a bit technical so we'll skip those details, but suffice to say you will likely want to keep track of what new input has happened until you handle it, then discard that information because it is now "stale". For example, in a platforming game, you probably want to move the player character to the right if a "right button" is being held down, then stop moving right when the input is no longer held down.
Take note of the usage of "if" and "then" statements above, because that is the beginning of how programming works. Check for some condition to be true, then do something... or if it is not true at some given time, do something else (maybe just ignore the condition itself).
Input is covered now, at a high level. Processing that input is now covered. But what about stuff that happens not in response to input? This is something called the game loop or update cycle. It is the lifeline of your game's logic. See those clouds floating around in the background? They need to know how to move, when to move, and how much to move over some given amount of time. This calculation is done during your update cycles.
The fact that you can actually see some graphics is also important. Actually taking your data about the cloud and drawing it to the screen is handled in something called a render cycle.
Think of it this way, you have two people in a room, a mathematician and an artist. The math guy calculates all the algebra involved with positional data about the cloud, then hands his results over to the art person. The art person doesn't have to care how the math guy got the answer, but instead only needs to know where the cloud is now. Once the art person looks at the answer, they draw the cloud in the right spot.
This is a simplified analogy and it can get a lot more complicated (and more efficient), but we'll save that discussion for later.
Ok, so we can do input, respond to input, do updates about data, draw data... now what?
Well, there is more.
Two major topics that we haven't covered yet is physics and artificial intelligence.
Physics is already tough as it is, but it gets worse in games. There are two major categories to consider that are part of the aspect called "physics" in games. This would be collision detection and collision response.
Collision detection is figuring out when and where interesting things collide with each other. How do we know when this happens? This is detecting collisions. This topic is quite complex and can require a bit of ingenuity to "get right". Honestly, this topic can get pretty math heavy, so if you're interested, you should probably research this as a separate topic. Fortunately, however, computing systems don't like to do a ton of complicated math (just like us!), so if you can think of ways to do as little math as possible, the better.
The "easiest" detection to find, and think about, is how do I know when a line hits another line? Yep, we just went back to basic algebra. The question of "when" may be misleading, so let me rephrase, where do two lines intersect, if ever? If they don't collide (maybe they are line segments?) we successfully detected that the two interesting lines, or line segments didn't collide!
Well, if you take that example and draw four line segments such that it makes a box, we could deduce that it is now possible to detect when our collection of 4 line segments may or may not collide with another collection of 4 line segments. This is the basics behind Bounding Box collision detection.
Collision response is the other complicated topic under physics. If we detected that something collided with each other, how do we want to handle it? Does it bounce backward? Does it pass through? Does it accelerate in some arbitrary direction? Does it lose speed? Does it lose acceleration? Does one of the objects break? Will it cause explosions? Do I take damage? There are a lot of possibilities and I definitely couldn't list them all here, in fact, for the most part, your collision response will be dictated by your game design. The important part is to detect when objects collide, then change something in response. If nothing changes, there may have been no point in detecting the collision in the first place. This is another complex topic of interest.
Think about it this way, if we have 100 game objects sprawled out around the screen and the player fires a ball up from the lower left corner of the screen, straight up, how do we do this?
Well, the "easy" answer is check all 100 objects to see if the ball hits any of them every update cycle, but this isn't good, because every time our game logic runs through we will have a lot of misses (probably 100 misses almost all the time!). This is largely wasteful and actually makes your game run very terribly. The better idea is to only check certain objects to collide against. There are many strategies to consider with this, but some of the easier ones to think about is -- well, what if we only considered collision against the objects on the left side of the screen since that is where the ball is. Moreover, what about the bottom left side of the screen since that is where the ball is.
Again, there are a lot of methods to consider and strategies to think about with how best to consider detecting, and handling collisions. Unfortunately, there really isn't any universal "best" way to handle this problem, so you will need to think about it, and research, then think about it some more.
Oh, and it should be mentioned, that if some game object doesn't have any collisions, then it should move, based on it's current trajectory (vector) and speed (magnitude). Sometimes, though, collisions aren't always obvious. Think for example a platforming game, and your character is on the ground. There is a collision at play, but since gravity is always at work against your player, how do you change the player's movement? Down? Nowhere? Left or right?
Collision detection and response, good times.
Sound. Really there isn't too much to be said about sound at the high level. It can be a real pain to figure out if you're doing the actual sound programming, but for the most part, game designers and/or programmers will only need to really worry about when to play a sound effect, or play background music. This is likely going to be a response during collision response -- ie, the ball hits an object in the sky, when that happens, make a popping sound, and also blow up the object and ball.
Artificial Intelligence. Or "AI". Your game can be pretty and do all this other stuff great, but what about something that challenges the player. Something that thinks like a human, acts like a human, but isn't really a human... ya know, something like a monster. Well, this is also a hefty topic, but really, as a developer, you will need to consider exactly what kind of AI there will be in a game. Some games don't even need an AI to "play against"... think of "Tetris", puzzle games, games that pits the player versus a geographic maze, things like this.
Assuming you do want to have an AI in to your game, you will need to consider several broad things (none of which I'll elaborate on since this is an intro article). First, does the AI respond to player input? How does an an AI agent (say, a monster) idle when not challenged directly by the player? Does the agent follow the same physics rules as applied to the player? Does the AI "know" hidden information that the player doesn't?
Of course, these are large questions to consider, but one of the more technical one would be what AI algorithm will be used for various circumstances. For example, you probably don't want to implement AI that would require a supercomputer to process. How do you limit what the AI can do with what it has to know, versus what its capabilities will be? Also, consider if the AI is even conquerable by the player? For example, in the classic game, "Pong", where there are two paddles on the screen and a ball. The AI could control the other paddle. It would be possible to have the AI simply "set" their paddle position to always be in line with the ball in play, thus making it completely impossible to score against. This is, of course, assuming your collision detection and response of the ball on the paddles is working correctly and it sends the ball back at you when it collides!
Ok, that was a lot of stuff to think about without getting too much in to the finer details. I may have left some things out, so by all means feel free to let me know if I missed something and I'll go over it sooner or later.
Also, if you're new to game development, I'd heavily recommend looking in to any game engine to help you along the way. It will speed up your production on a massive scale. Yes, you won't get all the "low level" stuff -- that has its time and place in the world, but if you just want to see your ideas come to life quickly, pick up an engine, learn it for a couple of weeks and months, and see what happens. If you can make some sort of sane game using the components reviewed above with a game engine, you can then challenge yourself to "go deeper" and try again. These same concepts will be present, but will be completely on you with how it gets accomplished, and it will be no easy task.
As a final note, for the nit-picky, I made some assumptions about software architecture to convey certain points about how certain game logic would work (specifically with the update/render cycles). Some of this information may not be relevant if you're using a game engine as some of this will be abstracted away and you won't have to worry about it. Rest assured that this information is still relevant because the engine is using these concepts without you knowing about it!
No comments:
Post a Comment