Hey, I've decided that after seeing so many noobs not having a clue what they were getting into or how to do anything, and seeing noone understand what making games is, I am going to write a complete guide to making a game. While focusing on DBP, many of it's concepts will apply to all games. I'm writing it like an FAQ about game making. I'm currently done with one question and about halfway through the second. I hope to continually update this until it's finished. It's long, but maybe it will help (if anyone can get through it that is, lol
). So, here it is, tell me what you think so far...
HOw DoO I lyEk mAk UbEr GaMeZ?!?!?
Translation:
How do I make a game?
First you have to understand it's not a walk in the park, so to speak, but it's not impossible. You won't produce the next “Halo” or “Grand Theft Auto” in three months, because games like those take professionals years to make, and they work with teams of many people, I don't want to guess, because it varies, but I'd say the largest games can have up to 150-200 people working on them. So, how can you get started on this game-making adventure now that you've decided it's worth the time and your ready to dive into the wonderful world of game-making? Well you can start by looking at games in a whole new light. After joining the rare breed of nerds known as programmers and game-makers, I, and I would assume other programmers as well, begin to look at games in an entirely different way. As an example:
Let's say your a normal gamer playing a game like “Call of Duty” (A World War II FPS, or First Person Shooter), and your an Allied soldier fighting in the streets of some Western European city that your squad and you are liberating. There's a Nazi rifleman in a window taking potshots at your squad, and two machine gunners below suppressing your squad, who are hiding behind different barriers. “Why can't they have more squad guys than just 4, it'd be cool to have a huge group”, you think. And then decide, “I need to use my rifle to pick of that rifleman”, so you hit the button to switch to your rifle, and your hands go off the screen, and come back with a rifle, just like they should. Crouching behind a small brick wall you pop up and shoot at the rifleman when he comes off, hitting him in the head, but he doesn't die. You shoot him again, and he falls down and dies this time. Now you set your sights on the machine gunners. One of your guy's runs forward and is gunned down. “Idiot”, you think. So you switch to your machine gun, and shoot at the two guys that are shooting at you, killing them. Your Sergeant tells your squad to move forward and your comrades walk forward. Nothing strange about that scene, everything works like it should it appears.
Now lets take that same scene from a programmers perspective:
Your an Allied soldier fighting in the streets of some Western European city that your squad and you are liberating. “Good level design”, you think, “It's hard to notice that I'm being forced down a specific path.” A Nazi rifleman begins shooting at your squad, who are ducking behind cover, then hiding back beside the window. “Decent AI (Artificial Intelligence), at least they take cover”, as you look at the enemy soldiers as well as your own hiding and shooting. You realize the reason the squad count is so low is because the people are “high poly” and to have to many of them would eat up the “FPS”(Frames Per Second”. You switch to your rifle to take out the enemy rifleman, your hands animate to switch weapons. “Nice animation, seems real yet isn't hard to do”, you think. You shoot the rifleman in the head and he doesn't die. “Wonder if they have limb detection...if so they need to make the headshot a kill”. One of your squad members runs forward and is gunned down. “Idiot, wonder why they didn't fix that before they released the game”. You switch back to your machine gun and shoot at the people firing at you, killing them. Your Sergeant tells your squad to move forward. “Must be scripted to where he says that when you kill those three guys”. And you continue on down the war-torn street to help your squad...
See the difference? You look at games from a more technical standpoint, and you realize the work that went into them. Of course they're still fun, but it's just...different. Okay, now that I've bored you to death with an example of how you'll see things differently, lets get to the question, how do you make a game? Well, like I've said, it's not easy. There are many parts that make a game, some you may have never thought of before. What are these parts? Design, programming, modeling, sound engineering, composing, world building, texturing, testing, and animating are the main ones. So, you may have no idea what some or all of those were, or maybe you do, so I'll go through each of them, and try to make it as not-boring as possible.
Programming:
What exactly is programming? Well, programming is pretty much you commanding the computer what to do. It's like the director of the action, it brings everything together, and directs everything to where it should go. What you do as a programmer is combine different commands to complete a task, something many people fail to realize.
To help illustrate, I'll make a comparison...programming is like being given a bunch of Lego's, your given all the pieces, and you just have to put them together in a way that achieves what you want. There are so many different ways to reach that goal, so many ways to “stack the Lego's”, as there are many ways to reach a goal in programming, it's up to you how to decide. Some ways are better than others, for example, it's better to build a large Lego tower out of two by four blocks than by one by one blocks, it just makes more sense, and it is more effective and well-built, just like in programming there are ways that are better than others. The larger the goal, the more ways to do it. There's more ways to make a castle than a tower. There's more ways to make a system where you shoot people than one that prints a word.
Another idea that we can get from this Lego comparison is that it doesn't make sense to ask, “Can I build a city with this?”. Well...duh, why couldn't you? Of course it all depends on your ability to do so. Can YOU build a city with it? This is like asking with programming, or really game-making in general, “Can I make a game where you can drive a car in first person?” or “Can I make a customized menu with this?”, and similar questions. Well...duh, why couldn't you? It all depends on your ability to do so. Can YOU achieve what you want with it.
So I hope now that I've made what appears to be a good comparison, it's easier for you to understand what programming is like, for a simple example, I'll make some code that will print a basic menu, you won't be able to interact with it yet though.
set text font "Arial" `we set the text font to “Arial”
set text size 100 `set the text size to 100, a large size, default is 10 or 15 I think
center text screen width() / 2, 10, "MENU" `now we just print the text “MENU” at the screen width divided by two, and ten pixels down centered over that point
set text size 15 `now we set the text size back down to 15
center text screen width() / 2, screen height() / 2 - 20, "New Game" `now we center the text “New Game” over the point half the screen width (so the center ), and the screen height minus 20 units so it doesn't overlap with the other two points.
center text screen width() / 2, screen height() / 2, "Load Game" `we do the same thing with “Load Game”, but don't position it twenty units up, so it is dead center.
center text screen width() / 2, screen height() / 2 + 20, "Quit" `lastly we center the text “Quit” at half the screen width and the screen height plus twenty units, so it would go down twenty units below “Load Game”
suspend for key `this waits for a key to be pressed before quitting the program, without it, the program would simply run through the code and quit so fast you wouldn't even be able to see the text
Now maybe you have a better understanding of what programming actually IS, now let's move on to modeling...
Modeling:
Modeling is creating the objects to be used in a game. Simple as that. You may have never thought about it before, but all those things in the game don't just appear there, someone has to make each and every one of them, bend each and every vertex, sculpt each and every one to what they want. Let's take one of my favorite screenshots from my favorite game, “Elder Scrolls IV: Oblivion”:
Now let's list all the objects that would have to be made for this single screen-the trees, the gravestones, the grass, the mushrooms, the rocks, the wall the church (not an easy model, each and every curve and corner on it would have to have been carefully sculpted), and the bush. All in a single not very active shot. How do you model? A modeling program. Modeling programs allow you to place a simple object, say a box, and sculpt that box in a way that achieves the model you want. Calagari Gamespace (
http://gamespace.thegamecreators.com/), Milkshape, (
http://www.swissquake.ch/chumbalum-soft/), and 3DS Max(
http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=5666151&linkID=5572501) are just a few of the many modelers you can use. To get a feel for what it's like to model, I suggest you download the easy to use, simple, and free “Google SketchUp”
http://sketchup.google.com/download.html, and take a look at the in-game video tutorials. Hopefully you get what modeling is now, so we'll move on to Design.
Design:
Design lies at the heart of every game. Design is well...designing the game. Writing, drawing, thinking of every tiny detail of the game. If you take our “Call of Duty” example from the programming section, let's see what the designers would have designed for that single scene. Every model would have been drawn in concept art, the layout of that street would have been drawn and redrawn, taking into consideration sniping spots, cover, distances, everything you could think of, the weapons would have been designed, the soldiers, the mission itself, the reloading animation, the damage done by hitting separate body parts, the ammo, the health, and the buildings themselves. That's just what I can think of off the top of my head. Every tiny thing about a game and every larger thing has to be designed. No matter how big or small. Designing is in itself an art form. “Is it better to give the player lots of health and give him one chance, or little health and give him three?”, “How do I make this world appear larger than it is?”, “Is the system I have right now easy for the player to control?”. All of those are a couple design questions that you might ask as a designer. Without good design, a game fails. Check out Tinkergirls excellent tutorials on design concepts here for a better idea of what kind of challenges a designer faces and some great design tips:
http://forum.thegamecreators.com/?m=forum_view&t=61947&b=19
Sound Engineering:
Because I don’t make my own sounds, I’m not really sure exactly how this works, but I’ll describe what it is anyway. Sound engineering is recording sounds for a game. How do you do that? Well, like I said, I’m not sure of the specifics, but you’d need a recording device and/or a sound manipulating program. Every sound in a game you hear must be made, a gunshot, a sword hit, a groan, a footstep, and the list goes on and on. Without sound, games can be very boring and are much less interesting (just try playing a game after turning the volume down, and see if it doesn’t annoy you and make you change it back within 10 seconds). Sounds can easily be found on the internet, but be careful that you don’t use ones that don’t allow license-free commercial use.
Texturing:
A game without textures is a game without life, beauty, realism, or really any kind of appeal at all. It’s like living in a gray world. A world where colors don’t exist, not even black and white, just one, dull gray color. Texturing brings a world, more specifically the models in the world to life, creates a realism in them. One of the main aspects next-generation games are improving on is textures, they are making them more detailed, and more realistic looking, adding to the environment and atmosphere of the entire game. What is texture? A texture is what is on every surface in a game, for example, a shack. It doesn’t just automatically come colored up and looking like a shack with straw and wood and metal, someone has to make those. Since It’s hard to explain, here’s an example. This is a Humvee model I’m currently working on; this is what it looks like without a texture:
here’s one with most of one (some temporary, but still easy to see the difference:
See the difference in the two? So hopefully you get what texture is, so how do you make them? Well all you need is a digital camera. It helps if you have a good photo-editing program like Paint Shop Pro or something similar, but it’s not required, you can just use paint.
Composing:
I have no experience in this either, but I can tell you what it is, and the basics of how it’s done. Composing is pretty much making music, then recording it for use in a game. I know that many large game companies use entire orchestras for their music. Not many indie developers get into this though, and most just use downloaded content, or make their own with a music manipulation program and an instrument or two. There’s really not much to say about this, except for that it’s not something that you should really worry about yet.
Animating:
Although I never have actually animated anything, I’ve been around it ever since I started programming. Animating is making things move. Many people fail to realize just how many animations are in a game. If you take our Call of Duty example, off the top of my head animations would be crouching, shooting, reloading, standing, running, walking, crouching and shooting, hiding, and ducking. And the list goes on and on. Every one of those actions must be changed in the model. How does it work? Many modeling tools have an animating tool already, and to animate, you need to “rig”. “Rigging” is like adding joints into a model so it can detect where it needs to bend. Then the animator moves these certain joints to make it look like the character, or whatever it is, is moving. Then the programmer controls when to play these animations and where with code.
World Building:
World Building goes along with level design as well as modeling. World building is, well…building the world, the graphical part of it to be more specific. Why is it different than modeling? Modeling is used for more detailed, smaller objects, where as world building is like drawing a map out of a bunch of boxes and other primitives. Think about every level, every building that you see in a game. That’s what world building does, it’s making those buildings, those levels. If you’re interested in how it works or just what it is, I’d suggest trying the free 3D World Studio Demo (
http://3dworldstudio.thegamecreators.com/downloads.php ), and if you like it, I’d suggest buying it, because it’s a great, easy-to-use, and flexible world builder. World building can also include terrain, which is the landscape, like mountains, rivers, grass, oceans, etc. Usually terrain is just made by a terrain making program, such as Geoscape 3D or T.ED, but it is possible, although difficult, to make your own in DarkBASIC Pro and other languages. Another common question for this is something along the lines of “cAn I MaK lyek a hOwS w/ WindOWS?!?!?!?!?!?!?!?!?!?!?!?”, translation: “Can I make a house with windows?”. Again this goes back to our Lego comparison…can YOU make a house with windows? Are YOU capable of putting the Lego’s together right? Because everything’s there for you to do it with, so the question is “can YOU?”, not “can IT?”.
Testing:
Last, but not least, is testing. Testing is just what it says it is…testing. Testing a game to find every little thing that’s wrong with it, technical and design-wise. Can the player reach this part of the map? Does the player go through that wall if I hold down shoot? Can I reload while shooting? If I kill someone and shoot him again, will it play his dying animation again? Once you understand programming better, and get into more complicated things, you’ll realize just how incredibly easy it is to go wrong, and for every tiny mistake in the sometimes thousands of lines of code, there’s one bug. I spend probably ½ my time on a program debugging it. Murphy’s law is oh so present here: Anything that can go wrong, will go wrong. It’s rare that something works like it should the first time, second time, and even third time. Not the most fun part of game making in my opinion, but it has to be done, you don’t want your player being able to walk through a wall or be invincible if he is holding down the reload button, do you?
If you’ve read through all that, you deserve a medal, or some kind of reward, because it was so long. So the two people in the world that actually read all of that, congratulations! Now I think I’ve explained what it takes to make a game, let’s answer some other common questions…
Y DoS tEh gaMs lUk sOoOOoo BaaaDD?
Translation:
What are FPS and Poly’s?
Two very important words (well, four if you count all of them in FPS
) are vital to knowing how to program/model effectively. FPS and Poly’s. Many of you may think that FPS is “First Person Shooter”, and it is, but it also has another common meaning, “Frames Per Second”. We’ll cover that first.
Frames per second are exactly what they sounds like, the number of frames that are on the screen in a period of a second. Videos also have “frames per second”, because all “moving” videos are actually not moving at all, but are just an illusion. They are really a bunch of pictures put together to have the appearance of a moving picture. Animated movies (think Disney) are made by artists actually drawing each frame onto paper and putting them together to give the appearance of movement. If you’ve ever seen or made one of those flip books where you flip the corners of a book with a bunch of pictures and it appears like it’s moving, that’s what I’m talking about. Another way you can see FPS is if you’ve ever (which I’m sure you have) experienced a “slow-down” while playing a game, where the game just slows down for no apparent reason, it’s because the FPS has dropped. So what’s a “good” FPS? People say anywhere from 30-60 FPS is good. I say from 50-60, because after that it become unnoticeable, and before it is noticeable and often feels dragged out and clunky. You should aim for 60 FPS though. If you’re a DBP user, here’s some code that will print the FPS to the screen (must be used in 3D).
text 0, 0, “FPS = “ + str$( screen fps() )
How do you regulate FPS? In DBP you use the “sync rate” command, allowing you to limit the FPS. Why would you want to limit the FPS? Because, if you have a higher FPS, then everything moves faster. So if someone with a high FPS plays a game, and it appears like they (and everyone else) is running, when they should be walking, that’s not good, is it? If you want to regulate your FPS to around 60, use:
Got it? Feel free to ask questions in the thread. So why can’t every game just have a perfect 60 FPS? Polygon’s, or Poly’s for short. Polygons are, in my own words, a 3D side to a shape on screen. In the words of Wikipedia:
“A polygon is a plane figure that is bounded by closed planar paths composed of a finite number of sequential line segments.”
I hope mines easier to understand
. So how many polys does a cube have? You may have said 6, which, actually, isn’t right. Why? A cube has 6 sides right? Yes, but each square side is made up of two triangles, and it’s these triangles which count as polys. I actually don’t know why the whole square can’t count as a polygon, I just know it doesn’t
. So actually, there are 12 polygons in a cube. So why do the number of polygons in a cube affect FPS? Because the more polys means the more the computer has to redraw to the screen every second, and the more it has to redraw, the more “computing” power it takes, and the more computing power it takes, the slower it runs, and the slower it runs, the slower the FPS. Got that
? What’s a good poly count? It depends. How effective is your code? How many background tasks are working? How many shaders are you using? What techniques are you using to hide unneeded polys? What kind of resolution are your textures? There’s no simple answer, but most professional games (rough estimate here) probably have anywhere from 50,000-75,000 on the screen at a time.
So the reason that all games can’t be as beautiful and detailed as you’d like is because the FPS has to stay up to make the game fun, and to keep the FPS up you need fewer polys, and to have fewer polys, you need fewer sides to objects
. Hope that makes sense and now you understand polygons and FPS a bit better, as they are a very important factor in game-making.
