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.

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 understand where you're coming from. We've all been at the beginning, and a lot of coding seems really dry and not-fun, and especially when you're forming a concept of what to code and how to code, it can be hard to see how programming a pong-clone can lead to understanding how to make a bigger, more-close-to-what-makes-you-excited game. Pong, basic though it may be, deals, fundamentally, with collision, input-handling and output. It also requires a basic gameloop, so it should teach you that, too. Those are not trivial by any means, in fact, that's most of what a lot of games are. Expanding pong, you can include things like score keeping, score saving (for high-scores and the like) and even rudimentary AI.

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.

You don't need to worry about the trivial things like how you get your time for your update loop yet. A while back there was a big ruckus about fixed-timestep gameloops and there I was with my crappy little game running a common, crappy variable-timestep gameloop. It was really easy to get bogged-down in the do-I-change-it-or-don't-I mindset but ultimately it was a relatively small change that I was able to make after I'd figured out a little bit more about how I would do it. In the meantime, though, running my game on a variable-timestep didn't actually prevent me from progressing with my logic code or anything else. In the end, if you decide you want to change how you get your time for your gameloop, you'll be able to figure out how to change it without messing everything else up.

My only question is, how does a game work, I mean REALLY work?

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.

I think one thing that gets a lot of us is understanding what you need to know and what you don't. It doesn't matter how much you know about TCP and UDP (for making games) if you don't know how a gameloop works.

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 should not aim for a "first time right" shot, imho.

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.

We are very good at hiding complexity for the user. With a physical object, eg a bridge, it is plainly visible how it is structured, it just looks impressive even from a distance. On the other hand, take a C++ compiler. You start it, it runs, and .... the prompt returns with a new file within 3 seconds. You never see the big data structures and the complicated computations it does to generate optimized code. No wonder people think programming is easy :)

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.

Then start with a text-based 'guess the number', that's about as simple as it gets. It's a handful of lines of code if you let it, or a full blown big project if you let it.

After that, a text-based tic tac toe, where you redraw the board by dumping out a few lines of text after every move.

Text based 'ski' game where you have two bars indicating the edge of the board and a mark in the middle the player moves.

Text based adventures, moving from room to room and doing the steps to solve the game.

Then move up and up and up as your experience increases.