So you want to program games?
Pages: 12
closed account (S6k9GNh0)
NOTE: This article does not start you on game programming!
The Beginning:
A lot of people who want to be video game developers seem to misunderstand what it means to develop a video game. So let me ask you a ironically rhetorical question. How are video games made?
WOH, you went to fast with that question! Let's start at the basics. What is a video game? A video game is a sequence of happenings that interacts with someone (or something) to entertain someone and is projected onto a video screen. This sentence opens up about 5 different questions which branch which I'm going to cover all in this post. Enjoy.
Chapter 1: The Definition
By sequence of happenings, you may think, "OH YEAH?? How is HALO a set sequence of happenings!?". If you have the slightest bit of programming experience, you would know the simple if statement and loops can all but fix this (in just about ALL scripting and programming languages). If not, then please read on. A simple game that comes to mind is GUESS. You randomly generate a number, and then tell the user to guess the number. And if he guesses wrong, you need to ask him again. To do this, you use a loop. A loop, loops back into preset code and repeats it. And then using if statements, the preset code which is executed may vary. Though this may seem complex, please try to write an example on paper. You'll find yourself able to do it and be able to understand it. If not PM me for a better example.
Alas, how does a sequence of happenings interact with a human? Well, all a program really does is take input and give output at almost all times (not including hard coded options to do a set list of things which only gives output). The program can allow the human to give it input and then give it output back and depending on that, the human may continue with the program or not. The interaction that goes on here is supposed to entertain the human and keep his attention. So an idiot, uh, I mean, a normal person might say something like, "OH YEAH?! WHAT OUTPUT AND INPUT IS IN HALO, RETARD?!". Can you notice that I've made this post for a reason yet? When you press the A button in Halo, that's input. And when your character does something in response to that input, that's output. Halo is actually a large amount of input and outputs all at once to make the game more fun and make the user think. This is rather hard to wrap your mind around at first without actually experiencing it first-hand it seems so if you have trouble, just drop it and read on.
Okay, we've gone through the entire definition. But your STILL full of questions! Where to start?
So let's begin with how all of this is REALLY made. Video games are actually generated images placed in front of the user based on the input to be used as output. This may sound slow but it's fast enough to have you jump instantly when you press A. Your computer that can play Halo seems a lot faster now doesn't it? So how are those images generated? What a question... I'll start a new paragraph for this one..
Chapter 2: The Concepts
In 3D programming, these images are actually part of a 3D world, literally. Every location has it's own vector (kinda) which means every location in Halo has a set vector such as (30,31,23). That 3D world then goes through a process known as rasterisation or the process of taking vector graphics and converting them into flat 2D graphics. More specific and more technical definition here: http://en.wikipedia.org/wiki/Rasterisation.
This itself is very complicated. How is the 3D world generated to make the 2D images? How are the 2D images shown on the screen? These are extremely complex and is a long read. If you think that calculus in high school is "bullshit", then a majority of 3D programming algorithms will definitely slap you across the face.
Images themselves are nothing but a large array of pixels. You know what resolution is yes? My resolution is currently 1600 x 1200. That means there are 1600 pixels going across my screen horizontally, and 1200 pixels going down my screen. The total amount of pixels or the area of my screen is n = 1600 x 1200. Do the math, that's a lot. Each pixel isn't a small matter either.
The Pixel:
At one point in time, a pixel could be the size of a bit, being either 0 or 1 (black or white). As you probably know, these days are WAY behind us (except for servers but they normally don't even project images. For another article). Then game (as far as I know), 8 bit graphics. This consisted of 256 colors. 8 bits is one byte. That's one byte per pixel. The size of one image fitting my resolution could be (if given an 8bpp picture) is 1600 x 1200. So that image would be 1920000 bytes. After 8 bit graphics came 16 bit graphics. Each pixel took up 16 bits (2 bytes) and had 256 x 256 colours. Just take that number (1920000) and multiply that by 2. That's 3840000 bytes. After 16-bit came the current and mostly used 32-bit pixel which is 256^3. Take that number (3840000) and multiply it by 2 again. That's 7680000 bytes. Then after 32-bit comes 64-bit which is coming up very soon and used on most gaming consoles. So take the latest number (7680000) and multiply it by 2 AGAIN! That's 15360000 bytes (or 14.6484375 megabytes) an image the size of my resolution. Now generate that using human input 60 times a second after the process of generating vector graphics and performing the task of rasterisation (and a few other processes if neccessary), and that's a the inner of a video game. Then add in all of the models, textures, animations, sounds, etc. into the game that has to process 60 times a second. I don't know about you, but that's a "HOLY CRAP" load of work, especially for anything that looks nice. Projecting an image is nothing more than slapping an array of pixels across the screen in order. (By the way, there's also something called Truecolor which is 24 bits per pixel but this is less commonly used. It IS used more oftenly in Xorg though. This had 2^16 colors in it.) To calculate the number of colors in any bpp size, simply take 2^x, x being the size of bpp.
I'm going to be frank. I haven't done much studying into 3D programming although I've done some basics to get the feel of it. I do not, however, no the true concept behind 3D programming yet. And trust me, I probably won't know for a few more months when I can finish reading some documents and books. Until then a great read can be found here: http://www.stewart.cs.sdsu.edu/cs596-3dprog/lecs/ch3-3dprogConcepts-3.html
I will also note that the above link shows concepts and terms. It doesn't show programming and I would like to let you know that all that is shown is BASIC OPERATIONS done by both APIs.
The above has to do with two things. One is flat images and what they are and 3D vector images based on a vector plane. Really, you don't need to know what is going on behind 3D API's to make them work. But you need to know that 3D vector images can be used and are used all the time in programming. There are normally two parts to a 3D game. There's the world and then there's the screen (often called screen canvas I believe). The screen can be used for many things such as posting a UI that is ALWAYS on your screen at all times. And then the world can be used to related your location to other objects (simple example is to say the visual distance from you and a desk. As you walk further back, the desk gets smaller where as your screen canvas does not change at all). This is true for any FPS game, including Halo.
Your GUI doesn't use the 3D vector world to place it on your screen. As a matter of fact, it normally uses an entirely different system that interacts directly with your screen. The 3D world usually generates it's image, plasters it on to your screen, and then you plaster your GUI on top of it.
Semi-conclusion:
This is basic 3D programming in an extremely large (and oddshaped) nutshell. This introduces about four out of thousands of modern concepts having to do with 3D programming. If ANY of the above sounded boring, made your brain hurt, or made you walk away for a few hours every sentence, and you STILL want to be a 3D video game programmer, all I have to say is that you need to be prepared for long days in a cubicle on your work computer developing some video game that you might not even like. If you think, "Oh by golly! This article inspired me to make the next best FPS that surpasses L4D, UT, and Quake!" your a jolly retard (bad word) that needs to have your motivation taken down a notch by the failures you receive each time you get frustrated by that awesome FPS game that you fail to make in the next 3 years by yourself (or even with a group).
NOTE: Anything else that you feel needs to be in the article, please post about it.
The Beginning:
A lot of people who want to be video game developers seem to misunderstand what it means to develop a video game. So let me ask you a ironically rhetorical question. How are video games made?
WOH, you went to fast with that question! Let's start at the basics. What is a video game? A video game is a sequence of happenings that interacts with someone (or something) to entertain someone and is projected onto a video screen. This sentence opens up about 5 different questions which branch which I'm going to cover all in this post. Enjoy.
Chapter 1: The Definition
By sequence of happenings, you may think, "OH YEAH?? How is HALO a set sequence of happenings!?". If you have the slightest bit of programming experience, you would know the simple if statement and loops can all but fix this (in just about ALL scripting and programming languages). If not, then please read on. A simple game that comes to mind is GUESS. You randomly generate a number, and then tell the user to guess the number. And if he guesses wrong, you need to ask him again. To do this, you use a loop. A loop, loops back into preset code and repeats it. And then using if statements, the preset code which is executed may vary. Though this may seem complex, please try to write an example on paper. You'll find yourself able to do it and be able to understand it. If not PM me for a better example.
Alas, how does a sequence of happenings interact with a human? Well, all a program really does is take input and give output at almost all times (not including hard coded options to do a set list of things which only gives output). The program can allow the human to give it input and then give it output back and depending on that, the human may continue with the program or not. The interaction that goes on here is supposed to entertain the human and keep his attention. So an idiot, uh, I mean, a normal person might say something like, "OH YEAH?! WHAT OUTPUT AND INPUT IS IN HALO, RETARD?!". Can you notice that I've made this post for a reason yet? When you press the A button in Halo, that's input. And when your character does something in response to that input, that's output. Halo is actually a large amount of input and outputs all at once to make the game more fun and make the user think. This is rather hard to wrap your mind around at first without actually experiencing it first-hand it seems so if you have trouble, just drop it and read on.
Okay, we've gone through the entire definition. But your STILL full of questions! Where to start?
So let's begin with how all of this is REALLY made. Video games are actually generated images placed in front of the user based on the input to be used as output. This may sound slow but it's fast enough to have you jump instantly when you press A. Your computer that can play Halo seems a lot faster now doesn't it? So how are those images generated? What a question... I'll start a new paragraph for this one..
Chapter 2: The Concepts
In 3D programming, these images are actually part of a 3D world, literally. Every location has it's own vector (kinda) which means every location in Halo has a set vector such as (30,31,23). That 3D world then goes through a process known as rasterisation or the process of taking vector graphics and converting them into flat 2D graphics. More specific and more technical definition here: http://en.wikipedia.org/wiki/Rasterisation.
This itself is very complicated. How is the 3D world generated to make the 2D images? How are the 2D images shown on the screen? These are extremely complex and is a long read. If you think that calculus in high school is "bullshit", then a majority of 3D programming algorithms will definitely slap you across the face.
Images themselves are nothing but a large array of pixels. You know what resolution is yes? My resolution is currently 1600 x 1200. That means there are 1600 pixels going across my screen horizontally, and 1200 pixels going down my screen. The total amount of pixels or the area of my screen is n = 1600 x 1200. Do the math, that's a lot. Each pixel isn't a small matter either.
The Pixel:
At one point in time, a pixel could be the size of a bit, being either 0 or 1 (black or white). As you probably know, these days are WAY behind us (except for servers but they normally don't even project images. For another article). Then game (as far as I know), 8 bit graphics. This consisted of 256 colors. 8 bits is one byte. That's one byte per pixel. The size of one image fitting my resolution could be (if given an 8bpp picture) is 1600 x 1200. So that image would be 1920000 bytes. After 8 bit graphics came 16 bit graphics. Each pixel took up 16 bits (2 bytes) and had 256 x 256 colours. Just take that number (1920000) and multiply that by 2. That's 3840000 bytes. After 16-bit came the current and mostly used 32-bit pixel which is 256^3. Take that number (3840000) and multiply it by 2 again. That's 7680000 bytes. Then after 32-bit comes 64-bit which is coming up very soon and used on most gaming consoles. So take the latest number (7680000) and multiply it by 2 AGAIN! That's 15360000 bytes (or 14.6484375 megabytes) an image the size of my resolution. Now generate that using human input 60 times a second after the process of generating vector graphics and performing the task of rasterisation (and a few other processes if neccessary), and that's a the inner of a video game. Then add in all of the models, textures, animations, sounds, etc. into the game that has to process 60 times a second. I don't know about you, but that's a "HOLY CRAP" load of work, especially for anything that looks nice. Projecting an image is nothing more than slapping an array of pixels across the screen in order. (By the way, there's also something called Truecolor which is 24 bits per pixel but this is less commonly used. It IS used more oftenly in Xorg though. This had 2^16 colors in it.) To calculate the number of colors in any bpp size, simply take 2^x, x being the size of bpp.
I'm going to be frank. I haven't done much studying into 3D programming although I've done some basics to get the feel of it. I do not, however, no the true concept behind 3D programming yet. And trust me, I probably won't know for a few more months when I can finish reading some documents and books. Until then a great read can be found here: http://www.stewart.cs.sdsu.edu/cs596-3dprog/lecs/ch3-3dprogConcepts-3.html
I will also note that the above link shows concepts and terms. It doesn't show programming and I would like to let you know that all that is shown is BASIC OPERATIONS done by both APIs.
The above has to do with two things. One is flat images and what they are and 3D vector images based on a vector plane. Really, you don't need to know what is going on behind 3D API's to make them work. But you need to know that 3D vector images can be used and are used all the time in programming. There are normally two parts to a 3D game. There's the world and then there's the screen (often called screen canvas I believe). The screen can be used for many things such as posting a UI that is ALWAYS on your screen at all times. And then the world can be used to related your location to other objects (simple example is to say the visual distance from you and a desk. As you walk further back, the desk gets smaller where as your screen canvas does not change at all). This is true for any FPS game, including Halo.
Your GUI doesn't use the 3D vector world to place it on your screen. As a matter of fact, it normally uses an entirely different system that interacts directly with your screen. The 3D world usually generates it's image, plasters it on to your screen, and then you plaster your GUI on top of it.
Semi-conclusion:
This is basic 3D programming in an extremely large (and oddshaped) nutshell. This introduces about four out of thousands of modern concepts having to do with 3D programming. If ANY of the above sounded boring, made your brain hurt, or made you walk away for a few hours every sentence, and you STILL want to be a 3D video game programmer, all I have to say is that you need to be prepared for long days in a cubicle on your work computer developing some video game that you might not even like. If you think, "Oh by golly! This article inspired me to make the next best FPS that surpasses L4D, UT, and Quake!" your a jolly retard (bad word) that needs to have your motivation taken down a notch by the failures you receive each time you get frustrated by that awesome FPS game that you fail to make in the next 3 years by yourself (or even with a group).
NOTE: Anything else that you feel needs to be in the article, please post about it.
Last edited on
Applause.
There are too many threads where someone plays some game, thinks "I can do that!", looks online for a programming language, finds C++ and then asks "How can I do that with this?"
There are too many threads where someone plays some game, thinks "I can do that!", looks online for a programming language, finds C++ and then asks "How can I do that with this?"
Nice article.
| Applause. There are too many threads where someone plays some game, thinks "I can do that!", looks online for a programming language, finds C++ and then asks "How can I do that with this?" |
closed account (S6k9GNh0)
I'm surprised I didn't write something stupid as it was written 3 in the morning. I'll revise it and add here in a bit.
It's a nice article, though it is awkwardly concentrated on graphics. It's not that complicated realy, especially since apis do all the hard work for you and no one is forcing you to do it 3d.
Anyways, there are more complicated things concerning game programing, such as AI.
Anyways, there are more complicated things concerning game programing, such as AI.
Nice article. And it really should belong to a "Why you shouldn't program games. [for dummies]" book ! :D
Last edited on
Good article but you forgot to mention things like entities, enemy AI, algorithms that tell which object must be rendered or not (
).
Also LOD (probably when working on large games with lots of enemies and open spaces), shadowing, some physics (gravity and etc.) and triple-layered polygons with at least 4 texture blending modes!
Or you couldsteal license a working game engine...
Now, if you stand in a room and you don't see the door out, because e.g. there is a column between you and the door, or if the door is closed, the room on the other side of the door will not be rendered. This means that all the models, brushes, particles, lensflares etc, in that other room will not even be considered for rendering and will spend 0 CPU time. |
).
Also LOD (probably when working on large games with lots of enemies and open spaces), shadowing, some physics (gravity and etc.) and triple-layered polygons with at least 4 texture blending modes!
Or you could
closed account (S6k9GNh0)
This was made to simply scare people... I'm not going into every concept. I might go into AI since it can get to some seriously complicated stuff that I have to yet to wrap my mind around (so many concepts, so little time).
Entities aren't terribly complicated. An entity is just a being which can even be a vector itself (or not depending on developer). It's also common to tag every entity with an id to track it by and even a string for a name. Another name for entity is object. It's basically where you classify anything as an object which is also relative to real life. Now, I could go into Factories, etc. but to be honest, I don't know much in that subject as well. Entity is not an actor or a living being since it does not need to be held in vector space. An actor (or live being) is usually also an object since everything is an object. //Edited to fix wrong explanation as to what an object and entity is.
Honestly, I'm sick of my 5th period class nerds who think they know how to develop games because they made something cool in Scratch or Alice. It sickens me, it really does. I made the basic game of 1 player pong and a side-scroller which didn't work to well. They made a big ass, hard coded program that did everything in a specific order. It was basically a story about how a cat is shot by another cat (seriously, wtf is this, kindergarden?) . When I presented my little pong game, they snickered saying it was crap and shit. Now, normally I wouldn't care because they're fuckin' stupid but when it's someone who doesn't know wtf they're talking about and talking like coding in Scratch is hardcore, I can't help but get a little frustrated. When he said something to my face about it later, I told them to stfu and go code something with OpenGL. When I really gave up was when they asked me what that was and started laughing saying something about how I was making up tech terms to make them look stupid.
I think the scariest thing is modeling. Last time I looked at an advanced 3D model, I shit myself. Although that usually has nothing to do with manual coding. Animation is even scarier.
EDIT 1: Also, concerning the basing on 3D programming... I only talked about 3D programming since as far as I know, OpenGL and DirectX (and maybe a few others but prolly not) are the only API's that access video hardware e.g. video card directly. Anything else is using a software renderer which isn't good for any main stream and heavily graphical game. A fantastic example is Maple Story. This game will not play if you do not have a DirectX capable video card. If that game were developed via software renderers, the game would be so CPU intensive and so slow, it probably wouldn't exist today. This is also a valid reason to hate SDL since it doesn't integrate with OpenGL while SFML does, simplifying the work that the developer has to do. But OpenGL is integrateable via the developer using SDL. It's just tedious work.
NOTE: This was my 666th post. An evil day indeed...
Entities aren't terribly complicated. An entity is just a being which can even be a vector itself (or not depending on developer). It's also common to tag every entity with an id to track it by and even a string for a name. Another name for entity is object. It's basically where you classify anything as an object which is also relative to real life. Now, I could go into Factories, etc. but to be honest, I don't know much in that subject as well. Entity is not an actor or a living being since it does not need to be held in vector space. An actor (or live being) is usually also an object since everything is an object. //Edited to fix wrong explanation as to what an object and entity is.
Honestly, I'm sick of my 5th period class nerds who think they know how to develop games because they made something cool in Scratch or Alice. It sickens me, it really does. I made the basic game of 1 player pong and a side-scroller which didn't work to well. They made a big ass, hard coded program that did everything in a specific order. It was basically a story about how a cat is shot by another cat (seriously, wtf is this, kindergarden?) . When I presented my little pong game, they snickered saying it was crap and shit. Now, normally I wouldn't care because they're fuckin' stupid but when it's someone who doesn't know wtf they're talking about and talking like coding in Scratch is hardcore, I can't help but get a little frustrated. When he said something to my face about it later, I told them to stfu and go code something with OpenGL. When I really gave up was when they asked me what that was and started laughing saying something about how I was making up tech terms to make them look stupid.
I think the scariest thing is modeling. Last time I looked at an advanced 3D model, I shit myself. Although that usually has nothing to do with manual coding. Animation is even scarier.
EDIT 1: Also, concerning the basing on 3D programming... I only talked about 3D programming since as far as I know, OpenGL and DirectX (and maybe a few others but prolly not) are the only API's that access video hardware e.g. video card directly. Anything else is using a software renderer which isn't good for any main stream and heavily graphical game. A fantastic example is Maple Story. This game will not play if you do not have a DirectX capable video card. If that game were developed via software renderers, the game would be so CPU intensive and so slow, it probably wouldn't exist today. This is also a valid reason to hate SDL since it doesn't integrate with OpenGL while SFML does, simplifying the work that the developer has to do. But OpenGL is integrateable via the developer using SDL. It's just tedious work.
NOTE: This was my 666th post. An evil day indeed...
Last edited on
As for your pains in 5th period, I truly feel for you... people just don't get how challenging things can be because nobody plays RL anymore.
@Null,
There are plenty of BSD and GPL game engines. You just gotta look for them. http://gpwiki.org/index.php/Game_Engines
Ugh, I hate people like that... A guy I know claims he's a great programmer because he made a Starfox rip-off (it wasn't a clone, it was just made using sprites from Starfox 64) using Game Creator or something, using java. Ew.
They don't. No OS would let them, that would be insane; asking for security flaws. What if I could just write directly to video memory? Then the lovely GUI (I actually don't like it. And don't say that's just bias: I hate apple too, but I think some parts of their GUI look 'nice' (although it makes my grind my teeth slightly to say that)) that microsoft spent five yearscopying from KDE making would be ruined! They interface with drivers.
There are plenty of BSD and GPL game engines. You just gotta look for them. http://gpwiki.org/index.php/Game_Engines
| Honestly, I'm sick of my 5th period class nerds who think they know how to develop games because they made something cool in Scratch or Alice. |
Ugh, I hate people like that... A guy I know claims he's a great programmer because he made a Starfox rip-off (it wasn't a clone, it was just made using sprites from Starfox 64) using Game Creator or something, using java. Ew.
| access video hardware e.g. video card directly |
They don't. No OS would let them, that would be insane; asking for security flaws. What if I could just write directly to video memory? Then the lovely GUI (I actually don't like it. And don't say that's just bias: I hate apple too, but I think some parts of their GUI look 'nice' (although it makes my grind my teeth slightly to say that)) that microsoft spent five years
Challenge said nerdy friends to attempt to program in c++ while telling them the advantages of c++ which will hopefully pique their interest and thus you will be put on a pedestal.
Don't know, I assume he just isn't willing to learn new things if they're too difficult. I don't think he's "one of us" (a real geek would enjoy the challenge of learning a new programming language. Besides that, Java is based on C++ and would make learning it easier (but mastering it harder)).
Pages: 12