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.

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

• 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.

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.

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.

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 ? 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.

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)

I don't think games are more complex than other applications. It's just the emphasises are elsewhere.

If a game crashes, the user is pissed then she restarts. If a company's main management system crashes, catastrophe.
Applications can have quite complex user interfaces, much more complex than games of game (content) making tools.
Parametric 3D design software is one of the very few programming areas where I donn't have the slightest idea how the hell they work.
Etc.

It's really the graphics and the audio that seems to be significantly more complex than other applications. And that applications (other than games) is a much broader field than game programming, so it's hard to realize the complexity of other applications.

game programming is the following:

• graphics programming
  
  
  
  • GPU programming
    
  • usage of libraries
    
  • manage large structures to be drawn efficiently using algorithms
    
  • networking
    
    
    
    • fast
      
    • huge amount of players
      
    • efficient servers
      
    • physics
      
      
      
      • usage of libraries
        
      • do it (or parts of it) on your own
        
      • artificial intelligence
        
        
        
        • heuristics
          
        • machine learning
          
        • pathfinding
          
        • game logic
          
          
          
          • scripting of events
            
          • game rules
            
          • input devices
            
            
            
            • for example interpret the touch events on iphone
              
            • game controller
              
              
              
              • game menus
                
              • level management
                
              • load / save
                
              • make game / levels upgradable (plugins)
                
              • integrate social networks
                
              • sound (do not know details)
                
              • possible write a game editor, where you can build your levels
                
              • security in the case of networking
                
              • ...
                
                all this can be covered by a game engine. you an do a game without programming. or you can do a lot without programming, and just write some scripts to extends the functionality of the game engine. then you have to program only a bit, but still understand a lot.
                
                and a lot more...
                
                important: game programming is normal programming. but, it needs some understanding, on how you do certain things best for games. so the code at the end is normal programming. but how to do it, is important!

One thing I have noticed though is that game programming in general tends to require a bit more knowledge in the mathematics/physics department than the average application. The mere act of getting an object to move around on the screen tends to require some knowledge of linear algebra and elementary physics. 3D games tend to require a considerable knowledge of linear algebra as you deal with matrices, vectors, quaternions, ect to a considerable degree. Even if you use a 3D engine with built in physics capability, some concept of what "mass" is can help (Just throw some more higgs bosons in there)

I think drop the word "game" from "game programming". Game programming is nothing but programming. You're just implementing an aspect of the game design process. Designing a game, then, is something else. Anyone can be a game designer.

If you want to learn to program a game, come up with your game idea first. Then find a means to get it made. You can even make a game with Javascript, CSS, and HTML, the most cross-platform languages right now with some limitations. Webpages have made text-based "go to page" adventure games incredibly easy to make. That's a start.

Then, as your game demands more features and gimmicks, you might want to start taking control of more aspects of the internal implementations. This is when you have to learn VB, C++, C#, whatever. It would then be more than just learning the language, you have to understand the concepts behind programming (object oriented programming, organization, abstraction, encapsulation, etc), otherwise you'll be making clunky, inefficient, brute-force software.

Like most games, start with a piece of paper and a pencil.

Drag and drop or typing text? No difference really, both can achieve programming,. games or otherwise. Operator stacking, wiring nodes, punch cards?

Since the output is==> a game you are programming a game,.

I have a dream/idea about a pure symbolic programming language that IS a game., you just reminded me about that one.

Excellent. Many interesting ideas, everyone. This has been very helpful and given me some interesting things to think about.

To clarify and respond to a few things...

Some of you seemed to think that I want to "make a game". I actually don't. I'm much more interested in programming rather than making a game (though I am also a gamer). I thought game programming would be a good avenue to provide programming challenge since it seems so complicated and varied. I'm more interested in low-level implementation details rather than high level usability.

Some of you simply described game programming as "programming". That's a good point with a lot of truth in it that I hadn't thought of before, but I disagree and it doesn't provide the information I'm looking for. From what I can see, game programming requires an additional set of skills and knowledge that most programmers fresh out of college don't have. A simple example would be The Game Loop. While loops are nothing special, the concept of The Game Loop seems to be something unique to game programming. The use of math in games programming would also be another example of "game programming" versus "other programming". Advanced manipulation of graphics and object interact interaction would also be examples. Perhaps this is just an area with many shades of grey? The more I ponder your responses the more apparent this seems to me.

Some of you simply described game programming as "programming". That's a good point with a lot of truth in it that I hadn't thought of before, but I disagree and it doesn't provide the information I'm looking for. From what I can see, game programming requires an additional set of skills and knowledge that most programmers fresh out of college don't have. A simple example would be The Game Loop. While loops are nothing special, the concept of The Game Loop seems to be something unique to game programming.

It's not unique to game programming. The main game loop is synonymous with any program's main event loop, and most programs have a main event loop.

The use of math in games programming would also be another example of "game programming" versus "other programming".

Not all programs are math heavy, but game programming isn't always math heavy, and there are plenty of non-games that are math heavy. Video and audio transcoding (which is my line of work) is quite math heavy and relies a lot on signal analysis and signal processing. Linear algebra (which is typically used a lot in games) is used in faaaar more than just games.

Advanced manipulation of graphics and object interact interaction would also be examples.

I would agree that most programs in the world don't deal much with graphics and GPUs, but this also isn't really unique to game programming. Graphics programming is used a lot in the entertainment industry (gaming is a part of this, but so are things like movies (for special effects), etc.) and in simulations (to help researchers visualize what's happening).

I think you're getting slightly confused about game programming assuming that programming one game is just like programming another game, which isn't how it is. Not all games use advance graphics, not all games are heavy on the math, not all games involve networking, not all games use physics, etc. A particular game will use things from several different branches of research (like networking, physics, 3D graphics with object deformation, etc.). But the same is true for any program. Any particular program will use things from several different branches of research (video/audio transcoding uses things from signal/image analysis and processing, color space theory, parallelism and load balancing, etc.). Looking at these two examples, you might declare game programming completely different from regular application programming, but you've extrapolated too far. Programming this game compared to programming this audio/video transcoder might be different. But there may be a different game or program out there that shows similarities between the two.

Programming in general just takes things from different branches of research, combining them with some computer-science related algorithms and design patterns. If you know your algorithms and design patterns, it's easy to work on any program, provided you just learn a bit about the branches of research that program incorporates so you know how to handle them. Not all games take from the same branches of research that other programs (and games) do, but there's always overlap to find. The thing is that one particular game may take from a specific, unique combination of branches of research and combine them in a particular way, making that one game unique. But it doesn't make general game programming unique. Just that one game. The same holds true for any program.

Indeed, Cornstalks. That explained everything very well. This answered my question. Thank you very much.

I know this seems a bit far fetched but in my opinion game programming(or any kind of graphics stuff) is the ultimate art form. You can simulate everything from books to drawings to 3D sculptures to even the universe (yes I think it would be possible to simulate the universe, not real-time of course). It is the ultimate catalyst of creativity and can turn some sad/unimportant guy, who is unhappy with his life, into a might warrior or soldier in WWII. It can do things that you can't do in real life and visualizes the human imagination.
The possibilities are literally endless(well not literally but basically).
Would be awesome if I live to see the first mainstream quantum computer. Imagine being able to simulate the universe close to real-time speed. It would be impossible to simulate the universe real-time.
No homo.

yes I think it would be possible to simulate the universe, not real-time of course

Isn't this provably absurd and in violation of some fundamental laws regarding entropy, maybe second law of thermodynamics?