Hello. I know this sounds like a stupid question, but as someone who wants to learn game programming and who is already moderately skilled in programming, hear me out.
The basic problem is that I want to learn game programming, but don't know where to start because I don't know what it even *is*. For example, would you say that someone who knows how to use GameMaker to literally drag-and-drop functionality into their game actually knows how to program games? No, you wouldn't. Of course, this problem goes both ways with someone who is knowledgable about programming, but honestly doesn't know how to make a single colored pixel move across the screen.
Let me make a less exaggerated example. Let's say there's a magical API out there that allows a programmer to program games from the perspective of a game designer rather than a computer programming. So, instead of dragging and dropping functionality , you can program it in (like GameMaker, but more powerful). Would you say that such an individual knows how to program games? I, personally, wouldn't. But, then again, I don't actually know what game programming *is*.
I hope that this has explained my point sufficiently.
So, what *are* the building blocks of game programming? Where does someone go if they want to learn concepts and theory instead of just raw practicality? I'm not as concerned about being able to make games quickly, or even make them at all (let alone good ones) so much as I am with understanding and being able to play around with the concepts. I want to understand the building blocks, then work my way up. Where would I go to start learning *that*?
What *is* game programming?
I would say that the building blocks are pretty much the same as any other project. Think of creating a normal project which has deadlines, requirements, needs to have certain functionality and the list goes on. The same stands for GAME programming. A game however simple it may be will have deadlines requirements and will be required to have a certain level of functionality.
http://en.wikipedia.org/wiki/Game_programming < Decent Description of game development.
http://content.gpwiki.org/index.php/How_do_I_get_Started < Pretty much the same just more detailed.
http://gamesfromwithin.com/so-you-want-to-be-a-game-programmer < Probably the best so far.
I still stand by my statement and say: It's the same as any normal software project just headed in a different direction with different tools.
http://en.wikipedia.org/wiki/Game_programming < Decent Description of game development.
http://content.gpwiki.org/index.php/How_do_I_get_Started < Pretty much the same just more detailed.
http://gamesfromwithin.com/so-you-want-to-be-a-game-programmer < Probably the best so far.
I still stand by my statement and say: It's the same as any normal software project just headed in a different direction with different tools.
I would say that in a nutshell, game programming consists of doing simulations. If you can program a simulation of a ball bouncing, you can also program games.
A ball-bouncing simulation in it's most basic form consists first of all of a description of the current state of the system: The location and velocity of the ball and the position of any walls. Then at regular intervals, the state of the system is updated by moving the location of the ball a tiny bit according to its velocity and time elapsed since last update, taking any necessary collisions with walls into account by reversing the velocity of the ball along the normal of the wall. After that the walls and the ball at it's current location are drawn to the screen.
The repeated application of updating the state of the simulation and drawing will make the apperance of a ball bouncing around on the screen.
Now add in an additional step of sampling an input device and using that information for moving the walls in the simulation and you've essentially created a very basic pong game.
Any other game will at some abstract level also consist of those same concepts
The only thing that differ pong from the latest multi-million dollar title is the scale and complexity of how those things are done and the specifics of what is stored in the state and what rules are being applied when updating.
A ball-bouncing simulation in it's most basic form consists first of all of a description of the current state of the system: The location and velocity of the ball and the position of any walls. Then at regular intervals, the state of the system is updated by moving the location of the ball a tiny bit according to its velocity and time elapsed since last update, taking any necessary collisions with walls into account by reversing the velocity of the ball along the normal of the wall. After that the walls and the ball at it's current location are drawn to the screen.
The repeated application of updating the state of the simulation and drawing will make the apperance of a ball bouncing around on the screen.
Now add in an additional step of sampling an input device and using that information for moving the walls in the simulation and you've essentially created a very basic pong game.
Any other game will at some abstract level also consist of those same concepts
- A description of the state of the game
- Sampling of input
- Updating the state according to input and rules of the game
- Rendering the state to screen and other output devices.
The only thing that differ pong from the latest multi-million dollar title is the scale and complexity of how those things are done and the specifics of what is stored in the state and what rules are being applied when updating.
I'm going to sound like a total smart aleck, but I'm not being one when I say this: game programming is programming games. It's not some magical world separate from programming in general.
Programming games. Practice, practice, practice.
University. But not to some "game making university." I mean a proper one, where you'll likely major in Computer Science (or Computer Science with some emphasis, which could be a gaming emphasis).
If you know how to program in general, it's easy to get into game programming, because it is programming.
So, what *are* the building blocks of game programming?
Programming games. Practice, practice, practice.
Where does someone go if they want to learn concepts and theory instead of just raw practicality?
University. But not to some "game making university." I mean a proper one, where you'll likely major in Computer Science (or Computer Science with some emphasis, which could be a gaming emphasis).
If you know how to program in general, it's easy to get into game programming, because it is programming.
I will say that GameMaker is hardly drag and drop and that it is game programming. I think some people have this notion that some programming languages are "real" and that if you don't use those "real" languages then you are not a "real" programmer.
I disagree. For a number of reasons Game Maker is not a great example. For one the GML language has full programming support (variables, loops, you name it). Even the event based system relies on programming logic containing the "visual" equivalents of setting variables and program flow control. Very little functionality in Game Maker can be "dragged and dropped" with no implementation of logic.
So in that regard I would have to say someone who knows how to use Game Maker is certainly able to program games.
I can hear the people saying "but it's not 'REAL' programming" what is real programming? What makes a real programmer? I work professionally as a software engineer and I have absolutely no idea. To me a real language is a language that you can use to accomplish the task that you set out to do. If I set out to make a game in Game Maker, and I am able to complete that game and instruct the computer how to perform my game's logic, then to me it is a real language.
I will echo the statement that games are like any other type of program. You take input, process that input, and display an output. Many of the concepts are shared between games and other types of applications. You will have the same issues with working with files, databases, interprocess communications, data structures, ect. Typically games involve a higher degree of graphics output and more multimedia output than most other types of applications require.
Modern AAA games are highly complex systems that typically use many different engines and middlewares to create the game world.
So yes game programming is *programming*. In my mind *programming* is telling the computer to do stuff and having it do that stuff. It doesn't make a difference to my definition if I am writing a bash script, or a 10,000 line C++/Qt application. Getting the task done is what matters.
I disagree. For a number of reasons Game Maker is not a great example. For one the GML language has full programming support (variables, loops, you name it). Even the event based system relies on programming logic containing the "visual" equivalents of setting variables and program flow control. Very little functionality in Game Maker can be "dragged and dropped" with no implementation of logic.
So in that regard I would have to say someone who knows how to use Game Maker is certainly able to program games.
I can hear the people saying "but it's not 'REAL' programming" what is real programming? What makes a real programmer? I work professionally as a software engineer and I have absolutely no idea. To me a real language is a language that you can use to accomplish the task that you set out to do. If I set out to make a game in Game Maker, and I am able to complete that game and instruct the computer how to perform my game's logic, then to me it is a real language.
I will echo the statement that games are like any other type of program. You take input, process that input, and display an output. Many of the concepts are shared between games and other types of applications. You will have the same issues with working with files, databases, interprocess communications, data structures, ect. Typically games involve a higher degree of graphics output and more multimedia output than most other types of applications require.
Modern AAA games are highly complex systems that typically use many different engines and middlewares to create the game world.
So yes game programming is *programming*. In my mind *programming* is telling the computer to do stuff and having it do that stuff. It doesn't make a difference to my definition if I am writing a bash script, or a 10,000 line C++/Qt application. Getting the task done is what matters.
In addition, there isn't some UPS truck (to borrow from someones' post) that delivers your "Official Game Programmers' Certificate".
What matters is shipping finished, feature-complete products. If you can do that in a game maker, then seriously consider using a game maker.
What matters is shipping finished, feature-complete products. If you can do that in a game maker, then seriously consider using a game maker.
I see where your confusion is coming from.
A game programmer doesn't make a full game. It only makes a part of the game. The programming part.
Using tool like Game Maker eases the programming part, but then you turn into a game designer.
A fully finished game needs a 2D Artist, a 3D Modeller, an animator (3D or 2D), a game designer, a programmer, a sound designer, a musician, and may even need a script writer (if your game has a story). Depending on complexity, some games may need more (i.e. Assassin's Creed employed Ph D. historians, the game Journey had counseling with a psychologist)
But what about those awesome & popular indie games made by one or two persons?
I said you needed at least artists, designers and programmers. But I didn't say they were all different persons. Those were all different skills. Those Indie devs just put a different hat on. They had very strong points in a few areas (usually programming or 2D art) and learned the skills they lacked trying to do their best on the other areas.
Those with strong programming background enforce the techie part of a game (i.e. Minecraft) while artists use available tools (like UDK, Unity, Source Engine) to compensate, while making stunning visuals (i.e. Dear Esther).
And they were all game designers. A game designer thinks which mechanics will work best, why a game is fun or not, what makes addiction. Should the player have 3 lives? or a lifebar? Should the player acquire new skills by leveling up? or by progressing through story? or by <insert your method here>? how can I present a challenge to the player? how can I make him think to solve a puzzle? Those are all designer questions that are neither art (in the traditional sense) nor programming.
But if you think you can make a game by being a game programmer, then you'll never finish it. By the end of the day you'll have a really nice executable that runs very fast, no crashes, no bugs.... and no fun. It will be an incomplete game.
It's as if you want to build your own car from scratch. You're a mechanic, but you don't want to do the electrician's job and the painter's job. You'll end up with a very nice car engine, but it's not a car.
A game programmer doesn't make a full game. It only makes a part of the game. The programming part.
Using tool like Game Maker eases the programming part, but then you turn into a game designer.
A fully finished game needs a 2D Artist, a 3D Modeller, an animator (3D or 2D), a game designer, a programmer, a sound designer, a musician, and may even need a script writer (if your game has a story). Depending on complexity, some games may need more (i.e. Assassin's Creed employed Ph D. historians, the game Journey had counseling with a psychologist)
But what about those awesome & popular indie games made by one or two persons?
I said you needed at least artists, designers and programmers. But I didn't say they were all different persons. Those were all different skills. Those Indie devs just put a different hat on. They had very strong points in a few areas (usually programming or 2D art) and learned the skills they lacked trying to do their best on the other areas.
Those with strong programming background enforce the techie part of a game (i.e. Minecraft) while artists use available tools (like UDK, Unity, Source Engine) to compensate, while making stunning visuals (i.e. Dear Esther).
And they were all game designers. A game designer thinks which mechanics will work best, why a game is fun or not, what makes addiction. Should the player have 3 lives? or a lifebar? Should the player acquire new skills by leveling up? or by progressing through story? or by <insert your method here>? how can I present a challenge to the player? how can I make him think to solve a puzzle? Those are all designer questions that are neither art (in the traditional sense) nor programming.
But if you think you can make a game by being a game programmer, then you'll never finish it. By the end of the day you'll have a really nice executable that runs very fast, no crashes, no bugs.... and no fun. It will be an incomplete game.
It's as if you want to build your own car from scratch. You're a mechanic, but you don't want to do the electrician's job and the painter's job. You'll end up with a very nice car engine, but it's not a car.
"magical API" or not if you make a game through the use of a programming language(not only scripting unless it's the primarily used language) then y
It's so strange to me that people think there is fundamental difference between programming and game programming.
Why do people even with programming experience think that?
Graphics make them think that?
I have been always wondering.
Why do people even with programming experience think that?
Graphics make them think that?
I have been always wondering.
It's so strange to me that people think there is fundamental difference between programming and game programming.
Why do people even with programming experience think that?
Graphics make them think that?
I have been always wondering.
It's the intricate interaction between many parts of a modern game that's complicated, second only perhaps to an OS.
Old games were not that difficult. You had a static or barely animated intro screen with a bit of text saying press fire to start game. If the user did that simple loop would have been exited and a new one entered that was equally simple. If the player died usually all movement stopped and a simple game over screen appeared and then it's back to the intro.
In a modern game you would have gamestates that blend into each other seamlessly. You leave the intro with a crossfade between it and the overworld. All the while the music crossfades too. That means both loops get intertwined. An action performed in one castle can affect an event in another part of the game (although that part isn't truly complicated but don't lose track)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
