I understand how frustrating it is to have to answer the same question over and over and over again, but I have YET to find a page, or forum, or book that addresses my problem. I go to school majoring in computer science. I know a fair amount of C++, and I've taken several game programming courses. I know Maya and have done a bit of level design. I've designed three games on Game Maker 8 that my teachers have been ecstatic about, but when it comes down to it, I haven't the faintest idea where to begin making a game.
I've read nearly 5 iPhone app development books, two of which are game-oriented, but they never explain the low-level, essential information about building or developing a game. I don't want to copy lines of someone else's code for hours just to get a duplicate of what they've done with no real explanation, but I KNOW that there are independent developers out there who can sit down and begin coding a game from scratch. So where on earth do I start? (Keep in mind, too, that I have scoured Amazon for books on C++ game development, and found absolute GARBAGE)
I understand that you need a game engine. But...why? What does the game engine provide for you? How does a game engine magically bridge you from c++ to a functional game? Hell, even before this, I don't understand how a computer can represent items graphically. How do 0s and 1s create pixels on screen? How do you get a computer to render an image if all it understands is binary?
But all this aside, I want to start writing games. I feel like I have all the ingredients for making a game (The coding, development experience, 3d modeling, etc) but no recipe to follow. Where do I possibly begin?
Thanks for your time,
Catfish
I have the ingredients, but no recipe...
I haven't the faintest idea where to begin making a game.
[/quote]
I think this is just one of those things that you need to learn by doing. Surely if asked you could figure out how to create some kind of 'game', if it were simple enough. If someone asked you how to write a 'guess the number' game, I bet you could figure it out. You've just got to start wherever you can, and continue to build on your skills. Maybe once you write 'guess the number', you can rewrite it with mouse support and simple graphics with SDL or OpenGL or DirectX. From that maybe you can make a match-3 game, or maybe even a pong clone. You just have to keep building and building on what you know.
I KNOW that there are independent developers out there who can sit down and begin coding a game from scratch.
[/quote]
Yes that's true, and its because they've been practicing and writing games long enough to have a good idea how all the pieces fit together in their head. This isn't really something you'll get from a readthrough of a book, you need to work with it over and over until it is intuitively drilled into your brain.
I understand that you need a game engine.
[/quote]
You don't.
But...why? What does the game engine provide for you?
[/quote]
It implements a lot of the boilerplate functionality that you might need to make a game with. Lets just say a game engine has a physics simulator and a graphics engine. A game engine you could just say, "throw these two beach balls at each other, and let them be lit overhead by a light at a 45 degree angle. You could achieve the exact same result without an engine, but in that case you have to write the code for collision detection and resolution, and write the code to display the balls and handle all the lighting and everything yourself. Its a lot of work, which is why an engine may be preferred by some people. But its certainly not required, its just a collection of code you can use so that you don't have to write it yourself.
Hell, even before this, I don't understand how a computer can represent items graphically. How do 0s and 1s create pixels on screen? How do you get a computer to render an image if all it understands is binary?
[/quote]
In the simplest explanation, consider a triangle in the center of the screen. This is represented by three vertices in your code. A graphics processor takes these coordinates, rasterizes them (converts an abstract triangle into the actual pixels that are covered by it), and assigns a color to each pixel (typically a 32-bit value with 8 bits for each of red,green, blue, and alpha). These values are stored in a framebuffer, which is a big chunk of memory that contains entry for each pixel in your screen. When the monitor is ready to draw, the display engine on the graphics card steps through the framebuffer and converts each pixel value into an analog signal, which it sends to the monitor and lights the respective pixels.
Start with small programs like pong/tetris etc, and you'll understand how games are done. To the cooking analogy: start with mashed potatoes, stewed vegetables and stuff like that. You will (should) soon realize that basically cooking is the same, no matter how fancy Jamie Oliver shit you are cooking [size="1"](cooking = when things get out of hand, take the stuff off the stove; taste the stuff you are making; use pots/pans with thick bottom).
You don't need a game engine. You can and in many cases you better be using one though. I never used game engines and made some games, even 3D games.
You don't need a game engine. You can and in many cases you better be using one though. I never used game engines and made some games, even 3D games.
You need a game engine if you want to use the fancy graphics features modern games can have. If you don't use one you will just end up making the same things yourself, which is good in some ways but not realistic for a beginning programmer to get very far.
It's always hard to find where to start a project, really. It's harder the less experience you have with similar projects, and a game is often a really big project. But just pick a few things to do, like get a model displaying on screen, get it moving around, get some kind of GUI to pop up, etc. etc.
In some ways it is better to do some smaller projects first, in some ways worse. Making pong is nothing like making Civilization 5, and you might find the tools great for making pong are a joke for making civilization 5 if that's your aim. First figure out what you want to do in general terms, then break that into some steps and try to do the most basic ones as a proof of concept then get mre ideas from there and as you are more aware of what's needed and potential problems you will be able to plan ahead a bit more and design better. That is programming in a nutshell.
It's always hard to find where to start a project, really. It's harder the less experience you have with similar projects, and a game is often a really big project. But just pick a few things to do, like get a model displaying on screen, get it moving around, get some kind of GUI to pop up, etc. etc.
In some ways it is better to do some smaller projects first, in some ways worse. Making pong is nothing like making Civilization 5, and you might find the tools great for making pong are a joke for making civilization 5 if that's your aim. First figure out what you want to do in general terms, then break that into some steps and try to do the most basic ones as a proof of concept then get mre ideas from there and as you are more aware of what's needed and potential problems you will be able to plan ahead a bit more and design better. That is programming in a nutshell.
but when it comes down to it, I haven't the faintest idea where to begin making a game.
Pick up any board game, card game, or other simple tabletop that has a rulebook. For instance monopoly. It has all the pieces you need to translate to a computer game. Player pieces, with locations on a board, and rules for movement and what happens on each turn at each location. It's the same thing if you pick a basic game you already know the pieces for, like tic-tac-toe, or tetris. Your first step really should be figuring out how to translate a small set of rules into code the computer can play for you. Then you can worry about making your own games, once you can come up with your own rules to translate. I'd also sugest just making the games in text format before jumping into graphics, as it is a few less complications to worry about, and the rules stay the same it's just how you display their results that is different.
I understand that you need a game engine. But...why? What does the game engine provide for you? How does a game engine magically bridge you from c++ to a functional game? Hell, even before this, I don't understand how a computer can represent items graphically. How do 0s and 1s create pixels on screen? How do you get a computer to render an image if all it understands is binary?[/quote]
You don't need a game engine, but game engines (like unity) and game oriented SDKs like SFML, SDL, and the like will all take care of a lot of the boilerplate code that you'll need to display information to the players of your game.
I've read nearly 5 iPhone app development books,
How many iPhone applications have you written?
Or better yet, have you written any programs yet?But all this aside, I want to start writing games. I feel like I have all the ingredients for making a game (The coding, development experience, 3d modeling, etc) but no recipe to follow.[/quote]
How many and what kind of applications have you written?
What kind of projects have you completed so far?
What kind of 3D models did you develop?
My best advice is to stop looking for a recipe. Making a program is more like painting a picture than baking a cake. You don't get ingredients, follow a recipe and end up with something mostly resembling cake. You get paints, brushes and techniques... but even with that you aren't guaranteed to end up with something that looks like you want without practice. And two different people won't really end up with the same painting even if they tried.
[font="arial, verdana, tahoma, sans-serif"]Lock yourself in a room for two years doing nothing but programming, eating cheez doodles, and drinking mountain dew. Then after two years when you emerge 50 lbs heavier, you will have a completed game and you will understand what 3d game programming is all about.[/font]
Think of a game engine as something that makes development easier/faster, you do NOT need one in order to make games. Most developers that I know did not start with any Engines, they just started using raw DirectX/OpenGL and went from there. A game engine is nice but not necessary.
I understand that you need a game engine. But...why? What does the game engine provide for you? How does a game engine magically bridge you from c++ to a functional game?
A game engine implies a library that is separated from the actual implementation of a game. There is no set in stone definition for what a game engine does, but it provides support classes and services that make the development of a game faster or easier. Games are composed of lots of different subsystems that perform different tasks, and which subsystems are present varies from game to game. There's code to render graphics, code to output sound, code to handle networking, AI code, math libraries, etc.
However, a game engine does not need to be on the scale of the Unreal 3 Engine. If you have an AI library that can handle pathfinding for you, and a sound library to load and manage music/sound effects, but nothing else, then those comprise your "game engine". If your AI code is tightly integrated with your NPC class representation, then it is not part of a reusable game engine. You can build entire games that are totally purpose built, that manage their own rendering, their own AI, their own networking, all in one pretty tightly interlocked code base.
Hell, even before this, I don't understand how a computer can represent items graphically. How do 0s and 1s create pixels on screen? How do you get a computer to render an image if all it understands is binary?
How does a computer do anything if all it understands is binary?
Have you even asked yourself, "What is binary?"
It's data. Pure and simple, all binary is is data. Nothing more, nothing less.
Think about two natural languages, like French and English. The word for "street" in English is "street", in French is it "rue". These are two different words that have absolutely no connection to reality. How do the squiggle lines of "street" and "rue", or the sounds made speaking them, translate into the concept of a paved stretch of earth used for travel?
Interpretation.
Data by itself is meaningless, at some point you need to interpret it into a concept. Languages do this through an immensely complex mesh of rules. English speakers have collectively agreed that the sounds made speaking the word "street" will represent that physical object, while French speakers have agreed that "rue" will represent that physical object. If I could get people to agree that "grabbadonk" would represent the concept of a street, then it would become a word. Without that rule, it's just gibberish.
Computers work on the same way. Binary is a mechanically convenient way to reliably store data as electrical charge. At some point, that electrical charge gets interpreted through a physical process (signal processing), and the end result is tangible, physical output, whether it be causing an LCD pixel to generate a specific color of light, or a speaker to vibrate at a specific frequency to make sound. Meaning, somewhere, some computer engineer has designed a physical circuit that converts the input (electrical signal representing bits), to another, useful electrical signal to drive an output device (pixel 1025, 563 turn red, produce a 800Hz drone, etc).
Let's take, for example, the Gameboy Advance. I took a class while in school to write programs for it (it was super fun!). The Gameboy Advance is little more than a modified SNES in portable form, so it's a really primitive piece of hardware by today's standard. There's no operating system, no development API, absolutely nothing standing between you and the hardware. So how does anything get done?
Basically, you accomplished everything by placing data values into special chunks memory. The GBA had a very strict memory mapping that cordoned off sections of memory for specific hardware functions. The entire system, like a big clock, ran in a self-sustaining loop from the time it was powered on until you shut it off. Every cycle (frame update), it would grab data out of these special sections of memory and pass it through some physical chip to process the signal and do something useful with it, and it would write to other, special sections of memory that you (the programmer) could access to get updates on how the system was running, kind of like how events are fired.
So, to render an image on the GBA, you did a few things.
1) Wait until the VBlank. This is the resting time in between drawing images to the screen, and it is the only time it is safe to alter data in the video buffer.
2) Set a bunch of flags at a specific address in memory to configure the graphics mode of the GBA. These flags were just binary values stored as integers.
3) Copy a big array of bits that contained color information, a bitmap essentially, into the video buffer. The video buffer was, you guessed it, a special location in memory.
4) Wait until the VBlank ends and the device starts rendering.
Then, computer engineering magic happens. Bear in mind I am not a computer engineer so I'm going to give a really abbreviated and sketchy version of this process.
1) The GBA has some sort of rendering chip on it that is semi-programmable. It checks the rendering mode flags you've set to see how it should interpret the bits in the video buffer
2) It starts iterating through the data in the video buffer and converting that information into another, universal bit representation of color values for each pixel on the screen. This is interpretation, just like how someone says "street" and you know what the physical object is. This takes an arbitrary string of bits, and converts them into something meaningful that can do real work.
3) The interpreted video data is passed off to another piece of physical hardware that reads in the universal color information, then produces electrical signals that cause the LCD pixel to alter itself so it only refracts a specific color of light. This is straying into the realm of physics.
Steps two and three might happen on the same bit of hardware, I don't know for sure.
Anyway, that's generally how a simple computer gets from variable->bits->light coming out of the screen. PC's and modern game consoles are way, way more complex and have many layers of abstraction between you and light coming out of the screen. However, you don't need to worry about it. Computers are mad complex, and they perform simple logic at a speed that is basically unfathomable to humans. You'll go nuts trying to envision the whole thing. There are other people who have spent many, many years making sure that all you need to do in order to make a pixel turn red is call some function like DrawPixel(1026, 623, Color.RED).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
