First off, a quick disclaimer: Apart from playing games digging through some source code, and some totally-for-beginners coding tutorials so I can attempt to read source code; I'm pretty much clueless when it comes to game development.

Game design isn't a problem - my friends have plenty of insight into what makes a good game to play, and I can come up with ideas for features and functionality from dawn 'til dusk.

I've tried the approach of start with simple games - I made a minesweeper clone once, which worked even if if was probably the most inefficient way to do it ever and taught me to hate Visual Basic - but this approach hasn't worked for my learning style.

What I really want to know is theory: I'm better at trying to grasp the overview and breaking it down into principles to test-code, than trying to come up with simple things to program. I'm sorry, but I'd rather read about MMO architecture than figure out how to make yet another newbie version of pong, and I've had more than my fair share of people telling me this is the wrong way to go about it - I've tried learning the way they did, I really did try.

I do understand that learning to program any decent game, from scratch or using software, is a big investment of time and effort. I have at several decades ahead of me to chuck at this, that's not the issue. I want to become a game developer, whatever it takes, but I do not want to be employed as one - too many horror stories.

My problem is sourcing articles about the theory of game programming. I've bought books - most of them have coding examples that don't work when you copy them out, and they stop well before any complex topics approach the horizon; a total waste of money, and usually out of date so fast, it's scary. Stuff that's not for beginners simply tells you to go away and come back when you know something, which is a very frustrating attitude.

I'm looking for pure theory, not coding examples or walkthroughs - those I can find. I don't have specific questions, I don't know enough. And I don't know where to start.

I occasionally manage to stumble across articles related to game development, such as the theory of the golden ratio applied to random scatter procedures, but as fascinating and as welcome a challenge as they are to grasp, they aren't attached to any other articles.

Game development is a huge topic, but nowhere I have found gives a good overview of the structure of a game, just sites under development, one-off articles and incomplete wikis. Everything is bottom-up and specific questions with contradicting technical answers that are more opinion than fact - such as currentTimeMillis() vs nanoTime() in Java, and I haven't even figured out how the main loop executes yet.

I've come here to plead, to beg on bended knee, for some decent pointers to places where I can start to get a feel for how a BIG game is put together, so I can grasp the internal structure of games and how different teams approach coding them. I need to find a way to make my learning style work for me instead of against me. How small games work isn't particularly helpful, they're just a Hello_World upgrade really, but beggars can't be choosers.

I'll willingly learn anything; from how NAND gates make everything in a computer work, to the most abstract mathematical principles, from wireframing and animation and texturing, to the production of synthetic sound, from binary and hexidecimal machine code, to electronically wiring up custom input devices, from physics engines to AI. But right now I'm not even completely sure what a socket is, and I've only just learnt the difference between TCP and UPD in some haphazard attempt to understand any topic I find posted which might be useful someday. I don't know the right keywords to search for, I don't have even a half-decent idea of how a game runs, and I don't have the option to throw a small fortune at this.

I could fill a whole forum with newbie questions, such as what is a sprite, or how do I write usernames and user-scores to a file. But those are not the answers I need. Ignoring the fact that so many people have asked them before, it's just not a good policy for me to have to ask questions like that, or I'd be pelting people with these questions non-stop because I'll never run out.

My only question is, how does a game work, I mean REALLY work ? And I know it's too big a question to answer here. But any links to anything even vaguely interesting - and every topic is interesting to me except people squabbling over tiny details - would be VERY much appreciated.

I do have an answer, but it wouldn't be more than a single post, mostly, so I am not sure I am actually answering the question you asked.

Here goes anyway:

You want to have a high level description of a game.

At the very high level of abstraction, a game is a program that produces output. To be precise, mostly graphical output. It's dumping zillions frames at a rate of 10-60 frames a second onto the screen. These frames slight differ in layout and position of all the elements, and as such, we perceive it as an animation.

Besides the output, the second differentiating element is user interaction. The user can tell the computer to change some animated elements in real time, while the frames are being pumped out. If the computer does that in the right way, the user feels he's part of the animation rather than just watching a pre-defined sequence (that is, watch a movie).

These concepts drive you to the basic game loop, a cycle of processing user input and generating another frame to display.

A big puzzle in creating this output is how to generate these frames in a convincing manner (and efficiently as well, since all computer resources are finite). In general, a lot f things can be moving at the screen at the same time. There may be things going on that are not even visible currently, but that will affect future animations.

This is where a world model comes in. An administration of what "exists" in the game, where it is, what it is currently being done, and so on. It is not too hard to generate animation frames from such a world in a convincing way.

Since the animations should interact with the user, they synchronize with the real time of the user. The world thus also synchronizes, as it forms the base of generating frames. The game loop part "generating another frame" thus gets split into two steps: First update the world model for the time of the next frame, then generate the graphical output for the screen.

Simulation games show this very well, they literally have a vast world model, and progress of time.

Does this answer your question?

It certainly starts to answer my question - I now know more than I did before. No answer is ever going to be big enough to count as a full answer, but every answer begins somewhere, and for that beginning, I thank-you !

What I really want to know is theory: I'm better at trying to grasp the overview and breaking it down into principles to test-code, than trying to come up with simple things to program. I'm sorry, but I'd rather read about MMO architecture than figure out how to make yet another newbie version of pong, and I've had more than my fair share of people telling me this is the wrong way to go about it - I've tried learning the way they did, I really did try.

You're asking for both ends of the spectrum at once, I think.

Theory is usually the smallest components. Theory explains all the details with a fine brush, like computer science aspects: the data structures, the fundamental algorithms, the most basic concepts.

Abstractions are usually the larger components. Abstractions cover broad topics with a wide brush, abstractions like design patterns, architecture patterns, abstract servers, abstract clients, abstract protocols.

Yes, you will need to learn both. The big parts are composed of all the little parts. If you only know the abstractions they will be difficult to apply if you struggle with the theory. If you know the theory already then good for you, keep going through the abstractions. But I'll join others in cautioning against not learning your theory, not learning your fundamentals. If you have an abstract idea that discusses needing to sort, you better know 20 different ways to sort and not just your library's sort() method so you can pick one best suited to the problem. If you have an abstract idea calling for a collection of items, you better have at least 10 different data structures in mind so you can pick one that fits your data space, not just the choice between a dynamic array or linked list.

I'll willingly learn anything

Probably the fastest way to get that is a computer science degree, coupled with extensive study on your own.

There really isn't a theory to game programming. It's principles are way too similar to software development, software engineering, computer science, and discrete math. The fastest way as mentioned by frob is to simply go to college for Computer Science. And once you go through enough classes, you will begin to understand some things. But you might not be able to read code from things like Unreal. That is normal due to Unreal being built by hundreds of people with abstractions all over the place.

Though a concept I should stress, is that it's mostly about data structures with rules.

A navmesh is a datastructure built of polygons. Polygons must be built from three or more connected vectors of space R^2 or R^3.

A model is a data structure of polygons built of vectors.

An entity is a data structure built of infinitely many unique predefined components.

Thank-you all, for your replies. To address a few points:

You're asking for both ends of the spectrum at once, I think.

I was working on the mathematical terminology of applied and theoretical. But yes, I do need both ends of the spectrum. It's the lack of one end that's been causing me a problem.

Probably the fastest way to get that is a computer science degree, coupled with extensive study on your own.

I have had a look around since you posted, and so far I have found this http://www.infoworld.com/article/2614635/application-development/-200k-for-a-computer-science-degree--or-these-free-online-classes-.html which seems promising.

Pong, basic though it may be, deals, fundamentally, with collision, input-handling and output.

At this point, I realise that it's not so much that pong is so basic as to be boring, it's that I wouldn't know where to start as much as anything. Yes I could go get a recipe off a tutorial, but it's the fact that I can't imagine how to do it at all that makes it a boring exercise of copy-the-coder. That pong could be both seemingly too simple and too complicated at the same time is unnerving.

I think this Youtube channel is awesome

Agreed, it looks VERY promising. TY

That's a big question. I think this Youtube channel is awesome for a lot of things game-related. It's probably not going to answer many of your questions right now, but he talks about a lot of what goes into programming a game.

Just to clarify for others. Watched in order; this is a series of videos teaching game programming in the language of C, in a way the broadcaster hopes will be accessible to everyone including raw beginners, and doesn't limit itself to low-level functionality.

I am wondering what people think of this as an approach to learning game programming, as I have never heard someone on a forum recommend beginning with C, and yet as I understand it, all other program development languages are written in C.

Apologies if this should be posted as a separate thread.

At this point, I realise that it's not so much that pong is so basic as to be boring, it's that I wouldn't know where to start as much as anything.

You're trying to solve a problem you don't understand. It is just impossible to design a solution for something you cannot grasp in it entirety in all its details.

There are software design methodologies, requirement analysis techniques, and so on, but at the end of the day, the biggest influence in getting a good design is experience. Someone who has been there before, and knows what to expect.

Even then, every program is different. Small changes in requirements can have a huge impact in the entire design of a program.

The solution to this problem is iteration. Don't aim for a single perfect build. Instead, build multiple versions, or build in an incremental fashion. When you hit a problem, rethink the design, then adapt to it. For smaller changes, refactoring works. For big changes, just starting again with the new knowledge may be faster.

The latter of course takes loads of time. In a commercial context it's often not feasible, but building the entire thing 2 or 3 times is a great way to stream-line the design and implementation of an application if you have enough time.

It's like the first project plan or the first financial budget. It never flies, but making it builds experience, and points out trouble spots, so you can improve in the next iteration.

This suggests you can start anywhere with Pong. Build experimental versions, eg the display, add movement, add score, etc. If things don't fit, rewrite, refactor, or start again (you can often re-use parts you already have from the previous experiment). Don't be afraid to throw away code, code isn't important, you can write the whole thing again in a day.

What matters is the knowledge that you get, the knowledge how to structure the program. That is the real goal. From a given structure, it's easy to recreate the code.

That pong could be both seemingly too simple and too complicated at the same time is unnerving.

At this point, I realise that it's not so much that pong is so basic as to be boring, it's that I wouldn't know where to start as much as anything. Yes I could go get a recipe off a tutorial, but it's the fact that I can't imagine how to do it at all that makes it a boring exercise of copy-the-coder. That pong could be both seemingly too simple and too complicated at the same time is unnerving.